VTEX OMS: przepływy zamówień, integracja API i połączenia z ERP

Ten przewodnik omawia mechanikę OMS, która ma znaczenie dla inżynierów: jak orderForm staje się zamówieniem, jakie operacje downstream wyzwala każdy status cyklu życia zamówienia oraz które wzorce API sprawdzają się pod dużym obciążeniem.

TL;DR: Co powinien wiedzieć integrator VTEX

VTEX OMS zarządza pełnym cyklem życia przepływu zamówień w ramach czterech odrębnych typów przepływów: Marketplace, Seller, Complete i Chain, i każda decyzja integracyjna wynika ze zrozumienia, w którym przepływie uczestniczy Twój sklep.

Wdrażaliśmy integracje VTEX OMS dla szybko rosnących detalistów w Europie, obserwując nasycenie kolejki Feed v.3 podczas sprzedaży błyskawicznej oraz podejmując na żywo decyzje architektoniczne dotyczące wyboru między Feed a Hook dla klientów z wymaganiami SLA poniżej 5 minut. Mechanika ma tu kluczowe znaczenie: gdy endpoint Place Order w Checkout API zwraca 201, powstaje orderId i zamówienie trafia do OMS jako nowy obiekt, pola orderForm pozostają w odpowiedziach API OMS, jednak tym obiektem zarządza teraz OMS, nie Checkout.

Od tego momentu status przechodzi przez etapy płatności, okno anulowania, obsługę i fakturowanie. Sposób śledzenia zmian statusów, kolejka pull Feed v.3 czy webhook Hook, to decyzja architektoniczna, którą przepracowuje ten przewodnik. Jeśli oceniasz, czy VTEX OMS pasuje do szerszej przebudowy platformy, złożoność integracji omówiona tutaj jest bezpośrednio powiązana z modernizacją infrastruktury OMS bez zakłócania działających operacji.

Miejsce VTEX OMS w platformie commerce

VTEX OMS działa downstream od VTEX Checkout API, przejmuje kontrolę w chwili, gdy istnieje potwierdzony orderId, i zarządza każdym kolejnym etapem statusu od tego momentu.

Podczas checkoutu aktywnym obiektem jest orderForm: mutowalna struktura koszyka budowana, walidowana i modyfikowana wyłącznie w Checkout API. Gdy kupujący finalizuje zakup, endpoint Place Order w Checkout API zwraca odpowiedź 201 zawierającą orderId. Ta odpowiedź wyznacza granicę. Od tego momentu zamówienie istnieje jako obiekt VTEX OMS wchodzący w cykl życia przepływu zamówień, choć pola orderForm pozostają i pojawiają się w większości payloadów odpowiedzi VTEX Orders API, co regularnie zaskakuje deweloperów spodziewających się wyraźnego rozdziału.

Jeden detal architektoniczny, który zaskakuje zespoły na wczesnym etapie: indeks OMS działa niezależnie od samego rekordu zamówienia. Zamówienie może być w pełni zatwierdzone i przechodzić przez etapy obsługi, podczas gdy indeks wyszukiwania odzwierciedla wcześniejszy stan. Zapytania o zamówienia przez f_creationDate lub status względem indeksowanego endpointu listy mogą zwracać nieaktualne wyniki; rekord zamówienia pobierany bezpośrednio przez orderId zawsze będzie miarodajny.

Dla zewnętrznych systemów zarządzających logistyką lub danymi katalogu ma to istotne znaczenie: rezerwacja stanów magazynowych następuje na poziomie OMS, nie przy checkoucie, a zamówienie w Seller Flow może wyświetlać status ready-for-handling w rekordzie, zanim indeksowana lista to odzwierciedli. Nasz zespół spotkał się z tym opóźnieniem w środowiskach o wysokiej przepustowości, gdzie wolumeny sprzedaży błyskawicznej powodowały opóźnienia indeksowania przekraczające możliwości tolerancji pollingu, właśnie dlatego Feed v.3 zaprojektowano tak, by działał całkowicie niezależnie od indeksowania.

