How LN's Integration Mapping Scheme translates to D365's family of distributed posting profiles, and how a project-pegged warehouse receipt travels from an IMS setup row to a D365 subledger voucher.
The posting engine is where a migration is won or lost. Every operational event — a goods receipt, a material issue, a labour confirmation, a project cost allocation — must produce exactly the right ledger entry. In LN, the Integration Mapping Scheme determines what "exactly right" means for every event in every module.
The Integration Mapping Scheme is LN's single, centralised, data-driven engine for translating logistic transactions into financial postings. It operates at two structural levels:
The IMS organises setup rows into categories, each covering a posting domain. The following table maps each major category to its D365 posting-profile surface.
The following scenario traces a single transaction — a goods receipt against a project-pegged purchase order — through the LN IMS and its D365 equivalent. This is the transaction type that most starkly illustrates the difference between the two systems.
LN starts with a logistic event, lets the IMS produce debit/credit pairs in the Financial Company's subledger, and then finalises those entries into the tfgld* general-ledger tables. D365 follows the same conceptual path, but the objects are named and layered differently.
The GL impact mapping is where the IMS translation becomes falsifiable. The table below gives the debit/credit pair that should appear for the common LN events and the D365 surface that must produce the equivalent result.
The hardest part of the IMS translation is not the common cases — item-group-to-posting-profile is mechanical — but the cases where LN's IMS uses a key that no D365 posting profile natively supports as a resolution key.
The IMS is LN's defining accounting construct. Translating it to D365 is the dominant financial workstream of the migration.