Data Quality and Duplicate Master Cleanup

The pain

After a few years of live operation, most SAP Business One company databases carry the same wound: the same customer exists three times. "ACME Trading LLC", "Acme Trading L.L.C." and "ACME TRD" all have open A/R Invoices, all have different payment terms, and none of them shows the real balance. Item masters drift the same way — the same part number entered twice with different UoM groups, one of them carrying the inventory and the other carrying the sales history.

The damage is not cosmetic. Credit limits are enforced against the wrong Business Partner. Aging reports split a single debtor across three lines. Sales analysis by item under-reports every product that has a twin. Purchasing re-orders stock that already sits in a warehouse under the other item code. And the moment someone tries to clean it up manually, they discover the real constraint: SAP Business One will not let you delete a Business Partner or Item that has any transaction history, and there is no native, supervised merge that carries documents, balances and history from a losing record to a surviving one.

So the duplicates stay. Teams work around them, reports get exported to spreadsheets and "corrected" by hand, and every migration, integration or BI project inherits the mess.

What ECOSIRE builds

We build a SAP Business One add-on that makes master data cleanup a governed, auditable process instead of a one-off data-surgery project.

Duplicate detection engine

A configurable matching engine scans OCRD (Business Partners), OCPR (contact persons), CRD1 (addresses) and OITM (Items) and produces scored candidate groups. Matching rules are yours to tune: exact, normalised (case, punctuation, legal-suffix and diacritic stripping), phonetic, token-overlap and numeric-identity rules on tax ID, VAT/GST registration, licence number, e-mail domain, phone digits, IBAN, barcode or manufacturer catalogue number. Each rule carries a weight, so a tax-ID collision can be decisive while a name similarity alone only proposes a review.

Results are written to User-Defined Tables (UDTs) so a cleanup campaign survives restarts, can be worked by several people over several days, and can be re-run to prove the database stayed clean.

Supervised merge with a survivor record

For each candidate group, a reviewer picks the survivor and inspects a field-by-field comparison. The merge screen lets you take individual field values from any record in the group — keep the survivor's CardCode but adopt the loser's tax ID, payment terms, price list, sales employee or default warehouse. Nothing is guessed; every kept value is an explicit decision recorded in the log.

The merge itself is executed through the DI API and Service Layer against the objects SAP actually exposes: open Sales Orders, Deliveries, A/R and A/P Invoices, Credit Memos, Incoming and Outgoing Payments, Purchase Orders, Goods Receipt POs, Activities, Opportunities, Service Calls, Contracts and Business Partner Catalog Numbers are repointed to the survivor where the object supports it. Where SAP does not permit a posted document to be repointed — and it often does not — the add-on takes the honest route: the losing record is reconciled, its open items are closed or transferred by explicit document, and the record is deactivated and locked rather than silently rewritten behind the accounting.

Deactivation, aliasing and re-entry prevention

Merged-away Business Partners are set inactive, renamed with a configurable prefix, and registered as an alias of the survivor in a UDT. A lookup UDF on the survivor lists every code it absorbed, so anyone searching the old code still lands on the right customer. A blocking rule on Business Partner and Item add/update stops the same duplicate being re-created: a new OCRD row with a tax ID that already exists can be warned or hard-blocked, and the check is available to the Service Layer so your web shop or CRM integration is held to the same standard.

Item master deduplication

Items get their own treatment because the constraints differ. The add-on compares OITM and OITW (per-warehouse rows), reports on-hand quantity, open documents, Bills of Materials, Alternative Items, Business Partner Catalog Numbers and price-list entries for each candidate. Where stock exists on a losing item, the tool generates the Inventory Transfer or Goods Issue/Goods Receipt pair needed to consolidate on-hand into the survivor, posted to the G/L accounts your Item Group defines — with the resulting document numbers written back into the merge log.

Audit trail and reversibility

Every campaign, decision and executed change is written to UDTs with the user, timestamp, before/after field values and the SAP document keys touched. Reversal scripts are generated for the steps that are technically reversible, and the log makes the rest reconstructable. Nothing runs without a snapshot of the affected rows.

Standing data quality rules

Beyond the one-off cleanup, the add-on ships a rules layer that scores your master data continuously: missing tax ID, missing country or currency, invalid e-mail format, Item without a Purchasing/Sales UoM, Business Partner without a payment term, address without a state where the localisation requires one. Scores are exposed through UDFs and a Crystal Report so the improvement is visible month over month.

Who it is for

Companies preparing for a migration, a consolidation, an e-invoicing mandate or a BI rollout — anywhere the first blocker is that the master data will not survive scrutiny. Also finance teams whose aging and credit control are wrong because one customer is three records, and operations teams re-buying stock they already own under another item code.

How delivery works

1. Scoping call. We look at your live company database structure, your localisation, your volume of Business Partners and Items, and the integrations that write into them. We agree what a duplicate means in your business — that definition is the project. 2. Fixed quote. You receive a written scope with the matching rules, the objects in scope, the merge behaviour for each document type, and a fixed price. 3. Build. We develop the add-on against a copy of your data so the matching rules are tuned on your real names, not on samples. 4. Install in test. We install into your test company database and run a full campaign there. You review the proposed merges before a single one is executed against production. 5. Install in production. After sign-off, we install into production, take the snapshot, and run the campaign with your team present. 6. Support window. A defined post-go-live support period covers defects, rule tuning and the second campaign pass once the first wave of cleanup exposes the next layer.

Lead time is typically 2–4 weeks from signed quote, depending on how many object types and localisations are in scope. This is built to order — there is no download, no trial, and no shelf product. What you get is an add-on shaped around your database and your definition of a duplicate.