Rick Seufert's Blog

Three EDI Behaviours You Can't Rehearse With a Real Trading Partner

2026-09-25T00:00:00+00:00

The chain everybody demos is 850 → 997 → 855 → 856 → 810. An order goes out, the syntax is acknowledged, the supplier confirms it, the goods ship, the invoice arrives. It is the part of EDI that fits on a slide.

It is also not what most of your integration code is for. The bulk of it exists for the days the chain doesn’t run cleanly: the buyer changes the order after you’ve packed it, the acknowledgment never comes, the same file is picked up twice. Those are the branches that carry the money, and they are exactly the ones you cannot rehearse — a real trading partner misbehaves on its schedule, not on yours, and “could you reject an invoice for me on Tuesday?” is a support ticket and a fortnight.

mock-edi 0.2.0 added all three. Here they are, with output from a mock started like this:

pip install "mock-edi>=0.2.0"
mock-edi --port 8080 \
  --drop-dir ./edi/in --pickup-dir ./edi/out \
  --despatch-delay 3600000 --invoice-delay 3600000

1. The buyer changes the order after you’ve packed it

A buyer that has placed an order and wants less of it sends an 860, and the seller answers with an 865. In EDIFACT the change is an ORDCHG — but the answer is an ORDRSP, the same message that answers an ORDERS, because EDIFACT has no change acknowledgment of its own. That asymmetry is the single most common thing to get wrong when porting a mapping from X12 to EDIFACT, and it is worth stating plainly rather than discovering in production.

Send an 860 that cuts line 1 from 100 to 60 and deletes line 2 entirely:

POC*1*QD*60**EA*12.50**VP*WIDGET-001~
POC*2*DI*0**EA*0**VP*BRKT-050~

and the 865 answers line by line, in the same vocabulary the 855 uses:

BCA*00*AC*4500001234**1*20260925***20260925~
POC*1*QD*60**EA*12.50**VP*WIDGET-001*UP*076123400003~
ACK*IA*60*EA*068*20260927~
POC*2*DI*40**EA*4.15**VP*BRKT-050*UP*076123400041~
ACK*IR*0*EA~
REF*ZZ**Line deleted at the buyer's request~

Note POC02 — the seller echoes the verb the buyer used (QD, DI), rather than flattening everything to “changed”, so the buyer can match each answer to the request it made.

The rule that matters is that a change cannot unmake what has already happened. A quantity cannot drop below what shipped; a shipped line cannot be deleted; an order that has been invoiced cannot be changed at all. A refused line comes back IR with a reason, and the stored order keeps the quantity it already had — reporting the order’s current state instead would tell the buyer its request had succeeded, which is precisely the bug this is meant to help you find.

The part that had to change in the mock

A change is only meaningful before the goods leave. That sounds obvious, and it exposed a real design flaw: the delay flags postponed delivery while the shipment and invoice were built the instant the order arrived. Nothing could ever be changed, because by the time a change arrived the order was already invoiced.

A despatch delay has to postpone the packing, not the posting. So the work is now scheduled rather than done:

$ curl -s localhost:8080/_mock/scheduled
despatch   4500001234   due 2026-09-25T01:48:15
invoice    4500001234   due 2026-09-25T01:48:15

Nothing has been packed. The change lands in that window, and when the despatch finally comes due it ships what the change left behind — 60 of line 1, and no line 2 at all:

LIN*1*VP*WIDGET-001*UP*076123400003~
SN1*1*60*EA**60*EA~

With the default delays of zero, none of this is visible: the work still happens before the request returns. The scheduling only matters once you ask for a window, which is the point.

2. Nobody acknowledged the invoice

Plenty of tools will send you a 997. Far fewer will read one, and the asymmetry hides the most expensive failure in EDI: an invoice that went out and was never acknowledged, sitting unnoticed until someone asks why a supplier hasn’t been paid.

mock-edi keeps a list:

$ curl -s localhost:8080/_mock/unacknowledged
4500001234   group 6   set 0006
4500001234   group 5   set 0005
4500001234   group 4   set 0004
4500001234   group 2   set 0002

Two control numbers per row, and both are needed. AK102 quotes the functional group control number from GS06; AK202 quotes the transaction set control number from ST02. ST02 is only unique within its group — matching on it alone finds the wrong document, or none. Send back a 997 that rejects the invoice and it is matched and recorded:

