Diagnosing a failed ERP–MES integration

Context

At TOTVS, one of the clients I supported was a plastics manufacturer. They ran Protheus ERP — Production Manager and MRP — integrated with Protheus MES, so that what the plant floor executed and what the ERP planned stayed in step with each other.

I had run that implementation — their AS-IS and TO-BE process models in BPMN, built in Bizagi, and the operations manual their users were trained from — so I already knew the shape of their product structure before I opened a single log.

One morning an operator reported that work orders were failing to integrate between the two systems. More than a dozen were affected.

The constraint

The reason this couldn’t wait is the shape of their products. They were built in layers. A bill of materials ran anywhere from 10 to 25+ components, and any one of those components could be a ready part or could trigger a work order of its own, with its own bill of materials underneath it.

Each SKU also carried its own economic batch quantity, so the quantity ordered and the number of work orders dispatched were not the same number: a need for 1,500 units against a 1,000-unit batch dispatched two work orders, not one.

On top of that, intermediate work orders can’t be registered until the one before them passes. So a single stuck order didn’t fail alone — it held up everything built on top of it. A single customer order can easily sit on 50+ work orders and 100+ SKUs.

What I did

Pulled the ERP integration log. It said “field mismatch” — accurate, and not specific enough to act on.
Ruled out the easy suspect. There had been no recent patch or update to either system, so this wasn’t a regression that had just been introduced.
Asked for the MES-side log, and waited on it. I couldn’t query that side directly. When it came through it gave me what the ERP log wouldn’t: exactly which records had been rejected. I compared those against the orders that had gone through cleanly.
Found the pattern in the difference. Every rejected order shared a bill of materials line for a product that had been created shortly before, with a quantity much larger than that field had ever carried. The integration’s assumed maximum field length was the limit the orders were hitting. Nothing was broken — the integration had simply never been sized for a number that size.
Widened the integration parameter with the operator, sized above the new maximum rather than just far enough to clear the backlog, so the same class of order wouldn’t come back and fail the same way.

The transferable part

A vague error isn’t a dead end. Rule out the easy cause, then compare what failed with what didn’t. The log told me what it could; the difference between the records that failed and the records that went through told me the rest.

Results

Reported in the morning, fixed by the end of the same day.
Sized for the next one, not just this one. Widening the parameter above the new maximum, rather than to the smallest value that cleared the backlog, is what kept the same class of order from failing again.
Logged in a personal compendium of resolved issues — what was reported, how I approached it, how it was resolved. A documentation habit, not a one-off.

What I’d do differently

I’d have run the field comparison myself while waiting for the MES logs. I couldn’t query the MES side directly, so I waited. But the ERP log had already told me a field was the problem — enough to pull a sample of work orders like the ones failing and compare them against the ones that weren’t, counting characters field by field in Excel to find where the pattern broke. That work didn’t need the MES logs to start.
I’d ask whether anything had been registered recently — first, instead of last. I only put that question to the operator after I’d worked through the logs. The cause was a product created shortly before, so one question at the start would have pointed straight at it.
I’d have opened the product’s own change log, not just the integration log. I read the integration logs on both sides and stopped there. The product change log would have shown me the new product and its quantity directly, instead of leaving me to infer it from the rejected records.

Stack

TOTVS Protheus ERP (Production Manager / MRP) · TOTVS Protheus MES · Integration logs on both sides