Receive supplier invoices from authorities' platform and send them to different automation solutions

[Sujeet_Kumar]

The introduction of new e-invoicing regulations by tax authorities is disrupting the current method for processing supplier invoices. Rather than receiving invoices directly from your suppliers, you must now retrieve them through the portals and platforms of the authorities.

During the process of pulling supplier invoices from authorities, most buyers encounter a situation where the same legal entities exist in different systems or different invoices need to be processed through different solutions (e.g. direct spend vs indirect spend). This means the supplier invoices addressed to the same VAT Registration Number must be classified and dispatched to different systems for further processing.

This problem stems from the fact that the VAT Registration Number serves as an invoice recipient's unique identifier, allowing authorities to route all invoices to only a single target system. Sometimes authorities allow us to use an additional identifier, but this is generally unreliable because it requires suppliers to fill in the buyers' target system correctly, which they typically are unaware of.

Suppose you have one legal entity with the same VAT Registration Number that exists in different systems in your landscape. In that case, there is a need to have a mechanism to identify and forward the supplier invoices to the correct system.

In a previous blog I received an electronic supplier invoice, what no... - SAP Community, we showed you that SAP Document and Reporting Compliance can be enhanced by integrating an incoming automation system.

In this blog, we’ll show you how you can integrate the Manage Electronic Documents app or the eDocument Cockpit with an incoming automation system of your choice to process B2B supplier invoices exchanged using KSeF in Poland as an example. Additionally, you could also add your own specific logic to identify which invoices belong to which systems, even when the invoices are addressed to the same legal entity or VAT Registration Number.

Let’s take Poland KSeF as an example:

 Prerequisite:

1. You have implemented the latest SAP Notes for Poland KSeF. For a complete prerequisite list refer to the SAP Note 3279206 - Electronic Document Processing for Poland - KSeF: Implementation Overview.
2. You have implemented the SAP Note 3284133 - Enhancements to BAdI EDOC_INCOM_DATA.
3. You have implemented the Electronic Supplier Invoices (B2B) of SAP Document and Reporting Compliance Poland KSeF (B2B) in SAP S/4HANA or SAP ERP. As a result, you can now see the electronic document in the Manage Electronic Documents app or the eDocument Cockpit.

What happens now?

The invoice you received via integration with SAP Document and Reporting Compliance, cloud edition, is forwarded to the SAP systems where you can see it with the eDocument Created status under Poland KSeF Incoming process.

Example of eDocument Created in the eDocument Cockpit

Steps for Implementing Multiple Incoming Automation Systems

Implement the BAdI:

Regardless of whether you are using the Manage Electronic Documents app or the eDocument Cockpit, you need to implement the eDocument Incoming Data Determination (EDOC_INCOM_DATA) and eDocument Incoming Automation (EDOC_INCOM_CONNECTOR) BAdIs. For the Manage Electronic Documents app, you need to additionally implement the Navigation to Target Documents (EDOC_FIORI_TARGET_DOC) BAdI.

Detailed information on the implementation of these BAdIs can be found in the system. You can run the transaction SE20 to display the BAdI and its documentation as shown in the screenshot below.

BAdI: EDOC_INCOM_DATA

You can use the DETERMINE_SOLUTION method to determine the incoming automation solution (CV_SOLUTION) based on the XML file (IV_FILE).

BAdI documentation in the system

Implementation Hints
You can use the XML_XSTRING_TO_ABAP method in the CL_PROXY_XML_TRANSFORM class to convert the data from XML into ABAP format using the DDIC_TYPE as EDO_PL_FAKTURA1 as shown in the sample code.

You can use the SystemInfo from the XML to determine the correct incoming automation solution (CV_SOLUTION).

Example: <Sample Code>

METHOD if_edoc_incom_data~determine_solution.
    DATA: lv_file TYPE xstring,
               ls_data TYPE edo_pl_faktura1.

* Get the xml file  
        lv_file = iv_file.

* Get XML data into ABAP data type
     TRY.
        cl_proxy_xml_transform=>xml_xstring_to_abap(
          EXPORTING
            ddic_type = 'EDO_PL_FAKTURA1'
            xml       = lv_file
          IMPORTING
            abap_data = ls_data ).
      CATCH cx_proxy_fault.
      CATCH cx_transformation_error.
    ENDTRY.

* Based on the system info value, determine the CV_SOLUTION.
    IF ls_data IS NOT INITIAL.
      CASE ls_data-naglowek-system_info.
        WHEN 'SAP SYSTEM 1'.
          cv_solution = 'ARIBA'.
        WHEN 'SAP SYSTEM 2'.
          cv_solution = 'CONCUR'.
      ENDCASE.
    ENDIF.
 ENDMETHOD.

BAdI: EDOC_INCOM_CONNECTOR

The BAdI implementation should be created with filter value as the incoming automation solution (CV_SOLUTION) which was determined in the EDOC_INCOM_DATA BAdI.

You can use the PROVIDE_DATA method to send the file (XML file (IS_ORIG_DOC) and HTML file (IT_FILE with FILE_TYPE as KSEF_HTML)) to the target incoming automation system using your own business logic (RFC/Iflow/Proxy/ etc).

Create Supplier Invoice from Poland KSeF Incoming

In this, we can see the scenario integrating SAP Document and Reporting Compliance Poland KSeF with multiple incoming automation systems.

1. A pushbutton is enabled in the main header of the incoming process in the Manage Electronic Documents app and eDocument Cockpit. With this button, you trigger the creation of an supplier invoice in the integrated solution.
   
2. On execution of action Create Incoming Invoice, the BAdI implementation of EDOC_INCOM_DATA is triggered and the incoming automation solution (CV_SOLUTION) is determined as per your business logic. Let’s consider CV_SOLUTION is determined as ‘ARIBA’.
3. After the incoming automation solution is determined, the BAdI implementation of EDOC_INCOM_CONNECTOR with filter value as ‘ARIBA’ (as determined in point 2) is triggered. The XML file (IS_ORIG_DOC) and HTML file (IT_FILE with FILE_TYPE as KSEF_HTML) can be sent to the target incoming automation system (ARIBA) using your own business logic (RFC/Iflow/Proxy etc).

Similarly, you may determine multiple incoming automation solutions as mentioned in point 2 and send file(s) to these target systems as mentioned in point 3.
Once your system is in production, you can automate the above steps using background jobs. 
This approach can be applied across countries with similar requirements.

I hope this blog post was useful for you! You can leave a comment here or continue browsing our community for more blog posts on SAP Document and Reporting Compliance topics.

Looking forward to seeing you here again!