Szerszy przegląd tego, jak łączą się warstwy platformy VTEX, znajdziesz w naszym przewodniku po platformie VTEX.

Od orderForm do OMS: tworzenie zamówienia

orderForm staje się rekordem zamówienia OMS dokładnie w chwili, gdy endpoint Place Order w VTEX Checkout API zwraca odpowiedź 201 (VTEX Developers, Creating a regular order with the Checkout API). Odpowiedź ta zawiera wygenerowany orderId. Domyślny format VTEX to 12-cyfrowy identyfikator numeryczny z 6-cyfrową sekwencją zaczynającą się od 500001; sklepy mogą zamiast tego wybrać format alfanumeryczny łączący prefiks ze skrótem nazwy konta i numerem sekwencji, na przykład `v1233363wlmr-02` (VTEX Help Center - Precautions when setting the order numbering). W obu przypadkach przyrost między kolejnymi numerami zamówień jest losowy, dzięki czemu osoby z zewnątrz nie mogą szacować wolumenu zamówień na podstawie samego ID, a format numeracji jest zablokowany na stałe po wyborze. Przed tym 201 orderForm jest zmiennym stanem wewnątrz Checkout. Po nim zamówienie istnieje jako obiekt VTEX OMS z własną progresją etapów statusu.

Rezerwacja stanów magazynowych następuje na tej samej granicy. VTEX rezerwuje stock w chwili otrzymania potwierdzenia 201, nie podczas tworzenia koszyka. Wyobraź sobie dwóch kupujących ścigających się przez checkout po ostatnią sztukę: pierwsze żądanie, które pomyślnie zakończy wywołanie Place Order, wyzwala aktualizację reservedItems w warstwie logistycznej, blokując tę sztukę dla potwierdzonego orderId. Żądanie drugiego kupującego jest blokowane, zanim płatność może zostać przetworzona, ponieważ dostępna ilość w ustawieniach magazynowych wynosi teraz zero. Aby dowiedzieć się, jak ten stan rezerwacji jest eksponowany, odpytaj endpointy szczegółów zamówienia i przeanalizuj tablicę logisticsInfo wewnątrz shippingData, każda pozycja zawiera quantity i warehouseId odzwierciedlające rezerwację.

Pola orderForm nie znikają po utworzeniu zamówienia. Pozostają i pojawiają się w większości odpowiedzi VTEX Orders API, dlatego integracje odpytujące endpointy szczegółów zamówień nadal widzą znane pola z ery checkout, takie jak clientProfileData, shippingData i itemMetadata w payloadzie OMS.

Od 201 wzwyż system OMS jest właścicielem cyklu życia zamówienia we wszystkich kanałach realizacji. Status przechodzi od payment-pending przez payment-approved, przez okno anulowania, następnie ready-for-handling i ostatecznie invoiced. orderId to stabilny klucz dla wszystkich operacji downstream: middleware ERP, konektory realizacji zamówień i kolejka Feed v.3, wszystkie się do niego odwołują.

Cztery typy przepływów zamówień VTEX

VTEX OMS przypisuje każde zamówienie do dokładnie jednego z czterech typów przepływów w chwili, gdy odpowiedź 201 zwraca orderId (VTEX Help Center - Order flow and status). Typ przepływu nie jest ustawieniem konfigurowanym ręcznie, wynika z roli sklepu w transakcji.

Chain Flow to typ, który konsekwentnie zaskakuje zespoły nowe w VTEX. W odróżnieniu od Marketplace Flow, gdzie platforma pobiera płatność w imieniu sklepu, sklep w Chain Flow otrzymuje jedynie powiadomienie, że płatność została przetworzona upstream. Praktyczna konsekwencja: logika fakturowania i wyzwalacze ERP muszą sprawdzać typ przepływu przed założeniem, że Twój sklep posiada rekord płatności. Zgodnie z dokumentacją przeglądu zamówień VTEX, każdy typ przepływu eksponuje odrębny podzbiór etapów statusu zamówienia, więc status taki jak waiting-for-seller-decision pojawia się wyłącznie w kontekstach Marketplace i Chain.

