Delta: MS Dynamics Business Central vs. Old Navision¶
ZWE-503
Closes out the two remaining ZWE-389 Definition of Done items, tracked as ZWE-503: a delta list of MS Dynamics relative to the old Navision, and the decision on sensitive-data handling. The planned meeting with the ERP administrator fell through — per ZWE-389, this milestone is deliberately not blocked by that, so this delta is produced from what's already documented and confirmed, with open items flagged rather than guessed.
"Old Navision" here means the current live integration: Navision 2018 over SOAP (K3 Retail / LS Retail extension), documented across Legacy Integration, Core Webshop Endpoints, Submit Order and the Endpoint Inventory. "MS Dynamics" means the target Microsoft Dynamics 365 Business Central REST API v2.0 (OData, OAuth2) described in the README.
Endpoint delta by capability¶
Nothing stays the same, deliberately
Every row below is Changed, Dropped, or Out of scope — none Stays the same. That's not an oversight: the move from SOAP to a REST/OData API changes the protocol for every capability that survives, so even functionally-equivalent endpoints (e.g. product/price/stock reads) still count as Changed. Nothing in this integration is expected to carry over byte-for-byte.
| Capability | Old Navision (SOAP) | Business Central (REST v2.0) | Delta | Notes |
|---|---|---|---|---|
| Product & variant catalogue | LS::GetProduct |
Items & inventory entities (e.g. items, itemVariants) |
Changed | Protocol moves from SOAP paging (queueEntryNo/cursor) to OData $filter/$select/$top. Exact entity/field names unconfirmed — see Open items |
| Pricing | LS::GetSalesPrice, Nav::GetPeriodicDiscount |
Price lists entities | Changed | BC's price-list API natively supports customer-specific pricing; the SOAP side's separate discount/multibuy endpoint may fold into one entity instead of two |
| Stock | Kei::GetRealStock |
Items & inventory (stock fields on the item/inventory entity) | Changed | Old Navision uses a dedicated single-item lookup; BC typically exposes stock as a field on the item entity itself — the standalone "real stock" call pattern likely disappears |
| Order submission | Nav::SubmitOrder |
Sales orders entity (POST) |
Changed, and an improvement | Old SubmitOrder_Result is a genuinely empty struct — no confirmation id is returned, which is why NavOrderSubmitter (Zwerfkei API) stores our own generated id as the reference. BC's REST API returns the created order's real id/number on POST, which removes that workaround entirely |
| Order status | Nav::GetOrderStatus |
Sales orders entity (GET, or a webhook) |
Changed | Old Navision is pull/buffer-based; BC's REST API supports webhooks, which could turn this into a push instead of a poll — worth a follow-up architecture decision once BC access exists |
| Order sync queue | Nav::GetSyncBuffer, Nav::DeleteSyncBuffer (OCP buffer) |
— | Dropped | This is a SOAP/OCP-specific polling/queue mechanism (see Legacy Integration). A REST API has no equivalent concept — the buffer layer goes away entirely once the connection moves off SOAP |
| Customer / membership account | LS::GetMemberAccount, LS::CreateMemberAccount |
Customers entity | Changed, unconfirmed mapping | Unclear whether BC's standard "customer" entity is a 1:1 replacement for LS Retail's loyalty "member account" concept, or whether that stays a separate LS Central retail feature. Flagged for the ERP administrator |
| Back-office / POS-only (purchasing, physical inventory, item import journals, label printing, session status) | Kei::PurchaseHeader/Line, PhysInventory, ItemImportJournal*, ItemLabelSetup, GetActiveSession, etc. |
Native BC back-office screens, not an API concern for Zwerfkei | Out of scope | Not called by the new webshop today (per Endpoint Inventory) and stays that way after the move — these are Zwerfkei Backoffice / back-office-team concerns, not webshop integration work |
Confirmed dead code (GetStore, StoreStockRequest, ShoppingCartRequest, SubmitReservation) |
n/a | n/a | Dropped | Already confirmed unused in the old codebase — nothing to carry forward |
Open items¶
These need the ERP administrator or the finalised BC blueprint to resolve with certainty — flagging rather than guessing, per the ZWE-389 milestone's own instruction not to block on the fallen-through meeting:
- Exact BC entity and field names are unconfirmed. Per the README: "Specific LS Central modules will be determined once the blueprint is finalised." This delta is capability-level, not field-level.
- Whether LS Retail's loyalty "member account" maps directly onto BC's standard customer entity, or remains a separate retail-extension feature.
- Whether BC's webhook support is actually used for order status (push) or whether the new backend keeps a pull-based pattern for consistency with how stock/price already work.
- Authentication in production: OAuth2/Azure AD (cloud) vs. Basic auth (on-prem) — depends on how Zwerfkei's BC environment is hosted, not yet confirmed.
Sensitive data handling¶
The ZWE-389 Definition of Done requires either a secure sharing channel for sensitive payload data, or a recorded decision to use anonymized data instead.
Decision: synthetic/sandbox data only, no secure channel needed
Every example payload captured across this milestone (Core Webshop Endpoints, Endpoint Inventory, Order Push Flow Demo) came from the NAV test sandbox (zwerfkei_test_up), using test data — e.g. test article 003027608 — not real production orders or customer PII.
Separately, the backend's own test suite (NavOrderSubmitterTest.php, zwerfkei-api) uses a synthetic customer id 500123 as a factory fixture — this is not a captured sandbox value and isn't cited by the 3 docs above; corrected here after a review question traced it and found no such value in any of them. No secure sharing channel was required or set up, since production data was never processed either in the sandbox testing or in the automated test fixtures.
If a future task needs real production payloads (e.g. validating against actual customer orders), a secure sharing channel must be established first — this is a prerequisite for that future work, not something resolved here.