The source package carries no localisation register, so this module maps what the evidence does support — tax lines inside the invoice and voucher patterns, statutory outputs produced by SQR and BI Publisher — and states plainly what must be established in the client estate.
This module is different from the others in this path, and it is worth saying why before anything else.
Three things about tax and statutory reporting are supported by the source package.
Everything else. The discovery set below is the minimum needed before a localisation design can be attempted, and none of it can be inferred from the source package.
In the source, tax on a transaction is ultimately expressed as accounting distributions within the invoice or voucher accounting entries. How those distributions are derived varies by estate — through tax configuration, through defaults on the customer, vendor or item, through the billing or voucher line structure, or in some estates…
Every statutory output in the target reaches one of three destinations, and the choice is an architecture decision with cost and support consequences.
The reporting estate is where statutory outputs currently live, and the customisation register's guidance applies directly.
Effective dating deserves a specific decision for tax, because the consequences are asymmetric.
Because this module is discovery-led, it is worth being explicit about the dependencies it creates elsewhere.
This module maps what the evidence supports and marks the rest as discovery, because the source package for PeopleSoft FSCM contains no localisation register and inventing one would be worse than acknowledging the gap.