Complete Flow jest domyślny dla sklepów z jednym sprzedawcą. Jeśli Twoja architektura obejmuje marketplace wielovendorowy, w którym platforma i realizacja zamówień są rozdzielone między oddzielne konta, dane zamówień zostaną podzielone między przepływy Marketplace i Seller, każdy z własnym orderId widocznym tylko dla odpowiedniego konta. Przewodnik po architekturze marketplace VTEX opisuje, jak te przepływy mapują się na routing zamówień do sprzedawców; nie będziemy tu powtarzać tych szczegółów.

Pola orderForm są utrwalane w odpowiedziach API systemu OMS we wszystkich czterech typach przepływów, co oznacza, że dane pozycji zamówienia, pola niestandardowe i dane adresowe klienta pozostają dostępne niezależnie od roli, jaką pełni sklep. Różnica między przepływami polega na tym, które etapy statusów są obecne i czy dane płatności są własnością danego systemu, czy jedynie do niego się odwołują.

Chain Flow szczegółowo: sklepy pośredniczące i powiadomienia o płatności

Chain Flow ma zastosowanie wtedy, gdy sklep działa jako pośrednik między marketplace a sprzedawcą: otrzymuje powiadomienie o płatności zamiast bezpośredniej wpłaty – i właśnie ta różnica jest przyczyną większości błędów w integracjach.

W scenariuszu z wielopoziomowym magazynem rekord zamówienia w VTEX OMS sklepu pośredniczącego odzwierciedla zdarzenie powiadomienia o płatności, a nie rozliczoną płatność. Oznacza to, że progresja statusu zamówienia w cyklu życia wygląda powierzchownie identycznie jak w Complete Flow, ale etap płatności niesie inne znaczenie: pośrednik potwierdza otrzymanie powiadomienia, nie środków.

Każdy system downstream – middleware ERP lub webhook do uzgadniania finansowego – który traktuje ten status jako „płatność zatwierdzona", będzie generował fałszywe wartości w raportach gotówkowych. Przepływ pracy związany z uzgadnianiem wymaga jawnej obsługi na każdym etapie. Gdy zdarzenie powiadomienia o płatności trafia do sklepu pośredniczącego, Twój konsument powinien zapisać tymczasowy rekord oznaczony jako „powiadomienie otrzymane, niezakończone rozliczenie". Dopiero po tym, jak upstream marketplace potwierdzi rozliczone środki – zazwyczaj poprzez osobną aktualizację statusu – ten rekord powinien zostać awansowany do stanu rozliczonego w Twoim systemie ERP lub finansowym.

Zespoły, które pomijają ten dwuetapowy wzorzec zapisu i rozwiązują oba stany w ramach jednej transakcji, napotykają luki w uzgadnianiu między kanałami.

Edge case związany z oknem anulowania powoduje frustrujące doświadczenia użytkowników próbujących zarządzać swoimi subskrypcjami. Po powiadomieniu o płatności zamówienia w Chain Flow nadal przechodzą przez okres karencji klienta, zanim osiągną etap ready-for-handling. Jeśli upstream marketplace anuluje zamówienie w tym oknie, rekord VTEX OMS w sklepie pośredniczącym aktualizuje się niezależnie od tego, co pokazuje przepływ po stronie sprzedawcy. Integracje subskrybujące powiadomienia Hook w sklepie pośredniczącym mogą wywołać trigger realizacji jeszcze przed zamknięciem okna anulowania. Rezerwacja magazynowa wymaga wtedy ręcznego cofnięcia, ponieważ zdarzenie anulowania dociera kilka sekund później w osobnym wywołaniu webhooka.

