Status

  Approved

Owner
Stakeholders

Issue

KDD066 defined the approach to simplify and standardize the EDI landscape.
It stated that for each business process there should be:

  • One Primary EDI

  • One Secondary EDI, allowed only as an exception

However, when KDD066 was approved, the Primary and Secondary EDIs listed were indicative only. They were based on conceptual design and not on detailed process analysis.

Since then, SyWay has moved into Detailed Design. During this phase, the processes, integrations, and partner constraints are now much clearer.

Because of this, the EDI assignments from KDD066 need to be:

  • Reviewed process by process

  • Evaluated against the SyWay To-Be design

  • Finalized for execution

In addition, a governance approach is required to manage any future need for new EDIs.

Recommendation

The below table is the recommendation of the Primary and Secondary EDI platforms for each business process based on the outcomes of the SyWay Detailed Design. These recommendations align with 

  • SyWay To-Be architecture

  • Supports standardization while respecting business realities

  • Ensures business continuity where legacy solutions must remain

  • Avoids uncontrolled growth of the EDI landscape

These EDI positions described serve as the guidelines for Sales, Procurement, Logistics, Transportation Management, Finance, and Global Trade Services. They replace the indicative EDI assignments previously documented and provide clarity for SyWay implementation and partner onboarding.

Any future change to the EDI directions defined in the tables will be subject to a formal change request and governance process, to ensure that deviations are assessed, approved, and documented in a controlled manner.

AreaTransactionPrimary EDISecondary EDI
SalesQuotationNone

Sales ContractNone

Sales OrderCommerce PortalElemica , Esker

BillingElemica , E-Invoicing (EDICOM), Commerce Portal

ComplaintsNone
ProcurementRFxNone

CatalogsAriba Catalogs

ContractsNone

Purchase OrdersAriba Network , Supplier Portal 

Order ConfirmationAriba Network , Supplier Portal

ASNAriba Network , Supplier Portal , Elemica

Service Entry SheetAriba Network , Supplier Portal

InvoiceAriba Network , Supplier Portal , E-Invoicing (EDICOM)
TM

Freight Collaboration (Carrier Confirmation, Slot Booking, Spot tendering)

BN4L

TMS4S


Yard Management (Check-in / Checkout)

Selfy

Simba/Focusol


Invoices

BN4L / VIM

CASS


Track and Track (Transportation Event Updates) - Ocean

BN4L GTT + P44



Track and Track (Transportation Event Updates) - Road, Rail, Air

BN4L

TMS4S
LogisticsInventory Management (Inc. Goods Receipt, Stock Transfer, Goods Issue, Stock on Hand etc.)3PL EDI Interfaces

InboundNone

OutboundNoneElemica

Goods ReceiptNone
FinancePaymentSwift
GTSCustoms

Customs Brokers Interfaces Per Region 


Background & Context

KDD066 was created at an early stage of the SyWay program, when the objective was to set a strategic direction for the future EDI landscape. The focus at that time was on reducing complexity by limiting the number of EDI platforms and introducing the concepts of Primary and Secondary EDI.

Following KDD066, the SyWay program progressed into Detailed Design across multiple domains, including Sales, Procurement, Logistics, Transportation, Finance, and Global Trade Services. This phase delivered several important clarifications:

  • A clear To-Be integration architecture, centred on SAP S/4HANA and SAP Integration Suite, with preference for API- and event-based integrations and controlled coexistence of legacy EDIs

  • A defined customer and supplier collaboration strategy, including Commerce Portal, Supplier Portal, and selective use of Ariba Business Network

  • A confirmed approach for 3PL integration, clearly distinguishing between integrated 3PLs and no-integration scenarios

  • Finalised bank connectivity decisions, retaining SWIFT Bureau connectivity

  • A regional GTS / Customs Control Tower model, with broker harmonisation and broker-agnostic message design

These Detailed Design outcomes provide the necessary maturity to move from conceptual intent to concrete, executable EDI decisions.

Therefore, this KDD builds on KDD066 by validating the original principles, reassessing the options per process, and confirming the final Primary and Secondary EDI platforms aligned with the SyWay To-Be design.

As a result, the indicative EDI assignments in KDD066 no longer reflect the executable To-Be design and must now be formally confirmed or adjusted.

Below table is the list of all the EDI assignments from KDD066 - The highlighted ones are evaluated in this KDD.

AreaTransactionPrimary EDISecondary EDI
SalesQuotationNone

Sales ContractNone

