Why an LN migration forces you to collapse two company types into one and re-express a centralised posting engine as a distributed family of posting profiles — and what that means for every design decision that follows.
What you will be able to do
Explain why the Logistic Company / Financial Company split is the first thing that surprises a D365 architect
Describe the IMS as LN's centralised bridge between operations and finance
Name LN's two defining conceptual primitives and articulate their D365 counterparts
Explain the VRC code-layering model and how it differs from D365 extensions
Describe what the D365 single-company model forces you to decide on Day 1
Introduction
Every ERP migration eventually collides with an uncomfortable truth: the two systems do not merely store data in different tables — they reason about the business in different conceptual languages.
The Logistic Company / Financial Company split
LN's most consequential architectural decision — and the first thing that surprises a D365 architect — is the explicit separation between two types of company.
The IMS — LN's centralised posting engine
The Integration Mapping Scheme is the bridge between LN's operational world and its accounting world. Introduced in BaaN V and conceptually stable across releases since, it is a data-driven rules engine that evaluates every logistic event — a goods receipt, a material issue, a production completion, a project cost allocation — and…
Project Pegging — LN's second defining concept
Project Pegging is LN's mechanism for tracking costs through the supply chain directly to project activities. A purchase order line pegged to a project activity carries that peg reference through goods receipt, through inventory, through production, through labour confirmations, and into the general ledger — at every step, the IMS reads…
VRC — the extensibility and code-layering model
LN customisation is structured through the Version-Release-Customer (VRC) framework, a three-layer code architecture:
Knowledge check
Summary
LN and D365 F&O both achieve accounting-grade operational tracking. They reach that result through fundamentally different architectural choices, and the migration is the work of re-projecting those choices onto D365's model.