[NEWS] Anulowanie zamówień przez kupującego / Orders cancellation by the buyer

[MaciejFrackowiak]

Od 05.05.2020 kupujący będą mogli anulować zamówienie w ciągu 3 dni od daty zakupu. Udostępnimy taką opcję, gdy:

• sprzedawca posiada konto Firma;

• status realizacji zamówienia (“fulfillment.status”) jest inny niż “PROCESSING”, “READY_FOR_SHIPMENT”, “SENT”;

• sprzedawca nie dodał numeru przesyłki do zamówienia.

  W związku z tym dla zasobów:

• GET /order/events - dodamy nowy typ eventu “BUYER_CANCELLED”. Jeżeli zobaczysz w dzienniku zdarzeń taki wpis, oznacza to, że kupujący zrezygnował z realizacji zamówienia.

  Ważne! Zdarzenie “BUYER_CANCELLED” może pojawić się przed lub po READY_FOR_PROCESSING.

• GET /order/checkout-forms oraz GET /order/checkout-forms/{checkoutFormId} - dodamy nowy status zamówienia “CANCELLED”.

Jeżeli kupujący anulował zamówienie już opłacone, możesz zwrócić otrzymaną wpłatę za pomocą POST /payments/refunds. Dla niezrealizowanych zamówień możesz wystąpić o rabat transakcyjny przy użyciu POST /order/refund-claims.

Więcej informacji o anulowaniu zamówień znajdziesz na stronie dla sprzedających.

---

On May 5, 2020 we will introduce to buyers option to cancel an order within 3 days after purchase. Buyer will be able to cancel an order if:

• seller has a company account;
• order fulfillment status (“fulfillment.status”) is different than PROCESSING, READY_FOR_SHIPMENT, SENT;
• seller has not added tracking number to the order.

Therefore, to the following resources:

• GET /order/events - we will add a new event type “BUYER_CANCELLED”. If you see such entry in the event log, it means that the buyer cancelled the order.

  Note! Event “BUYER_CANCELLED” may appear before or after “READY_FOR_PROCESING”.

• GET /order/checkout-forms and GET /order/checkout-forms/{checkoutFormId} - we will add a new order status “CANCELLED”.

If the buyer cancelled an order, which is already paid, you can refund the payment via POST /payments/refunds. For cancelled orders you can create a sale commission refund application via POST /order/refund-claims.

You can find more information about orders cancellation on the for sellers page.

[pawelosajda]

Czy możliwość anulowania zamówienia jest już dostępna w środowisku testowym?

[MaciejFrackowiak]

Nie, ponieważ trwają jeszcze ostatnie prace nad produkcyjną wersją mechanizmu.

[pietrach]

Ale jako sprzedający też mogę zmienić status zamówienia na CANCELLED ? Jednocześnie też mogę mieć taki status przy pobraniu zamówienia i to oznacza, że klient anulował ?

[MaciejFrackowiak]

@pietrach Nie, status zamówienia na CANCELLED (dla GET /order/checkout-forms i GET /order/checkout-forms/{checkoutFormId}) zmieni się tylko pod wpływem działania kupującego. Natomiast Ty ze swojej strony możesz zmienić status realizacj każdego zamówienia (fulfillment.status) korzystając z PUT /order/checkout-forms/{id}/fulfillment na CANCELLED.

[pietrach]

@MaciejFrackowiak To w takim razie jaki będzie status zamówienia jeśli zmienię poprzez API PUT /order/checkout-forms/{id}/fulfillment na CANCELLED i później pobiorę jego dane GET /order/checkout-forms i GET /order/checkout-forms/{checkoutFormId} ?

[MaciejFrackowiak]

@pietrach Musisz wziąć pod uwagę, że obecnie sprzedający będzie miał możliwość czasowego wyłączenia opcji anulowania zamówienia przez kupujących - i tu pojawiają się dwie ścieżki:

