Tworzenie dokumentów wstępnych

[Radosław Dobrowolski 28]

Witam,

Zacząłem próbować automatycznego tworzenia dokumentów wstępnych (ZK) w SGT. Szczerze, wg mnie wygląda to trochę słabo. Dopóki nie ma automatycznego grupowania transakcji wg formularzy, to ja bym dodał opcję, która nie tworzyłaby ZK w przypadku, gdy pojedyncza transakcja jest częścią większego zamówienia. Zaznaczenie tej opcji nakazywałoby tworzenie ZK z takich transakcji dopiero po zgrupowaniu. Z resztą ta opcja wygląda na bardziej uniwersalną, bo nawet gdy będzie już to automatyczne grupowanie, to ona też będzie działać.

Co o tym sądzicie?

[Bartosz Rosa 1 761]

Grupowanie będzie w najbliższym czasie. Będzie również nowy synchronizator do Subiekta. Dlatego nie planujemy niczego zmieniać w obecnych (starych) mechanizmach, bo po prostu jest to obecnie nieopłacalne.

[MARCIN e-kupowanie.pl 1 007]

2 godziny temu, Radosław Dobrowolski napisał:

to ja bym dodał opcję, która nie tworzyłaby ZK w przypadku, gdy pojedyncza transakcja jest częścią większego zamówienia

W chwili obecnej to nie było by dobre. Bo jeśli ktoś mam dużo zamówień do grupowania i np. jakiś czas nie jest obecny przy Sello (żeby to zrobić ręcznie), to brak automatycznej rezerwacji może skutkować sprzedażą towaru ponad stan w innym miejscu.

[Kaczor . 66]

Jak dla mnie ta opcja, która jest teraz z zk do każdej transakcji jest ok. Mamy bardzo dużą rotację towaru, bardzo dużo zamówień spływa i tak jak pisał @MARCIN e-kupowanie.pl gdyby nie było tej opcji to byłaby dupa  

[MARCIN e-kupowanie.pl 1 007]

1 minutę temu, Kaczor . napisał:

gdyby nie było tej opcji to byłaby dupa

O przepraszam! Tak nie pisałem...

[Dominik kidl 78]

Zakładając, że wykorzystujecie ZK tylko do rezerwacji towaru, to aktualne rozwiązanie wystarcza. Tutaj jednak z ogromną (już kilkuletnią) niecierpliwością czekam na automatyczne grupowanie. W takiej sytuacji nadal każdy będzie mógł tworzyć ZK, żeby rezerwować towar, ale będziemy mieli jedno ZK, do jednej transakcji, nawet jeśli klient kupił 20 pozycji.

 

Bartek wiem, że już kilkukrotnie pisałeś, że niedługo będzie i że na wiosnę, ale... strasznie męczy mnie to ręczne wprowadzanie ZK. Już pracujemy na 2 zmiany, dojdzie jeszcze praca w niedzielę. Teraz ktoś musi zaglądać lub siedzieć w pracy, żeby przyjąć zamówienia. Auto grupowanie, o które od lat prosiłem, jest potrzebne na wczoraj

Wiosna puka już do drzwi, a u nas 2x więcej zamówień niż rok temu. Przerzucanie ręczne transakcji do ZK to żmudny i zbędny proces.

 

Czekam dalej i liczę, że będzie szybciej

[MARCIN e-kupowanie.pl 1 007]

14 minut temu, Dominik kidl napisał:

strasznie męczy mnie to ręczne wprowadzanie ZK

Nie bardzo rozumiem skąd taka potrzeba? Jeśli Sello robi pojedyncze ZK to od razu po (ręcznym, ale zbiorczym) zgrupowaniu transakcji je usuwa i tworzy jedno ZK dla grupy.

Być może jednak chodzi Ci o jakiś inny scenariusz?

[Dominik kidl 78]

5 minut temu, MARCIN e-kupowanie.pl napisał:

