In this article, we will discuss the concept of EDI merging and splitting, EDI processing pipeline in B2B-add-on, and how to configure the EDI Separator/B2B Integration Cockpit to split bulk EDI messages. Moreover, the functionality of EDI Splitter in SAP Integration Suite on BTP (CPI/ BTP-IS)

EDI (Electronic Data Interchanges) is a global standard that is used to communicate business transactions like sales orders, invoices, etc. between business partners. When the volume of transactions is high, usually multiple EDI messages (transactions) are bundled together as one message before being transmitted to a business partner. The EDI message receiver needs to split the bulk EDI message into individual transactions before processing them.

Why Do We Need to Split EDI Messages?

In B2B business processors, often a large number of the transactional data is transmitted between partners. Therefore, it is cost-effective to bundle several transactions in one EDI file rather than transmitting multiple messages. For example, it is more effective to transmit 200 invoices in one EDI file than transmitting each invoice in 200 different files. This can reduce transmission costs through VAN or other networks.

Also, there are scenarios where EDI partner bundles together different types of transactions that are merged into a single EDI file. For example, one EDI file could contain multiple sales orders, invoices and delivery notifications (ASN).

Therefore, EDI message senders collect multiple transactions and message types into one EDI message before transmitting it to the receiver. Hence, at the receiver, these bulk EDI messages should be split into individual transactions and messages before being processed.

In PI/PO, we use the EDI Separator adapter provided with B2B Integration Cockpit to split bulk messages into individual transaction sets.

In SAP Integration Suite on BTP (CPI/BTP-IS), SAP has provided a standard process step not only split bulk EDI messages but also generate EDI achievements.

---

Prerequisites for Splitting EDI Messages using B2B Add-on (PI/PO):

Before we can implement EDI split scenarios, we need to have B2B Integration Cockpit installed in the SAP Process Orchestration system. Next, we must import the standard Control Key associations to B2B add-on.

Installing B2B Add-on in SAP PI/PO

Before we can implement any B2B integration scenarios through Integration Cockpit, we need to install the add-on if it hasn’t been done yet.

We need to setup components B2B Toolkit, B2B Mapping Kit and B2B EDI Runtime Content to complete the installation. You can follow the detailed guide on how to install B2B Integration Cockpit in my previous article.

Setup Standard Control Key Associations

To integrate standard EDI message formats, SAP has provided a set of B2B standard objects we can reuse in integration scenarios. For example, standard EDI message formats with different versions, EDI message XSDs, Control Key associations are some of the standard objects provided by SAP. You can download them directly from SAP Marketplace and import them to your system. The set of objects is known as B2B EDI Runtime Content.

These reusable objects come in handy when the integration scenario uses standard EDI formats. You can check my previous posts on how to import standard content to PI/PO and set up B2B EDI Runtime Content for detailed guides.

---

Message Processing Pipeline for EDI Splitting via B2B Integration Cockpit

Let us assume we have an EDI partner who delivers EDI files to SAP PI/PO using AS2 protocol. EDI files can have multiple messages such as order (ORDERS) and deliveries (DESADV). From the EDI messages received, sales orders and deliveries should be created in SAP S4 HANA back-end system.

Step 1 – Sender Adapter (AS2)

The first step of the processing pipeline is done by the sender adapter. The adapter engine connects with the external system and extracts EDI file for processing. With B2B Integration Cockpit, SAP has provided several EDI specific adapters such as AS2, OFTP and X100. Depending on the communication capabilities of external EDI partners, we can use not only these adapters but any adapter from the Adapter Engine to exchange EDI files.

Step 2 – EDI Separator Receiver Adapter

The EDI files extracted from EDI partner are then sent to EDI Separator Receiver Adapter (Communication Channel). At the EDI Separator receiver adapter, EDI file is split into individual transaction sets (messages).

EDI Separator receiver adapter always splits EDI messages to individual messages. The splitting criteria depend on the EDI message format. For example, ANSI X 12 EDI files are split at each “ST” (Transaction Set) segment. EANCOM EDI files are split at each “UNH” (Message Header) segment.

Step 3 – EDI Separator Sender Adapter

Then the EDI Separator Sender Channels pick these individual EDI messages and route them to the Operation and Message mapping program. Another important process performed by the sender EDI separator Communication Channel is converting the EDI message to EDI XML. SAP has provided different Converter Adapter modules to transform different types of EDI formats to XML. We will look at how to configure these Adapter Modules in this article.

