Magento Business Central: Integration with Microsoft Dynamics 365 and Navision

Navision was for a long time the common name of an ERP system that later ran under the name Microsoft Dynamics NAV. Microsoft Dynamics 365 Business Central has grown out of this system. In daily speech many people still say Navision when they mean their system, even if they already work with Business Central. For the Magento Business Central integration the exact name matters because version and operating mode determine the interfaces.

Business Central exists as a cloud solution and for operation in your own house. That is decisive for the integration because login methods and access rights differ. With Magento Business Central in the cloud, applications log in through Microsoft Entra ID with OAuth 2.0. In your own house the login depends on the setup and must be released by the administrator, for example the simple login with user name and access key.

Navision installations often run for many years and were adapted: own fields, own reports, own processes. That makes every integration a little individual. The Magento Business Central integration therefore always begins with three questions: which version do you use, who looks after your system, and which customizations exist? Only then can it be said seriously which way fits.

Which data flows in Magento Business Central you define with us in the inventory. Typically there are five areas that can be implemented individually or together.

Not every Magento Business Central project needs all five areas. A project often begins with orders and stock and later grows by prices and documents. This way you see results quickly and can use the budget in stages.

The table shows a typical pattern. In your business it may differ, and that is exactly what we clarify in the inventory.

With Magento Business Central a clear rule on data ownership prevents most disputes. Whatever can be changed in both systems leads to contradictions sooner or later. That is why we define exactly one leading system per type of data and describe the rule for the conflict case. The same terms do not always mean the same: an article status in the ERP can have several states in the shop, and a tax code must lead to the same rate in both systems.

For Magento Business Central this applies: Business Central provides a programming interface in version 2.0 through which applications exchange data by REST. For this Microsoft describes the approach of so-called connect apps, in which an application of a third party exchanges data with Business Central through standard calls. There are matching endpoints for articles, customers, sales orders and invoices.

Whoever has to map peculiarities of your system, for example self-created fields or special processes, can provide additional interfaces as an extension in the programming language AL. That does not change the core of the ERP and stays traceable on updates. Whether that is needed is shown by the inventory.

Business Central assigns the rights through permission sets. We work with a separate access that has only the rights the integration needs. That protects your data and can be traced at any time. Which login and which endpoints apply to your version and operating mode we check before the quote, because with cloud and own operation they differ.

For Magento Business Central and Navision there are add-on products and integration platforms. Whether one of them fits your process we check honestly before a decision. If an existing product covers your requirements, it is often the more economical choice, and we will tell you so.

An individual development of Magento Business Central pays off if your processes deviate from the standard: special price rules, several warehouses, special articles, payment terms per customer or an adapted Navision that standard products do not know. It is more expensive at the start but fits exactly. Often a mix makes sense, in which proven parts are used and only the deviations are added.

A middleware pays off if more than two systems are connected, for example shop, ERP, product information system and shipping provider. The decision aid is in the guide to ERP integration. For the shop side the guide to the B2B shop is also worth a look if customer prices and company accounts play a role.

On the Magento side we build the integration as its own module according to the standards of the system, without interventions in the core. The module uses the interfaces and queues of Magento so that transfers run in the background and the shop does not become slower for visitors. Orders are placed in a queue on arrival and processed there until the ERP has confirmed them.

Prices by customer group, tier prices and several warehouses are mapped by Magento with its own functions that the integration fills. Where possible we use these standard functions instead of inventing our own tables. That keeps the shop update-capable and lets other developers join in later.

In the admin you see what was transferred: a log shows date, record and result, with a filter for errors. For the peculiarities of Business Central we add settings in the admin, for example assignments of payment methods, shipping methods and tax classes, so that changes need no development.

Business Central adds an advantage: if a test environment exists, the data exchange can be practiced there safely before productive data is touched. We build Magento Business Central against this test environment first and switch to the productive data only after your approval.

We see these points again and again in projects. They can be planned if they are known early.