Sales OrderElemicaEsker 

BillingCustomer PortalElemica , Tungsten, E-Invoicing, ARKHINEO

ComplaintsNone
ProcurementRFxNone

CatalogsAriba Catalogs

ContractsNone

Purchase OrdersAriba Network Elemica

Order ConfirmationAriba Network Elemica

ASNAriba Network Elemica

Service Entry SheetAriba Network Elemica

InvoiceAriba Network Fedex , ProMaster , Synchro , Xerox , Ariba Network , E-Invoicing , Citibank , OpenText
TMFreight OrdersNoneBluJay , Transwide, CASS

InvoicesNoneCASS , TMS/CHEMLOGIX

Truck Weight UpdateNoneWeighbridge Systems: Selfy Weighbridge, LAS, Weightbridge - Tecsidel, APAC Weighbridge Systems, Qbit Portaria

Transport Event Update (via SAP BNL)NoneSelfy, Simba, Project 44, FDTMS
LogisticsInventory Management (Inc. Goods Receipt, Stock Transfer, Goods Issue, Stock on Hand etc.)3PL Template InterfacesArcese, Katoen Natie, Sunland Infor, Kenco, Mitsui Soko, PML CN, DHL CN

InboundNoneElemica

OutboundNoneElemica

Goods RecieptNoneElemica
FinancePaymentSwiftSwift , Bank Portals
GTSCustomsNoneSeeburger , COMEX , Jet etc..


Assumptions

Following are some of the assumptions that are considered as part of the analysis.

  • API-based and event-based integrations are preferred where possible

  • Legacy EDI solutions will remain only where required for business continuity

  • New partners will use the defined Primary EDI by default

Constraints

Following are some of the constraints that are already considered as part of the recommendations 

  • Existing contracts with customers, suppliers, banks, and brokers

  • Different levels of partner technical readiness

  • Regulatory and country-specific requirements

Impacts

Business Impact

  • Clear and consistent EDI rules per process

  • Easier partner onboarding

  • Better alignment across regions and GBUs

IT / Integration Impact

  • Reduced number of EDI platforms

  • Clear default integration patterns

  • Better monitoring and error handling

Change Impact

  • Some legacy EDIs will remain for specific partners

  • New partners will be guided to standard solutions

Financial Impact

The recommended EDI approach does not introduce large, unplanned investments.

Most activities (Supplier Portal, 3PL interfaces, BN4L integrations, Customs Broker) are already part of the SyWay scope and are aligned with existing delivery plans.

By limiting the number of EDI platforms and defining clear Primary EDIs, the approach avoids future incremental EDI costs driven by ad-hoc partner requests.

Business Rules

  • Each business process must have Primary EDI and Secondary EDIs are allowed only by exception

  • New EDIs require governance approval

  • New partners must use the Primary EDI

  • Exceptions must be documented and reviewed regularly

Options considered and Evaluation

For each functional area, EDI options were assessed based on:

  • Fit with SyWay architecture

  • Scalability and reuse

  • Partner readiness

  • Risk and business continuity

The following sections describe the selected Primary and Secondary EDIs per domain.

Sales (Order to Cash)

For Sales Orders and Invoice, following are the options

  • Option 1 – Commerce Portal as Primary EDI for all customers
  • Option 2 – Continue legacy EDIs (Elemica, Esker) as primary

  • Option 3 – Portal as default, legacy EDIs by exception (Recommended)

OptionDescriptionProsConsEvaluation
Option 1Commerce Portal as Primary EDI for all customers
  • Single, standardized channel for all customers

  • Scalable and aligned with SyWay digital strategy

  • Reduced dependency on multiple legacy EDIs

  • Better visibility and self-service capabilities

  • Requires customer change and onboarding effort

  • Not all strategic customers are willing to migrate

  • Risk of commercial impact if migration is forced

Not suitable as single approach
Option 2Legacy EDIs as primary
  • No disruption for existing customers

  • Stable and already integrated for some strategic accounts

  • Multiple EDIs increase complexity and support effort

  • Not scalable for onboarding new customers

  • Not aligned with long-term SyWay architecture

Not aligned with strategy
Option 3Portal as default, legacy EDIs by exception
  • Clear default channel for new customers

  • Protects strategic customers who cannot migrate

  • Limits growth of legacy EDIs

  • Balances standardization with business reality

  • Requires governance to control exceptions

  • Dual model must be clearly communicated

Recommended


