The posting engine

How IFS PostingCtrl — a centralised data-driven rules engine that resolves operational events into Code Strings — translates into D365's family of module-specific posting profiles, with a fully worked inventory-receipt example in both systems.

What you will be able to do

• Explain PostingCtrl structure: Posting Types, Control Types, and Control Type Values
• Trace how an operational event resolves a Code String through the PostingCtrl matrix
• Map each IFS Posting Type prefix to the corresponding D365 posting-profile surface
• Describe the granularity gap and how Item Groups and Default Dimensions bridge it
• Walk through a complete inventory-receipt posting example in both systems

Introduction

PostingCtrl is the single most operationally important accounting configuration in IFS and the single hardest to migrate without losing fidelity. It is the mechanism by which every IFS operational module — Inventory, Purchasing, Sales, Manufacturing, Maintenance, Projects, Fixed Assets — generates the correct accounting Code String when…

PostingCtrl in depth

PostingCtrl is organised by Posting Type. Each Posting Type has a code beginning with a prefix that indicates its domain:

How an event resolves a Code String

To illustrate the resolution process, consider an inventory receipt against a purchase order at Site FACTORY-NL, for a part whose Product Group is RAW-MATERIALS.

D365's posting-profile landscape

D365 implements the same conceptual function through a family of module-specific posting-profile surfaces. The key surfaces for an IFS migration are:

The granularity gap and dimension defaulting

The hardest part of the translation is granularity. IFS PostingCtrl rules can key off PART_PRODUCT_CODE and INVENTORY_VALUE_CLASS — IFS-side groupings with no direct D365 equivalent. These attributes must be absorbed into the Item Group taxonomy in D365, which is the single key that drives the Inventory Posting matrix.

Worked example: inventory receipt

Scenario: A purchase order line is received at FACTORY-NL for 100 units of part P100, Part Product Group = RAW-MATERIALS. Unit cost is EUR 10. The part belongs to D365 Item Group RAW-MAT. Default Dimension on the item carries CostCenter = CC-NL.

Worked example: M10 issue, control types and voucher trace

A receipt example proves the basic shape; an issue example proves why PostingCtrl is hard. Consider an IFS inventory issue from warehouse WH-NL for part P-771, Site FACTORY-NL, PART_PRODUCT_CODE=SPARES, PART_PRODUCT_GROUP=MAINT-SPARES, INVENTORY_VALUE_CLASS=HIGH, and no project.

GL impact per business event

For migration testing, each PostingCtrl family needs a transaction catalogue that states the expected debit, credit, MainAccount source and dimension source. A useful starter catalogue is:

Knowledge check

Summary

PostingCtrl is IFS's centralised operational-to-accounting bridge. D365 replaces it with a family of distributed posting-profile surfaces. The total configuration logic is equivalent; the work of translation is a design exercise per Posting Type, not a configuration migration.