Nie bardzo rozumiem skąd taka potrzeba? Jeśli Sello robi pojedyncze ZK to od razu po (ręcznym, ale zbiorczym) zgrupowaniu transakcji je usuwa i tworzy jedno ZK dla grupy.

Być może jednak chodzi Ci o jakiś inny scenariusz?

? na prawdę tak robi!? ?

Nigdy nie doszedłem do tego etapu. Uruchomiłem automat, zobaczyłem że "wali" ZK do każdej oferty i wyłączyłem. Więcej razy nie uruchamiałem. Nigdy też jakoś nie doczytałem na forum, żeby po późniejszym zgrupowaniu, ZK były usuwane i robione było jedno zbiorcze ?

Możliwe, że gdybym wiedział o tym wcześniej, to już dawno coś z tym byśmy podziałali.

Na aktualnym etapie już nie mogę zastosować tego rozwiązania. Zamówienia obsługujemy w SGT. Każde utworzone ZK, jest synchronizowane przez dodatek z ProstejPaczki. Program wrzuca do odpowiednich Pól własnych:

• numer zamówienia z Allegro
• ID konta sprzedawcy
• adres mailowy z "+" kupującego,
• rodzaj wybranego dokumentu końcowego (PAi, FS)
• sposób wysyłki
• adres punktu odbioru w przypadku usług odbioru w punkcie Poczty Polskiej

Dodatkowo synchronizuje sposób płatności oraz uwagi kupującego. Jeśli w zamówieniu nie ma żadnych uwag od klienta i wszystkie dane zostały prawidłowo zsynchronizowane, to ZK dostaje kategorię "Potwierdzone". Jeśli jest jakaś uwaga lub wystąpił jakikolwiek błąd w synchronizacji, to ZK dostaje kategorię "Do weryfikacji".

Nie wiem tak do końca, jak zareagowałaby ProstaPaczka, gdyby pojawiły się ZK do każdej oferty zamiast do całej transakcji. Co wtedy dokładnie zsynchronizuje i jak się zachowa, gdy te ZK znikną i pojawi jedno zbiorcze. Do tego wpadają w międzyczasie automatycznie ZK ze sklepów internetowych, telefoniczne i mailowe. Coś czuję, że byłby problem i spore zamieszanie w numeracji ZK. Mógłbym przetestować ten scenariusz. Może znajdę wolną chwilę, to spróbuję.

 

Na ten moment, idealne rozwiązanie to dorzucenie do Sello auto grupowania i tworzenie ZK w automacie. Wtedy zrezygnujemy z ręcznej obsługi ZK wcześniej oznaczanych kategorią "Potwierdzone". Te ZK byłyby od razu ustawiane przez PP jako "Gotowe do wysyłki". Skoro nie ma uwag od klienta, Sello potwierdziło wpływ pieniędzy i transakcja jest gotowa do przetwarzania, a w programie nie wystąpiły żadne błędy w synchronizacji, to nie ma sensu ręcznie ich przerzucać z potwierdzonych na gotowe do realizacji.

Oczywiście już teraz możemy do ZK ustawić, żeby od razu pojawiało się na magazynie. Póki co, testujemy czy mogą pojawić się jakieś błędy. Były tutaj komunikaty o dublowaniu transakcji i u nas nadal występuje błąd Forbirden. Gdy to wszystko zostanie wyeliminowane, wtedy ZK lecą od razu na magazyn, bez obsługi człowieka.

 

 

 

[MARCIN e-kupowanie.pl 1 007]

8 minut temu, Dominik kidl napisał:

? na prawdę tak robi!? ?

Naprawdę. Wyjątkowo Sello nie skasuje jakiegoś ZK z pojedynczych transakcji, ale bardzo rzadko... (procentowo nie umiem określić, bo "rzadko" dla mnie, to dla innych będzie np. co 2 dni..., wszystko zależy od ilości zamówień; ja przeglądam ZK w Subiekcie raz na jakieś 500 paczek, zazwyczaj jest OK).*

 