810 0006 -> rejected (matched True)
  BIG at segment 2: Segment has data element errors; element 4: Invalid code value ('BADPO')

$ curl -s localhost:8080/_mock/unacknowledged
['856', '865', '855']

A receipt for something the mock never sent comes back "matched": false rather than being quietly dropped — a duplicate, a receipt for an undelivered document, or a partner quoting the wrong control number are all real, and all evidence of the bug you are looking for.

?older-than=60 asks the question an operations team actually asks: not “what is outstanding” but “what has been outstanding long enough to chase”. And setting a partner to the no-ack behaviour means nothing is ever acknowledged, so the list only grows — which is how you test the chase-up timer that has never once fired in anger.

3. The same file, read twice

A great deal of EDI is still a folder. The partner writes a file into it; you pick it up. Every directory integration meets the same two problems, and both are quiet.

A file still being written must not be read. The convention is write-then-rename, so the file appears complete or not at all — but not every sender follows it. mock-edi leaves a file alone until it has been untouched for --drop-settle-ms, and never reads .tmp, .part or dotfiles at all. It writes its own output the same way, to a temporary name and then renamed, because recommending a convention you don’t follow is poor manners.

A file that has been read must not be read again. Read files move to processed/, unreadable ones to failed/:

$ curl -s -X POST localhost:8080/_mock/drop/scan
junk.edi           FAILED    -> not an EDI interchange: expected it to start with ISA (X12)
order-9001.edi     read      -> 997, 855
order-9002.edi     read      -> 997, 855

$ ls edi/in/processed          $ ls edi/in/failed
order-9001.edi                 junk.edi
order-9002.edi

Moved, not deleted. A mock that eats the evidence is no use at the moment a test fails. Drop order-9001.edi a second time and you get order-9001-1.edi beside the first, rather than one overwriting the other.

That scan endpoint is the other half of the design. There is a poller, but no test should have to wait for it: POST /_mock/drop/scan reads the directory now and reports what it found. It exists for the same reason POST /_mock/advance does — a test that sleeps is slow and flaky, and a test that advances a clock is neither.

Why this is worth the trouble

None of these three is exotic. Every EDI integration of any age has met all of them, usually in production, usually at the point where somebody is asking where the money went. What makes them hard to test is not complexity but availability: they are other people’s failures, on other people’s schedules.

A mock that only performs the happy path tests the code you were never worried about.

pip install mock-edi
mock-edi --port 8080
bash examples/demo.sh

The guided tour covers all three, and skips the sections your configuration doesn’t enable rather than pretending. There is a walkthrough of a full SAP-to-EDI integration in the previous post, and the changelog has the rest.

Testing an SAP-to-EDI Integration Without SAP or a Trading Partner

2026-09-24T00:00:00+00:00

Updated 25 September 2026: mock-sap 0.11.1 and mock-edi 0.2.1 are out, and each release carries one of the two examples below. mock-sap 0.10.0 added the last scenario in part two — an IDoc SAP accepts and then declines to post — which found a bug in the invoice check this post describes. Pin 0.11.1 or later: 0.11.0 added business errors on BAPI calls, and 0.11.1 fixes a delta read that could report nothing had changed when something had.

Every company that buys things through SAP and trades with suppliers over EDI has a piece of middleware in between. It reads purchase orders out of SAP, turns them into X12 850s, sends them to the supplier, takes the supplier’s 855 (the purchase order acknowledgment) back into SAP, and, when the goods ship, checks the supplier’s 810 invoice before anyone pays it. It is usually the least tested code in the building, because testing it properly needs two things that are hard to get: an SAP system you are allowed to break, and a supplier willing to misbehave on cue.

mock-sap and mock-edi are those two things. This post walks through both halves of a small integration, orders out and invoices in, with test suites that run in under a second with no SAP license, no VPN, and no supplier on the phone.

Running the mocks

pip install "mock-sap>=0.11.1" "mock-edi>=0.2.1"
mock-sap --port 8000 &
mock-edi --port 8080 &

mock-sap serves the purchase order service with real Gateway wire shapes (CSRF tokens, {"d": ...} envelopes, decimals as strings) and accepts inbound IDocs. mock-edi plays the supplier: send it an 850 and it answers with a 997, an 855, an 856 and an 810, validated against its own X12 dictionary.

