| Status | |
|---|---|
| Owner | SHARMA-ext, Meenakshi |
| Stakeholders | Laurence DANNET, Paulo Golinelli |
| Jira Request ID | |
| Jira Development ID |
| Parameter | Value |
|---|---|
| Application System | EDICOM |
| Business Process Reference | S/4HANA ROW, S/4HANA China |
This interface supports the automated receipt of electronic invoices from EDICOM Middleware into OpenText SAP VIM via web services. Its purpose is to enable a streamlined, touchless invoice intake process and initiate the VIM Document Processing (DP) workflow.
The objective of this functional specification is to define an interface that receives vendor invoice registered on the E-Invoice portal. The invoices are fetched by EDICOM and transmitted to SAP Vendor Invoice Management (VIM) in XML format via an inbound proxy. The interface ensures seamless, accurate, and secure transfer of invoice data into VIM for further processing.
Scope
Capture vendor invoices registered on the E-Invoice portal and retrieved by EDICOM
Receive invoice data in SAP VIM through an inbound proxy interface in XML format
Validate the incoming XML data for structure, completeness, and mandatory fields
Create and register invoices in SAP VIM based on the received data
Handle error logging, monitoring, and exception management for failed or incomplete messages
Support standard invoice scenarios
Out of Scope:
Manual invoice entry in SAP
Invoice approval workflows within VIM
Downstream FI posting and payment processing