Grupowanie ma być dorzucone (o ile mnie pamięć nie myli - @Bartosz Rosa?) do kolejnej wersji. W obecnym trybie pracy Sello brak grupowania jest uciążliwy...

 

*edit: jedyny skutek tego błędu to zbyt dużo zarezerwowanego towaru

Edytowane 25 Lutego 2020 przez MARCIN e-kupowanie.pl

[Bartosz Rosa 1 761]

Bardziej skłaniamy się ku tworzeniu transakcji z wieloma towarami. Pozwoli to uniknąć pewnych dodatkowych problemów i będzie prostsze. Wymaga to jednak nieco większych przeróbek po stronie struktury przechowywania danych. Wtedy ZK będą się tworzyć od razu na to co trzeba, bez konieczności usuwania, tworzenia nowych itp.

[Dominik kidl 78]

Jeśli Bartek piszesz "większe przeróbki", to coś czuję że na ten sezon wiosenny nie będzie oczekiwanej aktualizacji

[Bartosz Rosa 1 761]

Nie jakieś ogromne, ale początkowo chcieliśmy ich uniknąć, bo to grzebanie w "starym" kodzie a tam różne niespodzianki potrafią się pojawił po modyfikacjach .

[MARCIN e-kupowanie.pl 1 007]

Warto by także przyjrzeć się startowaniu synchronizacji po zgrupowaniu transakcji. Czyli wtedy gdy Sello usuwa pojedyncze ZK. Zazwyczaj nie tworzą się nowe ZK, chociaż stare są usuwane. Tworzy się luka czasowa i do następnej automatycznej synchronizacji z GT (która też nie zawsze się wykonuje) towary znów są bez rezerwacji.

[Dominik kidl 78]

Z tego co Bartek wyżej napisał, to zrozumiałem że już nie będzie czegoś takiego jak grupowanie transakcji.

2 godziny temu, Bartosz Rosa napisał:

Wtedy ZK będą się tworzyć od razu na to co trzeba, bez konieczności usuwania, tworzenia nowych itp.

Jeśli się nie mylę, to aktualnie Allegro zwraca w API zgrupowaną transakcję i to Sello samo rozbija na oferty i później trzeba zgrupować. Gdyby udało się uzyskać efekt taki, że od razu dostajemy kompletne zamówienie, już zgrupowane, to nie wystąpi sytuacja tworzenia wielu ZK i później ich usuwania oraz tworzenia jednego. Od razu otrzymamy kompletne ZK, jedno do transakcji. To jest na pewno efekt, jaki chciałbym uzyskać.

[Bartosz Rosa 1 761]

37 minut temu, MARCIN e-kupowanie.pl napisał:

Warto by także przyjrzeć się startowaniu synchronizacji po zgrupowaniu transakcji. Czyli wtedy gdy Sello usuwa pojedyncze ZK. Zazwyczaj nie tworzą się nowe ZK, chociaż stare są usuwane. Tworzy się luka czasowa i do następnej automatycznej synchronizacji z GT (która też nie zawsze się wykonuje) towary znów są bez rezerwacji.

Nowy synchronizator Subiekta będzie działał na taskach (atomowych zadaniach, tak jak działa obecnie Allegro). Jest to zupełnie inne podejście do synchronizacji niż było dotychczas. Jest dużo bardziej elastyczne i wszystkie taski obsługiwane są w ten sam standardowy sposób. Dzięki temu istnieje możliwość bardziej wybiórczego wywołania np. tworzenia dokumentu zaraz po zgrupowaniu, które dodatkowo tworzy taski/zadania potomne synchronizujące od razu stany towarów użytych w dokumencie. Dodatkowo, jeśli podczas synchronizacji pojawi się kolejna transakcja i trzeba wystawić nowy ZK, to nie czeka on, jak obecnie, na kolejną synchronizację, tylko zadanie wskakuje od razu do kolejki priorytetowej i będzie przetwarzane od razu po zakończeniu aktualnie wykonywanego zadania na Subiekcie. Sama zatem organizacja tego modelu synchronizacji rozwiązuje problemy opóźnień, luk czasowych czy długiego czasu synchronizacji towarów.

