Znajdź zawartość

Dzisiaj chcielibyśmy skonsultować z Wami potrzeby jakie macie w odniesieniu do mechanizmu podpinania wiadomości do zamówień wysyłkowych oraz ofert internetowych. Mechanizm dostępny w Sello NX będzie oparty na regułach wiadomości oraz dodatkowo jest on dostosowany do pluginowości - co oznacza, że zastosowane rozwiązania nie są dedykowane pod konkretny serwis internetowy (Allegro, Erli itp) tylko są pewnymi narzędziami umożliwiającymi pracę z dowolnym serwisem. Wykorzystanie reguł wiadomości ma pewne konsekwencje, mianowicie takie, że mechanizm reguł w module poczty w nexo rządzi się pewnymi prawami, do których musimy się dostosować albo znaleźć pewne rozwiązania. Sam mechanizm ma możliwości większe niż w Sello1, gdzie był on zamknięty i bazował w zasadzie tylko na tym, że w tytule wiadomości email był numer ofert z allegro w nawiasie. Sello NX natomiast ma mechanizm wyciągania numeru zamówienia, numeru oferty oraz nazwy konta zarówno z tytułu wiadomości jak i z jej treści. Zastosowaliśmy tutaj mechanizm identyczny jak w przypadku wiązania towarów z ofertami i zamówieniami - czyli wyciąganie danych z wiadomości za pomocą tagów i modyfikatorów. Reguły wiadomości są takimi uproszczonymi automatami i w samej regule definiuje się warunki oraz czynności. W tym przypadku pojawią się nowe czynności podpinające zamówienie i ofertę, które w parametrach będą miały formuły tagowe, które z danego maila potrafią wyciągnąć informację o nazwie konta oraz numerze zamówienia. Daje to plusy takie, że mechanizm można za pomocą tych formuł wykorzystać w zasadzie do dowolnego serwisu i jego składni wiadomości. Bywa, że szablony wiadomości w serwisach się zmieniają z dnia na dzień, więc w razie takich sytuacji można będzie odpowiednio dostosować formułę, bez konieczności oczekiwania na poprawkę z naszej strony. Dodatkowo, w sklepach internetowych szablony są w reguły tworzone przez właściciela sklepu i mogą one mieć różną postać. Bez elastycznego rozwiązania nie dało by się tego rozsądnie zrobić. Oczywiście, napisanie takiej formuły nie jest zadaniem trywialnym, trzeba przeanalizować kod HTML wiadomości i odpowiednio użyć modyfikatorów do tagów, dlatego pluginy integracji będą dostarczać takie formuły domyślne, które będzie można po prostu wybrać z listy rozwijanej, a następnie w razie potrzeby dostosować do własnych potrzeb. Co do wizualizacji, to w dolnych zakładkach dodamy listę wiadomości (płaską, bez podziału na foldery IMAP), zawierającą wszystkie podpięte wiadomości wychodzące i przychodzące. Dodatkowo w oknie edycji zamówienia i oferty pojawią się widgety po prawej stronie, wyświetlające podpięte wiadomości z możliwością ich otwarcia z tego poziomu. Pytania, jakie do Was mamy, to: Czy wiadomości podpinane do zamówień, np. informujące o zakupie, wpłacie czy anulowaniu zamówienia powinny być także podpinane do oferty z której pochodzi zamówienie? Czy może są takie maile, które mają być podpięte również do oferty a inne nie. Czy powinny być dwie czynności: Powiąż z zamówieniem wysyłkowym i Powiąż z ofertą internetową czy jedna, która wiąże co się da wg dostępnych danych. Trzeba tutaj wiedzieć, że nie wszystkie maile dostarczają danych umożliwiających podpięcie np. oferty. mają tylko odnośnik do zamówienia i wtedy takie osobne reguły nie zadziałają. Czy korzystaliście w Sello 1 z funkcji podpinania wiadomości ręcznie pod wybrane zamówienia i oferty? W Sello NX korzystamy z modułu poczty Gestora nexo i ma on nieco ograniczone możliwości. Miedzy innymi nie ma możliwości podpinania wiadomości ręcznie do wybranych obiektów - jest to funkcja Gestora i bez niego nie zadziała. Czy korzystaliście w Sello 1 z funkcji usuwania podpięcia - np. w przypadku źle podpiętych automatycznie wiadomości?

