How to resolve QAD's three-level organisational structure into a D365 legal-entity model without inventing statutory boundaries that the business never had.
Every module that follows depends on this one. The chart of accounts, the dimension design, the inventory ownership model, the intercompany configuration and the entire wave plan are downstream of a single question: how many legal entities are there, and which QAD construct becomes each one?
Start by being precise about the source, because loose language here produces bad targets.
Before proposing any target topology, classify every QAD entity into one of three buckets. This is a discovery deliverable with a named owner, not a workshop opinion.
The default is clear: a QAD site becomes a D365 site with a financial dimension. Elevation to a legal entity should be the justified exception. Three conditions justify it.
Every identity you decline to elevate has to reappear somewhere, or it is simply lost. That somewhere is the financial dimension set.
The finance notes for this adapter are unambiguous: intercompany is a design decision, not a default import. The posting rules reinforce it — the intercompany family is recorded as a gap with low confidence, and explicitly depends on the confirmed domain and entity design plus whether shared-service or centralised finance patterns exist.
The output of this module is one artefact, and it should be short enough that a steering committee reads it.
QAD's domain, entity and site structure has no clean counterpart in D365, and the mapping is a decision rather than a translation. Classify every entity as posting, operational or reporting-only against statutory evidence, elevate sites only for statutory obligation, genuinely different functional currency or separate ownership, and…