From SAP IDoc to cXML: An EDI Migration with a Pharma Key Account

The trigger

Vendor-managed inventory only works if the supplier regularly knows what is in stock at the customer and what has been consumed. At a manufacturer with two sites this exchange with a pharma key account had run stably for years: the customer sent SAP IDocs of type PROACT01 via SFTP, an EDI provider translated them, and the data landed in the ERP.

Then the customer introduced a new procurement platform. The requirement: from a cut-off date, inventory data would no longer arrive as IDoc but as cXML ProductActivityMessage via HTTPS POST through the platform. The supplier has little room to negotiate there. You rebuild, or you lose the automation.

Separate as-is and to-be cleanly

The first step was not technical. We described the existing flow completely: which system sends what and when, which fields the ERP actually uses, where the EDI provider converts, what happens on errors. That sounds trivial, but nobody had this description. It existed spread across three parties and a few emails from the original setup.

Only with the as-is picture could we define the to-be. The differences between the two formats are bigger than you would think:

• Transport: SFTP with file polling versus HTTPS POST with immediate response. The error behaviour is fundamentally different.
• Structure: IDoc segments are flat and position-based; cXML is an XML document with nested elements.
• Semantics: what is a segment field with an indicator in the IDoc is a dedicated element type in cXML.

The field mapping is the real work

The core of the project was a mapping specification: for every field the ERP needs, the source in the old and the new format. We organised it in four blocks:

1. Header: sender, receiver, timestamp, message ID. Sounds simple, but the customer’s identifiers have a different format in the new platform.
2. Line items: customer part number, supplier part number, unit. The part number assignment had to be checked – not every number that came in the IDoc arrives identically in cXML.
3. Quantity types: the trickiest part. Stock on hand, consumption, open orders, minimum stock – each quantity type has its own designation in cXML, and the mapping to IDoc fields was not one-to-one. This is where we spent the longest aligning with the customer.
4. Addresses: ship-to locations and storage locations. In cXML these are structured address blocks; in the IDoc they were identifiers that the ERP resolved internally.

For every field the specification states: mandatory or optional, format, example value, and what happens if it is missing.

Coordinating three parties

Technically the mapping could have been implemented in an afternoon. In reality the project took weeks because three parties were involved:

• The customer with its platform and its requirements – and a test window that could not be moved
• The EDI provider, who performs the translation into the ERP format and for whom cXML also meant an adjustment
• The ERP side, where we had to verify that the existing import interface would process the new data without changes

Our role was that of translator between these three. The mapping specification was the shared document everyone worked from – it prevented more misunderstandings than any conference call.

What we would do differently

• Work with the customer’s test messages earlier instead of only the platform documentation. Reality deviated in details.
• Plan the error behaviour from the start: what happens if the HTTPS POST fails? Who sees it? With SFTP the file simply stayed put; with HTTPS it is gone.
• Have the as-is description before the trigger. It would have been useful in every incident.

Takeaway

EDI migrations are rarely technically hard, but almost always organisationally demanding. The value lies in a clean mapping specification that all parties understand, and in the discipline of describing as-is and to-be separately. With that in place, the next format change – and it will come – takes considerably less effort.