jak przekazać zamówienia woocommerce do erp bez przepisywania

dlaczego zamówienia woocommerce nadal wpisuje się ręcznie do erp

Księgowość nadal otwiera WooCommerce, kopiuje numer zamówienia do Comarch Optima, enova365 albo Subiekt GT i przepisyje NIP, adres wysyłki oraz każdą pozycję. Ten rytuał pęka, gdy klient zmienia metodę wysyłki po płatności, spływa częściowy zwrot albo zestaw w sklepie nie ma kartoteki w ERP. Most ze skoroszytem, który działał przy pięćdziesięciu zamówieniach miesięcznie, rozsypuje się przy kilkuset: dwie osoby edytują ten sam CSV, stawki VAT się rozjeżdżają, a magazyn kompletuje status, którego księgowość nigdy nie zatwierdziła. Prawdziwy koszt to nie samo przepisywanie. To sporne faktury, stany, które ERP uważa za wolne, choć sklep już sprzedał sztukę, oraz zamknięcia miesiąca czekające na człowieka, który zgra prowizje bramki z numeracją dokumentów. Przy integracjach robionych pod NDA powtarza się ten sam obraz: sklep jest witryną handlową, ERP jest księgą formalną, a pomiędzy nimi żyje tylko wiedza plemienna, które pole dodatkowe oznacza który magazyn i która metoda płatności mapuje się na którą kasę. Bez kontraktu automatyzacji brakuje idempotentności. Odświeżenie strony podziękowania albo ponowienie webhooka tworzy drugi dokument ERP dla tego samego ID WooCommerce. Pracownicy anulują dokumenty ręcznie, co brudzi audyt i psuje ciągłość numeracji, której część księgowych broni jak świętości. Sklepy B2B w wielu językach dokładają problem: nabywca na fakturze to grupa VAT, odbiorca to oddział, a ERP oczekuje obu jako powiązanych kontrahentów zanim pozwoli zapisać zamówienie sprzedaży. Zamówienia z marketplace wrzucone do WooCommerce dokładają kolejne ID zewnętrzne, które musi zostać skorelowane, żeby zwrot trafił w właściwy dokument fiskalny. Dokładają się waluty i podatki. Checkout w EUR na firmę PLN w Optimie wymaga jawnego źródła kursu i daty księgowania. Obniżony VAT na książki albo żywność w jednej lokalizacji nie może cicho spaść do stawki podstawowej, bo ktoś przemianował klasę podatkową w motywie. Wysyłka jako osobna usługa opodatkowana versus fracht wliczony w linię zmienia schemat dokumentu w enova. Karty podarunkowe, store credit i doładowania portfela często nie mogą ruszać magazynu, a mimo to potrzebują dokumentu finansowego, inaczej znikają z raportów przychodu. Trwałe rozwiązanie traktuje opłacone zamówienie WooCommerce jako zdarzenie, mapuje SKU i klasy VAT wprost, zapisuje jeden dokument ERP na jedno ID zamówienia sklepu i odbija statusy z powrotem, żeby support nie obiecywał wysyłki, której księga nie przyjęła. Ten przypadek zamyka właśnie tę lukę: nie ładny dashboard, tylko pewne przekazanie z koszyka do dokumentu księgowego z jasną odpowiedzialnością, gdy mapowanie padnie, oraz ścieżką uzgodnienia, gdy webhooki wypadły w nocy. Zespoły, które odkładają tę integrację, zwykle płacą w szczycie sezonu: więcej wyjątków ręcznych, awaryjne poprawki w Excelu i mniej zaufania między sprzedażą, magazynem a finansami. Spiszcie raz model operacyjny (kto utrzymuje mapowanie SKU, kto zamyka dead-letter) i niech oprogramowanie egzekwuje nudną ścieżkę, a eksperci zajmują się tylko prawdziwymi wyjątkami. Szczegół operacyjny dla tematu document numbering and fiscal periods: wskazani właściciele, przykłady awarii oraz metryka, która dowodzi, że kontrola działa produkcyjnie w tej automatyzacji WooCommerce. Spiszcie krok runbooka, cel alertu oraz akcję rollback lub kompensaty, by dyżur nocny działał bez zgadywania. Podajcie nazwę systemu źródła prawdy i pole ID korelacji używane w logach. Sequence marker pl-woocommerce-orders-to-erp-pad-1.

kiedy opłacone zamówienie woocommerce ma utworzyć dokument w erp

Odpalaj na `order.paid` albo `payment_complete` w WooCommerce oraz ponownie na `order.updated`, gdy po pierwszym udanym zapisie w ERP zmienia się adres, pozycje albo status. Dokładaj piętnastominutowy reconcile listujący opłacone zamówienia bez ID dokumentu ERP w meta. Nie odpalaj na `pending` ani `on-hold`, chyba że polityka rezerwuje przed capture; większość sklepów PL i DACH czeka na pobraną płatność, żeby Optima albo enova nie tworzyła należności, które nigdy nie spłyną. Odnowienia subskrypcji używają ID zamówienia odnowienia jako klucza korelacji, nie samego ID subskrypcji rodzica.

jak zmapować pozycje woocommerce na dokumenty sprzedaży w erp