The two examples ship with the mocks. po_bridge is in mock-edi’s examples/ and invoice_check in mock-sap’s, and each is also in its package’s source archive on PyPI. Each repo’s CI runs its example against the other mock’s latest release from PyPI, so the examples keep working as new versions come out.

Part one: orders out, confirmations in

The code under test is po_bridge.py, about 150 lines of standard-library Python. It does two jobs:

send:     SAP PO (OData)  ──▶  X12 850  ──▶  supplier
receive:  SAP  ◀──  ORDRSP IDoc  ◀──  X12 855  ◀──  supplier

To send, it reads the purchase order from SAP’s API_PURCHASEORDER_PROCESS_SRV OData service, looks up the supplier’s part number for each material, and writes an 850. One detail matters later: the SAP item number (00010, 00020) goes into PO101, the line identifier, so the supplier’s answer can be matched back to the right SAP item.

for item in items:
    # PO101 carries the SAP item number, so the 855 can be matched back
    body.append("PO1*%s*%d*EA*%s**VP*%s" % (
        item["PurchaseOrderItem"], float(item["OrderQuantity"]),
        item["NetPriceAmount"], SUPPLIER_PART[item["Material"]]))

To receive, it collects 855s from the supplier, reads each line’s ACK segment (IA accepted, IQ quantity changed, IR rejected), and posts the result into SAP as an ORDRSP IDoc. Anything that isn’t a clean confirmation comes back as an exception for a buyer to look at.

The tests

Each test resets both mocks, creates a fresh purchase order in SAP for 100 widgets and 40 brackets, and then drives the bridge. The interesting part is that the supplier’s behaviour is one PATCH away.

def supplier_behaves(self, behaviour):
    control(EDI, "PATCH", "/_mock/partners/ACME", {"behaviour": behaviour})

The happy path

def test_supplier_confirms_everything(self):
    summary = self.bridge.send(self.po)
    self.assertTrue(summary["accepted"])
    self.assertEqual(summary["transactionSets"][0]["findings"], [])

    result = self.bridge.receive()[self.po]
    self.assertEqual(result["lines"], {"00010": ("confirmed", 100.0),
                                       "00020": ("confirmed", 40.0)})
    self.assertEqual(result["exceptions"], [])
    self.assertEqual(len(self.ordrsp_idocs()), 1)

The findings assertion is quietly the most useful line here. mock-edi validates every inbound document, so a malformed ISA, a bad segment count, or an invalid code shows up as a test failure instead of as a rejected 997 from a real supplier three weeks after go-live.

The supplier ships short

def test_short_shipment_is_raised_as_an_exception(self):
    self.supplier_behaves("short-ship")
    self.bridge.send(self.po)

    result = self.bridge.receive()[self.po]
    self.assertNotEqual(result["exceptions"], [])
    for item in result["exceptions"]:
        status, quantity = result["lines"][item]
        self.assertEqual(status, "short")
        self.assertLess(quantity, {"00010": 100, "00020": 40}[item])

With short-ship, the supplier confirms 80 of the 100 widgets and 32 of the 40 brackets, and the bridge flags both lines.

The supplier refuses a line

def test_rejected_line_reaches_sap(self):
    self.supplier_behaves("reject-line")
    self.bridge.send(self.po)

    result = self.bridge.receive()[self.po]
    rejected = [i for i, (status, _) in result["lines"].items() if status == "rejected"]
    self.assertEqual(len(rejected), 1)
    # the IDoc SAP received says so too (E1EDP01 ACTION 003)
    idoc = control(SAP, "GET", "/sap/bc/idoc/" + result["idoc"])
    self.assertIn("<POSEX>%s</POSEX><ACTION>003</ACTION>" % rejected[0], idoc["payload"])

This one checks both ends: the bridge noticed the rejection, and the IDoc that landed in SAP carries it on the right item. mock-sap keeps every inbound IDoc, so the test can read back exactly what SAP was sent.

The supplier says nothing

def test_silent_supplier_leaves_nothing_to_post(self):
    self.supplier_behaves("no-ack")
    self.bridge.send(self.po)

    self.assertEqual(self.bridge.receive(), {})
    self.assertEqual(self.ordrsp_idocs(), [])