Gdy któryś z tasków się nie uda to zawsze jest to sygnalizowane błędem, podświetleniem transakcji, wpisem w raporcie. Obecny stary synchronizator różnie się tutaj potrafił zachować, raz zasygnalizował, innym razem nie, bo specyficzny zbieg okoliczności sprawił, że algorytm (często rozsiany w wielu miejscach w kodzie programu) zadziałał w inny sposób. Samo wygenerowanie kolejnej porcji danych do synchronizacji wymagało odczekania aż ruszy nowy cykl synchronizujący.
Natomiast taski w nowym synchronizatorze mają kod scentralizowany, robią jedną konkretną rzecz, która może się udać lub nie. Włożyliśmy sporo pracy w cały mechanizm działania, kolejkowanie zadań, sygnalizowanie błędów, czy w końcu aby podzielić kod na osobne zadania (napisać go od nowa). Powinno to w znacznym stopniu zredukować takie dziwne przejściowe sytuacje. No ale jednak jest to nowy kod, stąd wymaga jeszcze dopracowania szczegółów.

28 minut temu, Dominik kidl napisał:

Jeśli się nie mylę, to aktualnie Allegro zwraca w API zgrupowaną transakcję i to Sello samo rozbija na oferty i później trzeba zgrupować. Gdyby udało się uzyskać efekt taki, że od razu dostajemy kompletne zamówienie, już zgrupowane, to nie wystąpi sytuacja tworzenia wielu ZK i później ich usuwania oraz tworzenia jednego. Od razu otrzymamy kompletne ZK, jedno do transakcji. To jest na pewno efekt, jaki chciałbym uzyskać.

Tak właśnie jest, ale struktura i procesy przetwarzające transakcję nie były gotowe na taką zmianę więc obecnie Sello rozbija zamówienie na osobne transakcje. Z początku wydawało się, że automatyczne grupowanie zda egzamin, bo nie będzie trzeba ruszać tej warstwy obsługującej transakcję a z punktu widzenia użytkownika nie będzie to praktycznie widoczne. Teraz, jak już nie ma aż tak dużego ciśnienia związanego z terminami wygaszania API można usiąść do tego jeszcze raz i zastanowić się jak to powinno być zrobione, a nie jak zrobić żeby działało . I tutaj nasuwa się wniosek, że powinny być pojedyncze transakcje z wieloma towarami. W końcu transakcja od zawsze ma taką możliwość, ale całe przetwarzanie zawsze było skierowane na sytuację, że w transakcji z Allegro jest zawsze tylko jeden towar z Allegro. Trzeba to zmienić i myślę, że rozwiąże to kolejną porcję problemów czy uciążliwych operacji.

 

[Bartosz Rosa 1 761]

Dnia 26.02.2020 o 17:44, Bartosz Rosa napisał:

Teraz, jak już nie ma aż tak dużego ciśnienia związanego z terminami wygaszania API można usiąść do tego jeszcze raz i zastanowić się jak to powinno być zrobione, a nie jak zrobić żeby działało . I tutaj nasuwa się wniosek, że powinny być pojedyncze transakcje z wieloma towarami. W końcu transakcja od zawsze ma taką możliwość, ale całe przetwarzanie zawsze było skierowane na sytuację, że w transakcji z Allegro jest zawsze tylko jeden towar z Allegro. Trzeba to zmienić i myślę, że rozwiąże to kolejną porcję problemów czy uciążliwych operacji.

No i jednak okazało się, że pozostaniemy przy automatycznym grupowaniu. Liczba zmian i czas potrzebny na ich realizację w przypadku transakcji wielotowarowych jest dość spory. Trzeba by rozwiązać przynajmniej 15 zlokalizowanych już problemów a ile wyjdzie po drodze... Całość zajęła by spokojnie około miesiąca.

Natomiast funkcję automatycznego grupowania właśnie ukończyliśmy i oddana została do testów.