search

allegro / allegro-api

Issue tracker and wiki for Allegro REST API
https://developer.allegro.pl/
217 stars 39 forks source link

Event READY_FOR_PROCESSING a zamówienie w statusie FILLED_IN #2700

Closed manhunto closed 4 years ago

manhunto commented 4 years ago

Występuje problem:

:beetle: Opis

Zauważyłem problem. Dla zamówienia 2fd178b3-0f0d-11ea-a45a-b53b4ffeffef dostałem eventy BOUGH, FILLED_IN oraz READY_FOR_PROCESSING. Natomiast odpytując endpoint /order/checkout-forms/2fd178b3-0f0d-11ea-a45a-b53b4ffeffef otrzymuje informację, że zamówienie jest w statusie FILLED_IN i zamówienie nie posiada adresu.

Dla nas zamówienie w statusie READY_FOR_PROCESSING powinno posiadać już adres i być gotowe do wysłania, natomiast tak się nie stało. Czy te zamówienie jest poprawne? Czy mamy się spodziewać kolejnego eventu READY_FOR_PROCESSING kiedy ten adres się pojawi?

PrzemyslawLukanowski commented 4 years ago

Zweryfikowałem to - w dzienniku zdarzeń wystąpiły wszystkie trzy statusy, mimo to zamówienie posiada status FILLED_IN. Zgłosiłem ten problem do odpowiedniego zespołu.

(...) że zamówienie jest w statusie FILLED_IN i zamówienie nie posiada adresu.

Adres jest dostępny w delivery.pickupPoint, ponieważ kupujący wybrał jako metodę dostawy Paczkomaty 24/7 pobranie.

PrzemyslawLukanowski commented 4 years ago

@manhunto Udało nam się znaleźć żródło tego problemu, podobne przypadki w przyszłości nie powinny już wystąpić. Kolejny event RFP już się nie pojawi - jak wspomniałem wcześniej, adres jest dostępny w delivery.pickupPoint, ponieważ kupujący wybrał jako metodę dostawy Paczkomaty 24/7 pobranie.

manhunto commented 4 years ago

Udało nam się znaleźć żródło tego problemu, podobne przypadki w przyszłości nie powinny już wystąpić. Kolejny event RFP już się nie pojawi

Bardzo dziękuję za rozwiązanie problemu.

jak wspomniałem wcześniej, adres jest dostępny w delivery.pickupPoint, ponieważ kupujący wybrał jako metodę dostawy Paczkomaty 24/7 pobranie.

@PrzemyslawLukanowski co w przypadku kuriera? czy wtedy jest jakaś informacja o adresie dostawy?

manhunto commented 4 years ago

Jako, że mam kolejne pytanie w temacie eventów to pozwolę sobie jej tutaj zadać.

Kiedy zostały udostępnione eventy dla zamówień

Kiedy wystąpiły to wiem po polu occured_at ale czy nie ma jakiś opóźnień w czasie kiedy można je pobrać?

PrzemyslawLukanowski commented 4 years ago

co w przypadku kuriera? czy wtedy jest jakaś informacja o adresie dostawy?

W przypadku kuriera informacja o adresie dostawy w polu delivery dostępna jest dopiero dla zamówień w statusie READY_FOR_PROCESSING.

Kiedy wystąpiły to wiem po polu occured_at ale czy nie ma jakiś opóźnień w czasie kiedy można je pobrać?

W dniu wczorajszym w okoliach godziny 13:00 wystąpiły drobne opóźnienia, dlatego taka sytuacja mogła mieć miejsce.

manhunto commented 4 years ago

@PrzemyslawLukanowski Bardzo dziękuję za odpowiedzi :)

KrzysztofStachyra commented 4 years ago

