Jak sprawdzić nieopłacone transakcje?
Moduł dostępny jest w menu Wapro Aukcje | Konfiguracja | Synchronizacja | "Pobieraj transakcje nieopłacone". Nowa implementacja pozwala użytkownikowi decydować, czy system powinien pobierać takie dane czy też nie.
Zarówno w poprzedniej, jak i w obecnej implementacji użytkownik musi mieć pełną świadomość, że transakcja nieopłacona jest w stanie pośrednim, czyli kupujący może wykonać jeszcze modyfikację tego zakupu.
Według dokumentacji Allegro oraz poradnika implementacji nowego API transakcje takie nie powinny być przetwarzane przez sprzedających. W tym stanie posiadają one status FILLED_IN a oczekiwany stan do dalszego procedowania to status READY_FOR_PROCESSING czyli zakup z wypełnionymi wszystkimi danymi, opłacony i potwierdzony przez Allegro w zakresie płatności.
Na liście transakcji dodano nową kolumnę o nazwie S, która prezentuje graficznie stan transakcji:
- kolor szary odpowiada statusowi
FILLED_IN- stan przed finalnym potwierdzeniem, - kolor zielony odpowiada statusowi
READY_FOR_PROCESSING- stan potwierdzony przez Allegro, gotowy do przetwarzania w ERP.
Kupujący może wykonać modyfikację w zakresie:
- zmiany formy dostawy (tym samym zmieni się koszt dostawy, jak również koszt całej transakcji oraz kwota wpłaty PayU),
- adres dostawy.
Kupujący NIE MOŻE zmodyfikować pozycji zakupu.
Dodatkowo, jeśli kupujący rozpocznie dwa zakupy lub więcej i zostaną one pobrane do programu Wapro Aukcje w stanie pośrednim (FILLED_IN), a następnie będzie chciał zapłacić za ten zakup jedną płatnością, w API Allegro zostanie zwrócone zupełnie nowe zamówienie (o nowym numerze), które będzie zawierało wszystkie pozycje zakupowe z poprzednich transakcji rozpoczętych a nieopłaconych.
Poniżej zaprezentowano szczegółowy opis zachowania program w trakcie takiej synchronizacji wraz ze skutkami poszczególnych działań.
Przykład
- 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.
- Następnie o 10.15 wykonana została synchronizacja programu Wapro Aukcje - program pobrał kontrahenta X i założył adres dostawy, ponieważ taki adres dla tego typu zamówienia będzie podany.
- Klient X wykonuje kolejny zakup bez płacenia za towar XYZ. W poniedziałek o 13.00 wybiera, że chce fakturę oraz decyduje się na przesyłkę kurierską na adres firmy (inny adres niż w pierwszym zakupie z wyborem do paczkomatu).
- O 14.00 użytkownik Wapro Aukcje uruchamia kolejną synchronizację, zaimportowane zostanie nowe zamówienie nieopłacone, nadpisywany jest adres kontrahenta, przypomnijmy, że potrzebuje on faktury, co ma wyższość nad poprzednim adresem domowym tego klienta.
- 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, zaznaczając znów, że potrzebuje fakturę i zmienia dane na zupełnie inne (jest to abstrakcyjna sytuacja, która prezentuje mnogość skomplikowanych przypadków, jakie mogą wystąpić).
- O 17.00 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 dwa poprzednie zamówienia. Może to ustalić jedynie na podstawie identyfikatora zakupu pojedynczej pozycji z tego zamówienia. Są to więc 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 Wapro Mag (dla wszystkich transakcji) wykryje, że pojawiło się 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). Jednak transakcja nie przeniesie się na kolejne zamówienie, ponieważ nastąpi zdublowanie rezerwacji i potencjalny problem z towarami. W tej sytuacji:
- nie można skasować poprzednich transakcji i zamówień, ponieważ nie jest pewne, jakie działania zostały w związku z nimi podjęte przez pracowników,
- nie można zmienić kontrahenta, ponieważ wydruki i ewentualne raporty wykonane do tej pory, nie będą spójne.
Program zatem zostawi tą transakcję w aukcjach i oznaczy ją wykrzyknikiem w NOWEJ KOLUMNIE o nazwie B, co oznacza, że wymaga ona ingerencji operatora systemu. Użytkownik sam podejmie lub anuluje poprzednie zamówienia i utworzy nowe na finalne dane. Ma możliwość skorzystania ze schowka i przeniesienia pozycji. Może również zrealizować dwie poprzednie transakcje na fakturę/paragon.
Drugi przypadek bardziej podstawowy zakłada import takiej transakcji do aukcji, celem ewentualnej obsługi zwrotów prowizji bez tworzenia zamówienia z rezerwacją. W tym przypadku program wykryje, że pojawiają się poprzednie transakcje, ale nie zostały przeniesione do Wapro Mag, wykona więc anulowanie poprzednich transakcji (przy założeniu, że żadna z nich nie jest przeniesiona do Wapro Mag). Następnie w miejsce dwóch poprzednich transakcji wstawi nową. Zasada tworzenia kontrahentów i ich adresów w obydwu przypadkach jest taka sama.
Dodatkowo anulowane transakcje zostaną zgrupowane, czego wyróżnikiem jest skopiowany numer transakcji nowozaimportowanego 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.
Poniżej zaprezentowano widok nowych kolumn graficznie prezentujących stan poszczególnych transakcji.