1) sprzedający wyłączył opcję --> status zamówienia nigdy nie zmieni się na CANCELLED (ostatni możliwy to RFP), stąd Ty jako sprzedący zmieniasz tylko fulfillment.status;

2) sprzedający ma aktywną opcję anulowania --> status zamówienia automatycznie (na skutek działania kupującego) zmieni się na CANCELLED i żadna Twoja operacja nie zmieni statusu zamówienia, zmienisz tylko fulfillment.status.

[Onixarts]

Czy jeśli kupujący anuluje zamówienie, to czy przy próbie ustawienia statusu zamówienia przez sprzdawcę np na PROCESSING albo READY_FOR_SHIPMENT zasób PUT /order/checkout-forms/{id}/fulfillment zwróci jakiś błąd? Jeśli nie, to sprzedawca nie dowie się o tym, że klient anulował w tym samym czasie zamówienie dopóki nie pobierze dziennika zdarzeń albo danych zamówienia.

[pietrach]

@MaciejFrackowiak ale ja na chwilę obecną mogę wysłać PUT /order/checkout-forms/{id}/fulfillment na CANCELLED i zamówienia jest anulowane przez sprzedającego. I wtedy jako fulfillment.status pojawi mi się "CANCELLED" ? Co masz na myśli "Musisz wziąć pod uwagę, że obecnie sprzedający będzie miał możliwość czasowego wyłączenia opcji anulowania zamówienia przez kupujących" ? Że wprowadzacie taką opcję ale będzie można z niej nie korzystać wogóle ?

[MaciejFrackowiak]

@Onixarts Nie, statusy realizacji zamówienia (fulfillment.status) zależą tylko od działania sprzedającego - może zawsze zmienić jego wartość na dowolną. Tak, aby sprawdzić czy kupujący anulował zamówienie niezbędne jest sprawdzenie dziennika zdarzeń lub bezpośrednio checkoutForms.

[MaciejFrackowiak]

@pietrach Tak, to będzie tylko zmiana porządkowa dokonana przez sprzedającego i będzie miała odniesienie wyłącznie do fulfillment.status. W podlinkowanym przeze mnie artykule dołączone jest szczegółowe info:

Aby każdy sprzedający mógł przygotować się do nowego sposobu anulowania zamówienia przez kupującego, do końca lipca obowiązywać będzie okres przejściowy. W tym czasie możesz wyłączyć opcję anulowania zakupu w swoich ofertach.

[Onixarts]

To trochę słabo. Teraz przed każdym ruchem sprzedawca będzie musiał pobierać dane z Allegro i całe pobieranie danych i trzymanie we własnej bazie staje się bez sensu, skoro wymuszacie w ten sposób pracę online.

[pietrach]

@MaciejFrackowiak w takim razie po jakich danych w API rozpoznać, czy anulował sprzedawca czy kupujący ?

[MaciejFrackowiak]

@Onixarts Tylko opierając się na dzienniku zdarzeń otrzymasz (najszybciej) na bieżąco informację, czy kupujący anulował zamówienie.

[MaciejFrackowiak]

@pietrach Jeżeli kupujący anulował zamówienie to ujrzysz event BUYER_CANCELLED oraz checkoutForm otrzyma status CANCELLED. Zmiany sprzedającego widoczne są tylko w statusie realizacji zamówienia (fulfillment.status).

[pietrach]

@MaciejFrackowiak ale ja nie korzystam z eventów wogóle. Czy nie może być takiej informacji tutaj GET /order/checkout-forms/{checkoutFormId} ?

[MaciejFrackowiak]

@pietrach Ale oczywiście też będzie - spójrz proszę do treści komunikatu.

[pietrach]

Czyli dodacie do pola status dodatkową wartość "BUYER_CANCELLED" lub "CANCELLED" ? Teraz możliwe wartości to READY_FOR_PROCESSING, FILLED_IN, BOUGHT, FULFILLMENT_STATUS_CHANGED .

