ERP solution

What the Build Needs From You Before It Starts

The scoping conversation is about systems. The build is about access and answers. A connector can be specified in a week and then sit for a month because nobody can log in to the test instance, or because the question of which side wins on a price field has no owner who will answer it in writing.

Test data is the requirement people underestimate. Synthetic records pass because they were written to pass. The useful test set is a period that has already closed, run end to end and reconciled against what the ERP reported for it at the time, because that period contains the records nobody would have invented: the credit note against a canceled order, the invoice paid in two parts, the customer created twice in one afternoon by two different people.

The rest is a short list, but the items on it are hard to substitute:

• A named person per object who can settle which system owns which field, available while the mapping is being written rather than at sign-off
• Credentials for a dedicated integration account in each system, scoped to the permissions the job actually needs, with a rotation policy that will not expire the account without warning
• A non-production instance to build against, or an explicit decision that there will not be one and the first passes run against production with a read-only account
• Access to whatever the record passes through before it reaches the ERP: the ecommerce platform, the CRM, the field service app, the mailbox an order arrives in as an attachment
• Booked time from finance during the reconciliation window, since that work cannot be staffed by the integration team alone

Error Handling Is a Design Decision, Not a Log File

A rejected record has to end up somewhere a person will look. The common failure is not that an integration lacks error handling. It is that the error handling writes to a log file on a server nobody opens, and the first sign of trouble is a customer asking where their order went.

Decide, per object, whether a failure stops the batch or is set aside so the rest continues. Stopping is right for journal entries, where a partial posting is worse than a late one. Continuing is usually right for sales orders, where twelve good orders should not wait behind one carrying a bad ship-to address. Either way, the set-aside records need a queue with a state on each row, so a person can see what failed, why, and whether it was retried, and so a corrected record can be resubmitted without anyone hand-editing the target system.

Retries need a limit and a backoff. An integration that retries a permanently invalid record every five minutes across a weekend generates thousands of identical alerts and trains everyone to ignore the channel they arrive in. Separate the two kinds of failure at the point of the error: a 5xx response or a dropped connection is worth retrying because the system was unavailable, while a 4xx validation rejection is not, because it will fail identically forever until the data itself changes.

The Duplicate Nobody Meant to Create

Idempotency is the property that submitting the same request twice has the same effect as submitting it once, and most ERP APIs do not give it to you for free. If the API assigns the document number on receipt, a second POST of the same invoice produces a second invoice. The way to get idempotency is to carry your own key: write the source system's identifier into a field on the ERP document and check for it before posting rather than after.

The case this protects against is a write that succeeded while the response was lost. The connector posts, the gateway times out or the connection resets, and the job has no way to distinguish a failed post from a successful post it never heard about. Retrying blindly is a common source of duplicate financial records created by an integration. A pre-check on the external key turns that ambiguity into a lookup.

That same key is what makes the numbers answerable later. When a total in the ERP does not match the total in the source system, the first question is which records are in one and not the other. It is a minute of work if every integrated document carries the identifier of the record that created it, and a research project if it does not.

Testing on Data That Behaves Like Production

Volume is the part of production a test instance usually does not reproduce. A job that handles two hundred orders in a demo can time out at four thousand, not because the logic is wrong but because a default page size, a per-record round trip, or a synchronous posting loop that was invisible at small numbers becomes the entire runtime. Test at month-end peak, inside the window the job will actually be given.

The other gap is data that is legal but strange. Production holds an address line longer than the target field, a customer name with an ampersand or a non-Latin character that breaks a query built by string concatenation, a quantity of zero, a line discount of one hundred percent, or a code that was deactivated after the record was created. None of these are error cases in the source system. All of them are error cases at the boundary.

Before go-live, the test set worth insisting on is a short list of specific situations rather than a count of records that passed:

• The target system taken down mid-run on purpose and then brought back, to prove the job resumes without re-posting what already landed
• The same record submitted twice, to confirm the second attempt is recognized rather than creating a second document
• A reversal, meaning a credit note, a return, or a cancellation, which often follows a different document path than the original and gets tested last if at all
• A record created just before midnight in one time zone and checked against the timestamp the ERP stored it under, since a job filtering on modified date against a server in another zone will silently skip or repeat a day
• A run started while the previous run is still going, since a schedule that overlaps itself is a routine way a job that worked for months starts producing doubles

When This Is Not the Work You Need

Some requests that arrive as integration requests are answered better elsewhere, and it is cheaper to find that out before a connector exists to be maintained.

Two cases come up often. When the actual complaint is that nobody can see a number, the ERP often already holds the data and the work is a report, not a connector. And when the volume is genuinely low, a person handling twenty records a week costs less than a connector that has to be monitored, re-authenticated, and re-tested after every vendor update on both sides. The threshold is not the record count, it is what an error in one record costs: twenty invoices a week justify a level of care that twenty newsletter signups do not.

The shape of the data also decides which service fits. If what needs to move is documents rather than transactions, the quotes, signed orders and delivery notes attached to a job, that is document management work sitting alongside the ERP rather than a field-level sync. If technicians are working from printouts while the ERP holds the job record, the fix lives in field service. And if the goal is that an approval given in email lands against the right ERP record without a second pass, the connection point is often Microsoft 365 rather than the ERP API.