High- Level Specification

Functional Overview

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.

Scope and Objectives

The objective of this functional specification is to define an interface that receives vendor invoice registered on the Government 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 Government 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

Assumptions

EDIWIN will transmit invoices to VIM via the inbound proxy and will route only Syensqo vendor invoices that are designated for VIM processing.

One invoice per XML.

Dependencies

Legal requirements of countries where vendor e-invoices are applicable.

Security, Integrity and Controls

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.

Configuration Requirements

• 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.

• XML fields will be mapped to VIM header and item fields

Language Requirements

N/A

Special Requirements

A custom 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, an email notification will be triggered and sent to a designated mailbox. The email content will be maintained in an SO10 standard text.

A TVARV variable will be used to store the mailbox address of the purchasing support team, who will be notified in case of such failures. Once the archive server issue is resolved, the team can access SXMB_MONI to review and clear the error messages.

Design Rationale

Functional Requirements

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.

Proposed Technology to Use

Inbound proxy and custom class to register the invoices in VIM will be used.

Data Source Considerations

Include an overview of the source. Can be deleted if not needed.

Data Validation Considerations

Include an overview of the data validation requirement. Can be deleted if not needed.

Custom Tables

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.

Master Data

<Title Custom Table 1>

<Include an overview of the table and what it’s used for>

Configuration Table

Title Configuration Table 1

Include an overview of the table and what it’s used for

Selection Screen Enhancement

N/A

Processing Logic

E-Invoice Registration Enhancement

1. 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.

2. Company Code & Country Determination

   • During registration, the enhancement reads the country and Company Code from the XML.

   • Based on the company code channel, the Content Repository will be identified where the XML document should be stored.

3. 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.

   • Additional attachments will also be retrieved and stored 

4. 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 SXMB_MONI.

     • An automated email notification is triggered to the support team with error details.

5. Reprocessing Mechanism

   • Once the Content Server issue is resolved:

     • The error entry in SXMB_MONI is manually cleared.

     • The message is reprocessed.

     • The XML invoice is registered successfully in VIM without requiring retransmission from the source system.

6. XML Parsing & Mapping

   • After successful VIM registration, as part of the Document Handler steps:

     • The XML content is parsed. Parsing might need enhancement as per the country requirements of XML.

     • Parsed XML fields are mapped to /n/opt/xml_map fields.

7. Header and Item Mapping

   • Fields from /OPT/XML_MAP are further mapped to:

     • VIM Header fields

     • VIM Item fields

8. Invoice Validation

   • The registered and mapped invoice is then subjected to:

     • Standard and custom business validations

     • Further VIM processing as per business rules (e.g., matching, tolerances, approvals) and post the document.

Volumetrics

Provide volumetrics details: Initial load volumes, Number of Records, Expected Frequency, Expected Long term Growth)

Performance Considerations

Specify if there are any specific performance factors that need to be taken into consideration during development i.e. enhancement must be able to be executed by 10 users at the same time, etc.

Error Handling

Detail how errors will be handled: Notification, Restart/ Recovery and Re-Processing Procedures

Testing

How to Test

Please provide some guidance and/or test data to help the developer unit test the enhancement. Please include both positive and negative testing (to validate error situations handling). The developer will need to test repeatedly, so where appropriate provide instructions to reverse the actions performed so the test may be run again or explain how to create new input data to the test. The developer will need logons for test users representing the various roles within the approval process.

Test Conditions and Expected Results

Test Considerations/Dependencies

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.

Other Information

Development Details

Package

Enhancement Implementation

Other Development Objects

Appendix

Custom Authorization Group Naming Convention

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.

See also

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.

Change log