Skip to content

Order-Push Flow — Successful Demonstration (ZWE-426)

ZWE-426

Closing subtask of the order-push milestone (ZWE-421). Demonstrates the full flow once end to end and answers ZWE-389's open question on whether order submission runs through Navision.

Answering the open question from NAV Scope docs (ZWE-389)

Yes — order submission runs through Navision, demonstrated end to end against the real NAV test sandbox. A backend order was built from real seeded data (ZWE-396), a SubmitOrder payload was generated (ZWE-423) and submitted (ZWE-424), and the result was independently confirmed present in NAV via GetSyncBuffer — not just inferred from a lack of error.

Caveat, tracked as a follow-up: "accepted" here means the order reached NAV's OCP synchronization queue, not the Transaction Journal. Moving it from the queue into the journal (DeleteSyncBuffer) is a separate, not-yet-wired step — see Caveats below.

Environment

  • NAV instance: zwerfkei_test_up test sandbox (zwerfkei.clouddesq.com:7157)
  • Service: Codeunit/NavSynchronization (the nav WSDL)
  • Backend: local development environment, Laravel backend against the seeded demo catalog (ZWE-396)

Step 1 — Build the order

A real Order + OrderLine was built from seeded catalog data: a Black Diamond Half Dome Helmet, quantity 1, real pricing and VAT rate, a real customer with a NAV nav_id, and a shipping method.

Step 2 — Generate and submit the payload

NavOrderPayloadBuilder generated the full SubmitOrder payload (NavOrder/NavCustomer/NavAddress/NavOrderLine, matching every field on the live WSDL type — see ZWE-423 for the two real WSDL quirks found along the way: strict struct-completeness and a 10-character VariantCode limit).

NavOrderSubmitter sent it via SubmitOrder. The call returned successfully — no SoapFault, no exception.

Captured proof — the accepted order's reference, stored on the backend order:

Order ID: 3
k3_document_number: "3"   (our own NavOrder.Id, sent to NAV - see note below)

Why the reference is self-generated, not returned by NAV

SubmitOrder_Result is a genuinely empty struct on the live WSDL — NAV returns no confirmation id. The reference stored is the NavOrder.Id the backend itself generated and sent. A successful call (no exception) is the only signal NAV gives that the submission was accepted for queuing.

Step 3 — Independently confirm it landed in NAV

A valid SubmitOrder response only proves the call didn't fault — it does not prove the order is retrievable in NAV. To confirm independently, NavSyncBufferReader (built for ZWE-495) was used to read NAV's OCP synchronization queue (GetSyncBuffer, table 11176106 — Orders) directly.

Captured proof — the live GetSyncBuffer response, showing the submitted order sitting in NAV's queue:

{
    "return_value": 1,
    "response": {
        "NavSyncQueue": {
            "EntryNo": 245492417,
            "Type": "2",
            "TableNo": 11176106,
            "RecId": "OCP Order Header: 3"
        }
    }
}

RecId: "OCP Order Header: 3" matches order id 3 exactly — independent confirmation that the submission reached NAV, not just a non-error response from the backend's own client.

Caveats and follow-ups

  • The order is in NAV's OCP sync queue, not yet in the Transaction Journal. Per the reference flow documented in reservation-cart-flow.md and the legacy Buffer.php implementation, a second step (DeleteSyncBuffer) is required to actually commit a queued entry into the Transactiejournaal. This is deliberately not automated yet on the new backend — flagged as a follow-up pending a flow-alignment call with Jasper (tracked on ZWE-495).

  • Stock precondition (found via the legacy codebase, ZWE-445): an order only reaches the Transactiejournaal if NAV has stock for the exact ItemNo + VariantCode combination on the line. If the variant is out of stock, the order stays silently stuck in the queue — no error is returned anywhere in the flow. Tracked on ZWE-488, which defines canOrderQuantity(variant, quantity) as a live-stock runtime check.

    Cart-time vs. submission-time

    ZWE-488 calls canOrderQuantity from the cart. This NAV failure mode is specifically a submission-time race (stock changes between cart-add and SubmitOrder) — worth confirming with whoever picks up ZWE-488 that the same check is re-run immediately before submission, not only at cart-add time.

    • Error handling for rejected submissions is covered separately — see ZWE-425: a failed/rejected SubmitOrder call is caught, logged with the correlating backend order, and never leaves the order falsely marked as sent.

SubmitOrder Reservation / Cart Flow Core Webshop Endpoints