Preventing ERP Imports From Overwriting Verified Asset Locations
Define field ownership between ERP and asset systems so routine imports cannot replace verified locations with stale procurement or cost-centre data.
How do you stop an ERP integration from replacing a verified physical location?
Agree which system owns each field and distinguish physical location from accounting attributes such as cost centre. Define how conflicting updates are reviewed, then test the integration with a newer verified location and an older ERP value. Preserve the source and history of accepted changes.
An asset team verifies a printer in Building B, but the next ERP import returns it to Building A. The import may be working exactly as configured: it treats the original procurement location as authoritative. The failure is a missing field-ownership decision. Integration design needs to say what each value means before deciding which system wins.
Separate fields that look similar
Map the physical site, room, responsible department, cost centre and delivery address as distinct concepts. They may coincide when an asset is purchased, then diverge after a transfer or restructuring. Ask operational and finance owners to describe how they use each value before merging fields with similar names.
Create a field-level ownership schedule showing the authoritative source, permitted update route and receiving systems. Include identifier rules so the integration matches the correct asset before changing anything. A reliable location rule cannot compensate for an interface that links records using a description shared by many identical items.
Specify how conflicts should behave
For each shared field, define whether incoming values are accepted, ignored, queued for review or used only when the destination is blank. Include effective dates and the provenance of observations where relevant. A generic latest-update rule can be misleading because a newly exported old value may appear more recent than a valid field observation.
Test an asset whose verified room differs from its ERP delivery address. Run the actual import path in an authorised test environment and inspect the saved record, change history and next export. Also test a legitimate approved location transfer so the rule does not prevent valid changes while blocking stale ones.
Monitor rejected changes as useful exceptions
Log conflicting updates with the asset identifier, field, incoming value, retained value and reason. Assign someone to review recurring patterns. A large number of rejected location changes may indicate an incorrect source mapping or an upstream process that still expects to own the field. Quietly discarding everything hides that design disagreement.
When a rule changes, record its approval and retest affected fields before the next full import. Reconcile a representative set of verified locations after scheduled runs. The objective is a stable division of responsibility between systems, not a permanent assumption that one application is correct about every attribute it holds.
Practical Example
Illustrative example: the ERP stores the department’s delivery address as Main Office, while fieldwork places printer PR-61 in the training annex. The integration previously copied delivery address into physical location every night. The team separates those fields and designates the verified location workflow as the source for room changes. A trial run retains the training annex, while the ERP cost centre still updates through its agreed finance-owned route.
Action Checklist
- 1.Map delivery address, physical location, department and cost centre as separate concepts.
- 2.Assign an authoritative source and update route to every integrated field.
- 3.Test stale incoming values against newer verified observations before rollout.
- 4.Record rejected or conflicting updates with enough detail for review.
- 5.Check representative verified locations after scheduled integration runs.
For integration rules that preserve verified field information, explore Asset Management Software.