A nie moglibyście tego ujednolicić czyli jak zamówienie ma status <> ready_for_processing to zwracacie tylko dane podstawowe a jak płatność zakończy się to wtedy dodatkowo adres dostawy? Do znacząco upraszcza integrację bo teraz w jednym przypadku już trzeba pilnować adresów dostawy. Dla przykładu nasi klienci chcą importować zamówienia już w statusie filled_in bo chcą rezerwować towar w ERPie pod te zamówienia. Na tym etapie jeśli nie było by dwuznaczności z danymi adresowymi to jest dużo prościej bo nie trzeba potem robić dodatkowych walidacji czy adres się nie zmienił. Obecnie będzie sytuacja gdzie klient przeniesie takie zamówienie do ERP skojarzy go z adresem dostawy np. z punktu odbioru bo taki się pojawi w API a klient na formularzu wycofa się z płatności i zmieni formę dostawy na kuriera i wskaże sobie adres domowy. Zamówienie będzie procesowanie z błędnym adresem albo potem trzeba jakoś poinformować operatora ERP, że zaszły zmiany. Swoją drogą akcja gdzie użytkownik może anulować sam proces płatności a to mu otwiera ścieżkę do zmiany formy dostawy to jakieś nieporozumienie przy systemie do integracji, dobrze by było żeby sprzedający taki rodzaj zdarzenia mógł w swoim koncie zablokować - to pewnie nie do Was jako zespołu API ale poddaje pod dyskusje.

PrzemyslawLukanowski commented 4 years ago

A nie moglibyście tego ujednolicić czyli jak zamówienie ma status <> ready_for_processing to zwracacie tylko dane podstawowe a jak płatność zakończy się to wtedy dodatkowo adres dostawy?

Taki mechanizm już funkcjonuje, dane kupującego udostępniamy dla statusów <> RFP w obiekcie buyer. Adres i metodę dostawy w sekcji delivery zwracamy natomiast tylko dla statusów RFP.

KrzysztofStachyra commented 4 years ago

No nie do końca bo z wypowiedzi na forum wynikało, że jak jest <>RFP a kupujący wybrał odbiór do punktu to taka informacja się jednak pojawia (Patrz 2700).

PrzemyslawLukanowski commented 4 years ago

Owszem, doprecyzuję - zwracamy metodę dostawy, jednak nie pole delivery.address - w przypadku dostaw do punktów jest to wartość w delivery.pickupPoint.

KrzysztofStachyra commented 4 years ago

Ja to rozumiem, ale istotą problemu nie jest fakt, że to jest w innym polu tylko fakt, że w ogóle adres się pojawia. Rozpiszę może w czym rzecz bo rozumiem, że Wy w API wystawiacie dane ale nie wystawiacie ich dla siebie tylko dla innych po to żeby zapanować nad logistyką:) w allegro tego nikt nie robi, więc u Was problem już nie istnieje ale w każdym erpie już istnieje.

  1. Problem pierwszy - jeśli zwracana jest jakakolwiek metoda dostawy z jej adresem (kurier lub punkt odbioru) to już potencjalnie powstaje problem, że jak ktoś decyduje się na rezerwację towaru pod taką sprzedaż (specjalistyczne sklepy nie mają dużych zapasów, więc tak robią). To z kolei powoduje, że zmienia się po drodze adres dostawy. Często z zamówień tworzone są paczki kurierskie, one bazują na adresie z Allegro. Jeśli zatem nastąpi wydruk zamówienia i magazynier nie zwróci uwagi, że coś się potem zmieniło to paczka leci nie na ten adres co finalnie wybrał kupujący.
  2. Problem drugi - kupujący może zmienić wartość całej transakcji ponieważ może wybrać inną metodę dostawy rzutującą na kwotę wpłacana na konto sprzedającego. Na podstawie płatności tworzone są zaliczki w systemie ERP kojarzone z takim zamówieniem. Są to dokumenty, które nie wiszą sobie w powietrzu tylko podpięte są do różnych dokumentów i mechanizmy kontrolne nie pozwalają ich edytować od tak bo ktoś sobie coś zmienił.
  3. Statusów filled_in może być wiele, więc każdorazowo wypadałoby brać nowy adres dostawy i go zmieniać w systemie co może powodować import wielu tymczasowych danych
  4. Brak importu zamówień o statusie filled_in nie pozwala automatyzować zwrotów prowizji do transakcji bez zakończonej płatności.

