Consider a service description held in two engineering fields that needs to fit into three asset management fields of 25 characters each. A direct copy may lose information. “Pressure” and “PRESS” may describe the same thing, while two similar-looking descriptions may refer to different duties. The reconciliation rules need to account for both.
A missing tag raises another question. Has equipment been added, retired, renamed, or simply omitted? Automatically creating a record can carry an unresolved assumption into the receiving system.
Other differences involve engineering decisions. A datasheet issued for review may describe the correct instrument, but it does not carry the same status as one issued for construction. Matching the tag and model number will not resolve that difference. Someone responsible for the engineering information needs to review it.
These are useful questions to settle before building the merge:
- Which differences can be handled by an agreed rule?
- Which need a person to investigate?
- What information must remain specific to each system?
The software should make those decisions traceable and keep unresolved records visible. Once approved changes are exported, the team also needs to check that the receiving systems accepted them.
CoreData’s custom software work includes this kind of industrial data reconciliation. Our detailed account of the reconciliation approach explains the checks, exception handling and controlled return of data to the source systems.