SAP ECC and Stedi integration

What moves between them

Purchase orders and materials flow from SAP ECC to Stedi. ml-connector polls BAPI_PO_GETDETAIL1 and BAPI_MATERIAL_GET_DETAIL on a schedule, transforms the data into 850 Purchase Order and item detail, and writes it to Stedi via REST with Idempotency-Key. Inbound flow is bidirectional: Stedi webhooks push 810 Invoice and 856 Advance Shipment Notice transactions as JSON, and ml-connector parses them, maps them to ECC vendors and GL accounts, and posts them as BAPI_ACC_DOCUMENT_POST GL entries and goods receipts (via BAPI_GOODSMVT_CREATE) back into ECC.

How ml-connector handles it

ml-connector runs an on-premises agent that opens RFC connections to ECC via NCo or JCo, handles HTTP Basic Auth credentials for ECC, and polls purchase order and material data on a cadence tied to your procurement cycle. It transforms the RFC result sets into Stedi's 850 and item JSON structure, stores the Stedi API Key securely, and batches outbound writes with Idempotency-Key headers to prevent duplicate orders on network retry. For inbound, ml-connector registers a webhook endpoint with Stedi that receives 810 and 856 transactions as JSON after Stedi parses the inbound X12, validates that required fields (PO number, vendor, line items) are present, maps vendor numbers and GL accounts from ECC, and writes the results back to ECC using BAPI_ACC_DOCUMENT_POST for invoices and BAPI_GOODSMVT_CREATE for receipts. ECC's lack of native webhooks means all inbound EDI must be handled via REST polling or manual webhook ingestion on the Stedi side. RFC calls timeout at the agent level, so ml-connector implements exponential backoff on COMMUNICATION_FAILURE or SYSTEM_FAILURE exceptions. Every record carries a full audit trail linking ECC purchase orders to Stedi 850 transactions and back to inbound 810/856 matches.

A real-world example

A mid-sized automotive parts supplier runs SAP ECC for procurement and finance, and relies on EDI to exchange purchase orders and invoices with OEM partners and second-tier suppliers. Before the integration, the sourcing team exported purchase orders from ECC to a spreadsheet, reformatted them into X12 850 format, and manually uploaded them to Stedi for delivery to each partner, then received inbound 810 invoices via Stedi, manually parsed them back to ECC, and re-entered line items into the GL to match the invoice with the PO. With SAP ECC and Stedi connected, each purchase order created in ECC flows directly to Stedi as a 850 transaction and out to the partner EDI network, and inbound invoices from partners arrive as 810 transactions, are automatically posted into ECC as GL entries with the matching PO reference, and the accounts payable team can reconcile and process them without re-keying.

What you can do

• •Export purchase orders and materials from SAP ECC to Stedi as 850 Purchase Order X12 transactions on a polling schedule, mapped to the correct vendor and item data.
• •Import inbound 810 Invoice and 856 Advance Shipment Notice transactions from Stedi, parse them as JSON, and post them into SAP ECC as GL documents and goods receipts with the correct vendor and PO reference.
• •Authenticate to SAP ECC via RFC Basic Auth and on-premises agent (NCo or JCo), and to Stedi via static API Key, with encrypted credential storage and no manual token refresh.
• •Prevent duplicate PO exports to Stedi using Idempotency-Key headers within the 24-hour deduplication window, and track all EDI transactions with full audit trail linking ECC and Stedi records.
• •Handle the on-premises RFC barrier by running a local agent, polling ECC on a schedule tied to your procurement cycle, and validating inbound EDI data before posting to ECC GL accounts.

Questions

Which direction do purchase orders and invoices flow between SAP ECC and Stedi?

Purchase orders and materials flow from SAP ECC to Stedi as 850 transactions. Inbound invoices and advance shipment notices flow from Stedi back into ECC as GL entries and goods receipts. Invoices are read-only in Stedi and cannot be written back to the EDI network, so all financial postings originate in Stedi or the partner and land in ECC.

How does ml-connector handle the on-premises RFC barrier and agent requirement?

SAP ECC is deployed on-premises and not reachable from the cloud, so ml-connector requires an on-premises agent running SAP .NET Connector (NCo) or Java Connector (JCo) on your network. The agent opens RFC connections to ECC using HTTP Basic Auth credentials and executes BAPI calls like BAPI_PO_GETDETAIL1 and BAPI_MATERIAL_GET_DETAIL on ml-connector's schedule. ml-connector stores the agent connection details encrypted and handles RFC timeouts and retries.

Does Stedi webhook delivery require special setup, and how are duplicate EDI transactions prevented?

Stedi webhooks push inbound EDI as JSON after parsing the X12 file, and ml-connector registers an HTTPS endpoint that receives those transactions. Stedi retries webhooks up to 4 times at 90-second intervals if your endpoint times out or fails, so ml-connector deduplicates using Stedi's eventId or a local transaction log. On the outbound side, ml-connector sends PO exports to Stedi with Idempotency-Key headers to prevent duplicates within 24 hours if the call is retried.