Dwa źródła prawdy dla ceny to nie dług techniczny, tylko korekty faktur

Dlaczego ten skrót jest kuszący

Argumenty za są mocne i wszystkie prawdziwe. ERP liczy cenę wolno. Odpytanie o cenę dla trzydziestu produktów na liście to trzydzieści wywołań. Sfera ma limit sesji. Klient narzeka, że katalog się ładuje.

Więc ktoś proponuje kompromis: „proste przypadki policzymy w sklepie, skomplikowane zostawimy ERP-owi". Rabat procentowy na grupę? To przecież mnożenie. Cena katalogowa minus 8%? Trywialne.

I to nawet działa. Przez pierwsze miesiące.

Co się rozjeżdża i kiedy

Rozjazd nie bierze się z błędu w kodzie. Bierze się stąd, że logika cenowa w ERP żyje własnym życiem - i nikt nie informuje zespołu e-commerce, kiedy się zmienia.

Handlowiec negocjuje z kontrahentem stałą cenę na jeden indeks i wpisuje ją do ERP-a. Księgowość zmienia kolejność naliczania rabatu i promocji. Ktoś dodaje próg ilościowy od 500 sztuk. Żadna z tych osób nie wie, że w sklepie stoi druga implementacja tych samych reguł - i nie ma powodu, żeby wiedziała.

Sklep dalej liczy po staremu. Koszyk pokazuje 11,20 zł. Faktura z ERP-a wychodzi na 10,90 zł.

I teraz najważniejsze: to nie jest błąd, który ktoś zgłosi. Klient, który zapłacił mniej, nie dzwoni. Klient, który zapłacił więcej, dzwoni po trzech miesiącach, kiedy porówna faktury. Wtedy okazuje się, że dotyczy to nie jednego zamówienia, tylko czterystu.

Dlaczego testy tego nie łapią

Bo testujesz swoją implementację, a nie zgodność dwóch implementacji.

Testy sklepu sprawdzają, że rabat 8% od 100 zł daje 92 zł. I dają. Testy przechodzą przez cały okres, w którym cena już się rozjeżdża - bo mierzą to, co sklep miał liczyć, a nie to, co ERP faktycznie liczy dzisiaj.

Jedyny test, który by to złapał, to porównanie ceny ze sklepu z ceną z ERP-a dla tej samej pary kontrahent-indeks, uruchamiane cyklicznie na produkcyjnych danych. Prawie nikt tego nie ma, bo to nie wygląda jak test - wygląda jak monitoring. I dlatego nie powstaje na etapie projektu, tylko po pierwszej awarii.

Gdzie przebiega granica

Reguła jest prosta i nie ma od niej dobrych wyjątków: cenę liczy ten system, który wystawia fakturę. Sklep może ją cache'ować, pokazywać, formatować - ale nie wyprowadzać.

To nie znaczy, że musisz odpytywać ERP trzydzieści razy na listing. Znaczy, że optymalizujesz transport i cache, a nie logikę:

• Cache z kluczem (kontrahent, indeks) i krótkim TTL - kilkanaście minut wystarcza, bo cenniki nie zmieniają się co sekundę.
• Batch: jedno wywołanie „policz ceny dla tych trzydziestu indeksów dla tego kontrahenta" zamiast trzydziestu osobnych. Większość ERP-ów to potrafi, tylko nikt nie pyta.
• Warstwa pośrednia, która to spina i cache'uje w jednym miejscu, zamiast w każdym module sklepu z osobna - o tym jest tekst o middleware.

Różnica jest zasadnicza. Cache może być nieświeży - i to jest do naprawienia jednym unieważnieniem. Druga implementacja logiki może być niezgodna - i to jest do naprawienia tylko przez usunięcie jej.

Jak wygląda model cenowy, który trzeba obsłużyć, rozbieram w tekście o cennikach kontraktowych.

Co dalej

• Model cenowy, który trzeba obsłużyć: Cenniki kontraktowe
• Gdzie postawić warstwę pośrednią: Middleware vs. bezpośrednio
• Pełny przegląd integracji: pillar /integracje