[MaciejFrackowiak]

@pietrach Dokładnie tak:

GET /order/checkout-forms oraz GET /order/checkout-forms/{checkoutFormId} - dodamy nowy status zamówienia “CANCELLED”.

[Onixarts]

@MaciejFrackowiak

Tylko opierając się na dzienniku zdarzeń otrzymasz (najszybciej) na bieżąco informację, czy kupujący anulował zamówienie.

To ja wiem, ale nie do końca czujecie chyba jak działają programy korzystające z API. Nie ciągną one przecież na żywo non stop dziennika zdarzeń, tylko robią to co jakiś czas. Nawet niech to będzie minuta to i tak w tej minucie kupujący może anulować zamówienie a sprzedawca lub jego system zacznie je przetwarzać i nie ma żadnej informacji o tym, że jest konflikt. W systemie sprzedawcy wygenerują się dokumenty, faktury, zostaną zafiskalizowane i trzeba to potem odkręcać. Aby zrobić to po waszemu, przed każdą operacją wykonaną w systemie sprzedawcy trzeba by ciągnąć dane zamówienia z Allegro, a pamiętajcie że tych zamówień niektórzy mają więcej niż 1 na godzinę i pobranie tych danych oraz samo ich przetwarzanie trwa pewien czas w którym w serwisie kupujący może anulować. Programiści i testerzy powinni u was pracować na większym zbiorcze danych to zobaczyliby w czym problem i że czas wymiany i przetwarzania danych to nie są milisekundy a często kilkadziesiąt sekund albo i minut. Moim zdaniem ustawienie przez sprzedawcę statusu wskazującego na przetwarzanie powinno generować błąd jeśli kupujący anulował zamówienie - inaczej będzie patologia, niby anulowane a jednak mogę sobie oznaczyć, że wysłane.

[MaciejFrackowiak]

@Onixarts Dziękuję za przedstawienie przez Ciebie spostrzeżeń. Obraliśmy natomiast kierunek, w którym zmiany kupującego widoczne są w eventach i checkoutFormie, natomiast sprzedającego w statusie realizacji zamówienia - są to dwie niezależne ścieżki, co pozwala jednoznacznie odpowiedzieć kto podjął działanie.

[Onixarts]

@MaciejFrackowiak A powinny być zależne. Nie można zjeść ciastka i mieć ciastka a ta funkcja na to pozwala. Tym bardziej, że kupujący nie będzie mógł anulować zamówienia jeśli sprzedawca zacznie je przetwarzać - a zatem obie funkcje są zależne - ale tylko w jedną stronę. Będą z tego nieporozumienia i błędy.

[MaciejFrackowiak]

@Onixarts W opisanym przez Ciebie przypadku wystarczy, że sprzedający w momencie rozpoczęcia przetwarzania zamówienia (a zakładam, że robi to dopiero, gdy status to READY_FOR_PROCESIING) dokona zmiany statusu realizacji zamówienia (fulfillment.status) na np. "PROCESSING" (w realizacji) i już kupujący nie może anulować zamówienia. W tym momencie nie dojdzie do "pomieszania".

[ghost]

@MaciejFrackowiak załóżmy jednak że może zdarzyć się sytuacja w której prawie jednocześnie ściągniemy zamówienie i Klient oznaczy CANCELLED lub wystąpi błąd w restAPI (dzienniki zareagują z opóźnieniem, co się zdarza) / aplikacji integrującej Co się stanie jeśli dla zamówienia CANCELLED zostanie wysłane PROCESSING Który z systemów jest nadrzędny i czy w odpowiedzi zostanie zwrócona jasna informacja że jest anulowane, czy dostaniemy cokolwiek co pozwoli nam przerwać proces Czytam powyższe posty ale nie ma jasno opisanego procesu i znów z tego wyjdą nieporozumienia

[pietrach]

