SAP Business ByDesign EDI and B2B integration

The ERP environment we integrate around

SAP Business ByDesign is one of the ERP editions ECOM scopes integration around. The edition, release and licensed modules are identified first, and coverage is confirmed for your environment.

The design identifies the installed edition and release, the company, the organizational units and the records in use. These values determine transaction routing, record validity, ownership and the financial or operational context in which a document is processed.

Systems and ownership

Close

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.

• EDI integration
• PRISM-WebEDI
• PRISM-SmartConvert
• Contact ECOM

Transaction flows and processing rules

Direction is relative to SAP Business ByDesign. Each flow is defined by its source, target business record, release condition and successful result. Creation, update, cancellation and enquiry are scoped separately.

Close

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.

Close

Processing control and error recovery

Business state controls the next action

For SAP Business ByDesign, the design evaluates the ERP's own approval, hold, fulfillment and billing states for each flow. 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.

Close

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.

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

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.