Separate Asset Management business-unit scoping from Book scoping, translate acquisition and depreciation accounting into asset posting configuration, and treat convention and useful-life differences as a Book-level review rather than a data mapping.
Asset Management is one of the better-evidenced domains in this source package, and it comes with a warning attached.
An Asset Management business unit answers which processing scope owns this asset. It determines who maintains it, which defaults apply, and — through its association with a GL business unit — where the accounting lands.
The depreciation rule's second instruction is the more time-consuming of the two, and it has to happen before any history is loaded.
Fixed asset groups in the target drive posting configuration and default depreciation behaviour. That makes them a configuration object rather than an analytical one, and it sets the rule for reduction: a group should exist where accounting or default depreciation genuinely differs.
Assets arrive in the target by more than one route, and each route intersects a design owned elsewhere.
The playbook places fixed assets, Books and opening balances in the same wave as projects. Four decisions govern the load.
The concept note's qualifier — straightforward only if custom book logic is limited — points at the same estate the Development & Architecture module inventories.
To close the evidence boundary honestly: the source package documents asset accounting. It contains no concept mapping, posting rule, customisation surface or gap entry addressing maintenance, work orders, preventive maintenance schedules, or enterprise asset management.
Asset Management converts cleanly when two scopes are kept apart and one review is done before the load.