@MaciejFrackowiak czy na chwilę obecną przed 5 maja jak użyje filtrów w metodzie GET /order/checkout-forms => status=CANCELLED to metoda wyrzuci błąd ? Bo testuje sobie z filtrami lineItems.boughtAt.gte, lineItems.boughtAt.lte, status, offset, limit i wyrzuca mi błąd:

{"code":"ERROR","message":"An error has occurred","details":null,"path":"\/order\/checkout-forms","userMessage":null}

[MaciejFrackowiak]

@SebastianOzdoba odpowiadając na:

Co się stanie jeśli dla zamówienia CANCELLED zostanie wysłane PROCESSING

W tej sytuacji PROCESSING będzie tylko porządkowym stanem realizacji zamówienia przez sprzedającego (nie wpłynie w żaden sposób na zamówienie, które jest już anulowane przez kupującego.)

Jak wspomniałem we wcześniejszym poście:

Obraliśmy natomiast kierunek, w którym zmiany kupującego widoczne są w eventach i checkoutFormie, natomiast sprzedającego w statusie realizacji zamówienia - są to dwie niezależne ścieżki, co pozwala jednoznacznie odpowiedzieć kto podjął działanie.

[MaciejFrackowiak]

@pietrach Wszelkie zmiany produkcyjnie pojawią się 5 maja.

[ghost]

@MaciejFrackowiak ale to bez sensu jaki "porządkowy" stan. Stan zamówienia jest jednoznaczny albo jest anulowane albo jest procesowane. Więc przy próbie wysłania PROCESSING dla CANCELLED powinien być zwrócony błąd, tak by sprzedawca mógł zareagować

[Onixarts]

@MaciejFrackowiak

W opisanym przez Ciebie przypadku wystarczy, że sprzedający w momencie rozpoczęcia przetwarzania zamówienia (a zakładam, że robi to dopiero, gdy status to READY_FOR_PROCESIING) dokona zmiany statusu realizacji zamówienia (fulfillment.status) na np. "PROCESSING

No właśnie nie wystarczy. To byłby świat idealny. Sprzedawca pobiera zamówienia w poniedziałek rano z weekendu. Trwa to np 2 minuty, bo jest ich sporo. Przechodzi do realizacji pierwszego z nich, status RFP. System wysyła do API status PROCESSING i zadowolony sprzedawca kontynuuje obsługę zamówienia. Nie wie jednak, że chwilę wcześniej kupujący anulował zamówienie. Dowie się dopiero, jak system ponownie sięgnie po dziennik zdarzeń, a robi to co pewien czas. I tutaj dochodzi do sytuacji wyścigu dwóch procesów. Tylko, że sprzedawca ma wpływ na zablokowanie możliwości anulowania jak będzie pierwszy, zaś jak kupujący będzie pierwszy to dochodzi do rozjazdu statusów.

[MaciejFrackowiak]

@Onixarts @SebastianOzdoba @pietrach Przeanalizowaliśmy Wasze spostrzeżenia i chcemy zaproponować koncepcję w podejściu do anulowania zamówień, którą szczegółowo opisaliśmy w dokumencie. Proszę, zapoznajcie się z nią - liczymy na Wasze komentarze.

[Onixarts]

Jak dla mnie wygląda całkiem w porządku i rozwiązuje problemy. Jestem na tak.

[TimothyKoval]

Wszystko fajnie, ktoś w końcu pomyślał dla odmiany. Tylko w takim przypadku przesuńcie termin z 5 maja, bo to są większe zmiany w systemie zamówień, a jest to elementarny element integracji w każdej platformie sprzedażowej.

[ghost]

Dla nas też to rozwiązanie jest dużo lepsze, z tym że termin 5maja mało realny by to wdrożyć

[pietrach]

@MaciejFrackowiak OK

[pietrach]