Jest jakiś łatwy sposób lub klucz do nadawania uprawnień ? Pamiętam że jak robiłem użytkownikom Gestora do obsługi emaili i faktur i użytkownikom Sello 1 i faktur Subiekta to było bardzo dużo kombinowania bo co chwila brakowało jakiegoś uprawnienia żeby zrobić fakturę. Klucz logiczny albo wskazówka coś w rodzaju zeby zrobić fakturę z sello NX trzeba dać uprawnienia do tego tamtego i jeszcze tego. Żeby dać uprawnienia do wysatwiania aukcji to do tego a do samej edycji akcji to do tego .....

Zakładam ten wątek jako propozycję wdrożenia przez zespół Sello NX modułu kompletacji zamówień na kolektorach danych Przy większej skali wysyłek kompletacja na podstawie papierowych zestawień znacząco ogranicza wydajność i zwiększa ryzyko pomyłek (nie wspominając o ilości gromadzonej makulatury). Naturalnym kierunkiem rozwoju wydaje się więc obsługa procesu kompletacji bezpośrednio na kolektorach, zintegrowana z Sello NX. W skrócie, minimalne wymagania funkcjonalne takiego modułu mogłyby wyglądać następująco: Pobieranie listy zamówień na kolektor Możliwość pobrania z Sello NX listy zamówień przeznaczonych do realizacji, z podstawowymi informacjami o pozycjach (SKU, EAN, ilości, Lokalizacja magazynowa). Przydzielanie zamówień na nośniki/koszyki Obsługa pracy na nośnikach (koszykach, wózkach) z dwoma trybami: – zbieranie wielu zamówień na jeden zbiorczy nośnik, – ograniczenie do ustalonej liczby zamówień przypisanych do jednego nośnika. Walidacja poprawności kompletacji Kontrola zgodności kompletacji z zamówieniem, w tym: – odchylenia ilości, – brak produktu, Zwrotne oznaczanie statusów w Sello NX Po zakończeniu kompletacji możliwość automatycznego oznaczenia zamówień w Sello NX jako: – skompletowane, – częściowo skompletowane (z informacją o brakach / różnicach). Przekazanie skompletowanych zamówień do pakowania Integracja z modułem pakowania, tak aby można było „wczytać” nośnik z kompletem zamówień i obsłużyć je na stanowisku pakowania (np. poprzez zeskanowanie nośnika / koszyka). Myślę, że taki moduł byłby realnym wsparciem dla firm obsługujących większe wolumeny zamówień i mógłby znacząco uporządkować proces magazynowy: od pobrania zamówień, przez kompletację, aż do pakowania. Zachęcam innych użytkowników do dopisania swoich potrzeb i scenariuszy – im więcej głosów, tym większa szansa, że taki moduł trafi na listę priorytetów rozwoju Sello NX.

Witajcie. Pracujemy obecnie nad funkcją list wysyłkowych znaną z Sello 1 i chcielibyśmy poznać Wasze zdanie, potrzeby, przypadki użycia, tak aby skroić ją na wymiar i dostosować do potrzeb. Wstępne założenia: Lista wysyłkowa (dalej LW) będzie zakładką w module zamówień wysyłkowych Jej główne przeznaczenie to grupowanie paczek z zamówień, w celu zapanowania nad ich nadawaniem LW będzie umożliwiała: drukowanie zamówień wysyłkowych (czyli listy magazynowej) tworzenie/drukowanie etykiet kurierskich zamawianie podjazdu kuriera dodawanie i usuwanie paczek z wybranych zamówień wysyłkowych LW będzie miało pola: Symbol/Numer powiązany z numeracją, którą można zmienić, domyślnie LW 1/DPD/2025 stemepelk integracji data utworzenia listy data wydania paczek kurierowi pola informacyjne związane z podjazdem kuriera LW będzie się tworzyła automatycznie po wybraniu operacji zamówienia podjazdu kuriera z zaznaczonych zamówień wysyłkowych - jeśli ktoś nie chce korzystać z LW, ale mimo wszystko potrzebujemy przechowywać gdzieś informacje o zamówieniu kuriera. LW będzie miała listę paczek na niej umieszczonych LW będzie tworzona w kontekście kuriera. Jeśli macie jakieś potrzeby, które tu nie zostały wypisane, albo chcecie opisać jak pracujecie obecnie np z listami wysyłkowymi w Sello 1 itp. to czekamy na Wasze zdanie :).