• Adapted Navision

  Own extensions in the ERP change the interfaces and must be known beforehand.

• Unclear data ownership

  Prices or customer data are changed in both systems and overwrite each other.

• Missing monitoring

  A failed transfer is noticed only after days because nobody looks at the log.

• Updates in the ERP

  After a version change the integration no longer works because it was not tested.

• Special cases

  Partial deliveries, returns, credit notes and foreign orders are missing in the concept.

• Too much real time

  Transferring every change immediately increases load and effort without the business needing it.

An integration connects two systems with business data, so clear rules apply. The exchange runs encrypted, credentials do not lie in the source code but in the protected configuration, and the integration receives only the rights it needs. Access belongs to a separate service account, never to a private account of a person.

When testing we work with test data or anonymized data as far as possible. As soon as developers get access to personal data, for example customer accounts or orders from Business Central, an agreement on commissioned data processing is needed. We clarify that before the start so that you are legally well set up.

The log of the integration contains what is necessary for operation but no credentials and no unnecessary personal data. Retention periods are defined with you. These notes are not legal advice, the concrete arrangement depends on your company.

We keep the start deliberately short so that you quickly know whether and how the integration is feasible.

The following constellations are examples from the practice of Magento Business Central projects, not statements about particular customers. The first is a wholesaler whose customers each have their own prices and tiers. Prices lie in the ERP, the shop is to show them after login, and orders are to arrive in the ERP without retyping. Here the data flow for prices and orders is at the center, the timeliness of stock is secondary.

The second constellation is a manufacturer with many variants and several warehouses. The challenge lies in the assignment of variants between the systems and in the question from which warehouse the shop calculates availability. A clean assignment of the numbers is the foundation, otherwise duplicates arise that have to be cleaned up at great effort later.

The third constellation is a merchant with a Navision adapted over years that contains its own fields and processes. Here the project begins with a thorough analysis because standard knowledge is not enough. The result can also be that part of the wish is not feasible or only at high effort. We say so openly before you invest. That too is a result that saves you money.

An interface is not a one-off project but ongoing operation. After the start a log monitors every transfer: what was transferred when, what failed, what is repeated? Errors that cannot be fixed automatically are reported visibly so that nobody learns of them only through a customer complaint.

Updates change the situation. A Magento update, a new state at Business Central or a change of the vendor interface can affect the integration. Therefore the planning includes an agreement on how updates are tested and who approves them. Ongoing care can be regulated through a maintenance contract that covers monitoring, updates and error fixing.

Documentation is part of the delivery. You receive a description of the data flows, the assignments and the rules for special cases so that your team or another provider understands the integration and can continue it. Source code and access stay with you.

A flat figure for Magento Business Central would be unreliable because the effort depends on your constellation. It is determined by the number of data flows, the quality of the data in Business Central, the number of special cases with prices, warehouses and customers and the required timeliness. A data flow in one direction is built much faster than a synchronization in both directions with conflict rules.

We work with an open hourly rate of 30 euros net, without emergency surcharge. After the inventory you receive a written estimate that lists the data flows individually so that you can control scope and order yourself. For clearly defined packages a fixed price is also possible. All prices are on the page pricing.

Besides the development, include the running items: hosting, maintenance and, where applicable, licenses or fees for Business Central and for additional services. We show these items separately in the estimate so that you can compare quotes over several years.

An honest offer includes naming the limits. We do not sell a ready-made connector off the shelf but develop Magento Business Central project by project according to your processes. That means: we implement exactly what you need, but not in a day and not for a flat price that cannot be calculated beforehand.

We are a web agency in which fixed freelancers work together, all from home offices. We are not a large agency with a hundred employees and cannot take on every project at every time. We tell you early whether and when we have capacity. We name customers only with their consent, and in the first conversation we gladly talk about comparable constellations.

We give no legal advice. Questions about commissioned data processing, data protection and the license terms of Business Central you clarify with your legal adviser and the vendor. What is technically possible depends on version, operation and license of your system and is checked in the inventory.