Redesign the business-unit and tableset-sharing model — the mechanism that decides which reference data a transaction can see — into D365 legal entities, operating units, sites and a deliberate shared-reference policy.
PeopleSoft separates two ideas that most ERP products merge, and understanding that separation is the whole of this module.
A PeopleSoft business unit is a processing boundary, and each functional module has its own. A General Ledger business unit carries ledger and balancing scope. A Payables business unit owns vouchers and payment processing.
The matrix is one row per business unit, per module, and it carries the evidence that supports a disposition rather than the disposition alone.
The second matrix is one row per record group, and its output is a policy rather than a mapping.
Vendors and customers deserve their own treatment, because both are rated high confidence direct mappings at the object level and both carry a redesign at the sharing level.
PeopleSoft balances transactions that cross unit boundaries through affiliate ChartFields and balancing rules, producing due-to and due-from entries inside its own model. The posting-rule set maps this to D365 intercompany accounting and reporting dimensions, and marks the mapping status partial with the plain note that this is often a…
PeopleSoft control tables are widely effective-dated, and the gap register rates effective-dated control tables as a medium-impact data-model gap with the note that D365 target handling varies by object.
Below the entity boundary sits the operational structure that D365 expresses as sites, warehouses and, where relevant, operating units of other kinds.
The dependencies run in one direction, and the playbook's wave structure reflects them.
Organisational modelling on a PeopleSoft programme is the work of collapsing three source questions — where is it processed, what can it see, who owns it statutorily — into the one boundary D365 recognises.