Zdarzenie
Webhook na zmianie statusu zamówienia na uzgodniony (najczęściej „w realizacji"), nie na moment złożenia.
Najczęstsza reklamacja księgowości przy integracji WooCommerce z ERP nie dotyczy braku danych, tylko różnicy jednego grosza. Bierze się z tego, że sklep trzyma ceny brutto i zaokrągla na pozycji, a ERP liczy od netto na całym dokumencie. Tę decyzję podejmuje się przed wdrożeniem, nie po pierwszym miesiącu sprzedaży.
W WooCommerce to ustawienie globalne. Zmiana po starcie sprzedaży przelicza cały katalog i rozjeżdża historyczne zamówienia, dlatego traktujemy ją jak decyzję jednorazową.
| Aspekt | Ceny wprowadzane brutto | Ceny wprowadzane netto |
|---|---|---|
| Typowe zastosowanie | sprzedaż detaliczna | sprzedaż B2B i mieszana |
| Cena na listingu | równa, bez końcówek | wyliczana, bywa z groszówką |
| Zgodność z ERP liczącym od netto | wymaga wspólnej reguły zaokrągleń | naturalna |
| Zmiana stawki VAT | zmienia netto, brutto zostaje | zmienia brutto, netto zostaje |
| Sprzedaż zagraniczna | trudniejsza — inna stawka zmienia marżę | łatwiejsza — netto stałe |
| Ryzyko różnic groszowych | wyższe | niższe |
Niezależnie od wyboru spisujemy jedną zasadę: czy VAT liczony jest na pozycji, czy na sumie dokumentu, i z jakim zaokrągleniem. Ta sama zasada musi obowiązywać w sklepie i w ERP.
Webhook na zmianie statusu zamówienia na uzgodniony (najczęściej „w realizacji"), nie na moment złożenia.
Pozycje z SKU wariantu, ceny netto i brutto, klasa podatkowa, rabaty, koszt dostawy, adresy, forma płatności.
Sprawdzamy kontrahenta, NIP, kompletność adresu i to, czy każda pozycja ma odpowiednik w kartotece ERP.
Zamówienie idzie z kluczem idempotencji. Sklep zapisuje w metadanych, że eksport się powiódł.
Numer faktury lub WZ wraca do zamówienia w WooCommerce, żeby obsługa klienta nie musiała szukać w ERP.
Od tego zaczynamy: tryb cen, klasy podatkowe i moment, w którym zamówienie ma trafiać do ERP.