Replace the ERP or Add a Calculation Layer: Diagnose the Cause Before an Expensive Project

Before replacing an ERP, establish whether the pain comes from the system itself or from a calculation missing on top of it. The two causes produce exactly the same complaint, but their remedies differ by an order of magnitude. Separating them takes a week of tests, not a board meeting.

Two failures that look identical from outside

A manager says: "I cannot tell what our profitability is per customer." That can be one of two things.

In the first failure, the data exists. There are orders, there are lines, there are costs, there are credit notes. What is missing is the definition of "profitability per customer" and the calculation that runs it across all of that at once. That is a missing layer.

In the second failure, the data does not exist. Freight cost is never recorded, or it is recorded as one global expense line with no customer attribution. No report will produce it. That is a problem with the system or its configuration.

The difference between the two is the difference between a project measured in weeks and one measured in quarters. The table below separates them by symptom.

How do you tell the two apart from the symptom?

The first and last rows are the ends of the scale. Most real cases sit in the three middle rows, and that is where the test matters more than intuition.

Five tests you can finish in a week

1. The manual computation test. Take one line the report gets wrong and compute it by hand from the records in the system. If you reach the right number, all the data exists.
2. The field test. Write down the five fields your calculation needs. Check each one against the form in the system. A field that does not exist is an entirely different signal.
3. The export test. Export the raw data into a single file and compute it outside the system. If the result is right, the calculation is possible from outside.
4. The definition test. Ask three people for the definition of the disputed metric, in writing, on the same day. Three different definitions explain the problem without any technology involved.
5. The write-back test. Ask whether the result has to return to the system or only be displayed. An answer of "display only" shrinks the project dramatically.

If four of the five tests point at a layer, there is no case for starting a replacement project before a layer has been built and lived with for a quarter.

What a calculation layer is, and what it is not

A calculation layer is a small service that reads data from the existing system, computes what the system does not compute, and presents the result. It does:

• Hold the definition of the metric in one place, in code, so it can be tested and changed.
• Read through a documented interface rather than straight from the database.
• Store its own output separately, so you can look back even after the source has changed.
• Live beside the system rather than instead of it, so it can be switched off without stopping anything.

It does not:

• Become a new source of truth for documents. An accounting document is born in the system, not in the layer.
• Substitute for missing configuration. If a field does not exist, the layer cannot conjure it.
• Finish. Definitions change, so the layer needs an owner too.

See also connecting a CRM and ERP to BI for what happens once that layer becomes a dashboard.

What does it cost to run a layer that only reads?

The answer depends on the interface, and in Priority's case it is documented and measurable. The documentation defines an API transaction as updating a form, meaning adding or updating a record, and gives the example that an order with five lines counts as six transactions. That section describes writes only, and does not describe reads as consuming transactions.

The fair use policy publishes limits you can plan against:

• Up to 100 API calls per minute per user.
• Up to 15 requests queued at once, of which up to 10 are handled in parallel.
• A request that takes longer than three minutes to process is dropped and returns an error.
• 5,000 requests per rolling 300-second window.
• A throttled request is rejected with HTTP 429.

The design implication is simple: a layer that reads in bulk with $filter and $select and makes few calls is cheap and predictable, while a layer that pulls one record at a time will hit a wall. For the errors themselves, see diagnosing Priority OData errors.

When replacement really is the answer

• When the data you need is never recorded, and no field can be added to record it.
• When your version is unsupported and there is no declared upgrade route.
• When there is no read interface at all, which also makes a layer impossible.
• When the exceptions in the core process fail on the screen itself, not only in a report.
• When maintaining the existing customisations already costs more than the process they serve.

In every other case, a layer built over a quarter delivers the answer people are waiting for and leaves the replacement decision open, with better data behind it. See also when not to build custom software.

Sources

• Priority REST API - Transaction Counting and Fair Use Policy
• Priority REST API - Querying data