A supplier that never answers is the failure that actually costs money, because nothing looks wrong. With no-ack, you can build and test the chase-up logic (alert when a PO has gone N hours without an 855) instead of discovering you need it.

SAP is down when the answer arrives

This is the test that earned its keep.

def test_sap_outage_does_not_lose_the_confirmation(self):
    control(SAP, "POST", "/_mock/faults", {
        "match": "/sap/bc/idoc", "method": "POST", "status": 503,
        "message": "No dialog work process available", "count": 1})
    self.bridge.send(self.po)

    self.assertEqual(self.bridge.receive(), {})     # SAP was down
    self.assertEqual(len(self.bridge.pending), 1)   # but we kept the 855

    result = self.bridge.receive()                  # next run: SAP is back
    self.assertIn(self.po, result)
    self.assertEqual(self.bridge.pending, [])
    self.assertEqual(len(self.ordrsp_idocs()), 1)

The first version of receive() collected the 855s and posted each one straight into SAP. Collecting from a mailbox is destructive, so if SAP was unavailable at that moment, the confirmation was simply gone: collected from the supplier, never delivered to SAP, and logged nowhere. The fix is a few lines of store-and-forward, keeping each 855 in pending until SAP has taken it:

try:
    receipt = self.sap.request("POST", "/sap/bc/idoc",
                               ordrsp_idoc(po_number, lines), "application/xml")
except urllib.error.HTTPError:
    still_pending.append(doc)          # try again next run
    continue

In production pending would be a table rather than a list, but the point stands. mock-sap’s fault rules (503, 423 locked, expired CSRF tokens, timeouts) make this kind of bug cheap to find on a laptop instead of expensive to find in production.

Part two: invoices in

The same supplier, a few days later, sends an 856 ship notice and an 810 invoice. invoice_check.py is the accounts-payable side: it posts an invoice into SAP as an INVOIC IDoc only if it passes a three-way match.

PO (SAP)  ──┐
856 ship  ──┼──▶  match?  ──▶  yes: INVOIC IDoc into SAP
810 bill  ──┘                  no:  blocked, with reasons

The whole check is one function. Every line of the invoice has to agree with the purchase order on price and with the ship notice on quantity, the lines have to add up to the total, and the invoice number must not have been posted before:

if invoice["number"] in self.posted:
    return ["invoice %s has already been posted" % invoice["number"]]
...
for item, (qty, price) in sorted(invoice["lines"].items()):
    total += qty * price
    po_price = Decimal(ordered[item]["NetPriceAmount"])
    if price != po_price:
        found.append("item %s billed at %s, ordered at %s" % (item, price, po_price))
    if qty > shipped.get(item, 0):
        found.append("item %s bills %s, shipped %s" % (item, qty, shipped.get(item, 0)))
if total != invoice["total"]:
    found.append("lines add up to %s, invoice total is %s" % (total, invoice["total"]))

Money is Decimal, never float. The 810’s TDS total carries two implied decimal places (113280 means 1132.80), which is the kind of detail a real supplier’s document tests for you whether you meant it to or not.

The tests

A clean invoice is posted

def test_matching_invoice_is_posted(self):
    po = self.order()

    [result] = self.check.run()
    self.assertEqual((result["po"], result["status"], result["problems"]),
                     (po, "posted", []))
    [idoc] = self.invoice_idocs()
    self.assertEqual((idoc["docnum"], idoc["status"]), (result["idoc"], "53"))

Status 53 is SAP’s “application document posted”. The test reads it back from mock-sap, so it checks what SAP received, not what the code thinks it sent.

A short shipment, billed as shipped, is posted

def test_short_shipment_billed_as_shipped_is_posted(self):
    # Checking the invoice against the PO quantity would block this one.
    # The supplier shipped 80 and 32 and billed 80 and 32: that is correct.
    self.supplier_behaves("short-ship")
    self.order()

    [result] = self.check.run()
    self.assertEqual(result["status"], "posted")

This is the test that keeps the check honest in the other direction. Matching invoice quantities against the purchase order is the obvious first version, and it blocks every legitimate partial shipment. The invoice has to be matched against what shipped.

A price disagreement is blocked

def test_price_disagreement_is_blocked(self):
    # We ordered widgets at 11.00; the supplier's catalogue says 12.50,
    # and a real supplier bills its own price.
    self.order(widget_price="11.00")

    [result] = self.check.run()
    self.assertEqual(result["status"], "blocked")
    self.assertEqual(result["problems"], ["item 00010 billed at 12.50, ordered at 11.00"])
    self.assertEqual(self.invoice_idocs(), [])

