You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

Status

  Approved

OwnerROWLINSON-ext, Kerry 
Stakeholders
Jira Request ID

ERP-228 - Getting issue details... STATUS

Jira Development ID

ERP-260 - Getting issue details... STATUS

High- Level Specification

ParameterValue
Application System (Source)Icertis Contract Intelligence
Application System ( Target)SAP ERP (PF2) & SAP ERP (WP2)
Business Process Reference03.04.04.01. Manage Outline Agreements (R2)

Functional Overview

The functional design of the Integration Process defines both inbound and outbound interfaces. An integration defines a specific physical interaction that will need to occur between the system and an external application in response to some business event. 

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 more complete and 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. 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.

Events for Amendment Execution, Renewal and Termination require development within Icertis in order to be initiated and for a custom event job to send the default payload to CPI.



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

Without this integration there is no place where the hierarchical structure of Icertis Master Service Agreements & associated Sub Agreements, Standalone Agreements, Non-Disclosure Agreements, Amendments & their parent agreements can be viewed with their association to the outline agreements in SAP ECC. It provides a mechanism to ensure the purchase contract content common to both systems remains aligned despite the reliance on manual entry by business users in SAP.

The linking of the documents in this way acts as a starting point for data enrichment for release 4, allowing the identification of outline agreements which do not have a legal purchase contract.  The data will be the foundation for the conversion of open outline agreements in release 4.


Process Flow Diagram


Step

Description

System

Comment

1

A purchase contract is executed in Icertis

Icertis

A legal purchase contract is executed in Icertis

2

Line items are downloaded from Icertis

Icertis

The user downloads the line item details from Icertis to assist in the future upload of the outline agreement

3

New entry in custom table for the Icertis Contract

SAP ECC

Integration automatically creates the Icertis Contract record in custom table in both SAP ECC systems (WP2 & PF2) with the Icertis Contract ID and the relevant data fields from the contract header.

4

An amendment to a contract in Icertis is executed

Icertis

An amendment for an existing contract is executed in Icertis.

5

Change entry in custom table for the parent contract of the amendment

SAP ECC

The existing entry in the table for the parent agreement of the amendment is located and the relevant fields in the table are overwritten with the values provided in the amendment.

6

A renewal of an existing contract in Icertis is made.

Icertis

An existing purchase contract in Icertis is renewed which updates the overall value and the validity end date.

7

The entry in the custom table for the contract is updated.

SAP ECC

The existing entry in the table for the purchase contract is updated to reflect the changes to the overall value and the validity end date.

8

An existing purchase contract in Icertis subject to automatic renewal is renewed.

Icertis

An existing purchase contract in Icertis is renewed automatically when the renewal date comes due which updates the validity end date.

9

The entry in the custom table for the contract is updated.

SAP ECC

The existing entry in the table for the purchase contract is updated to reflect the changes to the validity end date.

10

An existing purchase contract in Icertis is terminated.

Icertis

An existing purchase contract in Icertis is terminated which updates the validity end date and the status in Icertis.

11

The entry in the custom table for the contract is updated.

SAP ECC

The existing entry in the table for the purchase contract is updated to reflect the changes to the validity end date.

Assumptions

There are no specific assumptions identified.

Dependencies

The following two enhancement requests in Icertis are required to fully support the integration of the purchase contracts to the custom table in SAP ECC.

ERP-151 : Small adjustment based on DOA changes 

In order to correctly fill the target value ERP-151 enhancement is being made in Icertis to consolidate the total value of the amendments. In addition to ensure the currency of the contract is passed to SAP, the logic is being adjusted so that it uses the local agreed currency instead of defaulting to EURO.

This is required in order for the target value field for the contract in the custom table to be tested in all scenarios.

ERP-470: Enhancement Request for Icertis Integration to CPI

 Configure a custom event job to send the default payload (equal to the stream event payload) to SAP CPI from Icertis. This enhancement should support the following event types:

  • Amendment Executed

  • Renewal

  • Termination

This development in Icertis is required in order for integration to be tested for event types other than Agreement Execution.


Security, Integrity and Controls

There are no specific security, integrity or controls required for the processing of the interface.

Configuration Requirements

There are no specific configuration requirements for this interface.

Special Requirements

As the interface is one-way from Icertis to SAP ECC there are no special requirements, security or authentication considerations to take into account.

Design Rationale


Data Structure

Source Structure

The following fields from Icertis are required for the content of the custom table in SAP, or to support the interface process.

