Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Introduction:

As we all know, from PI 7.31, sap has shipped their own B2B add-on solution. To implement EDI, now customers may not have to rely on 3rd party EDI providers like Seeburger. SAP EDI adapters are still new and not exhaustively tested to validate their efficiency and robustness but it is certainly true that SAP has taken a big step towards developing a stable and cost effective EDI implementation.

We are all aware of importance of functional acknowledgements in EDI communication. In seeburger, we had a monitoring workbench where we can check the status of all outbound messages. In Most cases, Business expects a report every day that gives them a clear picture of status of all EDI messages sent to Vendors. This functionality is available in most of the middleware. Unfortunately, in SAP PI, this feature is still missing.

What is FA Reporting?

FA Status Reporting is a mechanism by which it is ensured by sending partners that all messages sent by them are successfully received at the receiver side. It also reports those messages which failed in error at the receiver side so that necessary measures could be taken. Whenever an EDI message is sent out, a log is created in the database. When we receive an Functional acknowledgement back, we update the corresponding call with the Status detail. In SAP PI, this information is maintained in BC_MSG table but there is no standard report available that generate a report that can provide information of all messages for which functional acknowledgement is not received and could be shared with business.

We had this requirement in our project. Business wants this report every day for all partners. As this functionality is not available in PI as of now, we had to implement it ourselves.

EDI message details.

Every EDI message have segment that are used to uniquely identify a document. I will be using EDI ANSI X12-850 message to explain our design.

There are three segments in an EDI X12 messages by which we can identify any message uniquely.

ISA, GS and ST segments can be used to get data which could be used to uniquely identify any message. We can extract this information before sending EDI file to the partner and save it in a database table. Initially, we can put STATUS as NONE.

ISA Control Number

GS Control Number(primary)

Status

other information

000003438

1212

NONE

any other required fields

Now the second step is to check received Functional Acknowledgements and update the entry created in above step. To achieve this, let us try to understand 997 FA structure.

ISA*01*0000000000*01*XXXXX     *01*XYZXYZXYZ      *12*ABCDABCDAB     *111206*1100*U*00401*000000001*0*P*>

GS*FA*XYZXYZXYZ*ABCDABCDAB*20111206*1100*1*X*004010

ST*997*0001

AK1*PO*1421

AK9*A*1*1*1

SE*4*0001

GE*1*1

IEA*1*000000001

For a 997 FA, the sender and receiver IDs will be swapped. This is self-explanatory as Sender of EDI document will be the Receiver of 997 Ack. Let us understand 997 FA structure closely.

The structure is similar to the outbound EDI file, however, sender/receiver IDs are swapped, Group type is FA(Functional Ack), and Document type is 997. But this is not the information we are interested in. We need to identify the original outbound EDI message for which we have received this FA. This information is available in AK1 segment of FA.

From Segment AK1, we will get GS control number while AK9 segment will give us the status(A=Accepted, R= Rejected, E= Error). Based on GS control number, you can update the previous entry in the database.

ISA Control Number

GS Control Number(primary)

Status

other information

000003438

1212

ACCEPTED

any other required fields

By this, we complete the first part of the requirement, ie, maintaining a database that contains FA status details of all messages going out of our system. The second part is to fetch data from this table and create customized reports. I don’t think there will be any issues in this part as we can use a simple JDBC to file, or JDBC to Mail scenario which will fetch data from this table via a select query and then will generate files at some location, or will send a mail to the respective partner.

Please let me know if you find this document relevant. Please let me know if some sections of this document are not clear.

Please share your feedback so that I can improve this document further.

5 Comments
Labels in this area