Step | Description | Comment |
|---|---|---|
Step 1 | The supplier is responsible for registering the invoices on the E-Invoice portal. | |
Step 2 | EDIWIN tool by EDICOM will extract Syensqo vendor invoices from the E-Invoice portal. | |
Step 3 | EDIWIN will publish the XML file in the country-specific e-invoice format supported by VIM. | For example Italy XMLs will be in FATTURA format |
Step 4 | SAP CPI(Cloud Platform Integration) system will be middleware between EDIWIN by EDICOM and S/4 VIM and responsible to route the incoming e-invoice to right S/4 instance | For example: If China e-invoices will be in scope it has to be routed to China S/4 VIM instance. Rest of the world invoices should be routed to ROW S/4 VIM Instance. |
Step 5 | A proxy interface will be established for receiving e-invoices. | Inbound Proxy file will have country code and invoice payload in base |
Step 6 | An application job class will be implemented that calls the proxy to check for new invoices and register the incoming XML under the country-specific VIM e-invoice XML channel and archive ID. | |
Step 7 | While registering the invoice in VIM, in the event of a connection issue with the archive server for the content repository, a Launchpad notifications will be triggered. Table will be maintained for recipient groups for the notifications in case of error. | |
Step 8 | Further enhancements to XML parsing will be implemented based on country-specific e-invoice requirements. | |
Step 9 | XML fields will be mapped to the VIM header and item tables as per the mapping of semantic names of electronic document in Invoice Inbound configuration. | It will done as part of configuration |
EDIWIN will transmit invoices to VIM via the inbound proxy and will route only Syensqo vendor invoices that are designated for VIM processing. EDICOM will be routing the invoice to correct S4 VIM instance.
One invoice per XML.
This enhancement is dependent on the capabilities and interfaces to be agreed upon with EDICOM. It is also subject to the legal requirements of the countries where vendor e-invoicing is applicable.
Inbound Proxy: The inbound proxy file will contain the invoice payload encoded in Base64 format.
Control Table: A custom table will be maintained to store the country, company code, and transaction type values that are in scope for e-invoicing.
Configure input channel OAWD_XXXX in SAP VIM for each Syensqo E-invoicing country to receive XML invoices from the EDICOM system.
Configure the archive document type to process XML invoices and enable visualization/rendering of XML content for each Syensqo E-invoicing country.
Link country-specific standard module handlers to the corresponding e-invoice channels.
Based on Syensqo requirements, configure an enhanced XML parsing class.
N/A
An application job class will be implemented in the inbound proxy to register the incoming XML under the dedicated XML channel and archive ID corresponding to the relevant country and company code.
In the event of a connection issue with the archive server for the related content repository, a launchpad notification will be triggered and sent to the identified recipient groups.
A table will be used to store the recipient groups, who will be notified in case of such failures. Once the archive server issue is resolved, the team can access /AIF/IFMONI to review and clear the error messages.
SAP VIM will receive e-invoices from EDICOM through an inbound proxy interface in a country-specific XML format. The inbound message will contain the country and company code along with the invoice payload encoded in Base64 format. The country and company code combination will be used to correctly identify and route the invoice to the appropriate VIM input channel for further processing.
Inbound proxy and custom class to register the invoices in VIM will be used.
Include an overview of the source. Can be deleted if not needed.
| Table | Field Name | Comments/Calculation/Field Manipulation |
|---|---|---|
Include an overview of the data validation requirement. Can be deleted if not needed.
| Table | Field Name | Comments/Calculation/Field Manipulation |
|---|---|---|
If any custom configuration tables are required, which will be read by the enhancement logic, then specify them here. Can be deleted if not needed.
<Title Custom Table 1>
<Include an overview of the table and what it’s used for>
| Field | Description | Data Type/Length | Validation rule/ Value Help |
|---|---|---|---|
Title Configuration Table 1
Include an overview of the table and what it’s used for
| Field | Description | Data Type/Length | Validation rule/ Value Help |
|---|---|---|---|
N/A
| Field Name | Description | Select: Option or Parameter Check box or Radio button Import or Export | Data Type/Length | Default Value/ Validation rule/ Value Help | Selection Logic |
|---|---|---|---|---|---|
Inbound XML Receipt
XML invoices will be received via the inbound proxy.
An enhancement will be triggered during inbound processing to handle XML invoice registration in VIM.
Country and Content Repository Determination
During registration, the enhancement reads the country from the XML.
Based on the country, the Content Repository will be identified where the XML and if there is any attachment should be stored.
VIM Registration
The XML invoice is registered in VIM with the determined Content Repository.
The original XML file is stored as an attachment against the VIM document.
Content Server Connectivity Check
While registering the document, the enhancement checks the Content Server connection.
If the Content Server connection fails:
The registration process is stopped.
An error is logged in AIF.
An automated launchpad notification is triggered to the identified recipients with error details.
Reprocessing Mechanism
Once the Content Server issue is resolved:
The error entry in AIF is manually cleared.
The message is reprocessed.
The XML invoice is registered successfully in VIM without requiring retransmission from the source system.
Volume is driven by the number of invoices that we receive through proxy.
No specific performance considerations since we just receive the invoices.
Invoice registration interface failures can be monitored through Launchpad notifications as well as via transaction /AIF/IFMON
Based on interface with EDICOM, E-invoice files will be received in VIM and documents will be registered in S4 VIM and workflow will be triggered with XML data mapped to VIM header and item fields.
| ID | Condition | Expected Result |
|---|---|---|
| 1 | Send XML invoice from EDICOM to VIM | DP gets registered in VIM and XML gets archived in respective country content repository. |
| 2 | Send XML invoice from EDICOM to VIM while the archive server is down | DP does not get registered as archive server is down. And launchpad notification will be triggered to identified recipients. |
| 3 | Send XML invoice embedded with PDF attachment from EDICOM to VIM | DP gets registered in VIM and XML & attachments gets archived in respective country content repository. |
| 4 | Send XML invoice from EDICOM to VIM | DP gets registered in VIM as per the values received from source XML nodes. |
| 5 | Send XML invoice with missing mandatory nodes to VIM | DP not created, error logged. |
| 6 | Send XML invoices for different countries. | DP gets registered under correct company code and archived under correct country specific content repository |
| 7 | Send an XML invoice with a large embedded PDF | Successful processing within system limits or controlled error handling. |
| 8 | Clear SXMB_MONI error and process the error files | DP gets registered and archived successfully as long as archive server is up and there is no other issues |
| 9 | Send duplicate XML invoice from EDICOM | Duplicate invoice is detected and handled as per legal requirement to handle duplicate e-invoices of respective country |
| 10 | Send XML invoice with invalid XML structure | Invoice is rejected with appropriate error logging and notification as designed as part of EDICOM interface |
| 11 | Send XML invoice with special characters / encoding differences | Invoice is processed correctly without data corruption |
List any considerations essential for application test planning (e.g., test this before ABC along with DEF separate from GHI). If the development encompasses a user interface, explain how to test it. List any insights as to how this component could be tested the most efficiently.
| Package Name | Parent Package |
|---|---|
| Enhancement Type | Standard Definition Name | Custom Implementation Name | Design Rationale Reference |
|---|---|---|---|
| Object Type | Object Name | Purpose/High Level Logic | Design Rationale Reference |
|---|---|---|---|
This table is based on the Syensqo development standards document. It provides the naming conventions for authorization groups to associated with custom reports and tables to comply with security requirements.
ABAP | ZFI | ZMM | ZPS | ZCO | ZSD | ZBC | ZFI | ZCA |
|---|---|---|---|---|---|---|---|---|
| TABLES | ZFIT | ZMMT | ZPST | ZCOT | ZSDT | ZBCT | ZFIT | ZCAT |
Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.
