ERP integration · SAP
SAP S/4HANA Cloud Public Edition EDI and B2B integration
Order, shipment and invoice integration for SAP S/4HANA Cloud Public Edition, with mapping, validation and reconciliation.
- Integration supported
- Implementation services available
- Cloud, on-premises or hybrid
Overview
Connecting SAP S/4HANA Cloud Public Edition with your trading partners
Connect SAP S/4HANA Cloud Public Edition with customers, suppliers and the applications that support your business. ECOM defines integration at the transaction and data level: the record to create or update, the fields to exchange, the business rules to apply, and the evidence that processing completed.
The scope below describes integration functions and controls that can be included in an ECOM project. Coverage is confirmed for your product version, licensed modules and business requirements. We explain ECOM’s specific connection path and deployment architecture during a live meeting.
This page sets out the scope for SAP S/4HANA Cloud Public Edition: the systems involved, the records and transaction flows, field mapping and validation, error recovery, reconciliation and rollout, with diagrams of who owns what and how a document moves through processing.
Methods
Integration approaches for SAP S/4HANA Cloud Public Edition
EDI
X12 or EDIFACT documents exchanged with customers, suppliers, carriers and banks under each partner's implementation guide, mapped to and from the SAP S/4HANA Cloud Public Edition records in scope.
PRISM-WebEDI
Web-based EDI collaboration and document processing, subject to the same SAP S/4HANA Cloud Public Edition validation and business controls as other channels.
PRISM-SmartConvert
Converts business documents into structured integration data that is validated and applied to SAP S/4HANA Cloud Public Edition under the agreed rules.
PRISM-WebConnect
Automation of trading partner portals and workflows, brought under the same SAP S/4HANA Cloud Public Edition validation and business controls.
Document mapping
How EDI documents map to SAP S/4HANA Cloud Public Edition
Typical mappings between common X12 documents and SAP S/4HANA Cloud Public Edition business objects. Actual designs depend on your configuration and partners.
| EDI document | SAP S/4HANA Cloud Public Edition object | Direction |
|---|---|---|
| 850 Purchase Order | Sales order and item | Into SAP S/4HANA Cloud Public Edition |
| 860 Purchase Order Change | Schedule quantity and date | Into SAP S/4HANA Cloud Public Edition |
| 855 Order Acknowledgment | Schedule quantity and date | From SAP S/4HANA Cloud Public Edition |
| 856 Advance Ship Notice | Outbound delivery | From SAP S/4HANA Cloud Public Edition |
| 810 Invoice | Billing document | From SAP S/4HANA Cloud Public Edition |
Planning
Implementation considerations
Cover only the activated scope
Build a transaction coverage list for the business scope actually activated in the public cloud tenant. Scope coverage and ECOM implementation coverage are separate checks.
Control extension fields
Define allowed extension fields and partner-specific references as part of the business data contract. Test those fields again when relevant cloud releases or business configurations change.
Receipt is not acceptance
Separate receipt of a buyer message from successful order acceptance. Customer commitments and outbound confirmations must reflect the resulting business state.
Integration design
SAP S/4HANA Cloud Public Edition: scope, flows, controls and tests
The scope below describes integration functions and controls that can be included in an ECOM project. Coverage is confirmed for your product version, licensed modules and business requirements. We explain ECOM’s specific connection path and deployment architecture during a live meeting.
Editions and versions we integrate
ECOM scopes SAP S/4HANA Cloud Public Edition integration for the edition and release you run. Coverage, permitted actions and record availability are confirmed for your version, licensed modules and business requirements.
- SAP S/4HANA Cloud, Public Edition
The ERP environment we integrate around
SAP S/4HANA Cloud Public Edition is SAP’s public cloud ERP offering, also presented within SAP Cloud ERP branding. It is distinct from SAP HANA Cloud and from S/4HANA private cloud deployments.
The design identifies activated scope, sales area, company code, plant and cloud tenant. These values determine transaction routing, record validity, ownership and the financial or operational context in which a document is processed.
Systems and ownership
| System or participant | Integration responsibility |
|---|---|
| SAP S/4HANA Cloud Public Edition | Maintain the approved ERP records, business rules, stock and financial results within the agreed module scope. |
| Customer or supplier systems | Supply orders, revisions, forecasts, invoice details and partner reference numbers; receive agreed business responses. |
| Warehouse or fulfillment application | Own physical pick, pack, dispatch and receipt facts where separately deployed. Return actual quantities and shipment references. |
| ECOM integration services | Coordinate agreed document exchanges, business data mapping, validation and processing visibility across the defined systems. |
SAP S/4HANA Cloud Public Edition keeps the approved records, business rules and results; partners supply and receive agreed business documents; a separate warehouse application owns physical facts where one is deployed; and ECOM coordinates document exchange, mapping, validation and visibility. A system of record is decided for each data group.
A system-of-record decision is made for each data group. For example, partner purchase order numbers can originate externally while ERP order numbers are assigned by the ERP. External instructions do not automatically authorize changes to item masters, tax settings, accounting periods or payment details.
Input channels can include EDI, PRISM-WebEDI, PRISM-SmartConvert documents and PRISM-WebConnect portal activity, each subject to the same agreed ERP validation and business controls.
ERP records in the proposed scope
- Business partner
- Product
- Sales order and item
- Schedule quantity and date
- Outbound delivery
- Billing document
- Purchase order
- Supplier invoice
Record availability and permitted actions are checked against the installed environment; the list is a functional scope inventory rather than a claim that every record is enabled in every edition.
Transaction flows and processing rules
Direction is relative to SAP S/4HANA Cloud Public Edition. Each flow is defined by its source, target business record, release condition and successful result. Creation, update, cancellation and enquiry are scoped separately.
Each flow has a source, a target business record, a release condition and a successful result. Creation, update, cancellation and enquiry are scoped separately for SAP S/4HANA Cloud Public Edition.
| Business flow | Direction | Processing and completion rule |
|---|---|---|
| Customer order | Into ERP | Create the appropriate sales order with source PO, line references, customer, ship-to, item, quantity, unit and requested date. |
| Order change or cancellation | Into ERP | Match the existing order and revision. Apply only permitted changes to open quantities; hold conflicts with shipped or invoiced activity. |
| Order response | Out of ERP | Return accepted or rejected lines, confirmed quantity and date, and ERP order reference. Transport receipt alone is not order acceptance. |
| Shipment and ASN | Out of ERP or coordinated | Use actual released shipment facts, order-line references, quantities and packaging details. A planned pick does not establish shipment. |
| Invoice or credit | Out of ERP | Use the agreed released or posted billing record. Retain original order and shipment references, charges, allowances and tax treatment. |
| Supplier purchasing | Both as scoped | Publish approved purchase orders and accept supplier confirmations, receipt information and invoices under the purchasing rules. |
| Availability and status | Out of ERP where scoped | Share the agreed stock or available-to-promise measure and timestamp; distinguish on-hand stock from committed or unavailable stock. |
Partner documents and business meaning
X12 examples include 850 orders, 860 order changes, 855 order acknowledgments, 856 shipment notices, 810 invoices and 820 payment or remittance advice. Relevant EDIFACT messages can be scoped for international partners. A 997 or 999 technical acknowledgment is tracked separately from business acceptance. Document selection follows the partner’s implementation guide, not the ERP product name.
A distributor adopting SAP public cloud needs retailer order automation without losing control of its standardized business processes. ECOM can plan partner workflows around the scope enabled in that environment.
Data mapping and validation
We define a mapping specification at header, line and related-document level. It records source meaning, target business field, transformation, required condition, default ownership and rejection behavior. Partner identifiers remain traceable after ERP identifiers are assigned.
| Data group | ERP fields or business attributes | Validation rule |
|---|---|---|
| Organization | Sales Area, Company Code, Plant | Validate activated scope, sales area, company code, plant and cloud tenant. Reject unknown or unauthorized combinations. |
| Trading party | Business Partner and partner roles | Resolve partner identifiers to approved ERP accounts and locations. Do not match solely on a free-text name. |
| Product identity | Product, Customer Product Reference | Map buyer and supplier item aliases to the correct ERP product. Check variants, revisions and active status where relevant. |
| Quantity and unit | Requested Quantity, Order Unit, Confirmed Quantity | Keep each quantity distinct. Apply approved pack or unit conversion, precision and rounding rules; reject an unknown conversion. |
| Dates | Requested Delivery Date, Confirmation Date | Preserve meaning, time zone and date-only values. Reject invalid formats and identify stale revisions. |
| Price and money | Net Amount, Transaction Currency, Pricing Conditions | Define the authoritative price and tax calculation. Reconcile line extensions and document totals within approved tolerances. |
| References | Buyer Order Reference, Sales Order, Delivery | Use stable line references across splits and updates. Retain original order, shipment, invoice and correction links. |
| Extensions | Approved custom business fields | Agree field ownership, allowed values and length. Do not silently truncate values or discard unmapped required data. |
Field labels above identify business attributes; exact technical names, availability and allowed write actions are verified for your release. They do not disclose ECOM’s connection method.
Identity and duplicate control
The business identity starts with buyer order reference + sales area + buyer line + revision. The final rule also distinguishes a new document, a retransmission and a legitimate revision. ERP-assigned IDs are recorded after successful creation. A retry reuses the same business identity instead of creating a second order or invoice.
Processing control and error recovery
Business state controls the next action
For SAP S/4HANA Cloud Public Edition, the design evaluates accepted sales order, confirmed quantity, delivery completion and billable document status. A document is not considered complete simply because it arrived or passed a format check. Completion requires the intended ERP business result and its returned reference.
| Processing stage | Required evidence and next action |
|---|---|
| Received | Assign a correlation reference, retain the source identity and record receipt time. Check whether this is a duplicate or new revision. |
| Validated | Confirm required fields, authorized organization, master data, quantities and business rules. Reject or hold a failed document before unintended posting. |
| Submitted | Record the intended target action and processing attempt. Submission is an intermediate state, not evidence of ERP acceptance. |
| Accepted or held | Capture the ERP business record ID or a specific rejection or hold reason. Distinguish a business hold from an unavailable system. |
| Completed and reconciled | Confirm the agreed milestone, expected line results and outbound response. Reconcile source identity to ERP and partner references. |
For SAP S/4HANA Cloud Public Edition, the design evaluates accepted sales order, confirmed quantity, delivery completion and billable document status. A document is not considered complete simply because it arrived or passed a format check. Completion requires the intended ERP business result and its returned reference. Held or rejected documents are corrected and replayed with the same business identity, so a retry never creates a second order or invoice.
Changes and sequencing
Process a dependent change against the correct original record and current revision. If a change arrives before the order exists, retain it for controlled review or dependency handling. Define a cut-off state after which quantity, price or ship-to changes require an exception or formal correction. Posted financial history is corrected through the authorized business process.
Safe retry and uncertain results
Temporary availability failures can be retried under an agreed retry limit and escalation policy. Invalid items, closed periods and missing approvals need correction rather than blind retries. When a submission times out, first determine whether the ERP already created the record. An unknown result must not be converted immediately into a new create request.
For multi-step flows, retain completed steps and resume only the incomplete authorized action. An order created successfully must not be recreated because its acknowledgment failed. Recovery should retain original references, corrected values, attempt history and the responsible user or process.
Reconciliation and operational ownership
Reconcile document counts, line counts, quantities, monetary totals and business references at the agreed interval. Identify documents received without ERP results, shipments without required notices, invoices without partner delivery results and aging exceptions. Assign an owner and response target for each exception category. Set the interval and service targets from business deadlines and measured ERP capacity.
SAP S/4HANA Cloud Public Edition-specific integration requirements
Design requirement 1: Build a transaction coverage list for the business scope actually activated in the public cloud tenant. Scope coverage and ECOM implementation coverage are separate checks.
Design requirement 2: Define allowed extension fields and partner-specific references as part of the business data contract. Test those fields again when relevant cloud releases or business configurations change.
Design requirement 3: Separate receipt of a buyer message from successful order acceptance. Customer commitments and outbound confirmations must reflect the resulting business state.
Example integration sequence
A distributor adopting SAP public cloud needs retailer order automation without losing control of its standardized business processes. ECOM can plan partner workflows around the scope enabled in that environment.
- Receive the partner order or demand instruction and identify customer, item, organization and delivery requirements.
- Validate and create or update the agreed ERP record; retain the assigned order and line references.
- Produce a business response from accepted quantities, dates and any holds rather than from message receipt alone.
- Use actual fulfillment information to build the required shipment notice and preserve split-delivery references.
- Publish the agreed billing document and reconcile order, delivered quantity, invoiced quantity and open balance.
Security, testing and production rollout
Security and access requirements
Define access by business action and organizational scope. Separate permissions for reading masters, creating documents, changing open records, releasing transactions and viewing financial data. Use dedicated integration identities and approved credential management; avoid shared administrator access. Keep customer environments and partner configuration boundaries explicit.
Agree protection of data in transit and at rest, secret rotation, audit retention and masking of sensitive logs. Restrict test datasets and exception screens to authorized users. Changes to payment details or sensitive master data require separate business authorization; ordinary transaction processing must not silently update them.
Acceptance tests
| Test condition | Expected evidence |
|---|---|
| Valid transaction | One intended ERP result with correct organization, party, lines, quantities, amounts and external references. |
| Replay and duplicate | A replay does not create a second business record or duplicate a stock or financial movement. |
| Invalid master data | An unknown item, location or account produces a clear exception and no unintended posting. |
| Partial transaction | The completed quantity and remaining quantity reconcile across the original and related records. |
| Revision conflict | A stale or late revision does not overwrite newer or completed business activity. |
| Uncertain submission | A timeout after submission is resolved by checking the business outcome before another create action. |
| Volume and cut-off | Representative peak volume meets agreed deadlines with measured backlog, processing duration and recovery behavior. |
| Authorization | An identity cannot access another company or perform an unapproved release, master-data change or finance action. |
Controlled rollout
Approve the transaction list, mapping rules and success criteria first. Test representative partner documents in the agreed nonproduction environment, then complete partner certification where required. Reconcile opening references and queued documents before production cutover. Start with a defined partner or transaction set and monitor actual results before expanding coverage.
The rollout plan identifies who can pause processing, how queued work is retained, how already posted documents are corrected, and when operations resume. ERP upgrades, cloud releases, new partner requirements and mapping changes require impact review and regression tests for affected flows.
Initial synchronization and cutover data
Define the initial data population separately from ongoing transaction processing. Identify which active customers, suppliers, products, locations and reference values are required before the first live document. Include only the open orders, balances or historical references that the agreed business scope needs. Record source ownership, extraction time and the reconciliation totals for the opening population.
During cutover, distinguish transactions already processed in the previous environment from transactions waiting to be processed. Preserve original partner references and ERP identifiers for open documents. Establish how changes made during the cutover window are captured and reconciled. A historical document used for reference must not accidentally be replayed as a new stock or accounting transaction.
Processing frequency and capacity
Assign a frequency to each flow rather than one timing promise for the entire integration. Urgent order changes, periodic inventory availability, shipment notices and financial reconciliation have different deadlines. Agree the peak document rate, typical and largest line counts, permitted backlog, ERP maintenance windows and the oldest acceptable unprocessed transaction.
Measure acceptance time, business completion time and partner response time separately. Test the effect of an ERP outage and the rate at which accumulated work can safely resume. Publish operating targets only after representative testing; a successful small sample does not establish peak-volume capacity or a guaranteed near-real-time service level.
SAP S/4HANA Cloud Public Edition integration FAQs
How quickly are transactions processed?
Timing is defined by business need, ERP capacity and partner deadlines. The design distinguishes event-driven business triggers, scheduled processing windows and bulk reconciliation requirements without promising an unmeasured latency.
What happens when the ERP rejects a transaction?
The operating design identifies the failed document, relevant fields, business reason and responsible owner. Correction and replay must preserve the original identity and prevent duplicate posting.
What will ECOM explain during the live meeting?
We review the actual connection path, hosting and deployment requirements, environment prerequisites and detailed technical responsibilities after understanding your ERP and scope.
Keep exploring
Related
Solution
ERP Integration
Connect your ERP to trading partners through EDI, APIs, IDocs, files and connectors.
Service
ERP Implementation
ERP implementation for SAP, Oracle, Microsoft, NetSuite, Infor, Epicor, QAD and Sage, with B2B integration built in.
Solution
EDI Integration
Exchange X12 and EDIFACT documents with partners and integrate them directly with your ERP.
ERP
SAP Business ByDesign
Order, shipment and invoice integration for SAP Business ByDesign, with validation and reconciliation.
ERP
SAP Business One
EDI and API integration for SAP Business One through the Service Layer and DI API, plus implementation services.
ERP
SAP ECC
IDoc-based EDI integration for SAP ECC and support for migrating partner interfaces to S/4HANA.
ERP
SAP S/4HANA
IDoc, API and EDI integration for SAP S/4HANA, plus S/4HANA implementation services.
Integrating or implementing SAP S/4HANA Cloud Public Edition?
Bring your SAP S/4HANA Cloud Public Edition version, installed modules, priority transactions, sample documents and known exceptions. ECOM will review the required systems integration, explain the specific integration path during a live meeting and define a practical implementation scope with your team.