W celu niezawodnego śledzenia zamówień w Chain Flow Feed v.3 jest bezpieczniejszym wyborem właśnie dlatego, że działa niezależnie od indeksowania. Hook uruchamia się raz na każdą zmianę statusu; Feed v.3 kolejkuje zdarzenie i przechowuje je do momentu, gdy Twój konsument je potwierdzi – dzięki temu system downstream, który przetwarza powiadomienie o płatności i następne anulowanie, otrzymuje oba zdarzenia w kolejności, nie w wyścigu. Zapoznaj się z dokumentacją VTEX Orders i poznaj pełną mapę statusów Chain Flow, aby skonfigurować ustawienia poprawnie przed uruchomieniem produkcyjnym.

Etapy statusów zamówień: znaczenie i co monitorować

Statusy zamówień w VTEX OMS nie mają jednakowego znaczenia dla systemów downstream. Większość statusów ma charakter informacyjny; pięć z nich to zdarzenia wymagające działania – dla integracji ERP, rezerwacji WMS lub przekazania do przewoźnika.

Cykl życia przepływu zamówień przebiega przez następujące etapy, zgodnie z dokumentacją pomocy VTEX:

Okno anulowania to status, który większość zespołów monitoruje zbyt rzadko. VTEX domyślnie ustawia 30-minutowy okres karencji przed przejściem do ready-for-handling; możesz go skonfigurować w VTEX Admin w sekcji Ustawienia sklepu > Zamówienia > Ustawienia (VTEX Help Center – Ustawianie okresu karencji dla anulowania zamówienia). Każde działanie WMS przed etapem ready-for-handling naraża na zmarnowaną pracę kompletacyjną przy zamówieniach, które zostaną anulowane w tym oknie bez żadnych kosztów.

W przypadku integracji ERP trzy statusy, które muszą wywoływać wywołania API, to: payment-approved (utwórz rekord zamówienia), ready-for-handling (zatwierdź rezerwację magazynową) i invoiced (zamknij realizację). Status canceled wymaga bezwarunkowej ścieżki wycofania w obu systemach; na podstawie naszych doświadczeń z wdrożeniami VTEX brakujące procedury obsługi anulowania są najczęstszym źródłem rozbieżności w stanach magazynowych w środowiskach produkcyjnych.

Feed v.3 vs Hook: wybór właściwego wzorca pobierania zdarzeń

Feed v.3 to kolejka oparta na modelu pull, którą odpytujesz według harmonogramu; Hook to webhook push, który VTEX wysyła do skonfigurowanego przez Ciebie URL (VTEX Developers – Feed v3). Właściwy wybór zależy od gwarancji dostarczalności, infrastruktury i wolumenu zamówień, ale dla większości produkcyjnych integracji Feed v.3 jest bezpieczniejszym wyborem domyślnym.

Feed v.3: niezawodne odpytywanie kolejki pod obciążeniem

Feed v.3 działa niezależnie od indeksowania VTEX OMS, co ma większe znaczenie, niż mogłoby się wydawać. Opóźnienia indeksowania, typowe podczas wyprzedaży błyskawicznych lub okresów wysokiego wolumenu, nie blokują pojawiania się zdarzeń Feed w kolejce. Każde zdarzenie zawiera orderId i nowy status; potwierdzasz odbiór jawnie, więc nieprzetworzone zdarzenia pozostają w kolejce do momentu, gdy Twój system je potwierdzi. Ta pętla potwierdzania sprawia, że Feed v.3 jest odporny na przejściowe awarie systemów downstream: jeśli middleware ERP zerwie połączenie, zdarzenie czeka zamiast znikać.

Częstotliwość odpytywania jest konfigurowalna. Na podstawie naszych doświadczeń z integracją VTEX Orders API dla klienta prowadzącego wyprzedaż błyskawiczną głębokość kolejki wzrosła do kilkuset niepotwierdzeń zdarzeń w ciągu kilku minut od uruchomienia kampanii. Feed v.3 sprawdził się bez zarzutu: zdarzenia były kolejkowane, pobierane w kolejności i potwierdzane bez strat. Architektura oparta wyłącznie na Hookach w tym samym scenariuszu wymagałaby po naszej stronie trwałego bufora przychodzącego, aby uniknąć gubienia webhooków przy skokowym obciążeniu.

Hook: powiadomienia push jako uzupełnienie