FieldField LabelDescriptionLength/Format
ICM Tenant IDTenant ID**Confirm with Dhiraj format and length and how we define - specific client for purchasing contracts; Dhiraj to check with WytseTBA
CONTRACTTYPENAMEIcertis Agreement TypePossible values are:
ICMMasterAgreement
ICMSupportingAgreement
ICMSubAgreement
ICMStandaloneAgreement
ICMBaselineAgreement
ICMMasterAgreementAmendment
ICMSupportingAgreementAmendment
ICMSubAgreementAmendment
ICMStandaloneAgreementAmendment
(supporting agreement is the NDA; no amendments possible for Baseline Agreements)
224 CHAR
NAMEName**Amit to determine how the NAME field is going to be used ; if descriptive could be a useful addition to the report to help users identify what the contract is for (eg. where there are multiple for a supplier and our report will have no line items for context.
Amit - still under discussion with Laurence for formatting rules and length (Action tracker item 116)
1000 CHAR
ICMAGREEMENTCODEAgreement CodeThe naming convention for Icertis Agreements is defined; characters describe the type and the fact it is amendment may be in the structure of the code. 
The contract number starts at 1,2,3,4 etc. 
ICMMasterAgreement_nnnnnnnnnn
ICMSupportingAgreement_nnnnnnnnnn
ICMSubAgreement_nnnnnnnnnn
ICMStandaloneAgreement_nnnnnnnnnn
ICMMasterAgreementAmendment_nnnnnnnnnn
ICMSupportingAgreementAmendment_nnnnnnnnnn
ICMSubAgreementAmendment_nnnnnnnnnn
ICMStandaloneAgreementAmendment_nnnnnnnnnn
ICMBaselineAgreement_nnnnnnnnnn
224 CHAR
SYSIDSystem ID

Along with CONTRACTTYPENAME, SYSID is the key with which CPI makes the call to Icertis to retrieve the complete header contract field details.

This is important to have from Icertis in addition to the agreement code - used in backend table mapping in Icertis and is important to keep the relationship to the agreement code.
Not shown to user but stored in table (identifier for the agreement code in the system)
Example: 1343f2e0-9386-4fa7-aa5b-22abba04d35a (36 chars)

36 CHAR
PARENT SYS IDParent System IDAn amendment in Icertis is assigned a new ICMAGREEMENTCODE and a new SYSID. But the original agreement code that the amendment is for is in the PARENT CONTRACT field, and the original system id is in the PARENT SYS ID field.
The parent contract and parent sys id are required in order to identify the existing contract record in the custom table which needs to be updated in the case of amendments.
36 CHAR
PARENT CONTRACTParent ContractAn amendment in Icertis is assigned a new ICMAGREEMENTCODE and a new SYSID. But the original agreement code that the amendment is for is in the PARENT CONTRACT field, and the original system id is in the PARENT SYS ID field. So the format of the Parent Contract field will be the format of the original agreement code field:
ICMMasterAgreement_nnnnnnnnnn
ICMSupportingAgreement_nnnnnnnnnn
ICMSubAgreement_nnnnnnnnnn
ICMStandaloneAgreement_nnnnnnnnnn
The parent contract and parent sys id are required in order to identify the existing contract record in the custom table which needs to be updated in the case of amendments.
224 CHAR
ICMSUPPLIERSAPIDSupplier's Account NumberThe supplier numbers will be the same as the ECC supplier numbers. NDA's may not necessarily have a supplier id as it is possible to define an NDA for a bidder supplier only.
Cannot be validated as the supplier records do not exist in both SAP systems.
224 CHAR
ICMEFFECTIVEDATEStart of Validity Period"YYYY-MM-DDTHH:MM:SS"DATE
ICMEXPIRYEnd of Validity Period"YYYY-MM-DDTHH:MM:SS"DATE
ICMTOTALCONTRACTVALUETarget Value for Header Area per DistributionIt needs to be the total value of the contract (in ECC it is target value at header level)
In the case of amendments, it needs to be the updated overall total
Renewals may also update the overall value.
ERP-203 Icertis: Total Contract Value calculation with multiple amendments to enable ECC Integration
INT(15 including 2 decimals)
ICMCURRENCYCurrency KeyConfirmed the currency codes in Icertis are aligned to SAP codes5 CHAR
ICMLEGALENTITYCODECompany CodeOrganizational data - company code, purchasing group, purchasing org are being aligned in Icertis to ECC - it is the 4 char code for company code which matches SAP1000 CHAR
ICMPURCHASEGROUPCODEPurchasing GroupOrganizational data - company code, purchasing group, purchasing org are being aligned in Icertis to ECC - it is the 3 char code for purchasing group which matches SAP1000 CHAR
ICMPURCHASEORGCODEPurchasing OrgOrganizational data - company code, purchasing group, purchasing org are being aligned in Icertis to ECC- it is the 4 char code for purchasing organisation which matches SAP1000 CHAR
ICMREGIONRegionIcertis has values for each region which will be useful for the consolidation report to enable filtering of the Icertis Z table records by region. Possible values are:
WW, EMEA, APAC, AMS (world-wide, Europe, Asia Pacific, Americas)
4 CHAR
ICMPRIMARYOWNERNAMEContract Owner**Amit to check the field name in Icertis and the length likely to be used;
Use for filtering in the report on Z table so owners can find their own to work on
First name, last name and email id in one field
Action: Amit to check the number of characters and the value**
224 CHAR
ICMINCOTERMCODEIncotermsIncoterms are being aligned to correspond between Icertis and ECC
This field in Icertis is the 3 char code for the terms
224 CHAR
ICMPAYMENTTERMSCODEPayment TermsPayment terms are being aligned to correspond between Icertis and ECC
This is the 4 char code that matches to SAP's codes in ECC
224 CHAR
ICMTERMINATIONDATETermination DateWhen a termination message is received, the expiry date field remains same in ICertis but the termination date will have to become the expiry dateDATE


Target Structure

The following fields will be used to provide the required information for this interface.

Note: Although some of the Icertis fields correspond directly to fields in SAP, it is not possible to use these fields for validation due to the two separate SAP ECC systems. The intention is to have the same content filled in the custom table in both systems, regardless of whether the company code, purchasing organization, supplier etc. are defined in that system. All fields therefore have to be text-based fields.

Field labels are to correspond with the Icertis field labels.

Apart from the fields which are defined to be the key for the table and will therefore be (i) available for all events  (ii) considered mandatory, all other fields are optional entry in the custom table.

Parent System ID and Parent Contract are not relevant to store in the custom table. The situation where these fields are filled from Icertis is when the Agreement Type is an amendment. These will only be used in the middleware to determine which entry in the custom table requires updating.


FieldField LabelDescriptionLength/Format
Z*Tenant ID
TBA
Z*Icertis Agreement TypePossible values are:
ICMMasterAgreement
ICMSupportingAgreement
ICMSubAgreement
ICMStandaloneAgreement
ICMBaselineAgreement
ICMMasterAgreementAmendment
ICMSupportingAgreementAmendment
ICMSubAgreementAmendment
ICMStandaloneAgreementAmendment
(supporting agreement is the NDA; no amendments possible for Baseline Agreements)
224 CHAR
Z*NameDescription given to the contract (useful for reporting)1000 CHAR
Z*Agreement Code

The agreement code is the contract number in Icertis and is preceded by the agreement type. Example: ICMMasterAgreement_nnnnnnnnnn

This value from Icertis will be stored on the header of the outline agreement in SAP ECC.

224 CHAR
Z*System ID

Along with CONTRACTTYPENAME, SYSID is the key with which CPI makes the call to Icertis to retrieve the complete header contract field details.

Example: 1343f2e0-9386-4fa7-aa5b-22abba04d35a (36 chars)

36 CHAR
Z*Supplier's Account NumberThe supplier numbers will be the same as the ECC supplier numbers? We take only the first 10 char of 224? NDA's may not necessarily have a supplier id as it is possible to define an NDA for a bidder supplier only.
Cannot be validated as the supplier records do not exist in both SAP systems.
224 CHAR
Z*Start of Validity Period"YYYY-MM-DDTHH:MM:SS"DATE
Z*End of Validity Period"YYYY-MM-DDTHH:MM:SS"DATE
Z*Target Value for Header Area per DistributionIt needs to be the total value of the contract (in ECC it is target value at header level)
In the case of amendments, it needs to be the updated overall total
Renewals may also update the overall value.
ERP-203 Icertis: Total Contract Value calculation with multiple amendments to enable ECC Integration
INT(15 including 2 decimals)
Z*Currency KeyConfirmed the currency codes in Icertis are aligned to SAP codes5 CHAR
Z*Company CodeOrganizational data - company code, purchasing group, purchasing org are being aligned in Icertis to ECC - it is the 4 char code for company code which matches SAP1000 CHAR
Z*Purchasing GroupOrganizational data - company code, purchasing group, purchasing org are being aligned in Icertis to ECC - it is the 3 char code for purchasing group which matches SAP1000 CHAR
Z*Purchasing OrgOrganizational data - company code, purchasing group, purchasing org are being aligned in Icertis to ECC- it is the 4 char code for purchasing organization which matches SAP1000 CHAR
Z*RegionIcertis has values for each region which will be useful for the consolidation report to enable filtering of the Icertis Z table records by region. Possible values are:
WW, EMEA, APAC, AMS (world-wide, Europe, Asia Pacific, Americas)
4 CHAR
Z*Contract Owner**Amit to check the field name in Icertis and the length likely to be used;
Use for filtering in the report on Z table so owners can find their own to work on
First name, last name and email id in one field
Action: Amit to check the number of characters and the value**
224 CHAR
Z*IncotermsIncoterms are being aligned to correspond between Icertis and ECC
This field in Icertis is the 3 char code for the terms
224 CHAR
Z*Payment TermsPayment terms are being aligned to correspond between Icertis and ECC
This is the 4 char code that matches to SAP's codes in ECC
224 CHAR
Z*Termination DateWhen a termination message is received, the expiry date field remains same in ICertis but the termination date will have to become the expiry dateDATE

Mapping and Calculation




Note:  For all field values from Icertis, remove any blank spaces from the beginning and end of the value and the remaining content is to go into the target field. Icertis has many text-based fields ranging from 224 to 1000 chars which are able to be input by users. We cannot control that the contents will fit into a fixed length field on the target system. Field lengths will have to be the same on both systems. 

Source TableAPI or Portlet NameSource FieldRequired (Y/N)Description

Target 
Table

API or Portlet Name

Target Field

(Label in SAP)

Required (Y/N)DescriptionRule TypeRule Instruction


ICM Tenant IDYUnique ID that defines purchase contracts within IcertisZ*
Icertis Tenant IDY

middleware rule - filtering, dates formatting


CONTRACTTYPENAMEY
Z*
Contract TypeYIN TARGET FIELD put the label for the field from SAP



NAMEY
Z*
Contract NameY




ICMAGREEMENTCODEY
Z*
Contract IDY




SYSIDY
Z*
System IDY




PARENT SYS IDN
Z*
Parent System IDN




PARENT AGREEMENTN
Z*
Parent Contract IDN




ICMSUPPLIERSAPIDN
Z*
Supplier's Account NumberN




ICMEFFECTIVEDATEN
Z*
Start of Validity PeriodN




ICMEXPIRYN
Z*
End of Validity PeriodN




ICMTARGETVALUEN
Z*
Target Value for Header Area per DistributionN




ICMCURRENCYN
Z*
Currency KeyN




ICMLEGALENTITYCODEN
Z*
Company CodeN




ICMPURCHASINGGROUPN
Z*
Purchasing GroupN




ICMPURCHASINGORGN
Z*
Purchasing OrganizationN




ICMCONTRACTOWNERN
Z*
Contract OwnerN




ICMINCOTERMN
Z*
IncotermsN




ICMPAYMENTTERMSN
Z*
Terms of Payment KeyN


Processing Logic

Processing within Source


check with Wytse if there is any in Icertis


Processing within Middleware


refer to the mapping sheet


Processing within Target


not applicable

Interface Dependency

Interface Constraints

Delivery Requirements

Delta or Full Load Requirements

Interface Alert & Monitoring

Interface Reporting

Language Requirements

User Interface Requirements


Volumetrics



Performance Consideration



Error Handling



Testing

How to Test

Test Conditions and Expected Results

IDConditionExpected Results






Test Considerations/Dependencies



Other Information


Development Details

Package

Package NameParent Package




Other Development Objects

Object TypeObject NamePurpose/High Level LogicDesign Rationale Reference









Appendix


See also


No files shared here yet.

Change log

Version Published Changed By Comment
CURRENT (v. 20) Mar 31, 2026 11:51 ROWLINSON-ext, Kerry
v. 187 Mar 27, 2026 13:23 ROWLINSON-ext, Kerry CR-0397 Events for Legacy Contract Loads
v. 186 Jan 20, 2026 12:03 KUMAR-ext, Rajesh
v. 185 Jan 20, 2026 11:57 ROWLINSON-ext, Kerry
v. 184 Jan 20, 2026 11:52 KUMAR-ext, Rajesh
v. 183 Jan 15, 2026 16:41 ROWLINSON-ext, Kerry
v. 182 Dec 20, 2025 06:33 ROWLINSON-ext, Kerry
v. 181 Nov 27, 2025 12:00 ROWLINSON-ext, Kerry
v. 180 Nov 25, 2025 12:37 ROWLINSON-ext, Kerry
v. 179 Nov 25, 2025 08:30 ROWLINSON-ext, Kerry

Go to Page History

  • No labels