An online store sells bottles in cases of 12. Its ERP tracks stock by the bottle. When an order for two cases arrives, the warehouse needs instructions for 24 bottles, with the correct pack information attached. Passing “quantity: 2” between applications leaves a decision for someone on the warehouse floor to resolve.
We'll use this bottle example to follow the setup decisions behind an order. The product mapping needs a selling unit and a conversion that both applications understand, with someone responsible for updating that relationship when the packaging changes. That continuing work is part of ERP master data management.
What Is ERP Master Data Management?
ERP master data management establishes how a business maintains the core records used by its ERP and connected applications. Each record has a defined identity and an accountable owner. Rules govern its creation and subsequent changes, including how approved information reaches the applications that use it in daily operations.
A customer account is one example. It describes the customer and is reused across transactions, potentially for years. An invoice records a particular transaction involving that account. Country codes belong to reference data, which provides standard classifications. These distinctions are covered in IBM's overview of master data management.
| Master record | Information to maintain | Used in |
|---|---|---|
| Product | Product identifier and unit relationships | Order processing and stock movements |
| Customer | Account identity and billing details | Sales orders and invoices |
| Supplier | Supplier identity, contacts, purchasing status | Purchase orders and invoice matching |
| Facility | Facility identifier and location details | Receipts and transfers |
An online store and ERP can retain their own identifiers for the same product. The mapping between them establishes the shared identity; the associated attributes establish how that product is handled.
Who Owns the Information?
When finance approves a customer's payment terms, the integration specification should name the application that publishes the approved value. It should also identify who can authorize another change. A developer shouldn't have to infer that authority from whichever application happens to send an update last.
A customer editing their display name in the online store isn't necessarily requesting a change to the legal name on their invoices. Copying the whole account record into the ERP risks overwriting that billing detail, so the update rules need to specify which fields the store is allowed to change.
For product content, a product information management system, or PIM, might own descriptions and sales-channel attributes. Master data management has a wider scope that includes supplier and customer identities. Where the responsibilities overlap, a documented owner prevents the PIM and ERP from repeatedly overwriting each other's changes. The receiving application can hold a local copy while leaving editing authority with the source.
Two subsidiaries buying from the same supplier may have negotiated different payment terms. Their shared supplier identity needs room for both arrangements, including which company each applies to.
Finding the Source of Duplicate Records
A salesperson searching by a trading name won't always find an account filed under the legal company name. Creating another account gets the order moving, but subsequent sales start accumulating under separate records. By the time someone investigates the divided sales history, both accounts could have open orders attached to them. The search behavior belongs in the investigation too: allowing recognized alternative names gives the next salesperson a better chance of finding the original account.
Integrations need stable internal identifiers, with external references stored against them. Account 123 in the CRM and account 123 in the online store remain separate references until a mapping connects them.
Before combining accounts, the reviewer has to establish that they represent the same entity and examine their linked orders. A matching address doesn't prove much when separate businesses occupy the same building. Branches may also have their own accounts for a reason, such as separate billing arrangements.
Connected applications might continue sending the old identifier after a merge. Keeping a mapping to the surviving account allows those references to resolve. Deletion needs a review of transaction dependencies and retention requirements before anything is removed. Where the aim is simply to stop new orders against an inactive account, deactivation can preserve the history already attached to it.
Validation Across Forms and Imports
Required fields on a screen protect the records entered through it. A spreadsheet import that accepts incomplete rows creates another route into the same database, so its validation deserves the same attention during implementation. API requests need checks appropriate to the records they create as well.
The catalog team shouldn't have to invent a pack size just to save an unfinished product. A draft status gives them somewhere to keep the work until operations confirms the fulfillment details. The application can enforce the required checks at activation, before orders are allowed to use the record.
When the Pack Size Changes
In the bottle example, the approved relationship starts at 12 bottles per case. A later supplier change introduces a case of 10, while some 12-bottle cases remain in stock. Both pack sizes are now valid, and the warehouse needs to distinguish them.
Changing a single conversion field from 12 to 10 would lose that distinction. The design needs a way to identify each pack. Separate pack identifiers are one option. Effective dates help describe changes over time where appropriate, but dates alone do not distinguish two packs being handled on the same day.
Historical orders add another constraint: an order placed for two 12-bottle cases must retain its original quantity and terms. How the application preserves those details depends on its transaction model. The implementation review should check that older order lines aren't recalculated using the current product conversion. The same review should cover open orders that will be fulfilled after the packaging change.
Handling Updates Between Systems
For the case-size change, the warehouse has to receive the approved pack information before it handles orders using that pack. The integration design should specify what happens if the update hasn't arrived. Holding affected orders until the receiving application confirms the setup is one possible approach. The exact control will depend on how order acceptance works in the connected systems.
A rejection message such as “invalid product” leaves too much investigation for the person receiving it. Including the product identifier and the rejected field gives the responsible team somewhere to start. Periodic comparisons of selected fields across applications can uncover discrepancies that remain after delivery has been reported as successful.
An old export arriving late can overwrite a newer approved value if the receiver accepts updates in arrival order. Version checks or ordered processing need to account for that possibility.
After a timeout, the sender doesn't always know whether the receiving application created the record. Retrying the request is reasonable, but the receiver needs to recognize a repeated attempt and return the existing result. This is called idempotent processing. It's worth checking during integration testing because a retry that creates a second account can remain unnoticed until transactions begin using both.
Applying These Controls in Moqui and Apache OFBiz
Moqui's Mantle documentation describes an existing product data model. Apache OFBiz publishes its party entity model, including structures for people and organizations. Reviewing these models helps establish where the business's current records belong before custom tables are introduced.
For a Moqui development project, that mapping exercise can expose differences hidden by field names. One source might keep a combined account record where the target model separates related information. Resolving the meaning of those fields early makes subsequent import and update rules easier to define.
An Apache OFBiz customization review should similarly examine the existing entities and services against the required workflow. Approval behavior and duplicate handling need to be verified in the implementation being used. A published data model establishes structure; the project still has to configure or develop the necessary controls.
An integration writing directly to the database can bypass checks enforced by application services. Its update path needs to be included in the implementation review.
Do You Need a Separate MDM Platform?
A separate MDM platform becomes worth evaluating when several independent applications must reconcile shared identities across a business. With one ERP owning most operational records, its existing controls and integrations may cover the requirements. The evaluation should identify the specific gaps that another platform would be expected to handle.
A group that acquires businesses running different ERPs may want consolidated supplier reporting while leaving local accounts in place. A shared MDM layer can reconcile the identities used in those reports. Before committing to that architecture, the group needs to assign responsibility for disputed matches. Someone will have to investigate when two sources disagree about a supplier, and that workload belongs in the operating budget.
Choosing a Manageable First Improvement
We recommend beginning with records tied to a recurring operational problem. For orders held because of product setup errors, the investigation starts with the affected fields and how their values entered the ERP. A missing import check gives the team a specific fix to make alongside the cleanup. It also provides a manageable scope for checking whether the same error returns.
During an ERP data migration, these checks belong before the final import. Ownership for subsequent updates should be assigned before go-live so that the cleaned records have a maintenance process from day one.
For this product-data work, we'd track orders held because of setup errors before and after the change. The time spent resolving rejected updates is useful alongside that figure, especially if a new validation rule has created extra manual work. The review should include the people processing those exceptions.
At NOI Technologies, we work with Moqui and Apache OFBiz on custom ERP projects. If your team is repeatedly correcting the same records by hand, we can discuss the affected workflows and what your implementation needs to support.