Step 4 – EDI to iDoc Message Mapping

Next, individual EDI XML messages are mapped with relevant iDoc messages using appropriate message mapping programs.

Step 5 – Receiver iDoc_AAE Adapter

Finally, iDoc XMLs returned by message mapping programs are sent to SAP back-end system via iDoc_AAE receiver adapter.

---

ANSI X 12 EDI Split Scenario with Configuration

Let’s assume we have a scenario where multiple invoice (EDI 810) messages are sent by the EDI partner in one message. We need to split them into individual invoice messages and map them to INVOIC.INVOIC02 iDoc.

EDI Message format	ANSI X12
Transaction set	810 (Invoice)
Version	004010
Inbound iDoc	INVOIC.INVOIC02

Bulk ANSI X12 EDI File

ISA*00*                   *00*                   *ZZ*Sender_ID1                            *01*Receiver_ID1*20191109*0509*U*00400*000000145*0*P*>
GS*IN*Sender_ID1*Receiver_ID1*20191109*0509*145*X*004010
ST*810*0001
BIG*20191109*InvoiceNo1*20191109*123456***DI
REF*CO*4500000009
N1*BT*INTHUB
N3*22 Boston Ave
N4*Cambridge*MA*02139
IT1*00010*11*EA*32.00**VP*887131
PID*F****Widget, Blue
SLN*00010**O
TDS*6000
CTT*1*2
SE*12*0001
GE*1*145
GS*IN*Sender_ID1*Receiver_ID1*20191109*0509*145*X*004010
ST*810*0001
BIG*20191009*InvoiceNo2*20191009*112998***DI
REF*CO*4500000010
N1*BT*INTHUB
N3*22 Boston Ave
N4*Cambridge*MA*02139
IT1*00010*76*EA*11.00**VP*887131
PID*F****Widget, Blue
SLN*00010**O
TDS*6000
CTT*1*2
SE*12*0001
GE*1*145
IEA*1*000000145

Here we have an EDI file with one ISA envelope and two invoices in two ST segments.

ISA/IEA Segment – Interchange Envelope

EDI envelope for ANSI X 12 starts with ISA and ends with a corresponding IEA segment. This is called the Interchange Envelope of the EDI file.

ISA*00*                   *00*                   *ZZ*Sender_ID1                            *01*Receiver_ID1*20191109*0509*U*00400*000000145*0*P*>

You can find transmission information such as Data separator, Interchange Sender ID, Interchange Receiver ID, Date, Time, Interchange Control Number, etc. under Interchange Envelope.

In this example,

Authorization Information Qualifier	00
Security Information Qualifier	00
Interchange ID Qualifier	ZZ
Interchange Sender ID	Sender_ID1
Interchange ID Qualifier	01
Interchange Receiver ID	Receiver_ID1
Date	20191109
Time	0509
Repetition Separator	U
Interchange Control Version Number	00400
Interchange Control Number	000000145
Acknowledgment Requested	0
Usage Indicator	P

GS/GE Segment – Functional Group

The functional group is the inner envelope of EDI file inside ISA/IEA segment. Functional Group can contain multiple Transaction Sets (ST/GE) all of the same type. For example, it can hold multiple invoices or multiple purchase orders, etc. But all the Transactional Sets inside one Functional Group should be of the same type.

GS*IN*Sender_ID1*Receiver_ID1*20191109*0509*145*X*004010

Functional ID code	IN
Interchange Sender ID	Sender_ID1
Interchange Receiver ID	Receiver_ID1
Date and Time	20191109/0509
Group Control Number	145
Responsible Agency Code	X
Version/Release/Identifier Code	004010

ST/GE Segment – Transactional Set

In ANSI X12 every transactional Set is represented by a three-digit code. For example, 810 for invoices, 856 for ASN, 997 for Functional Acknowledgment, etc.

Transactional Set in ANSI X12 starts with a ST segment and ends with a GE segment.

ST*810*0001

Transaction Set Identifier Code	810
Transaction Set Control Number	0001

In the Receiver EDI Separator adapter of PI/PO, these Transaction Sets are split into individual Transactions. We can use B2B Number Range Objects to assign Control Numbers of outgoing EDI messages.

---

Let’s look at how to configure the EDI splitting integration scenario.

