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)


other information




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*>








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)


other information




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.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Saravana Kumar Kuppusamy

    We are planning on passing the IDOC number in the ISA control number field of the outbound EDI. The inbound 997 should carry the same control number back, which we plan on mapping in PI to the SYSTAT idoc and posting to SAP. In this approach, we avoid the Ztable creation and maintenance and the IDOC status in SAP should tell you the FA status. Do you anticipate any issues in this approach ?



    1. Gavaksh Saxena Post author

      Hi Saravana,

      Sorry for the late reply.

      I dont think there will be any issues in using idoc numbers as control numbers. The points you should check are:-

      1. idoc number length <+ The max length of ISA control number.

      2. there are other control numbers (GS control number etc). and 997 may contain these numbers. How are you planing to fill these control numbers.

      the only concern is that the number should be unique, So I dont think there will be any problem in using idoc numbers as Control numbers.


      Gavaksh Saxena

    2. Bhavesh Kantilal

      Hello Sara,

      Hope all is well! Just one note with regards to using the IDoc# as the InterfaceChangeControl#.

      This solution will work only if you are not sending multiple Functional Groups and /or Transaction Sets in a single EDI Message. If there is a requirement to collect multiple IDoc’s into a Single EDI Interfacechange, then the Idoc# as a Interchange ID will not work. If no such requirements exist, then we should be good!



  2. kn chekri

    I appreciate your wonderful document. If you post another blog with 997-STATUS interface with mapping details that would be a welcome gesture from you.

    Thank you,



Leave a Reply