Scope tax determination, statutory reporting and electronic invoicing for a CloudSuite Industrial migration when the source evidence names statutory outputs only as a triage category — and set the discovery that closes the gap.
This is the thinnest domain in the CloudSuite Industrial evidence base, and the honest thing to do is to say so at the start and then be useful anyway.
The statutory obligation attaches to the legal entity. The concept mapping records the entity as the default statutory anchor, qualified by the statutory test. Whatever survives that test as a D365 legal entity is what files, registers and reports.
Where the source evidence is absent, the target evidence is complete, and the design should be anchored there. D365 offers four distinct mechanisms and the design task is choosing between them per obligation.
The artefact this module produces is a statutory inventory, and its defining property is that it is keyed on obligation rather than on source artefact.
For each row in the inventory, the choice between the four target mechanisms follows a consistent order.
The gap in the evidence base is closed by a short, specific discovery pass. It is short because the questions are narrow, and specific because an open-ended "review localisation" task will produce a document rather than a decision.
The evidence base for CloudSuite Industrial says almost nothing about statutory behaviour, and pretending otherwise would produce a mapping table that reads well and describes nothing.