Hook sprawdza się w środowiskach o niższym wolumenie lub w przypadkach, gdy chcesz otrzymywać powiadomienia push w czasie zbliżonym do rzeczywistego do systemu zewnętrznego – usługi powiadomień dla klientów, pipeline BI lub lekkiego panelu statusów – bez zarządzania interwałami odpytywania. Skonfiguruj docelowy URL przez VTEX Orders API, a VTEX wyśle ładunek POST przy każdej zmianie statusu w cyklu życia przepływu zamówień.

Dokumentacja platformy VTEX jednoznacznie pozycjonuje Hook jako uzupełnienie Feed, a nie jego zamiennik. Gdzie to się załamuje: Hook nie oferuje wbudowanej gwarancji ponownej próby poza własnym mechanizmem dostarczania VTEX. Jeśli Twój endpoint zwróci kod inny niż 2xx, zdarzenie nie trafia ponownie do kolejki tak, jak dzieje się to w przypadku zdarzeń Feed.

Macierz decyzyjna

W przypadku każdej integracji dotykającej rezerwacji stanów magazynowych lub statusów zamówień w ERP prawidłowym wyborem jest Feed v.3. Hook stosuj dla konsumentów po stronie odczytu, którzy mogą tolerować sporadyczne pominięte zdarzenia.

VTEX Orders API: kluczowe endpointy, paginacja i filtrowanie dat

VTEX Orders API udostępnia dwa odrębne wzorce endpointów: endpoint listowy do odpytywania zamówień zbiorczego oraz endpoint szczegółowy do pobierania pojedynczego zamówienia po orderId. Prawidłowe skonfigurowanie paginacji i filtrowania dat od samego początku pozwala zaoszczędzić sporo czasu na debugowaniu.

Endpoint listowy: paginacja i filtrowanie dat

Endpoint listowy (`GET /api/oms/pvt/orders`) przyjmuje per_page maksymalnie do 30, żądania przekraczające tę wartość są po cichu ograniczane, co zaskakuje zespoły migrujące z systemów o wyższych domyślnych rozmiarach strony. Połącz go z parametrem page, aby stosować paginację przesunięcia w dużych zbiorach zamówień.

Filtrowanie dat wykorzystuje parametr f_creationDate w formacie ISO 8601 ze składnią zakresu:

f_creationDate=creationDate:[2025-01-01T00:00:00.000Z TO 2025-03-31T23:59:59.999Z]

Nawiasy kwadratowe i słowo kluczowe TO są wymagane, podanie pojedynczego znacznika czasu lub epoki Unix zwraca pusty zestaw wyników bez błędu, co sprawia, że błąd jest niezauważalny. Zgodnie z dokumentacją VTEX Orders API oba ograniczenia zakresu muszą być obecne. Używaj UTC przez cały czas, VTEX OMS przechowuje znaczniki czasu tworzenia w UTC niezależnie od skonfigurowanej strefy czasowej sklepu.

Endpoint szczegółowy i struktura orderId

Endpoint szczegółowy (`GET /api/oms/pvt/orders/{orderId}`) zwraca pełny obiekt zamówienia, w tym pola orderForm, które zachowują się z procesu checkout w reprezentacji OMS. Identyfikator orderId jest generowany w momencie, gdy wywołanie Place Order w Checkout API zwraca kod 201, od tej chwili zamówienie istnieje jako encja VTEX OMS i można je odpytywać przez ten endpoint.

Praktyczna uwaga z naszych wdrożeń VTEX: odpowiedź endpointu szczegółowego zawiera pełny payload orderForm, co oznacza, że dane na poziomie SKU, pola niestandardowe i metadane płatności są wszystkie dostępne. Zespoły budujące middleware dla ERP często pobierają pełny obiekt szczegółowy zamiast składać go z wielu wywołań. Filtrowanie krzyżowe po zakresach orderId nie jest obsługiwane na endpoincie listowym, do masowej ekstrakcji używaj f_creationDate, a następnie pobieraj rekordy szczegółowe pojedynczo.