Conclusion

  • Commerce Portal is Primary EDI

  • Legacy EDIs remain Secondary, only for existing strategic customers

  • Note: For Invoicing E-Invoicing (EDICOM) is primary EDI for all the countries where it is mandatory as part of Regulation

Procurement (Source to Pay)

Following are the options for Purchase Order, Invoices

Option 1: Ariba Business Network as Primary EDI for all suppliers

Option 2: Supplier Portal as Primary EDI for all Suppliers

Option 3: Supplier Portal as default, Ariba for selected suppliers (Recommended)

OptionDescriptionProsConsEvaluation
Option 1Ariba Business Network as Primary EDI for all suppliers
  • Strong automation for high-volume suppliers

  • Mature and proven SAP solution

  • Supports straight-through processing

  • Heavy onboarding effort for small and medium suppliers

  • Supplier resistance based on past experience

  • High operational effort for procurement teams

Not suitable for all suppliers
Option 2Supplier Portal for all suppliers
  • Lightweight and easy to onboard

  • Usable by all suppliers

  • Low change impact and fast adoption

  • Limited automation for very high-volume suppliers

  • Not optimal for M2M integration scenarios

Not sufficient alone
Option 3Supplier Portal default, Ariba for selected suppliers
  • Flexible model based on supplier maturity

  • Reduces onboarding friction

  • Leverages Ariba where it adds real value

  • Supports long-tail suppliers effectively

  • Requires clear supplier segmentation rules

  • Two primary channels must be governed

Recommended

Conclusion

  • Supplier Portal is Primary by default

  • Ariba Business Network is Primary for selected suppliers

  • The determination of the supplier’s channel (Supplier Portal vs. Ariba Business Network) will be made at the time of supplier onboarding.

  • Once assigned, the communication channel will remain fixed for the duration of the supplier lifecycle, unless a formal change is requested by the supplier 

Logistics – 3PL (Warehouse Execution)

Following are the options for 3PL integrations

Option 1 – Integrate all 3PL warehouses (3PL Specific Integration) 

Option 2 – As-Is Integration with existing 3PL's and No integration for other 3PL (3PL Specific Integration) 

Option 3 – Integrate where justified, no integration otherwise (Standardize modernised the integration via API)

OptionDescriptionProsConsEvaluation
Option 1 Integrate all 3PL warehouses (3PL Specific Integration) 
  • Full visibility and automation

  • Reduced manual effort and errors

  • Standardized execution across sites

  • Not justified for low-volume or temporary warehouses

  • Higher upfront integration cost

  • Not scalable
Not pragmatic
Option 2As-Is Integration with existing 3PL's and No integration for other 3PL (3PL Specific Integration) 
  • Comparatively lower integration cost

  • Quick set-up

  • Varied processes and delayed visibility

  • Higher operational effort

  • Not scalable

Not scalable
Option 3Integrate where justified, no integration otherwise (Standardize and modernised the integration via API)
  • Integration effort aligned with business value

  • Supports strategic warehouses

  • Avoids unnecessary cost

  • Clear and pragmatic model

  • Scalable - Change of warehouses is possible in future
  • Requires decision per warehouse

  • Needs governance to avoid inconsistency

Recommended

Conclusion

  • Integrate where justified, no integration otherwise (Standardize and modernised the integration via API)

Transportation Management (TM)

Following are the options for Transportation Management tools

Option 1 – Keep multiple regional TM tools (As-Is)

Option 2 – Global carrier collaboration platform (with US as exception)

OptionDescriptionProsConsEvaluation
Option 1Keep multiple regional TM tools (As-Is)
  • No immediate change in regions

  • Existing carrier adoption

  • Fragmented landscape

  • Higher support and integration effort

  • No global standard

Not aligned
Option 2

Global carrier collaboration platform (with US as exception)

  • BN4L
  • TMS4S / CASS (Road and Rail) for US and Canada
  • Simplified landscape

  • Global standard processes

  • Lower long-term support effort

  • Transition effort for some regions

  • Carrier onboarding required

Recommended

Conclusion

  • One global TM platform is confirmed as Primary

Mode of TransportPrimary EDISecondary EDINotes
RoadBN4L TMS4S/CASS (US & CA)Transition to global standard
RailBN4LNoneNew Global Coverage
OceanBN4LNoneNew global coverage
AirBN4LNoneNew global coverage

Finance (Bank Connectivity)

Option 1 – Move to SAP Multi-Bank Connectivity

Option 2 – Retain SWIFT Bureau (Recommended)