W wersji 61 planujemy dodać (a w zasadzie rozszerzyć) możliwości korzystania z szablonów dla ofert internetowych. Chcielibyśmy pokazać jak to będzie działać, skonsultować, zebrać pomysły, uwagi oraz życzenia od Was co do przedstawionego modelu, możliwości itp. Na wstępie od razu dodam, że szablony w Sello NX nie będą kopią szablonów z Sello 1 i ich zasada działania będzie inna, co wynika z różnic architekturalnych obu programów, innych nieco potrzeb i chęci rozwiązania wielu problemów o bardzo zbliżonym podłożu. Założenia wstępne szablon umożliwia ustawianie wartości pól w ofertach tworzonych jak i istniejących istnieją domyślne szablony, stosowane automatycznie w różnych scenariuszach (np. dodawanie nowej oferty, powielanie, wystawianie towaru w ofercie, importowanie towaru do oferty) domyślne szablony pozwalają ustawiać oraz zerować wybrane pola w szablonach można używać tagów, aby pola w ofertach mogły być uzupełniane danymi wyliczanymi lub pobieranymi dynamicznie np. z towaru minimalizacja liczby potrzebnych szablonów przeniesienie ustawień domyślnych, rozsianych w różnych miejscach programu do szablonów możliwość tworzenia własnych szablonów i stosowania ich w wybranych miejscach przed wykonaniem szablonu własnego, zawsze stosowany jest szablon domyślny dla wybranej funkcji Jak było w Sello 1? Szablony w Sello 1 były zapisane jako specjalny typ oferty (aukcji), co skutkowało tym, że okno szablonu było bardzo podobne do okna oferty. Niektóre pola umożliwiały stosowanie dynamicznych wartości w dość ograniczonym zakresie, niektóre pola (głównie tekstowe) pozwalały użyć tagów. Rozwijanie przez nas ofert/aukcji każdorazowo wymagało także rozwijania m.in. obsługi zmian zbiorczych, zmian w ofertach trwających, szablonach, zmian zbiorczych w szablonach a wszystko to dodatkowo w kontekście serwisu internetowego Allegro (gdy Sello obsługiwało serwis eBay, pracy było 2x więcej). Szablony można było przypisać do towarów i wystawiać z nich oferty, ale często wymagało to tworzenia bardzo dużej liczby szablonów - minimum tyle, ile kategorii w Allegro, w których były wystawiane oferty. Jak będzie w Sello NX? Szablony w Sello NX zostały już dodane kilka wersji temu, ale jedyną ich funkcją była możliwość ustawienia domyślnych wartości dla nowo utworzonych ofert i były w zasadzie dodane bardziej na zasadzie sprawdzenia, czy takie podejście ma sens. Mianowicie, szablony w Sello NX bazują na zmianach zbiorczych ofert i można powiedzieć, że są to takie presety/gotowe zestawy zmian, aplikowanych w różnych scenariuszach pracy z towarami i ofertami. Daje nam to taką korzyść, że implementujemy funkcję raz, a może być stosowana w dwóch miejscach: jako zmiana zbiorcza oraz jako zmiana w szablonie. Nie wszystkie zmiany zbiorcze natomiast będą dostępne w szablonach - jeśli nie będzie to miało sensu lub z jakichś przyczyn będą to zmiany konfliktowe, będą one ukryte - tak jak ma to miejsce obecnie w szablonie podstawowym, o którym poniżej. I tak dla przykładu, w obecnym module Szablony ofert internetowych, zamiast istniejącego obecnie jedynego szablonu Podstawowy szablon ofert internetowych pojawią się nowe domyślne szablony, które będą aplikowały wybrane zmiany zbiorcze podczas wykonywania operacji tworzenia ofert (nazwy mogą jeszcze ulec zmianie): Pozwala to skonfigurować program tak, aby np. czyścił wybrane pola przy powielaniu ofert, ustawiał wartości domyślne dla wybranych kont i serwisów przy zmianie konta, wstawiał domyślne wartości dla nowych ofert, przenosił tagami dane z towaru do ofert wystawianych z asortymentu lub przy importowaniu towaru do oferty. Szablony domyślne będą nieusuwalne, mogą być najwyżej puste i nic nie robić. Gdy zajdzie potrzeba resetowania/czyszczenia jakiegoś pola to wystarczy ustawić to w odpowiednim szablonie lub w kilku. Podobnie jeśli ma tam być wstawiona wartość domyślna statyczna bądź dynamiczna (tagi). Przy aktualizacji bazy do wersji 61, obecne ustawienia funkcji Przygotuj do wystawienia w serwisie oraz Import asortymentu do oferty zostaną przeniesione do odpowiednich szablonów. Mowa o tym oknie: Występujące tutaj znaczniki do wyboru zostaną zepchnięte na drugi plan, a pierwsze skrzypce będą grać szablony. Oczywiście funkcja wyboru i zmiany ad hoc pozostanie dostępna w tym oknie i zmiany te będą wprowadzane po zastosowaniu szablonu domyślnego oraz ewentualnego wybranego własnego. Edycja szablonu będzie zatem wyglądać tak jak wygląda okno zmian zbiorczych. Dotyczy to również obsługi różnych kont. Na tę chwilę zakładamy, że istniejący w zmianach zbiorczych mechanizm pozwalający stosować różne wartości dla różnych kont będzie tutaj wystarczający i nie będziemy robić osobnych szablonów pod różne konta. Dynamiczny wybór szablonu W miejscach programu, gdzie będzie się dało wybrać szablon własny do zastosowania będzie również dodane pole tagowe, które pozwoli dynamicznie wybrać szablon dla towaru, bazując np. na wartości pola własnego czy grupy. Będzie to rozwiązanie przydatne, jeśli dla różnych towarów czy grup towarowych stosowane mają być różne szablony. Zastosowanie dowolnego szablonu w dowolnym momencie Prawdopodobnie jeszcze nie w wersji 61, ale taka konstrukcja szablonów pozwoli nam także dodać funkcję stosowania szablonów w dowolnym momencie. Np. jeśli zachodzi potrzeba wykonywania cyklicznie/często pewnego zestawu zmian w ofertach trwających, można to zapisać jako szablon/preset zmian zbiorczych i uruchomić w razie potrzeby ręcznie, a może i poprzez automatyzację. Przykładowo jakieś obniżki okazyjne, które będą zmieniać nie tylko cenę ale np i opis, tytuł itp. Szablony aktualizacji Kolejnym krokiem, który w przyszłości planujemy w związku z szablonami, jest dodanie szablonów automatycznej aktualizacji ofert. Na tę chwilę jeszcze za wcześniej aby mówić o szczegółach, ale wedle wstępnego planu pozwoli to stworzyć z kartoteki towarów nexo czy GT swego rodzaju PIM (Product Information Management), z którego Sello NX będzie mogło automatycznie aktualizować oferty w wielu serwisach po dokonaniu zmian w kartotece na towarze. Zastąpi/rozszerzy to obecny mechanizm wyboru ofert do aktualizacji stanów i cen poprzez ustawienia cech. Ale na tę chwilę to wizja dalszych zmian. Mechanizm a możliwości (v61) Obecnie pracujemy nad samym mechanizmem działania i dodatkowo rozwijamy też mechanizm zmian zbiorczych. Możliwe, że nie wszystkie pola oferty będą dostępne do zmiany w wersji 61, bo wymaga to także prac po stronie zmian zbiorczych właśnie, ale jeśli są takie, które szczególnie są Wam potrzebne to również dajcie znać poniżej.