W przypadku śledzenia w czasie rzeczywistym dokumentacja dla deweloperów VTEX rekomenduje Feed v.3 zamiast wielokrotnego odpytywania endpointu listowego, właśnie dlatego, że Feed v.3 działa niezależnie od indeksowania OMS, a nowo utworzone zamówienie pojawia się w kolejce Feed zanim pojawi się w wynikach endpointu listowego.

Łączenie VTEX OMS z ERP lub systemem back-office

Integracja ERP z VTEX OMS działa najlepiej, gdy traktujesz VTEX Orders API jako strumień zdarzeń, a nie cel odpytywania. Cykliczne zapytania do endpointu listowego wprowadzają warunki wyścigu na granicach statusów i generują zbędne obciążenie. Feed v.3 to właściwy wzorzec dla większości projektów middleware.

Feed v.3 jako fundament middleware

Feed v.3 zapewnia Twojemu middleware trwałą kolejkę zdarzeń aktualizacji zamówień. Każde wywołanie endpointu Feed zwraca oczekujące zdarzenia, przetwarzasz je, a następnie zatwierdzasz przesunięcie kolejki, potwierdzając odbiór. Ponieważ Feed v.3 działa niezależnie od wewnętrznego potoku indeksowania VTEX, przejścia statusów pojawiają się w kolejce szybciej niż w przypadku filtrowanego zapytania listowego, co ma istotne znaczenie, gdy generowanie fal kompletacji w ERP jest wrażliwe na czas.

Pętla integracyjna, którą powinno stosować Twoje middleware ERP:

1. Pobierz oczekujące zdarzenia z endpointu Feed.
2. Pobierz pełne szczegóły zamówienia przez `GET /api/oms/pvt/orders/{orderId}`. Zdarzenia Feed zawierają status i orderId, nie pełny payload zamówienia.
3. Wykonaj upsert rekordu ERP, używając orderId jako klucza idempotentności.
4. Zatwierdź przesunięcie Feed dopiero po pomyślnym zapisie do ERP.

Krok 4 to miejsce, w którym większość pierwszych wdrożeń się sypie, wyzwanie, któremu wiodące organizacje wychodzą naprzeciw dzięki starannemu planowaniu. Zatwierdzenie przed potwierdzeniem zapisu do ERP oznacza, że nieudany upsert po cichu traci zdarzenie, kolejka posuwa się naprzód, ale ERP nigdy się nie aktualizuje. Zawsze zatwierdzaj jako ostatni.

Idempotentność i obsługa błędów: Ponieważ awarie sieci i przekroczenia czasu ERP są nieuniknione, projektuj każdy upsert tak, aby był bezpieczny do ponownego odtworzenia. Przechowuj orderId i jego ostatnio przetworzony status w lokalnej tabeli stanu przed zapisem do ERP. Jeśli upsert się nie powiedzie, niezatwierdzone przesunięcie Feed oznacza, że zdarzenie zostanie ponownie dostarczone w kolejnym cyklu pobierania, a Twoja tabela stanu zapobiega podwójnemu przetworzeniu. Na potrzeby rekoncyliacji uruchamiaj nocne zadanie odpytujące `GET /api/oms/pvt/orders` filtrowane po krótkim oknie czasowym aktualizacji i porównujące wyniki z rekordami ERP. Każda luka ujawnia zamówienia, które wypadły podczas przedłużonej awarii, dając Ci czystą ścieżkę odtworzenia bez ręcznej interwencji w kanałach sprzedaży.

Hook jako uzupełnienie, a nie zamiennik

Hook (webhook push VTEX) wysyła powiadomienie na skonfigurowany URL przy każdej zmianie statusu zamówienia. W praktyce Hook sprawdza się dobrze jako warstwa alertów o niskich opóźnieniach, wyzwalając powiadomienie downstream lub lekką inwaliduację cache, jednak nie oferuje gwarancji dostarczenia ani mechanizmu odtwarzania, gdy Twój endpoint jest niedostępny. Do autorytatywnej synchronizacji ERP model pull-and-commit Feed v.3 jest bardziej niezawodny.