Pewnie znalazłbym jeszcze ze 3 poważniejsze problemy po głębszej analizie, ale nie w tym rzecz. Chodzi o to pewną niekonsekwencję (nie padł zwrotnie argument dlaczego taka niekonsekwencja została przyjęta). To co opisałem to feedback od klientów, którzy po otrzymaniu narzędzia z Waszymi wytycznymi czyli przetwarzajcie tylko to co ma RFP. Nie pobieranie FI czy B ma swoje konsekwencje w obsłudze zwrotów prowizji, a import ich ma konsekwencje z ciągłym pilnowaniem w ERPie wszystkich danych adresowych i daje niestety finalnie pole do pomyłek zwykłym pracownikom a to naraża na straty naszych wspólnych klientów...

PrzemyslawLukanowski commented 4 years ago

Dziękuję za szczegółowy opis problemu. Przekazałem informacje jako sugestię do działu odpowiedzialnego za rozwój API. Jeśli zdecydujemy się na wprowadzenie zmian, poinformujemy o tym w odpowiednim komunikacie.

KrzysztofStachyra commented 4 years ago

Dzięki - tak jak wspomniałem rozważcie o ile to możliwe np.sterowanie tym przez sprzedawcę czy on zezwala kupującym tylko na dokończenie płatności czy po drodze może jeszcze wpływać na parametry związane z logistyką bo to znacząco zmienia proces posprzedażowy. Nasi klienci z tego co wiem będą też opisywać swoje spostrzeżenia przez opiekunów handlowych.

KrzysztofStachyra commented 4 years ago

Mam pytanie, kiedy dokładnie w API pojawia się status BOUGHT - chodzi mi o interakcję frontu do wystąpienia tego zdarzenia? Sądząc po czasach to w większości jakoś natychmiast po bought pojawia się filled_in, mam jedną transakcję gdzie mam ciągle bought ale to był przypadek laboratoryjny, więc nie wiem czy to takie normalne zachowanie. Dotyczyło to zakupu z odbiorem osobistym. I dodatkowe pytanie czy zamówienie w statusie BOUGHT może mieć zmieniony zakres pozycji i to samo dotyczy statusu Filled_in - chce mieć jasność co na jakim etapie przetwarzania może ulec zmianie.

PrzemyslawLukanowski commented 4 years ago

Status BOUGHT pojawi się wraz ze statusem FILLED_IN w momencie kiedy kupujący wybierze "Kupuję i płacę", ponieważ dopiero na tym etapie kupuje przedmiot. Wyjątkiem są starsze, niezaktualizowne aplikacje mobilne, gdzie zakup mógł odbyć się już na etapie wybrania "Kup teraz" bez uzupełniania FOD-a - wtedy właśnie pojawi się sam event BOUGHT. Jeżeli zauważyłeś, że taki przypadek miał miejsce dla zamówienia, dla którego FOD został uzupełniony, poproszę o numer, zweryfikujemy to.

I dodatkowe pytanie czy zamówienie w statusie BOUGHT może mieć zmieniony zakres pozycji i to samo dotyczy statusu Filled_in - chce mieć jasność co na jakim etapie przetwarzania może ulec zmianie.

Zdarzenie BOUGHT może pojawić się po statusie FILLED_IN, zgodnie z poradnikiem:

Z uwagi na uwarunkowania techniczne, w pojedynczych przypadkach zdarzenia mogą pojawić się w nieoczekiwanej kolejności; to znaczy, że jest możliwość by np. zdarzenie ze statusem READY_FOR_PROCESSING pojawiło się przed FILLED_IN; nie traktujemy tego jako błąd.

Lecz ta kolejność już się nie zmieni:

Raz utworzona kolejność i liczba utworzonych zdarzeń nie zmieni się,