OptionDescriptionProsConsEvaluation
Option 1SAP Multi-Bank Connectivity
  • SAP-native solution

  • Potentially lower transaction costs

  • Limited bank coverage

  • New implementation effort

  • No strong added value over current setup

Not justified
Option 2SWIFT Bureau
  • Stable solution

  • Covers all banks

  • Lower risk and cost

  • Supports transition period

  • External dependency as it is a non-SAP solution
Recommended

Conclusion

  • SWIFT Bureau remains Primary

Global Trade Services (GTS)

Following are the options for Customs Broker Integration

Option 1 – Country-specific brokers and EDI designs

Option 2 – Regional broker harmonization with broker-specific EDIs

Option 3 – Regional brokers with broker-agnostic EDI design (Recommended)

OptionDescriptionProsConsEvaluation
Option 1Country-specific brokers & EDIs
  • Local flexibility

  • Minimal short-term change

  • High fragmentation

  • Difficult to govern

  • High future change cost

Not sustainable
Option 2Regional brokers with broker-specific EDIs
  • Reduced number of brokers

  • Some level of standardization

  • Broker dependency remains

  • Redesign needed if broker changes

Limited flexibility
Option 3Regional brokers with broker-agnostic EDIs
  • Supports broker harmonization strategy

  • Flexible to future broker changes

  • Reduced rework and dependency

  • Clear regional governance

  • Slightly higher initial design effort
Recommended

Conclusion

  • Regional model confirmed with broker-agnostic EDI



See also


  File Modified
PDF File KDD100 - EDI Solution - Approval L2C & P2F.pdf Approval L2C & P2F SC Apr 15, 2026 by CRESPIN-ext, Edouard
PDF File KDD100 - EDI Solution - Approval S2P.pdf Approval S2P Apr 15, 2026 by CRESPIN-ext, Edouard
PDF File KDD100 - EDI Solution - Approval R2R.pdf Approval R2R Apr 15, 2026 by CRESPIN-ext, Edouard

Change log

Version Published Changed By Comment
CURRENT (v. 21) Apr 16, 2026 08:32 RUIZ SOMOZA-ext, Carolina
v. 23 Apr 16, 2026 07:28 RUIZ SOMOZA-ext, Carolina
v. 22 Apr 16, 2026 07:23 RUIZ SOMOZA-ext, Carolina
v. 21 Apr 15, 2026 15:50 NARAHARI-ext, Bhargavi
v. 20 Apr 15, 2026 12:49 NARAHARI-ext, Bhargavi
v. 19 Mar 03, 2026 11:08 WENNINGER-ext, Sascha
v. 18 Feb 19, 2026 06:43 NARAHARI-ext, Bhargavi
v. 17 Feb 18, 2026 06:55 NARAHARI-ext, Bhargavi
v. 16 Feb 18, 2026 04:29 NARAHARI-ext, Bhargavi
v. 15 Feb 08, 2026 21:39 NARAHARI-ext, Bhargavi

Go to Page History

1 Comment

  1. While the Business Rules section clearly defines that each business process must have one Primary EDI (with Secondary allowed only by exception), I think we may need to clarify how this will actually be enforced operationally.

    At the moment, the KDD defines which channel is primary per process, but it doesn’t explicitly describe how that rule is applied during supplier onboarding and activation.

    Considering that:

    • We are operating in a dual-channel model (Supplier Portal and Business Network),

    • Channel selection depends on supplier segmentation,

    • Identity provisioning is managed via IAS,

    • Integration routing is handled through SAP Integration Suite,

    it would be helpful to clarify how the collaboration channel is technically controlled.

    My suggestion would be to explicitly state that:

    • The collaboration channel (Supplier Portal / Business Network / E-Invoicing) is assigned during supplier onboarding and stored as a master data attribute in S/4 or MDS.

    • That attribute drives identity role provisioning, integration routing, and transaction enablement.

    • A supplier should not be considered operational (i.e., eligible to receive POs) until channel assignment and enablement validation are completed.

    Without this clarification, there is a potential risk of:

    • Parallel channel usage for the same process,

    • POs being issued before technical readiness,

    • Inconsistent application of the Primary EDI rule,

    • Identity provisioning not aligned with the collaboration model.

    I am not suggesting any change to the decision itself. Rather, I believe making the enforcement mechanism more explicit would strengthen the document and ensure alignment between the EDI governance, the Supplier Lifecycle (KDD077), identity provisioning, and integration routing.