Częsty wzorzec w budowanych przez nas integracjach produkcyjnych: uruchamiaj Hook i Feed v.3 równolegle z oddzielnymi zadaniami. Hook obsługuje e-maile o statusie zamówienia dla klientów, podczas gdy Feed v.3 steruje aktualizacjami rezerwacji stanów magazynowych. Takie rozdzielenie utrzymuje niskie opóźnienia w komunikacji z klientami, jednocześnie zapewniając, że księga stanów ERP nigdy nie jest aktualizowana na podstawie niekompletnego lub niepotwierdzonego push.

Obsługa granicy orderForm

Pola orderForm zachowują się w odpowiedziach OMS API, co oznacza, że Twoje middleware napotka pola z etapu checkout, w tym szacunki wysyłki, tokeny metod płatności i pola niestandardowe ustawione podczas składania koszyka, wewnątrz tego, co wygląda jak czysty rekord zamówienia. Mapuj je świadomie w swoim schemacie zamiast je ignorować.

Kluczowe pola do jawnego mapowania:

• `paymentData.transactions[].payments[].paymentSystemName`: wymagane przez moduły finansowe, które uzgadniają sumy metod płatności online.
• `paymentData.transactions[].payments[].installments`: potrzebne do raportowania liczby rat i dokumentów fiskalnych na rynkach, gdzie taka treść jest wymagana prawnie.
• openTextField i wszelkie niestandardowe pola aplikacji customData: zawierają ustawienia specyficzne dla sprzedawcy, wprowadzone podczas składania koszyka, i łatwo je przypadkowo odrzucić.
• Pola invoiceData: referencje dokumentów fiskalnych, od których zależy przepływ należności w twoim ERP.

Ignorowanie tych pól grozi utratą danych, których potrzebuje moduł finansowy ERP. Dowiedz się, które pola konsumuje twój ERP, na wczesnym etapie mapowania, nie po uruchomieniu produkcyjnym.

Szerszy kontekst architektury platformy VTEX, który stanowi fundament tych punktów integracyjnych, znajdziesz w naszym przewodniku po platformie VTEX. Jeśli twoja konfiguracja obejmuje przepływy zamówień Marketplace lub Seller kierowane przez wiele kont, przewodnik po architekturze marketplace VTEX opisuje, jak routing zamówień wpływa na to, które konto otrzymuje dane zdarzenia w Feed.

FAQ: VTEX OMS, pytania techniczne, które deweloperzy zadają najczęściej

Co dalej: zasoby dotyczące platformy VTEX

VTEX OMS stoi w centrum szerszej decyzji architektonicznej dotyczącej platformy. Jeśli oceniasz całą architekturę, nasz przewodnik po platformie VTEX opisuje środowisko commerce, strukturę katalogu i powierzchnię API otaczającą dane zamówień. Zespoły budujące systemy wielodostawcowe, w których istotny jest routing zamówień w ramach Marketplace Flow i Seller Flow, znajdą w przewodniku po architekturze marketplace VTEX mapę tego, jak zamówienia sprzedawców i rezerwacja zapasów współdziałają między sklepami.

Jeśli twoja integracja obejmuje ERP lub dane katalogowe leżące u podstaw pozycji w zamówieniu, warto przeczytać przewodnik po integracji PIM z VTEX równolegle z dokumentacją OMS. Zespoły migrujące historię zamówień z Magento znajdą omówienie mechaniki w przewodniku po migracji z Magento do VTEX, a nie tutaj.

Netguru realizowało integracje VTEX OMS w złożonych środowiskach commerce. Jeśli Twój zespół zastanawia się, jak zdarzenia związane z zamówieniami propagują się w ramach rozdzielonych serwisów, nasz przegląd wzorców architektury headless commerce omawia podstawowe zasady projektowania.

Jeśli Twój zespół planuje wdrożenie VTEX OMS, integrację ERP lub konfigurację Marketplace Flow i chce skonsultować architekturę z ekspertami, porozmawiaj z naszym zespołem.