Step 1 – Confirm EDI Runtime Content is available

Before moving to configuration, confirm EDI Runtime Content for EDI Invoice message Type 810 and version 004010 is available in EDI Content Manager.

Control Key	SAP
Set	810
Version	004010
Message Format	ANSI X12

Step 2 – Download EDI XSD

Download the XSD schema of the EDI 810 message’s XML format.

Step 3 – Create External Definition

Create an External Definition with the downloaded XSD.

Step 4 – Create an Outbound Service Interface

Assign External Definition as the Data Type to create an Outbound Service Interface.

Step 5 – Import iDoc Type to ESR

Import the target iDoc structure to ESR.

iDoc Type

INVOIC.INVOIC02

Step 6 – Create Message Mapping between EDI XML and iDoc

Create a mapping program between source EDI XML format and target iDoc structure.

Assign the EDI External Definition we created in Step 3 to the sender message type and iDoc type we imported in Step 5 to the target Message Type.

Map the iDoc Control Record and other relevant segments/fields of the iDoc.

Step 7 – Create Operation Mapping between EDI Sender Service and iDoc

Using the Outbound Service Interface, iDoc imported, and Message Mapping created in previous steps, build an Operation mapping.

Step 8 – Create and Configure EDI Separator Reciever Channel

Configure EDI Separator receiver adapter that splits EDI files. This Channel splits the bulk EDI file into multiple Transaction Sets.

Adapter Type	EDISeperator
Transport Protocol	PI
Message Protocol	Electronic Document Interchange
Adapter Engine	Central Adapter Engine
Formatting	Indent messages, Enable Plain, XML and Default

Step 9 – Create and Configure EDI Separator Sender Channel

Configure a sender EDI Separator Communication Channel that picks split EDI messages (Transaction Sets) of Type 810 with Interchange Sender ID as “Sender_ID1” and Interchange Receiver ID as “Receiver_ID1”.

Adapter Type	EDISeperator
Message Protocol	ANSI X12
Version/Release/Identifier Code	004010 (ASC X12)
Transaction Set Identifier Code	810
Interchange Sender ID	Sender_ID1
Interchange Sender ID Qualifier	ZZ
Interchange Receiver ID	Receiver_ID1
Interchange Receiver ID Qualifier	01
Character Encoding	UFT-08

Not only does EDI Separator sender Adapter pick individual EDI Transaction Sets split by Receiver Adapter, but also converts ANSI X12 EDI format to XML.

EDI format is converted to XML by adapter modules. To convert EDI files of format ANSI X12 to XML, we need to use the adapter module “localejbs/X12ConverterModule”.

Complete list of EDI to XML Converter Modules in SAP PI/PO

EDI Format	Converter Module
ANSI X12	localejbs/X12ConverterModule
EDIFACT	localejbs/EdifactConverterModule
EANCOM	localejbs/EdifactConverterModule
ODETTE	localejbs/OdetteConverterModule
TRADACOMS	localejbs/TradacomsConverterModule
VDA	localejbs/VdaConverterModule
PLAIN	localejbs/PlainConverterModule

Step 10 – Create EDI Sender Communication Channel

Create a Communication Channel that extracts EDI files from the external partner. Use a suitable protocol depending on the scenario. For this example, I will create an AS2 sender Communication Channel.

Step 11 – Create an iFlow from EDI Partner Sender System to EDI Separator

Build a common EDI sender interface from EDI partner to EDI Separator Reciever Adapter. You can use an internal Business Component or a Business System to represent the EDI Separator receiver.

This interface is just a pass-through without any mapping.

EDI sender party	EDIPartner
EDI sender Communication Component	B2B
Inbound Service Interface	B2B_Common_Inb_Async
Sender Communication Channel (AS2)	AS2_s_Common
Receiver Communication Component	BC_B2B
Outbound Service Interface	B2B_Common_Out_Async
Receiver Communication Channel	EDISeparator_r

Step 12 – Configure iFlow from EDI Separator to SAP Back-end System

The second iFlow is needed to process the EDI files split by the EDI Separator receiver adapter. This is the integration flow that captures individual Transaction Sets and executes mapping between EDI XML and iDoc.

Communication party	EDIPartner
Communication Component	B2B
Inbound Interface	EDI_810_004010_Out_Async
Sender Communication Channel	EDISeparator_s_810
Receiver Interface	INVOIC.INVOIC02
Operation Mapping	EDI_810_004010_to_INVOIC_INVOIC02
Receiver Channel	iDoc_r
Receiver Business System	SSXCLNT900