No PATCH needed for this one. mock-edi bills at its own catalogue price whatever the order says, the way real suppliers do, so a purchase order with a stale price is enough to produce the commonest EDI dispute there is.

The same invoice, twice, is posted once

def test_duplicate_invoice_is_posted_once(self):
    # A supplier with a retry bug sends the same invoice again a second
    # later.  Release it now rather than sleeping.
    self.supplier_behaves("duplicate-invoice")
    self.order()

    [first] = self.check.run()
    control(EDI, "POST", "/_mock/advance?all")
    [second] = self.check.run()

    self.assertEqual(first["invoice"], second["invoice"])
    self.assertEqual(first["status"], "posted")
    self.assertEqual(second["status"], "blocked")
    self.assertIn("already been posted", second["problems"][0])
    self.assertEqual(len(self.invoice_idocs()), 1)

A duplicate invoice is how companies pay twice. mock-edi’s duplicate-invoice behaviour sends the copy a second after the original, which is realistic and would make a naive test either slow or flaky. /_mock/advance?all releases it immediately instead, so the test is neither.

SAP takes the IDoc and doesn’t post it

def test_an_idoc_sap_would_not_post_is_not_treated_as_posted(self):
    # SAP answers 201 with a docnum and then declines to post the invoice.
    # Reading the docnum and stopping there books an invoice SAP rejected.
    control(SAP, "POST", "/_mock/idoc-posting",
            {"mestyp": "INVOIC", "status": "51",
             "message": "Posting period 08 2026 is not open"})
    self.order()

    [result] = self.check.run()
    self.assertEqual(result["status"], "not posted")
    self.assertIn("status 51", result["problems"][0])

    [idoc] = self.invoice_idocs()
    self.assertEqual(idoc["status"], "51")
    self.assertEqual(self.check.posted, set())

This one is newer than the rest of this post, and it is here because it found a real bug in the code above. Posting an IDoc is two events, and SAP reports them separately: the port answers 201 and issues a document number, and then the application posts the invoice or doesn’t. mock-sap 0.10.0 added /_mock/idoc-posting so the second answer can be asked for; the first thing it was pointed at was invoice_check.py, which read DOCNUM from the receipt and reported posted without ever reading STATUS.

So an invoice SAP had refused was booked as ready to pay. Worse, its number went into the posted set, so the resend after someone opened the posting period would have looked like a duplicate and been blocked — the invoice would never have posted and nothing would have said so. Both halves are fixed above; the check now requires status 53.

That is the shape of the failure worth designing tests around. A 503 is loud and retryable, and the bridge in part one already survives one. An accepted IDoc that never posts looks exactly like success from the sending side.

Running it

$ python3 -m unittest -v test_po_bridge test_invoice_check
test_rejected_line_reaches_sap ... ok
test_sap_outage_does_not_lose_the_confirmation ... ok
test_short_shipment_is_raised_as_an_exception ... ok
test_silent_supplier_leaves_nothing_to_post ... ok
test_supplier_confirms_everything ... ok
test_an_idoc_sap_would_not_post_is_not_treated_as_posted ... ok
test_duplicate_invoice_is_posted_once ... ok
test_matching_invoice_is_posted ... ok
test_price_disagreement_is_blocked ... ok
test_short_shipment_billed_as_shipped_is_posted ... ok

----------------------------------------------------------------------
Ran 10 tests in 0.166s

OK

Ten scenarios, two systems, under a second. The full code:

Orders out: po_bridge.py and test_po_bridge.py, also in mock-edi’s examples
Invoices in: invoice_check.py and test_invoice_check.py, also in mock-sap’s examples

Both run in CI in their repos, against the other mock, so they keep working as the mocks change.

Neither mock implements real business logic, and that’s the point. The integration’s job is to move documents between two systems correctly and to survive when either one misbehaves. That’s exactly what these tests cover.

Rick Seufert Launches Site

2016-08-30T00:00:00+00:00

Well. Finally got around to putting this old website together. Neat thing about it - powered by Jekyll and I can use Markdown to author my posts. It actually is a lot easier than I thought it was going to be.