# Magento and Microsoft Dynamics NAV, Kept in Step: Prices, Stock and Orders Without Retyping

> How we connected Mage-OS and Hyvä to Microsoft Dynamics NAV: products, per-store prices and stock, promotions, orders, invoices and cancellations kept in sync.

URL: https://magento.zip/case-studies/erp-integration-microsoft-dynamics-nav · Generated: 2026-10-30 03:34 UTC

A multi-location retailer ran its whole business in **Microsoft Dynamics NAV**: items, prices for every store, stock in every warehouse, customers, orders and invoices. The online store had to show exactly what NAV knew, and every web order had to land in NAV as if a salesperson had keyed it in. When the two drifted apart, customers saw wrong prices or stock, and staff spent their day fixing orders by hand.

### The challenge

The retailer already had a NAV connector from a third party, but it was not reliable enough to trust with the catalog or with orders:

- **Large reads broke.** Paging through tens of thousands of records used the paging style Microsoft advises against, so records could be skipped or duplicated when data changed during a run.

- **No timeouts and no retries.** A slow ERP response could hang a sync forever, and one failed call was simply lost.

- **Half-finished runs.** A sync that failed part-way left the store in a mixed state, with some products updated and others not.

- **Hard to see what happened.** Logging was thin, so a wrong price on the website took a long time to trace back to its cause.

On top of that, the business is not simple. Every store has its own price and its own stock. Clearance prices run in date windows per store. Product sets are assembled from separate items. Promotions are defined in NAV. And NAV staff edit orders after they are placed: they add a line, change a quantity or cancel, and the web order has to follow.

### What we built

We rewrote the integration from the ground up as a family of small Mage-OS modules on one shared connection layer. Each part does one job and can be switched on, previewed and run on its own.

**From NAV to the store:**

- **Products** from the NAV item card, with an admin field mapping, so new items appear on the site and changed items update.

- **Categories** built from NAV's own item grouping, as a two-level tree.

- **Product sets** from NAV assembly lists: the set and each piece in it become products, linked together.

- **Price and stock per location**, so a shopper who picks a store sees that store's price and availability.

- **Clearance prices per store**, with their start and end dates.

- **Promotions** turned into Magento cart price rules, so discounts apply in the cart automatically.

- **New store locations**: a store opened in NAV appears on the site, ready for staff to add opening hours and a map.

**From the store to NAV and back:**

- **Orders** go to NAV with the customer, every line, its discounts and the payment.

- **Invoices, shipments with tracking, and cancellations** made in NAV come back to the Magento order.

- **Order changes made in NAV** (added, changed or removed lines) are applied to the web order, and its totals are recalculated.

**For staff:** sync panels in the Magento admin with preview and dry-run, a per-product "what changed" view, a read-only search of NAV orders, items and customers, and a query tool for NAV's web services, so the web team can answer most questions without asking the ERP team.

### How it works

**Keeping the catalog in step**

- NAV flags an item when someone changes it. On a schedule, the store asks NAV only for flagged items and only for the fields it needs.

- The connector follows NAV's own page links to the end of the list, with a timeout on every call and automatic retries with a growing wait when NAV is slow or busy.

- Each product is compared with what the store already has, and only the fields that changed are written, so manual edits by the web team are not overwritten.

- Stock, store prices and clearance windows are updated for that item at every location.

- When the item is saved, the store tells NAV, and NAV clears the flag. An item that failed keeps its flag and is picked up again on the next run.

- The page cache and the CDN are cleared after a sync that changed something, so shoppers see the new price straight away.

**Sending an order to NAV**

- The order waits in an export queue until its payment is confirmed.

- Every SKU is checked against NAV first. An order with an unknown item stops here, with a clear reason, instead of creating a broken order in NAV.

- The customer is looked up in NAV by email: updated if found, created if not.

- The order header is created and NAV's order number is saved at once, then each line with its discounts, then the payment.

- Each step is recorded. If a step fails, the export is marked failed with the error and retried later, up to a set number of attempts, and it carries on from where it stopped instead of creating a second order.

- The NAV order number and the export status show in the Magento order grid, so staff can see at a glance which orders have reached the ERP.

**Bringing NAV's changes back**

- Invoices, shipments, cancellations and order edits from NAV go into their own queues.

- Scheduled jobs work through the queues: they create the Magento invoice or shipment, apply line changes, recalculate totals, cancel and release stock.

- A record that fails is kept with its error and retried, and every queue has its own admin grid.

### Under the hood

- **Store:** Mage-OS (open-source Magento 2) with a Hyvä storefront.

- **ERP:** Microsoft Dynamics NAV, reached through its OData web services, plus NAV's custom actions for creating orders and confirming syncs.

- **Scheduling:** Magento cron jobs per area (items, stock and prices, clearance, promotions, order export, invoices, cancellations), each with its own schedule, plus command-line and admin buttons that run the same code.

- **Queues and status tables** for every order-side flow, so nothing is lost when a call fails and every record has a visible state.

- **Locks**, so a scheduled run, a command and an admin button can never run the same sync at the same time.

- **Safe full rebuilds:** a full stock resync loads into a staging table and is checked before it replaces live data.

- **Logs per run** with the requests and answers, kept for a set number of days.

- **Unit tests** on the pricing rules, the part where a mistake costs money.

### What it changed

We don't publish the client's sales figures. What we can describe is what the business can now do:

- **One place to change things.** Staff edit items, prices, promotions and orders in NAV, and the website follows on its own.

- **Bad prices are stopped at the door.** The price import refuses an extreme price move for a single store (a sudden large drop or rise, or a zero price), keeps the last good price and emails an alert. An hourly check compares the store with NAV again and repairs any drift.

- **Clearance prices behave.** A future or expired clearance window can never replace one that is running today. A weekly full refresh fills in any store price that went missing; before it existed, a lost clearance price could sit at full price for days until someone noticed.

- **Failures are visible and recoverable.** Every order shows whether it reached NAV; a failed one is retried, and staff can re-send it with one click.

- **New stores go live without a developer.** A location opened in NAV appears on the site; existing store details the web team corrected are never overwritten, and differences are reported instead.

- **Fewer questions to the ERP team.** The web team can look up NAV orders, items and customers from the Magento admin.

### Could this work for you?

If your stock, prices or orders live in an ERP (Microsoft Dynamics NAV or Business Central, or another system with an API) and your online store is a second copy that someone keeps in step by hand, this is the kind of work we do. It suits:

- retailers with several stores or warehouses, each with its own price and stock;

- businesses whose staff edit or cancel orders in the ERP after the customer has paid;

- stores stuck with an old connector that nobody trusts any more.

We often do this work together with a move to Mage-OS and Hyvä: see the Magento 1 to Mage-OS + Hyvä migration and the Magento 2 to Mage-OS + Hyvä upgrade, or all our services. To talk about your ERP, get in touch and tell us which system you run and what has to stay in step.

## Links

- [Page](https://magento.zip/case-studies/erp-integration-microsoft-dynamics-nav)
- [Store guide (llms.txt)](https://magento.zip/llms.txt)