@MaciejFrackowiak a co np. jeśli przy pobieraniu zamówień zmienimy im status na w realizacji a ich rzeczywisty czas realizacji będzie powiedzmy za 2-3 dni. Chodzi o to aby się zabezpieczyć przed anulacją przez kupującego. To dobry pomysł czy Allegro sprawdza ile czasu się realizuje zamówienie i później ma to wpływ na jakieś oceny itp. ?

[Onixarts]

Hehe, już knujecie funkcję

• [x] oznacz nowe zamówienia jako w trakcie po odebraniu? ;) Też o niej przez chwilę pomyślałem, bo zapewne nasi klienci o to wkrótce zapytają.

[MaciejFrackowiak]

@Onixarts @SebastianOzdoba @pietrach @TimothyKoval Dziękuję za Wasze opinie nt. proponowanej zmiany. Finalnie, wdrożymy rozwiązanie z "revision", jednak nie wpłynie to na datę wprowadzenia opcji anulowania zamówień w Allegro. Każdy sprzedający będzie mógł wyłączyć do lipca opcję w zakładce Ustawienia zamówień.

[MaciejFrackowiak]

@pietrach W chwili obecnej taka zmiana statusów nie wpływa na oceny.

[pietrach]

@MaciejFrackowiak a czy może wpłynąć na oceny za jakiś czas ?

Aby to wyłączyć to trzeba mieć abonament conajmniej podstawowy wykupiony czy niekoniecznie ?

[Onixarts]

A kiedy to będzie działać na sandboxie?

[MaciejFrackowiak]

@pietrach Nie, opcja zostanie udostępniona dla każdego sprzedającego, nie trzeba będzie posiadać abonamentu.

@Onixarts Wraz z wejściem na produkcję funkcjonalność zostanie dodana na Sandbox.

[ghost]

@MaciejFrackowiak kiedy będzie dostępny nowy plik YAML? Obecny nie ma danych dotyczących tego procesu

[MaciejFrackowiak]

@SebastianOzdoba Zmiana planowo wdrożona zostanie 5 maja 2020 i wówczas pojawi się aktualna wersja swagger.yaml.

[ghost]

@MaciejFrackowiak prośba na przyszłość by publikować takie rzeczy wcześniej, tak samo jak i zmiany na sandbox. Nawet nie możemy przetestować ani nawet zacząć implementacji (serializujemy sobie yaml) przed umieszczeniem przez Was na produkcji :)

[alekskuc]

Witam, @MaciejFrackowiak chciałbym zaimplementować zmiany odnośnie anulowania zamówień "na sucho". Czy to są wszystkie przewidywane zmiany w dokumentacji swagger.yaml? Proszę o weryfikację.

[MaciejFrackowiak]

@SebastianOzdoba Twoją sugestię przekażę bezpośrednio do osób związanych z rozwojem REST API.

@alekskuc Tak, na chwilę obecną tak - nowy event "BUYER_CANCELLED" + zdarzenie "CANCELLED" dla checkoutForm.

[Onixarts]

@MaciejFrackowiak czy 5 maja będzie również zaimplementowane rozwiązanie z revision opisane w dokumencie? Czy to pojawi się później?

[MaciejFrackowiak]

@Onixarts Pole "revision" pojawi się później, dlatego każdy sprzedający dostanie możliwość wyłączenia opcji anulowania zamówień (do lipca) w zakładce Ustawienia zamówień.

[pietrach]

Czy to już zostało wdrożone ? Bo szukam w zakładce ustawienia dla zamówień opcji wyłączenia tego i nie ma.

[MaciejFrackowiak]

@pietrach Opcja w ustawieniach jest już widoczna.

[ghost]

@MaciejFrackowiak jak mogę anulować zamówienie na sandbox? Widzę że są nowe ustawienia na koncie firmowym, ale jako kupujacy w szczegółach zamówienia nie widzę opcji anuluj Kupuję, opłacam, wchodzę na konto do szczegółów zamówienia i nic nie ma :) Może jestem ślepy :)