---

How to Test EDI Splitting in PI/PO

Let’s test the complete EDI splitting interface using the Test Tool.

To test the scenario go to Test Tool and trigger the EDI Common interface from EDI partner. This is the first iFlow we built in step 11.

Message Successfully Processed by EDI Reciever Adapter

EDI message is passed from the EDI partner to EDI Separator Receiver Adapter and processed successfully.

Bulk EDI Message Split into Multiple Transaction Sets by EDI Separator

EDI File split into two 810 Transaction Sets by EDI Separator adapter.

Split EDI Messages Picked up by EDI Separator Sender Adapter

EDI Message Converted to XML by Adapter Module

XML of Invoice # “InvoiceNo1”

<?xml version="1.0" encoding="UTF-8"?>
<ns:ASC810_004010 xmlns:ns="urn:Source_System:Invoice">
	<S_ISA>
		<D_DATAELEMENTSEPARATOR>*</D_DATAELEMENTSEPARATOR>
		<D_I01>00</D_I01>
		<D_I02>                   </D_I02>
		<D_I03>00</D_I03>
		<D_I04>                   </D_I04>
		<D_I05>ZZ</D_I05>
		<D_I06>Sender_ID1                            </D_I06>
		<D_I05_2>01</D_I05_2>
		<D_I07>Receiver_ID1</D_I07>
		<D_I08>20191109</D_I08>
		<D_I09>0509</D_I09>
		<D_I10>U</D_I10>
		<D_I11>00400</D_I11>
		<D_I12>000000145</D_I12>
		<D_I13>0</D_I13>
		<D_I14>P</D_I14>
		<D_I15>></D_I15>
		<D_SEGMENTTERMINATOR>
</D_SEGMENTTERMINATOR>
		<S_GS>
			<D_479>IN</D_479>
			<D_142>Sender_ID1</D_142>
			<D_124>Receiver_ID1</D_124>
			<D_373>20191109</D_373>
			<D_337>0509</D_337>
			<D_28>145</D_28>
			<D_455>X</D_455>
			<D_480>004010</D_480>
			<S_ST>
				<D_143>810</D_143>
				<D_329>0001</D_329>
				<S_BIG>
					<D_373>20191109</D_373>
					<D_76>InvoiceNo1</D_76>
					<D_373_2>20191109</D_373_2>
					<D_324>123456</D_324>
					<D_640>DI</D_640>
				</S_BIG>
				<S_REF>
					<D_128>CO</D_128>
					<D_127>4500000009</D_127>
				</S_REF>
				<L_N1>
					<S_N1>
						<D_98>BT</D_98>
						<D_93>INTHUB</D_93>
					</S_N1>
					<S_N3>
						<D_166>22 Boston Ave</D_166>
					</S_N3>
					<S_N4>
						<D_19>Cambridge</D_19>
						<D_156>MA</D_156>
						<D_116>02139</D_116>
					</S_N4>
				</L_N1>
				<L_IT1>
					<S_IT1>
						<D_350>00010</D_350>
						<D_358>11</D_358>
						<D_355>EA</D_355>
						<D_212>32.00</D_212>
						<D_235>VP</D_235>
						<D_234>887131</D_234>
					</S_IT1>
					<L_PID>
						<S_PID>
							<D_349>F</D_349>
							<D_352>Widget, Blue</D_352>
						</S_PID>
					</L_PID>
					<L_SLN>
						<S_SLN>
							<D_350>00010</D_350>
							<D_662>O</D_662>
						</S_SLN>
					</L_SLN>
				</L_IT1>
				<S_TDS>
					<D_610>6000</D_610>
				</S_TDS>
				<S_CTT>
					<D_354>1</D_354>
					<D_347>2</D_347>
				</S_CTT>
				<S_SE>
					<D_96>12</D_96>
					<D_329>0001</D_329>
				</S_SE>
			</S_ST>
			<S_GE>
				<D_97>1</D_97>
				<D_28>145</D_28>
			</S_GE>
		</S_GS>
		<S_IEA>
			<D_I16>1</D_I16>
			<D_I12>000000145</D_I12>
		</S_IEA>
	</S_ISA>
</ns:ASC810_004010>
<!--Converted in 4142392 nanoseconds-->

