2-M Logo2-M
Switch to French

Business Central · NAV · AX · Finance & Operations

Your ERP records very well. Answering is another trade.

Your group knows the ERP as a product. Its French entity runs it with a local configuration, and the figures sit in the database, exact and complete. What remains is the layer that gives them back the meaning the application added on screen.
Business Central, SaaS
BC
Dynamics NAV, on premises
NAV
Dynamics AX, on premises
AX
Finance & Operations, cloud
F&O

The starting point

Your data is right. Its meaning remains to be rebuilt.

An ERP is designed to write fast and without loss. Its data model follows that constraint: labels are stored apart, companies partitioned, codes abbreviated, and part of what the user sees on screen is calculated at the moment they look at it.

A faithful extraction of the tables therefore returns data that is right and unusable as it stands. It is the most frequent trap: the report gets built, it displays numbers, nobody sees an error, and the totals match nothing the controlling team knows.

Our work starts there. Rebuilding the calculations the application performed, aligning the reference data of the different companies, and checking figure by figure before anyone relies on it.

The four

What changes from one Microsoft ERP to another

They share a brand, not a data model. The way out and the main trap differ for each.

Extraction routes and points of attention by ERP
ERPFormHow to get the data outThe main trap
Business CentralSaaSOData API, or incremental export to a data lake when volumes exceed what the API quotas allow.FlowFields, calculated at display time, come out empty from any extraction.
Dynamics NAVOn premisesDirect access to the SQL database, with no intermediary and no quota, which remains the most comfortable route.One set of tables per company, prefixed with its name: consolidation is built table by table.
Dynamics AXOn premisesDirect access to the SQL database, with a data model that has nothing in common with NAV.Companies share the same tables, separated by a column: one forgotten filter doubles the figures.
Dynamics 365 Finance & OperationsCloudSynchronisation to Dataverse, then to a lake or to Fabric; the application database stays closed.The shape of the published data follows the entities, not the tables: the correspondences can be found.

The best known case

FlowFields, and why they come out at zero

In Dynamics NAV and Business Central, some fields contain nothing. A customer balance, the outstanding amount of an order, the available stock: these are FlowFields, calculated on demand from other tables. The field exists in the structure, the database does not store it.

An extraction therefore reports them empty, and the report built on top displays zeros or partial totals without ever flagging an error. We spot them during the inventory, we read their calculation formula in the application, and we rebuild them as DAX measures, which has the advantage of making them readable and editable, as they never were.

The common ground

Several companies, several ERPs, one figure

Your systems arrive as they are in a first layer, time-stamped. A second layer aligns the reference data, charts of accounts, dimensions and customers, and settles the duplicates. A third sets one definition per indicator. Reports, Excel and your applications then all read the same thing.

What does not change

Four tasks common to all four ERPs

Whatever the generation, the same four subjects decide the success of the project. None of them is technical.

The tasks common to any ERP consolidation
The taskWhat is at stake
The chart of accountsTwo entities that code the same account differently produce two totals, both correct.
Analytical dimensionsCost centre, project, activity: their meaning varies from one entity to another more often than expected.
Third partiesThe same customer carries several codes depending on the company that created it. It is the first task of a consolidation.
Depth of historyA ten-year load wakes up business rules abandoned since, and financial years nobody can explain any more.

Frequently asked

What people ask about ERP data

Why does ERP data call for a particular skill?

Because an ERP is built to record transactions safely, not to answer questions. Its model is normalised for writing: labels live in separate tables, companies are partitioned, and part of the figures shown on screen is calculated at display time rather than stored. Extracting the tables therefore gives data that is exact and unusable as it stands. The work consists in rebuilding the meaning the application added.

What are FlowFields, and why do they cause trouble?

In Dynamics NAV and Business Central, a FlowField is a field whose value is calculated on demand from other tables: a customer balance, for example, is the sum of their entries. The field exists in the structure and is empty in the database. An extraction therefore reports it as zero, and the report appears to work. We spot them during the inventory, we read their calculation formula, and we rebuild them as DAX measures in the semantic model.

We have several companies on the same ERP. Is it the same work?

The connection, yes. The alignment, no, and it is the alignment that makes the project. You have to decide what an account, a dimension and a customer mean for the whole, while each entity built its codes independently. This arbitration is led with your finance and business teams; we come out of it with a mapping table, and a figure-by-figure reconciliation before any switch-over.

Our ERPs differ from one subsidiary to the next. Is that workable?

Yes, and it is our most common ground. A historical NAV in one subsidiary, a recent Business Central in another, an AX somewhere else: each releases its data by its own route, then all join the same chain. The hard part is not the variety of connectors, it is making reference data built separately say the same thing.

Do we have to migrate to Business Central before doing BI?

No, and the reverse often helps more. A business intelligence project run on the existing system reveals the real state of the reference data and how the rules have diverged, which is exactly the preparation work of a migration. Companies that chain the two in this order approach the migration with a map they would not otherwise have had.

Do you work with the integrators who deploy the ERP?

Regularly. An ERP integrator knows its client’s business and the configuration of the solution; the decision-support layer calls for other reflexes: dimensional modelling, arbitration of rules, model performance. We work on that layer, alongside the team that carries the ERP, without encroaching on its ground.

Two hours to look at your ERP and tell you what is feasible.

Eleven expert consultantsSaint-Priest, near Lyon, France

A scoping workshop with a consultant: we open your source inventory, we spot the FlowFields and the reference data that diverge, and we give you a target architecture and an order of magnitude.

Request a scoping workshop

Scoping workshop · 2 hours · free · near Lyon or remote

Our technologies

Microsoft FabricPower BIPower AppsPower AutomateMicrosoft Partner