Govern project, item and cost-code identities across site systems

Start with the objects that cause real reconciliation work: legal entity, project, package, supplier, material, unit and cost code. For each, write a short definition of what one record represents and which attributes distinguish it from another.

A project code may identify a contract in finance and a planning programme in another tool. A package may be split differently in procurement and construction. Those differences are not necessarily errors. They need a mapping with a stated purpose, not an automatic demand that every system use the same hierarchy.

Assign a business owner for each type. Engineering decides material equivalence within its authority. Procurement maintains supplier relationships and purchasing attributes. Finance owns accounting dimensions. IT implements the approved controls and mappings; it should not decide commercial or technical meaning from a data-cleaning report.

In this fictional example, two valve records share size and a similar description, but differ in a specification that matters to their intended use. The duplicate-detection report proposes a merge. Engineering reviews the supporting specifications and rejects equivalence, so the records remain separate.

The team improves the descriptions and searchable attributes to make the difference visible. It can place both records in a common category for analysis without making one a substitute for the other. That delivers better discovery while preserving the purchasing and installation distinction.

If engineering later approves equivalence for a defined application, record the scope and effective decision. It does not automatically follow that every historical order, certificate or installed asset should be rewritten to the surviving code. Historical transactions need to retain the identity under which they occurred, with a traceable cross-reference where appropriate.

One central master can simplify governance when systems genuinely use the same objects and definitions. It also creates a dependency: every consuming system must handle changes correctly. A federated arrangement can work when systems have different purposes, provided ownership and mappings are disciplined.

Compare the two approaches against actual changes. Who creates a project? Who approves a new item? How quickly must a supplier correction reach site purchasing? What happens if the central service is unavailable? The best architecture is the one that supports those decisions reliably, not the one with the fewest tables.

ERPNext's Accounting Dimensions documentation gives a product example of using project and other dimensions for reporting. It does not define your cross-system identity model. Agree that model before configuring mandatory fields or bulk-importing codes.

A mapping needs source system, source identifier, target system, target identifier, relationship type, effective dates, owner and approval reference. If one source maps to several targets, record the approved allocation or interpretation. Do not hide a many-to-many relationship inside a spreadsheet lookup that returns the first match.

Reject code reuse that changes the meaning of historical records. A closed project's code should not become a new project simply because the list has grown long. Keep inactive identities searchable for history while preventing inappropriate new transactions.

Unit conversions need similar discipline. A purchasing pack and a stocking unit may be related, but the conversion can depend on the item and packaging definition. Store the approved relationship in the right scope and test receipts, returns and reporting after any change.

Before approving a merge or major correction, identify affected orders, receipts, invoices, assets, drawings and reports. Some systems may store the current master description beside historical values; others may render old transactions using the latest master text. Test what users will actually see.

Prepare a change record with the reason, evidence, affected systems, implementation steps and recovery approach. Take appropriate backups or exports under the organisation's controls. A reversible mapping change is different from an irreversible merge of transaction history; do not treat them as the same operation.

Run the change in a safe test environment with representative records. Verify totals, links, permissions and historical retrieval. If the receiving application cannot reverse a merge, that limitation needs an explicit decision before production work, not after the wrong records disappear.

Governance fails when creating a legitimate new record takes so long that users invent local aliases. Provide a clear request with the minimum evidence, a responsible owner and an escalation route. Let users search similar records before requesting another, but do not force them to choose an unsuitable item to satisfy a deadline.

Track repeated rejection reasons and temporary identifiers. A temporary code should have a defined scope, owner and reconciliation plan; it should not quietly become permanent across several systems. Show unresolved identities in reports rather than dropping their transactions from totals.

The Primavera–ERP integration guide shows why unmapped records must remain visible in control totals. The same principle applies to purchasing and material reconciliation: incomplete mapping should reduce confidence explicitly, not make the numbers appear cleaner.

Test a genuine duplicate, two similar but different items, a project split, a changed unit and a historical code lookup. A successful process resolves each with an accountable decision and preserves transaction meaning. Measure request turnaround and recurring mapping errors as well as duplicate counts.

The aim is a shared understanding of what records mean, supported by identities that systems can exchange safely. A smaller master list is helpful only when it improves that understanding.

1. Select the identity types behind one recurring reconciliation problem.
2. Assign business owners and define the attributes that make records distinct.
3. Review proposed merges and mappings against technical and commercial evidence.
4. Test historical transactions and recovery before applying the approved changes.