How to establish where fixed assets and maintenance actually live in a QAD estate, and how to design the D365 target for both when the source evidence must come from a tenant.
Like the projects domain, this one has thinner source evidence than the rest of the path, and the honest thing is to say so at the start.
Where is the fixed-asset register maintained? Ask to see it. A register that finance maintains in a spreadsheet is common, functional and entirely legitimate — and it changes the migration from a data movement to a data cleanse plus implementation.
Where the register is in scope for migration, the extract needs to be complete at asset level.
The target separates the asset from its depreciation behaviour. An asset is defined once, with identity, class, location and dimensions. Each Book on that asset carries a depreciation profile, a service date, a value position and its own posting behaviour.
Depreciation posts with financial dimensions, and those dimensions carry the cost-centre, site and business-unit reporting that the controller reads every month.
The register load has a strict gate: net book values agree asset by asset. Aggregate agreement is not enough, because compensating errors between assets remain hidden until someone examines an individual asset — typically during an audit.
Maintenance is a separate decision from the fixed-asset register, and it needs its own justification.
Assets under construction need a home before they become assets, and two patterns exist.
The source material for this path contains no asset or maintenance entries, so this module locates the estate rather than mapping it. Establish where the register and maintenance actually live before planning anything, because migration, integration and implementation are three different plans.