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: 
abhijit_masih
Explorer
0 Kudos
Hi All,

I am writing this blog to showcase inbound interface design for finance interfaces, in most of the Integration projects we get requirement to Integrate third party systems with SAP via SAP PI/PO and post financial documents in SAP. In my recent project, we were integrating more than 40 third party systems with SAP digital core (SAP S4H 1511) in order to enable organization’s digital solution. We have gone through many possible ways for Integration and concluded to use IDOC (ACC_DOCOUMENT03) as API to create financial documents in S4H, while designing Integration solution; we have always kept in mind of re usable solution and also robustness of the solution.

We were integrating more than 40 third party systems so it became very essential to have custom Interface Framework in place in order to provide generic solution for all Interfaces and future changes should be easy to implement.

Challenges and Considerations: While designing solution we had to answer the below mentioned challenges and develop a reusable and robust custom framework solution to reduce the development and future code maintenance effort.

  1. More than 40 third party systems were interfacing inbound finance data to S4H and we planned to use only one IDOC type for posting. Hence it was very important to distinguish each idoc posted in S4H by third party system perspective for better interface management and easy data tracing .

  2. Each Interface had its own data validation logic so it was required to have reference of each interface ID in IDOC so that custom reusable solution could be build to validate data specific to the interface ID.

  3. We have more than 150 Interfaces from 40 third party systems so needed some generic solution to validate interface specific data.

  4. User should be able to see all errors for any specific interface IDOC in one go so he or she can take appropriate actions to fix issues.

  5. It was quite possible that many legacy systems will not send some inter dependent interface data in one go and we should process these interdependent interfaces automatically once dependent interface is available in S4H. Automatic functionality of IDOC re-processing for Inter dependent Interfaces was much needed

  6. Most of the interfaces had business rules to do some data conversion and many times these business rules are shared across many interfaces and sometimes it was unique as well, we needed generic solution which can handle these requirements.

  7. Any data conversion happened in SAP should be visible in WE02 as a status message (Example: Lookup SAP value based on Source value) for data transparency.


Solution: 

Below is the architecture diagram for Integration solution built based on all considerations.



 

We have used SAP’s provided conversion rules functionality to design our solution and combined BRF+ for better control and validation. We have designed our solution in two step processing where first step is defined for data validation, interface re-processing and any data conversion requirement, second step is actual processing of Interface and any specific validation is implemented there.

We have used different idoc statuses to control processing of Interfaces, example we have used idoc status 56 for automatic re-processing of IDOCS for dependencies and schedule idoc re-processing job with idoc status 56.

All the interface data validation related issues are denoted with IDOC status code 65 with custom messages and all the errors are showed in WE02.

We have also used different IDOC statuses like 68 for denoting end of idoc processing for erroneous for which no further actions is required.

Our decision to use single IDOC type for all interfaces and conversion rule helped us to build generic reusable code for many application level processing requirements. We have achieved this using global custom class and methods.

All our custom processing is also applicable while performing any IDOC re-processing as it is shown in above architecture diagram.

Please note I will be providing technical details such as exit and conversion rule details in separate blog along with step by step implementation and configuration steps for entire solution.

Please refer below blog where I have mentioned how we can track IDOC from source system perspective.

https://blogs.sap.com/2017/02/11/interface-file-tracking-po-to-s4h/

Also please refer below blog where I have mentioned how BRF+ can be used for data validation.

https://blogs.sap.com/2017/02/07/interface-data-validation-power-of-brf/
1 Comment
Labels in this area