High- Level Specification

Functional Overview

Icertis Contract Intelligence is the contract management and authoring application for Syensqo's purchase contracts. Purchase orders are created in S/4 HANA with reference to purchase contracts (outline agreements). The key information from the legal contract which is relevant for procurement forms the basis of the purchase contract or outline agreement in S/4 HANA.  For release 4, the integration between Icertis and S/4 HANA will be completer and more automated. However, for release 2 the option for a 'light' integration was decided due to the limitations of the two SAP ECC systems and in particular the substantial existing custom logic which needed to remain unaffected by any changes.

The 'light' integration consists of three main parts:

1. Maintaining the relationship between the Icertis Contract ID and the SAP outline agreement number.
2. The ability to report where there are inconsistencies in the data between the two systems.
3. The ability for users to update the Icertis Contract ID on the SAP outline agreement.

When an agreement in Icertis is executed, an event in Icertis is initiated and the stream event payload is received to CPI (Cloud Platform Integration). CPI then uses key fields from that payload to make a call to Icertis to retrieve the complete contract record payload from Icertis. An additional call is made for some agreement types to find associations to a master agreement. Based on the information received from Icertis in those calls confidential records are filtered out; fields not required are ignored; and some field values are translated.

A subset of the total fields provided are then mapped to fields in a custom table in both SAP ECC systems (PF2 and WP2) where the data is stored. New contracts which are executed in Icertis and which are relevant for storing in the custom table will have a new entry made. Amendments, renewals and terminations require existing table entries to either be updated or first deleted and then re-created.

The purpose of this functional specification is to provide the details of the ABAP logic in SAP ECC which takes the field values from CPI and enables placement of the entries into the custom table.

Scope and Objectives

The objective of the interface for release 2 is to provide a functional relationship between the Icertis Contract and the SAP outline agreement to enable consistency of the data to be reported and therefore maintained. The business users will manually create and change the outline agreements as a result of contract executions, amendments, renewals and contract terminations.

The entry and update of the contract data in the custom table enables:

1. Validation that the correct Icertis Contract ID is entered on the outline agreement.
2. Reporting any key header data from the outline agreement which is not aligned with the corresponding data in Icertis.
3. Enables identification of orphan outline agreements which do not have an Icertis Contract ID assigned.
4. Enables a complete reporting view of all the Icertis types of purchase contracts, their hierarchical structure along with their association to the SAP outline agreement (if relevant for assignment).

The purpose of this specification is to define the logic of the custom ABAP program which will take the data received from Icertis and make the necessary entries in 

Process Flow Diagram

Assumptions

There are no specific assumptions identified.

Dependencies

This specification is dependent on the integration development ERP-260 Custom Integration to Call/Dump Icertis Records into Z-Table.

Security, Integrity and Controls

No confidential agreements (ICMCONFIDENTIALCONTRACT=YES) are to be stored in the custom table.

Configuration Requirements

There are no configuration requirements.

Special Requirements

Specify any special requirements or considerations that may impact the interface based on specific locations, regulatory compliance or system limitations. Clearly outline requirements e.g. localization rules for countries like China

If the interface interacts with third-party systems such as Icertis, describe any additional integration, security or authentication considerations that must be taken into account.

Design Rationale

This template section may be used to specify the custom API design. The requirement can be for an API provider which means the API will be designed in the system or can be for an API consumer which means that an API will be consumed in the system.

API Use

Populate the type of the API use  in this section. Will the API be Consumed or Provided. 

Data Structure

The following fields will be used to provide the required data structure of the interface:

Calculation and Validation

Populate the table below to list the calculation and validation rules per field

Processing Logic

Describe the processing requirement in the System

Delta or Full Load Requirements

Please describe change tracking requirements, i.e. transferring only delta, or always full load

Interface Alert & Monitoring

Please describe any alert & monitoring requirement for business users and support organization, i.e. AIF

Language Requirements

Specify multi language requirements

User Interface Requirements

Capture the requirements for the user interface (UI) associated with the interface. It should provide a clear description of how users will interact with the interface and how information will be presented to ensure usability and accuracy.

Volumetrics

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

Performance Consideration

Specify if there are any specific performance factors that need to be taken into consideration during development i.e. interface must be able to handle 100 posting per-hour, 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 interface. 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. In particular, 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

Other Development Objects

Appendix

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