1. Zweryfikuj zamówienie: wymagane pola billing, format NIP dla B2B, waluta dozwolona w firmie ERP oraz każde SKU w tabeli mapowań. Odrzuć ze strukturalnym błędem, gdy linia gift-card lub wirtualna nie ma artykułu ERP, a polityka zabrania cichego pomijania. Zapisz odcisk walidacji, by identyczne ponowienia kończyły się od razu.
2. Upsert kontrahenta w ERP. Najpierw NIP, potem e-mail, na końcu utwórz z adresem billing. Dołącz ship-to jako drugi adres, gdy Subiekt lub Optima modelują oddziały osobno od nabywcy prawnego. Zachowaj ID klienta WooCommerce jako klucz zewnętrzny do późniejszej deduplikacji.
3. Zbuduj dokument sprzedaży: mapuj pozycje, stawki VAT, wysyłkę jako usługę lub pole frachtu, kupony jako rabaty z tym samym VAT co w sklepie oraz metodę płatności na kasę lub konto bankowe w ERP. Opłaty marketplace dodawaj jako koszty tylko gdy księgowość tego chce na tym samym dokumencie.
4. Zatwierdź albo zapisz dokument według reguł firmy, zapisz numer i ID wewnętrzne ERP w meta zamówienia WooCommerce i ustaw stan `posted`, `draft` albo `needs_mapping`, by support widział to bez otwierania ERP. Emituj zdarzenie wewnętrzne dla magazynu lub WMS.
5. Przy późniejszych zwrotach i anulacjach twórz korektę albo anulowanie powiązane z oryginalnym ID ERP. Nigdy nie wystawiaj nowego dokumentu sprzedaży na zdarzenie refund. Odbij status dokumentu ERP na status zamówienia lub notatkę, gdy magazyn dokończy przyjęcie, w tym częściowe realizacje jeśli ERP je wspiera.

jak webhooki n8n i api erp przenoszą payload zamówienia

Preferuj webhooki WooCommerce do n8n dla prawie natychmiastowego przekazania, z Action Scheduler albo WP-Cron jako siatką bezpieczeństwa, gdy endpoint webhooka leżał. n8n trzyma mapowania, ponowienia i dead-letter; czysty PHP wystarczy dla jednej firmy Optima ze stabilnymi SKU, ale słabo się starzeje, gdy dokładacie enova dla drugiego podmiotu. Kształt payloadu to JSON zamówienia znormalizowany do DTO: nabywca, linie, podatki, płatności i ID korelacji. Connector ERP mówi API Optimy, usługi enova albo API partnera / procedurę SQL Subiekta - jeden connector na kod firmy, bez współdzielenia tokenów. Sekrety poza bazą WordPress, w vault hosta automatyzacji. Callbacki statusu z ERP aktualizują tylko meta zamówienia; nie tworzą nowych zamówień sklepu. Google Sheets może być widokiem operatora awarii, nie źródłem prawdy. Przy dużym wolumenie batche'uj reconcile, ale ścieżkę opłaconego zamówienia prowadź dokument po dokumencie, by utrzymać klucze idempotentności. Szczegół operacyjny dla tematu contractor upsert and NIP matching: wskazani właściciele, przykłady awarii oraz metryka, która dowodzi, że kontrola działa produkcyjnie w tej automatyzacji WooCommerce. Spiszcie krok runbooka, cel alertu oraz akcję rollback lub kompensaty, by dyżur nocny działał bez zgadywania. Podajcie nazwę systemu źródła prawdy i pole ID korelacji używane w logach. Sequence marker pl-woocommerce-orders-to-erp-pad-2.

co zrobić gdy erp odrzuci synchronizację zamówienia woocommerce

Klasyfikuj błędy: walidacja (zły NIP, brak SKU), transport (timeout, 429) oraz odrzucenia biznesowe (kontrahent zablokowany, okres zamknięty). Walidacja otwiera ticket Slack lub mail z linkiem do zamówienia i nie retry'uje, dopóki mapowanie nie zostanie poprawione. Transport retry z backoffem i jitterem do limitu, potem dead-letter. Odrzucenia biznesowe zamrażają zamówienie w `needs_erp_review` i wołają księgowość; nie walcie w zamknięty okres. Zawsze kluczuj zapis ID zamówienia WooCommerce. Loguj hashe request/response bez danych karty i bez surowego PESEL z pól custom. Jeśli ERP przyjęło dokument, a sklep nie zapisał meta, reconcile szuka po ID zewnętrznym w ERP zamiast wystawiać drugi raz. Cotygodniowy digest wieku dead-letter, żeby ciche kolejki nie gniły miesiąc.

kiedy ręczne księgowanie zamówień w erp nadal się opłaca

Poniżej około osiemdziesięciu opłaconych zamówień miesięcznie przy jednej niezmiennej liście SKU wyszkolony operator w Optimie może nadal wyjść taniej niż budowa i nadzór connectorów. Odłóż też, gdy projekt ERP jest w migracji i schematy dokumentów zmieniają się co tydzień - zautomatyzujecie chaos. Czysty dropshipping, gdzie dostawca fakturuje klienta końcowego, zwykle wymaga innego obiegu niż klasyczne zamówienie sprzedaży w Subiekcie; nie wciskajcie tego wzorca na siłę.

wskaźniki zdrowia synchronizacji woocommerce do erp

• Mediana minut od payment_complete do ID dokumentu ERP na zamówieniu
• Udział opłaconych zamówień starszych niż godzina bez ID dokumentu ERP
• Liczba zduplikowanych dokumentów ERP dla tego samego ID WooCommerce miesięcznie
• Udział prób sync kończących się needs_mapping względem posted