Rozpoczęliśmy prace nad funkcją importowania zamówień z Subiekta GT. Funkcja ta w dużej mierze wykorzystywana jest w Sello 1 do importowania zamówień ze sklepów internetowych poprzez Subiekta, do którego najczęściej są już dostępne różnego rodzaju synchronizatory. Przewidujemy, że funkcja będzie działać podobnie jak w Sello 1, gdzie za pomocą filtrów można było wybrać jakiego typu ZK mają być do Sello pobierane. W Sello NX powstanie dodatkowa integracja Subiekt GT ale typu integracja serwisu internetowego. Jakkolwiek dziwnie to nie brzmi, generalnie tego typu integracje mają funkcje importowania zamówień z serwisów internetowych (zewnętrznych) do Sello NX, więc ta nowa integracja będzie działać dokładnie jak pobieranie zamówień z Allegro. Oczywiście będzie implementować tylko pewien podzbiór możliwości takich integracji, ale całe pobieranie będzie się odbywać tak samo jak z serwisów internetowych. Wiele kont Subiekt GT Będzie możliwość dodania wielu kont dla tej integracji, co oznacza, że każde konto będzie mogło pobierać inny podzbiór ZK z Subiekta, charaktertyzujący się np. integracją Subiekta z różnymi sklepami. Dzięki takiemu podejściu, będzie można nazwać konta np. Zamówienie ze sklepu 1, sklep 2 itp, więc będą działały wszystkie mechanizmy filtrowania, rozróżniania kont na poziomie zamówień wysyłkowych itp. Konta te będą wymagać obecności podstawowego konta integracji z systemem handlowo magazynowym i z niego będą czerpać ustawienia (czyli de facto dane do połączenia bazy danych Subiekta GT). Filtry zamówień Przewidujemy filtrowanie ZK do importowaniu według kryteriów: Kategoria dokumentu Rozszerzenie dokumentu Status Informacja, czy numer oryginału jest wypełniony Dodatkowo data odcięcia, która jest standardowa dla wszystkich kont integracji dla zamówień. Piszcie, jeśli potrzebujecie czegoś więcej, albo też fajne by były przykłady po czym rozróżniacie takie zamówienia w Subiekcie, które należy potraktować jako wysyłkowe. Sposób dostawy Zastosujemy tutaj mechanizm rozpoznawania dostaw w usługach na liście pozycji ZK, który jest obecnie dodany w technicznym koncie integracji Sello, który działa dla funkcji Przygotuj do wysłania w Subiekcie nexo. Czyli jest to lista słów kluczowych, które są wyszukiwane w nazwach pozycji i są dalej traktowane jako koszt dostawy i usuwane są z listy towarów na EZ. Dodatkowo, dodamy mechanizm wyłuskiwania danych dla sposobu dostawy z pola uwag. W praktyce będzie to coś podobnego, jak zastosowaliśmy w wersji 55 do automatycznej identyfikacji towarów w ofertach, czyli mechanizm bazujący na tagach i modyfikatorach, który pozwoli z "dowolnego" pola (z listy poniżej) ZK wyciągnąć informację i dalej wykorzystać ją do ustawienia odpowiedniej dostawy. Planujemy w tym celu udostępnić kilka pól z ZK w postaci tagów [ZamowienieOdKlienta] NumerZamowienia NumerOryginalu Kategoria Tytul Podtytul Uwagi PolaWlasne Jeśli widzicie potrzebę pobierania danych z ZK z innych pól, również proszę o informację poniżej. Adres dostawy, punktu odbioru Adres dostawy będzie pobierany z adresu dostawy z ZK. W dalszej kolejności, jeśli tego adresu tam nie będzie, to będzie brany adres dostawy pobrany z kartoteki kontrahentów. Czy są inne miejsca, w których synchronizatory przez Was używane umieszczają takie dane, które powinny trafić do danych odbiorcy w EZ? Ewentualnie, czy z jakiegoś powodu adres dostawy z kontrahenta nie powinien być brany pod uwagę, bo jest jakieś inne ważniejsze pole w którym ten adres jest umieszczony? Punkt odbioru, czyli np. numer maszyny paczkowej również będzie wyłuskiwany z różnych danych dostępnych tagami, jak w poprzednim punkcie. Potrzebne informacje Tutaj prośba do Was, aby podesłać nam informacje, które dane z ZK i kontrahenta są wykorzystywane przez Was do nadawania przesyłek, w jaki sposób Wasz synchronizatory ze sklepami internetowymi umieszczają dane zakupu, sposób dostawy, punkty odbioru, typ dokumentu końcowego, uwagi kupującego, informacje o płatnościach. Tak abyśmy mogli stworzyć odpowiednie rozwiązania pozwalające całość zautomatyzować.