XML of Invoice # “InvoiceNo2”

<?xml version="1.0" encoding="UTF-8"?>
<ns:ASC810_004010 xmlns:ns="urn:Source_System:Invoice">
	<S_ISA>
		<D_DATAELEMENTSEPARATOR>*</D_DATAELEMENTSEPARATOR>
		<D_I01>00</D_I01>
		<D_I02>                   </D_I02>
		<D_I03>00</D_I03>
		<D_I04>                   </D_I04>
		<D_I05>ZZ</D_I05>
		<D_I06>Sender_ID1                            </D_I06>
		<D_I05_2>01</D_I05_2>
		<D_I07>Receiver_ID1</D_I07>
		<D_I08>20191109</D_I08>
		<D_I09>0509</D_I09>
		<D_I10>U</D_I10>
		<D_I11>00400</D_I11>
		<D_I12>000000145</D_I12>
		<D_I13>0</D_I13>
		<D_I14>P</D_I14>
		<D_I15>></D_I15>
		<D_SEGMENTTERMINATOR>
</D_SEGMENTTERMINATOR>
		<S_GS>
			<D_479>IN</D_479>
			<D_142>Sender_ID1</D_142>
			<D_124>Receiver_ID1</D_124>
			<D_373>20191109</D_373>
			<D_337>0509</D_337>
			<D_28>145</D_28>
			<D_455>X</D_455>
			<D_480>004010</D_480>
			<S_ST>
				<D_143>810</D_143>
				<D_329>0001</D_329>
				<S_BIG>
					<D_373>20191009</D_373>
					<D_76>InvoiceNo2</D_76>
					<D_373_2>20191009</D_373_2>
					<D_324>112998</D_324>
					<D_640>DI</D_640>
				</S_BIG>
				<S_REF>
					<D_128>CO</D_128>
					<D_127>4500000010</D_127>
				</S_REF>
				<L_N1>
					<S_N1>
						<D_98>BT</D_98>
						<D_93>INTHUB</D_93>
					</S_N1>
					<S_N3>
						<D_166>22 Boston Ave</D_166>
					</S_N3>
					<S_N4>
						<D_19>Cambridge</D_19>
						<D_156>MA</D_156>
						<D_116>02139</D_116>
					</S_N4>
				</L_N1>
				<L_IT1>
					<S_IT1>
						<D_350>00010</D_350>
						<D_358>76</D_358>
						<D_355>EA</D_355>
						<D_212>11.00</D_212>
						<D_235>VP</D_235>
						<D_234>887131</D_234>
					</S_IT1>
					<L_PID>
						<S_PID>
							<D_349>F</D_349>
							<D_352>Widget, Blue</D_352>
						</S_PID>
					</L_PID>
					<L_SLN>
						<S_SLN>
							<D_350>00010</D_350>
							<D_662>O</D_662>
						</S_SLN>
					</L_SLN>
				</L_IT1>
				<S_TDS>
					<D_610>6000</D_610>
				</S_TDS>
				<S_CTT>
					<D_354>1</D_354>
					<D_347>2</D_347>
				</S_CTT>
				<S_SE>
					<D_96>12</D_96>
					<D_329>0001</D_329>
				</S_SE>
			</S_ST>
			<S_GE>
				<D_97>1</D_97>
				<D_28>145</D_28>
			</S_GE>
		</S_GS>
		<S_IEA>
			<D_I16>1</D_I16>
			<D_I12>000000145</D_I12>
		</S_IEA>
	</S_ISA>
</ns:ASC810_004010>
<!--Converted in 4232992 nanoseconds-->

EDI XML Mapped with iDoc Reciever

Converted EDI XML by EDI separator Sender adapter mapped with INVOIC02 iDoc by Massage Mapping Program.

iDocs Generated in SAP

Two invoice iDocs generated in SAP back-end system.

---

How to Use EDI Splitter in SAP Integration Suite of BTP (BTP-IS/CPI)

SAP Integration Suite provides a standard process step for splitting bulk EDI messages. Not just split but EDI Splitter can also validate EDI messages and generate acknowledgements.

Bulk EDI Sample with Multiple Transaction Sets

Assuming we receive ANSI X12 850 and 810 transactions in the same EDI message, I will create an iFlow to split the bulk EDI message into individual transactional steps. I will save each transaction into the respective data store based on the type of transaction—for example, 810 transactions in one Data Store and 850 in another Data Store.

