Model zamówienia

Problem#

W marketplace jedno zamówienie kupującego prawie nigdy nie jest jedną jednostką operacyjną. Każdy sprzedawca pakuje osobno, wysyła osobno, anuluje osobno i dostaje pieniądze osobno. Pytanie brzmi, czy ten podział ma być widoczny w modelu danych, czy wystarczy, że linie znają właściciela.

Dwa modele#

Minimalna wersja#

• Linia zamówienia zna sprzedawcę i ma własny stan realizacji.
• Anulowanie i zwrot działają na poziomie linii, nie tylko całego zamówienia.
• Stan zamówienia jest wyliczany ze stanów linii, a nie ustawiany niezależnie.
• Numer widoczny kupującemu jest jeden, niezależnie od wewnętrznego podziału.

Czego nie budować teraz#

• Rozproszonego przepływu z kompensacjami między usługami. Przy tej skali to złożoność bez zysku.
• Własnego silnika stanów z konfigurowalnymi przejściami.
• Automatycznego dzielenia zamówień na przesyłki. Sprzedawca wie lepiej, jak pakuje.
• Historii każdej zmiany pola. Historia zmian stanu i operacji pieniężnych wystarczy.

Zaplanuj z góry#

Granulacja anulowania i zwrotu#

To jest decyzja, którą najtrudniej cofnąć w całym rozdziale. Jeżeli model dopuszcza wyłącznie anulowanie całego zamówienia, dołożenie anulowania pozycji oznacza przeliczenie wartości, podatków i prowizji w zamówieniach historycznych. Odwrotny kierunek jest darmowy.

Ilość zwrócona osobno od ilości zamówionej#

Zwrot częściowy to nie zmiana ilości w linii, tylko osobna informacja obok niej. Nadpisanie ilości niszczy to, co kupujący faktycznie zamówił, a od tego zależą wszystkie późniejsze rozliczenia.

Zamówienie zna swoje pieniądze#

Wartość pozycji, podatek, koszt wysyłki i naliczona prowizja mają leżeć przy zamówieniu, nie być doliczane przy każdym odczycie. Odczyt z żywych danych oznacza, że raport z zeszłego miesiąca daje dziś inny wynik.

Wyzwalacze#

• pierwsze zamówienie, w którym jeden sprzedawca wysłał, a drugi jeszcze nie;
• pierwsza prośba o anulowanie jednej pozycji;
• pierwszy zwrot częściowy;
• pierwsze pytanie sprzedawcy, dlaczego widzi cudze pozycje w zamówieniu;
• rozliczenie zaczyna wymagać grupowania w każdym zapytaniu.

Następny etap#

Po pierwszym i czwartym wyzwalaczu naraz: wydzielenie części zamówienia należącej do sprzedawcy jako osobnego bytu, z własnym stanem i własnym widokiem. Po piątym: to samo, ale motywacją jest rozliczenie, nie interfejs. Oba prowadzą w to samo miejsce, więc jeśli oba są blisko, nie odkładaj.

Częste błędy#

Co się sprawdza w praktyce#

Podział zamówienia na część należącą do każdego sprzedawcy okazał się decyzją, która odblokowała wszystko, co przyszło później: rozliczenia, wypłaty, zwroty i odwracanie przelewów. Każdy z tych modułów operuje na gotowej jednostce zamiast grupować linie za każdym razem.

Nie polecam tego jednak jako domyślnego startu. Ten podział ma sens dopiero wtedy, gdy wielu sprzedawców w jednym zamówieniu jest normą, a nie wyjątkiem. Przy sprzedaży, w której zamówienie prawie zawsze ma jednego sprzedawcę, własność na poziomie linii wystarcza i jest znacznie tańsza.

Checklista#

• Linia zamówienia zna sprzedawcę i ma własny stan realizacji.
• Stan zamówienia jest wyliczany, nie ustawiany.
• Anulowanie i zwrot działają na poziomie pozycji.
• Ilość zwrócona jest osobną informacją od ilości zamówionej.
• Wartości pieniężne są zapisane przy zamówieniu.
• Sprzedawca widzi wyłącznie swoje pozycje.