Ostatnia aktualizacja WAPRO Aukcje programu do obsługi integracji WAPRO Mag z portalem Allegro udostępniła użytkownikom nową funkcję. Dotyczy ona pobierania transakcji nieopłacony w Allegro.
Na portalu Goldeline prowadziliśmy ciekawą dyskusję z użytkownikami aplikacji, którzy przekonali mnie merytorycznymi argumentami, że warto to wprowadzić.
Warto jednak zauważyć, że sam proces integracji takich transakcji (zamówień) nie jest zalecany przez samo Allegro ponieważ rodzi wiele potencjalnych problemów.
Statusy transakcji
Allegro dla swoich transakcji przez Rest API odsyła różne statusy są to m.in.:
- Bought
- Filled_in
- Ready_for_processing
Wg dokumentacji użytkownicy powinni pobierać tylko status Ready_for_processing bo on oznacza kompletne zakończenie zamówienia oraz jego opłacenie przez kupującego.
Z punktu widzenia biznesowego jednak jest on nie wystarczający ponieważ niektórzy chcą mieć import statusu Filled_in z kilku powodów m.in.:
- szybka rezerwacja towaru pod klienta z internetu
- możliwość wycofywania wniosków grupowo z poziomu programu dla transakcji nie zrealizowanych
Konfiguracja
Parametr dostępny jest w menu WAPRO Aukcje | Konfiguracja | Synchronizacja | „Pobieraj transakcje nieopłacone”. W przeciwieństwie do poprzedniego modułu transakcji bez FOD, nowa implementacja pozwala użytkownikowi decydować czy w ogóle system ma pobierać takie dane czy nie.
Przykłady problematycznych wyjątków
Załóżmy, że klient X wykonał zakup 1 szt. towaru ABC w poniedziałek o 10.00 nie płacąc za nią, ale wybrał odbiór w punkcie Paczkomaty.
2. Następnie o 10.15 wykonana została synchronizacja przez użytkownika programu WAPRO Aukcje – program pobiera kontrahenta X i zakłada w nim adres dostawy bo taki adres dla tego typu zamówienia będzie podany.
3. Klient X wykonuje kolejny zakup bez płacenia za towar XYZ w poniedziałek o 13.00 wybiera, że chce fakturę oraz wybiera przesyłkę kurierską na adres do firmy (mamy zatem inny adres niż w pierwszym zakupie z wyborem do paczkomatu).
4. O 14.00 użytkownik WAPRO Aukcje uruchamiamy kolejną synchronizację, zaimportowane zostanie nowe zamówienie nieopłacone do aukcji, nadpisywany jest adres kontrahenta bo ten chce fakturę więc ma wyższość nad poprzednim adresem domowym tego klienta
5. O 16.00 klient orientuje się, że nie płacił za te zakupy i robi zapłatę za obydwa zakupy korzystając z opcji jednej płatności dla zaznaczonych zakupów znowu zaznaczając, że chce fakturę i zmienia dane na zupełnie inne (abstrakcyjny przypadek, żeby pokazać mnogość dziwnych przypadków jakie mogą wystąpić).
6. O 17.00 uruchamiamy użytkownik WAPRO Aukcje uruchamia synchronizację danych i pojawiają się schody.
Program nie otrzyma informacji z Allegro, że to zamówienie, które teraz importuje to są de facto 2 poprzednie zamówienia. Może to ustalić jedynie na podstawie identyfikatora zakupu pojedynczej pozycji z tego zamówienia.
Mamy tu dwa przypadki jakie zostały uwzględnione w logice programu. Jeden zakłada, że zamówienia nieopłacone z 10.00 oraz z 13.00 zostały przeniesione na zamówienia.
W takim przypadku program przy włączeniu opcji automatycznego tworzenia zamówienia do maga (dla wszystkich transakcji) z transakcji wykryje, że przyszło zamówienie na nowego kontrahenta (ponownie są podane dane do faktury, więc wygenerowany zostanie nowy kontrahent na te dane, poprzednie dane też były do faktury więc program ich nie nadpisze).
Ale transakcja nie przeniesie się na zamówienie kolejne bo nastąpi zdublowanie rezerwacji i potencjalny problem z towarami:
- nie można też skasować poprzednich transakcji i zamówień bo nie wiadomo co pracownicy z nimi zrobili
- nie można zmienić w nich kontrahenta bo rozjadą się wydruki i ewentualne eksporty, które mogły być po drodze wykonane
Program zatem zostawi tą transakcję w aukcjach i oznaczy ją w NOWEJ KOLUMNIE o nazwie B wykrzyknikiem, że wymaga ona ingerencji operatora systemu. Użytkownik sam podejmie czy anuluje poprzednie zamówienia i tworzy nowe na finalne dane, czy korzysta ze schowka pozycji i przenosi pozycje czy też realizuje po prostu 2 poprzednie na fakturę/paragon.
Drugi przypadek bardziej podstawowy zakłada tylko import takiej transakcji do aukcji celem ewentualnej obsługi zwrotów prowizji bez tworzenia zamówienia z rezerwacją. W tym przypadku program wykryje, że owszem ma poprzednie transakcje ale nie przenoszone zostały do maga, więc wykona anulowanie poprzednich transakcji (przy założeniu, że żadna z nich nie jest przeniesiona do maga). I w miejsce 2 poprzednich wstawi tą nową transakcje. Zasada tworzenia kontrahentów i ich adresów w obydwu przypadkach jest taka sama.
Dodatkowo anulowane transakcje zostaną zgrupowane, wyróżnikiem grupowania jest skopiowany numer transakcji nowo zaimportowanego zamówienia i wstawienie go do kolumny GUID_GRUPY w tabeli AUK_ALL_TRANSAKCJE. Pozwala to w celach diagnostycznych sprawdzić dlaczego zostały zaimportowane ponownie te same pozycje zakupowe.