EDI Splitter Configuration in SAP IS-BTP (CPI)

As I am expecting ANSI X12 EDI messages, I will configure the X12 configuration as follows:

The EDI splitter splits the bulk EDI file into individual transactions. Each ST/SE envelope of ANSI X12 EDI message will be generated as a separate message by the EDI Splitter.

For other EDI types such as EDIFACT, and EANCOM the general behaviour remains the same.

EDI Router Configuration in BTP-IS

As the split transactions can belong to different transaction types such as 810 and 850, I will configure a router step to identify the message type or transaction type of each message. This allows for further processing based on transaction type. For example, map the 810 transactions to INVOIC iDocs and map 850 transactions to ORDERS iDocs.

None-XML Condition to Route Messages

Multiple EDI-specific header parameters will be available for you in the Exchange for processing the EDI message further. As I am interested in the Transaction Type of each message, I can use the header parameter “EDI_Message_Type” to identify the type of each message. Let’s route the messages to Data Stores based on the “EDI_Message_Type”.

But in this scenario, we will save the messages in specific data stores based on the transaction type.

810 transactions in Data Store: DS_EDI_850

850 transactions in Data Store: DS_EDI_850

If there are any other EDI types, I will route them to Data Store DS_EDI_Other.

Usually, the Splitter step of the integration flow should be closed by a corresponding gather step. However, the EDI Splitter in combination with the Gather, Join, or Aggregator steps in the integration flow is not supported.

Test Bulk EDI Splitter Step and iFlow

I triggered the interface via Postman with the sample EDI file with multiple EDI transactions.

Notice in the message monitor of SAP Integration Suite, the EDI message has been split by the EDI splitter into two messages. One for 850 transaction and the other one for 810.

Notice that the ISA envelope of the incoming bulk EDI message gets copied over to both messages, 850 and 810. In that sense, the EDI splitter behaves similarly to the “General Splitter” step of SAP Integration Suite CI on BTP which copies over the enveloping elements to all messages.

Individual Transactions are saved in their corresponding Data Stores.

Generate 997 Acknowledgements Using EDI Splitter

If you want to generate acknowledgements based on the status of EDI splitting, set”Create Acknowledgment” as “Required”. It activates the generation of acknowledgements.

It will generate one 997 acknowledgement message per bulk EDI file. However, an individual 997 Transaction Set will be created for each corresponding Transaction Set in the incoming EDI message. All the 997 transaction sets will be included in the generated acknowledgement message.

You also have the option of creating a new unique control number from a Number Range object. Then the Control Number of the acknowledgement will be assigned from the next number of the Number Range.

Route Generated 997 Messages

Since we now have 997 EDI messages also in the process step, I will add another path to route the 997 messages into Data Store DS_EDI_997. In real-life scenarios, maybe you want to send these 997 messages back to the EDI file sender or save them for auditing.

I am just using the header parameter “EDI_Message_Type” to route messages. However, in your scenario maybe you will receive 997 transactions in the incoming bulk EDI message itself. In such cases, use a combination of parameters such as “EDI_GS_SenderID” to identify the 997 messages generated by the EDI splitter from the 997 acknowledgements received in the bulk EDI message itself.

None-XML Condition for the EDI Router: ${header.EDI_Message_Type} = ‘997’

Test the Bulk EDI Splitter and Acknowledge Generation

Now there is an additional message that gets generated by the EDI Splitter. That is the 997 acknowledgement of the bulk EDI file.

997 Acknowledgement is Saved in the Data Store

Control Number Assignment of the Acknowledgment

Control numbers of each Transaction Set of the EDI incoming messages as well as the Control Numbers of the Functional Group get assigned to the corresponding 997 acknowledgement.

To summarize, EDI messages are often transmitted as a collection of Transactions in one message. EDI message receivers should split them and process them individually. SAP Integration Suite on BTP (CPI) provides a standard step to split bulk EDI messages into Transactional Sets. Additionally, it allows you to validate and generate acknowledgements.

The B2B Integration Cockpit of Pi/PO provides a set of functionalities to split and process bulk EDI messages. You can configure iFlows and B2B Integration Cockpit to set up as shown above to process bulk EDI messages.

Please leave a comment if you have used any other techniques and if you have any questions about the EDI processing procedure described here.