Onboarding console shipped in the core ERP product

Challenge

Rolling out an ERP at a new client starts with a thankless task: bringing the basic master data (suppliers, customers, carriers, items) from wherever it lives into the system. This was done with spreadsheets, manual typing and one-off scripts written by whoever was on the rollout. Every consultant had their own way of doing it. And none of them reused the validation the product’s official screens already perform.

Unlike the rest of my portfolio, this is not a client customisation: it’s a feature of the core product, used by any ERP rollout.

Solution

I designed a multi-tab console with a single pattern, repeated for each master-data type: file upload, a staging area, a bulk review-and-edit grid, deleting what doesn’t belong, and commit.

The design decision everything else rests on is staging. Imported data doesn’t go straight into the real registry. It sits in an intermediate area, where it can be reviewed and bulk-corrected, and only then gets committed. And committing calls the save routine of each master-data type’s official screen instead of writing to the database on its own. That way all of the product’s business validation keeps applying, and the import doesn’t create inconsistent data that the ERP later rejects.

Alongside the console I built the integration with the Brazilian tax authority’s lookup API, with caching of the last query. During import, the corporate-entity registry is completed and checked automatically, including tax-regime verification. That integration started out generic inside the product, was reused in a client customisation and later became a standalone component, with bulk base updates.

Outcome

The rollout gained an official tool in place of hand-built scripts, and imported data now goes through the same validation as data typed on screen. The tax authority integration cut down manual registry checking and then outgrew this case altogether: it became a reusable piece that now runs outside the console it came from.

What this case shows

This is core-product code, with the compatibility care that requires: break something here and it breaks in every rollout. I reused the validation that already existed instead of writing my own version of it. And I followed an integration from inside the core until it became a standalone component.