KrzysztofStachyra commented 4 years ago

No dobra to jeszcze pytanie dodatkowe, kiedy może być sytuacja że wystąpi kilka zdarzeń RPF (zgodnie z informacją z poradnika). Bo to trochę zaprzeczenie teorii - "możecie go używać i przetwarzać bo nie ulegnie zmianie". Czy poza tym co jest poda jako przykład "np. zakup, wpłata, dopłata" wyczerpuje tą listę? Na przyszłość taka mała uwaga do poradnika aby właśnie przy takich specyficznych założeniach dopisać zdanie komentarza, jakie uwarunkowania wpływają po stronie frontu/aplikacji mobilnej. Wtedy można oszacować ryzyko czy takie zachowanie API rzutuje na inne procesy po zaciągnięciu danych.

Jeszcze doprecyzuje tylko kwestie kolejności, rozumiem że może być losowa i zalecacie oprzeć się na ID, ale teraz pytanie czy jeśli losowa kolejność wystąpi to RPF może mieć niższe ID niż Bought? Ewentualnie jeśli tak to czy data w occuredAt będzie poprawna zgodnie z logiką i jednak RPF będzie miał wyższą datę niż bought?

Co do zamówienia to dla porządku możesz sprawdzić zamówienie o ID 1c2624b2-3b6c-11ea-b9bf-d571bca24be6 bo w logach widzę tylko bought bez kolejnych eventów.

PrzemyslawLukanowski commented 4 years ago

No dobra to jeszcze pytanie dodatkowe, kiedy może być sytuacja że wystąpi kilka zdarzeń RPF (zgodnie z informacją z poradnika). Bo to trochę zaprzeczenie teorii - "możecie go używać i przetwarzać bo nie ulegnie zmianie"

Przytoczone przez Ciebie sformułowanie dotyczy danych adresowych w formularzu - w przypadku statusu RFP już się nie zmienią. Nie piszemy o tym w kontekście samych zdarzeń. Allegro działa na strukturze rozproszonej, dlatego event READY_FOR_PROCESSING dla tego samego zamówienia może występować więcej niż raz. Jeśli chodzi o działania ze strony klienta, które mogą wygenerować dodatkowy event RFP, będzie to tylko dopłata.

Kolejność zdarzeń może być losowa. Jeśli status RFP wystąpi przed FILLED_IN jego ID będzie niższe, ale - tak jak napisałeś - data w occuredAt będzie poprawna, wyższa.

Co do zamówienia to dla porządku możesz sprawdzić zamówienie o ID 1c2624b2-3b6c-11ea-b9bf-d571bca24be6 bo w logach widzę tylko bought bez kolejnych eventów.

Sprawdziłem to, poniżej wklejam id eventu wraz z datą wystąpienia:

1579514634011595 - FILLED_IN - 2020-01-20T10:03:39.629Z 1579514635325114 - READY_FOR_PROCESSING - 2020-01-20T10:03:40.719Z 1579514637401289 - BOUGHT - 2020-01-20T10:03:39.021Z

Na podstawie tego przykładu widać, że kolejność zdarzeń jest losowa, z każdym kolejnym eventem ID jest wyższy, ale sama data w occuredAt dotyczy momentu, w którym wystąpiło zdarzenie

KrzysztofStachyra commented 4 years ago

dzięki to już rozwiewa moje wątpliwości :) teraz trzeba to okopać po naszej stronie, żeby użytkownik, który chce mimo wszystko importować statusy <> RPF chociażby pod zwroty prowizji nie narobił sobie kuku w procesie po sprzedażowym. Dzięki za pomoc.

stale[bot] commented 4 years ago

W tym wątku nie pojawiła się żadna nowa odpowiedź w ciągu 30 dni. Dlatego automatycznie oznaczamy go jako przeterminowany. Jeśli w ciągu 7 dni nie pojawi się żadna odpowiedź, zamkniemy ten wątek. Dziękujemy za zaangażowanie w dyskusję.