Status
Owner	ROWLINSON-ext, Kerry
Stakeholders	TILBEE-ext, Amanda NARAHARI-ext, Bhargavi RAI-ext, Praveen EPASINGHE-ext, Kapila TORRES-ext, Benedict BEZEMER-ext, Wytse
Jira Request ID
Jira Development ID

High-Level Specification

Implementing System	SAP ERP (PF2) & SAP ERP (WP2)
Invoked by	ERP-260
Business Process Reference	03.04.04.01. Manage Outline Agreements (R2)

Functional Overview

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 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:

Maintaining the relationship between the Icertis Contract ID and the SAP outline agreement number.
The ability to report where there are inconsistencies in the data between the two systems.
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) via interface ERP-260. 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(s) 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:

Validation that the correct Icertis Contract ID is entered on the outline agreement(s).
Reporting any key header data from the outline agreement which is not aligned with the corresponding data in Icertis.
Enables identification of orphan outline agreements which do not have an Icertis Contract ID assigned.
Enables a complete reporting view of 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 the custom table in SAP ECC.

Both ECC systems have the same custom table and the same entries. For this reason the data cannot be validated against the actual SAP field values as the values are not consistent between the systems.

Process Flow Diagram

This system interface is invoked for a number of different events in ICertis, which are listed below. Events raised by ICertis are received by CPI Integration Process ERP-260, and forwarded to the System Interface described in this document.

Event in ICertis	Resulting action in SAP ECC
A purchase contract is executed in Icertis: Master Agreement Supporting Agreement Sub Agreement Standalone Agreement	New entry in custom table for the Icertis Contract Integration automatically creates the Icertis Contract record in custom table in both SAP ECC systems (WP2 & PF2) with the Tenant ID, Agreement Type, System ID, Icertis Agreement Code and the relevant data fields from the contract header. Purchasing Organization values and the System ID are stored in a separate custom table.
An amendment for an existing contract is executed in Icertis.	Change entry in custom table for the parent contract of the amendment. The existing entry in the table for the parent agreement of the amendment is located and all the relevant fields in the table are overwritten with the values provided in the amendment. Purchasing Organization values for the System ID are overwritten in a separate custom table.
An existing purchase contract in Icertis is renewed automatically when the renewal date comes due, which in turn updates the validity end date.	Update the existing entry in the table for the purchase contract to reflect the changes to the validity end date.
An existing purchase contract in Icertis is terminated which updates the validity end date and the status in Icertis.	Update the existing entry in the table for the purchase contract to reflect the change to the expiry date.
Changeable fields (tracking attributes) are updated in an existing purchase contract in Icertis	Update the existing entry in the table for the purchase contract to reflect the changes to the fields. Purchasing Organization values for the System ID are overwritten in a separate custom table.

</Start CR0397>

Icertis Contract Management to SAP ECC integration relies on event creation from ICertis, processing in CPI and storage in a custom table in SAP ECC. ERP-260,ERP-261, ERP-508 (links) enable this process for new contracts created and for lifecycle events on migrated contract but not for the initial bulk loading in Icertis of legacy contract data.

A solution in Icertis to automatically create new events for each of the relevant steps in the load of legacy contracts requires changes in SAP ECC to handle the processing of these new events.

Theoretically, the loading of legacy contract data only occurs once at the time of cutover to the new Icertis Contract Management system, and therefore these events would be used a single time. However, a possible scenario is the acquisition of a new business whose legacy contracts will be loaded into the existing Icertis system. These events would be generated from Icertis to CPI.

The table below shows the new event names which are received through to SAP as a result of the legacy contract loading, the action taken and the changes required in SAP ECC.

Event Name	Legacy Load Stage	SAP Action	SAP Changes
Published	In the first stage of legacy contract bulk load, CPI passes Published event to SAP. No associations are passed for the contracts at this stage.	New entry in ICM contracts table with Published event	No Change Required
AssociationPeerLinkage	In the second stage of legacy contract loading, any associations to the contracts loaded in the first stage are created. This includes associations to master agreements for subagreements and supporting agreements. CPI passes the event AssociationPeerLinkage for the sub agreement/supporting agreement system id.	Update existing table entry with all the field values passed, including the associations if the event is ‘AssociationPeerLinkage’	‘ActionName’ field needs to be extended to 30 characters to hold 'AssociationPeerLinkage' (with some additional character space to support any other future events). Currently the logic makes no updates to associations because once entered in the Executed event, they never change. Add exception logic that if the action is AssociationPeerLinkage then also put in the associations when the line item is changed.
AmendmentPublished	In the third stage of legacy contract loading, any amendments for already loaded contracts are created. The event AmendmentPublished is created for the Amendment Agreement.	Update existing table entry with all the field values passed, exluding the associations.	No Change Required

</End CR0397>

Assumptions

There are no specific assumptions identified.

Dependencies

This development will be called by integration development ERP-260.

Security, Integrity and Controls

No confidential agreements (ICMConfidentialContract='true') are to be stored in the custom table. These are filtered out in interface ERP-260 so there is no trace of them in the custom table in ECC.

Configuration Requirements

SOAMANAGER configuration for the web service is required.

Special Requirements

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

Other custom tables in SAP ECC do not have any authorization controls apart from transaction code. This custom table does not require a transaction as it is not subject to manual maintenance as part of the processes. However, for the integrity of the interface manual maintenance will be prevented for business users who currently have table maintenance access via SM30.

Support users may need in exception cases to maintain the table entries manually (for example, any issues at go live, or faults with the automated table updates whilst the fault is being remediated). To facilitate this, an authorization group will be assigned to the custom table. Edit access for this authorization group will not be assigned to support users though. Any changes they need to make in production is made via the Firefighter process.

Design Rationale

The CPI interface ERP-260 will take care of complex transformations and rules while the ABAP logic in this development will take care of the following types of manipulation of the data from CPI before updating the custom table:

Removal of any spaces from the beginning and end of field values
Splitting of any field value
Stripping out parts of the field values (eg. stripping out the individual purchasing org values)
Reformatting of field values (eg. trimming the length of the content of a field)
Defining and managing coded values for fields to reduce field sizes (eg. Contract type names to have coded values)
Storage of any field values in separate custom tables (eg. Purchasing organization codes to be stored in their separated values in an additional table)

Validation

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 unless otherwise specified.

Data Structure

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

Field	Description	Mandatory (Y/N)	Data Type - SAP ECC lengths
TENANTID	Tenant ID	Y	20 CHAR (3 CHAR in ECC with view and coded values)
CONTRACTTYPENAME	Contract Type Name	Y	224 CHAR (3 CHAR in ECC, with view and coded values)
SYSID	System ID	Y	36 CHAR in ECC
ICMAGREEMENTCODE	Agreement Code	Y	224 CHAR (25 CHAR in ECC)
ACTIONNAME	Action Name	Y	20 CHAR
EVENTDATETIME	Event Date Time	Y	30 CHAR
ICMPURCHASINGORGCODE	Purchasing Org Code	N	1000 CHAR (224 CHAR in ECC) Note: In the case of master agreements, no purchasing org will be passed from Icertis. Can be left blank in ECC table. Field in Icertis is multi value and all values will be passed in this field with each 4 CHAR code separated by a comma. To be stored with the System ID and the separated values in a different custom table.
ICMCONFIDENTIALCONTRACT	Confidential Contract	N	5 CHAR (1 CHAR in ECC with value selected or not)
NAME	Agreement Name	N	1000 CHAR (First 255 CHAR in ECC)
ASSOCIATINGTYPE	Associating Agreement Type	N	224 CHAR (3 CHAR in ECC, with view and coded values)
ASSOCIATINGCODE	Associating Agreement Code	N	224 CHAR (25 CHAR in ECC)
ASSOCIATINGSYSID	Associating System ID	N	36 CHAR (36 CHAR in ECC)
ICMAPPSRCSUPPLIERID	Bidders/Supplier SAP ID	N	224 CHAR (10 CHAR in ECC)
ICMEFFECTIVEDATE	Effective Date	N	DATE
ICMEXPIRYDATE	Expiry	N	DATE
ICMTOTALCONTRACTVALUE	Total Contract Value	N	INT(15 including 2 decimals)
ICMCURRENCY	Supplier Currency	N	1000 CHAR (5 CHAR in ECC)
ICMLEGALENTITYCODE	Syensqo Legal Entity Code	N	1000 CHAR (4 CHAR in ECC)
ICMORGTEAM	Org Team	N	1000 CHAR (25 in ECC)
ICMCONTRACTOWNER	Contract Owner	N	1000 CHAR (100 CHAR in ECC)
ICMINCOTERMSCODE	Incoterms Code	N	224 CHAR (3 CHAR in ECC)
ICMINCOTERMSLOCATION	Incoterms Location	N	1000 CHAR (70 CHAR in ECC)
ICMPAYMENTTERMS	Payment Terms	N	224 CHAR (4 CHAR in ECC)

Calculation and Validation

The table below shows the rule instruction for each field in table ZMM_ICMCONTRACT:

Field	Rule Type	Rule Instruction
TENANTID	Coded Values	For the development system: source: "/icertis/syensqo-dev" For the test system: source: "/icertis/syensqo-uat" For production: source: "/icertis/syensqo" Create a view for these values and assign a 3 CHAR code of DEV, UAT, PRD to each, with the description holding the full value.
CONTRACTTYPENAME	Coded Values	Possible values are: ICMMasterAgreement ICMSupportingAgreement ICMSubAgreement ICMStandaloneAgreement ICMMasterAgreementAmendment ICMSupportingAgreementAmendment ICMSubAgreementAmendment ICMStandaloneAgreementAmendment Create a view for these values and assign a 3 CHAR code of 001, 002 etc. for each; these coded values will be used in the custom table. For reporting, the original values can be displayed.
SYSID	None	36 CHAR in ECC, direct mapping (keep upper/lower case)
ICMAGREEMENTCODE	Remove spaces and limit length	224 CHAR (25 CHAR in ECC) Values will be in this format where nnnnn starts at 1, 2, 3 etc.: Master Agreement: PMAnnnnnnn Supporting Agreement: PSUPnnnnnnn SubAgreement: PSUBnnnnnn Standalone Agreement: PSTnnnn Master Agreement Amendment: PMA-AMDnnn Supporting Agreement Amendment: PSUP-AMDnnnn SubAgreement Amendment: PSUB-AMDnnnn Standalone Agreement Amendment: PST-AMDnnnn Remove spaces from the field value provided from CPI/Icertis
ACTIONNAME	None	20 CHAR in ECC, direct mapping
EVENTDATETIME	None	30 CHAR in ECC, direct mapping EventDateTime": "2024-04-12T07:16:17.9661276Z
ICMPURCHASINGORGCODE	Remove spaces, and limit the length. Separate the individual values.	Icertis provides for purchasing organization to be multi-select. Where there are multiple values, they will be provided separated by commas. Remove any spaces from the beginning and end of the value sent. Split out the individual values (which will be 4 character codes) 1000 CHAR (224 CHAR in ECC) Split the values in the field provided into separate purchasing org codes and store them in a separate table with the SYSID. Whenever a record is received, all entries in this purchasing org/SysId table are overwritten for the SYSID.
ICMCONFIDENTIALCONTRACT	Convert to single value on/off	Convert the ICertis values of 'true' and 'false' to a single character selected/deselected. Note: There will never be an entry in the table for a confidential contract as they will be filtered out in CPI.
NAME	Remove spaces and limit length	1000 CHAR (First 255 CHAR in ECC) Strip any spaces from the beginning and end of the value delivered; then take only the first 100 CHAR of the contents
ASSOCIATINGTYPE	Coded Values	Possible values are: ICMMasterAgreement Create a view for these values and assign a 3 CHAR code of 001, 002 etc. for each; these coded values will be used in the custom table. For reporting, the original values can be displayed.
ASSOCIATINGCODE	Coded Values	224 CHAR (25 CHAR in ECC) Values will be in this format where nnnnn starts at 1, 2, 3 etc.: Master Agreement: PMAnnnnnnn
ASSOCIATINGSYSID	None	36 CHAR (36 CHAR in ECC) - direct mapping
ICMAPPSRCSUPPLIERID	Remove spaces and limit length	224 CHAR (10 CHAR in ECC) Strip any spaces from the beginning and end of the value delivered (there should be no more than 10 CHAR remaining)
ICMEFFECTIVEDATE	None	Format in Icertis is YYYY-MM-DDTHH:MM:SS CPI will remove the HH:MM:SS to provide to SAP as YYYY-MM-DD
ICMEXPIRYDATE	None	Format in Icertis is YYYY-MM-DDTHH:MM:SS CPI will remove the HH:MM:SS to provide to SAP as YYYY-MM-DD
ICMTOTALCONTRACTVALUE	None	INT(15 including 2 decimals) - direct mapping
ICMCURRENCY	Remove spaces and limit the length	1000 CHAR (5 CHAR in ECC) Strip any spaces from the beginning and end of the value delivered (there should be no more than 5 CHAR remaining)
ICMLEGALENTITYCODE	Remove spaces and limit the length	1000 CHAR (4 CHAR in ECC) Strip any spaces from the beginning and end of the value delivered (there should be no more than 4 CHAR remaining)
ICMORGTEAM	Remove spaces and limit the length	1000 CHAR (25 CHAR in ECC)
ICMCONTRACTOWNER	Remove spaces and limit the length	1000 CHAR (100 CHAR in ECC) Email address of the Syensqo contract owner. Strip any spaces from the beginning and end of the value delivered; then take only the first 100 CHAR of the contents
ICMlNCOTERMSCODE	Remove spaces and limit the length	224 CHAR (3 CHAR in ECC) Strip any spaces from the beginning and end of the value delivered (there should be no more than 3 CHAR remaining)
ICMINCOTERMSLOCATION	Remove spaces and limit the length	1000 CHAR (70 CHAR in ECC) Strip any spaces from the beginning and end of the value delivered; then take only the first 70 CHAR of the contents (70 CHAR aligns with the location field in SAP)
ICMPAYMENTTERMS	Remove spaces	224 CHAR (4 CHAR in ECC) Strip any spaces from the beginning and end of the value delivered (there should be no more than 4 CHAR remaining)

Response Message

The web service call will return a response message with the following fields indicating the success or failure of the request as well as the error message

Field	Description	Data Type - SAP ECC lengths	Comment
TYPE	Message Type	Character 1	The types are as follows: E - Error S - Successful W - Warning I - Information Successful, Warning and Information indicates that the record has been saved with or without any messages Error indicates that the records were not successfully stored.
ID	Message ID	Character 20	Defaulted to ZMM_ICM
NUMBER	Message number	Character 3	Message number as stored in the message class
MESSAGE	Message	Character 220	The complete message text of the error/success
LOG_NO	Application Logging Number	Character 20	Not in use
LOG_MSG_NO	Application Log Internal Number	Numeric 6	Not in use
MESSAGE_V1	Message Variables	Character 50	Variables as needed in the Message
MESSAGE_V2	Message Variables	Character 50	Variables as needed in the Message
MESSAGE_V3	Message Variables	Character 50	Variables as needed in the Message
MESSAGE_V4	Message Variables	Character 50	Variables as needed in the Message
PARAMETER	Parameter Name	Character 32	Parameter name with reference to the message
ROW	Row	Numeric 10	Item number of the message
FIELD	Field name	Character 30	Field name with reference to the message
SYSTEM	System	Character 10	System name where the message originates from

Processing Logic

The ABAP logic will determine whether to make a new entry or to change an existing entry based on whether the Agreement Code and System ID already exist in the custom table.

The composite key of the custom table is: TENANTID + CONTRACTTYPENAME + SYSID + ICMAGREEMENTCODE

For a single Icertis contract there will be one entry in the custom table. ICMPurchasingOrgCode is a multi value field in Icertis and the separated values will also be stored in an additional custom table where they can be available for reporting.

Delta or Full Load Requirements

The payload of the agreement data from Icertis is expected to have many more fields than what are relevant to store in the custom table in SAP ECC. CPI will filter out the fields which are not required to be stored in SAP or used in the determination of field values.

Interface Alert & Monitoring

The following will be monitored:

API endpoints are available.
Failures on inbound processing need to be handled. Please check the Error Handling section.
Messages are processed in reasonable time to ensure that the custom table record in SAP ECC is available for the business user when they go to create the outline agreement. The table update is expected to occur immediately after the execution of a new contract or the initiating event in Icertis. From a business point of view this will appear to be processed without any waiting time. In terms of the business process, a wait time of even 5 minutes is acceptable and will not be noticeable.

Language Requirements

There are no language requirements for this integration. The contents of fields from Icertis are predominantly text-based formats and are being transferred in the language in which they were entered.

User Interface Requirements

There are no requirements for any user interface associated with this interface. The only interaction with users will be via the consolidation report being delivered via Business Warehouse.

Sequencing

The sequencing of the messages from Icertis to CPI to SAP is important. They must be processed in the sequence in which they occurred in Icertis. This is because whilst there will usually be a lengthy time between messages for the same SysId (Icertis Contract Id), it is possible for some fields on the original Icertis contract to be updated directly (without an amendment) and technically multiple messages for the same contract could come through in rapid succession. Other changes which require an amendment are expected to have a length of time between messages in order to draft, author, approve and execute Agreements or Amendments. Technically any processing out of sequence could result in overwriting values in the custom table and cause an inconsistency in the data between the two systems.

For this reason the processing from CPI to SAP ECC will be managed synchronously. The processing of the next message will not start until success messages are returned to CPI from both SAP systems to indicate successful table updates in ECC.

It was considered whether the sequencing could be restricted just to messages for the same Icertis contract Id (SysId). The issue is that the SysId in the received event from Icertis is not necessarily the exact SysId in the custom table in ECC. In the case of amendments, CPI uses parent field information from the first call for the agreement details to 'replace' the SysId with the one which is held in ECC. The volume of messages for this integration is low and processing synchronously means that the same sequence does not have to be managed in both CPI and then again in SAP ECC.

Volumetrics

Approx. 3,000 purchase contracts will exist at the point of go-live.

It is estimated that fewer than 100 new contracts are created or changed each day. This System Interface would be called for each relevant execution (signed) and change.

Performance Consideration

Response time is less important as this interface is triggered as a background process, and not visible to users.

Error Handling

CPI tracks the sequence and sends the messages determined from the events in the sequence in which they were provided from Icertis. Each event has an EventDateTime field which is held in SAP in the custom table for traceability and resolution of any errors. Changes are triggered via the webhook to API Management based on specific actions executed at the Icertis end, and the sequence is preserved as a JMS queue which is used at the CPI end.

CPI must wait until the completion of the call from SAP ECC (both systems WP2 and PF2). Upon receipt of the message from CPI, SAP ECC secures a successful lock on the custom table in order to make the updates, trying multiple times if necessary. Each SAP system sends a successful message back to CPI, or an error message if unsuccessful.

Following a successful message from both SAP systems, CPI may process the next message.

In the event of one or both SAP systems sending an error message to CPI, the next message must not be processed. CPI will attempt to retry the failed message multiple times. Retries will be to both SAP ECC systems, as CPI is not tracking the system responses separately. Functionally there is no issue with the same message being reprocessed again in the same system where it has already been successful.

This process handles the scenarios of lock entries on the custom table preventing the update, or if one of both of the SAP ECC production systems are temporarily down. Other scenarios which may prevent an update are authorization errors, password failures or an unforeseen failure to be able to write to the custom table in ECC. There are no reasonably expected functional table update errors expected as the content of the fields are not being validated against SAP field values but are treated as text.

When an error response from SAP is received in CPI, the alert messages are triggered to the Integration Team for investigation and resolution. Processing of the Icertis messages in CPI is stopped. Retries are made at least 5 times over a period of 10 hours. This is expected to be sufficient time for even a major system outage to be resolved, or for locks to be cleared, authorization and password issues to be resolved and for the message to be reprocessed successfully. If the problem is not resolved after 10 hours the problem message must be moved aside to allow subsequent processing of all the messages queued behind it. The message will be in the Dead Letter Queue and the alert notification to the Integration Team will have the complete message details.

From the Dead Letter Queue, there is no reprocessing. Analysis would be required of the message and the content in the custom table followed by manual update of the relevant entries in the custom table (available to Production Support only).

The following scenarios are not possible for the correction handling of integration errors:

There is no updating of data within CPI as this is closed to maintain integrity of the data. No errors can be handled by updating data within CPI.
A resend of the event cannot be initiated from Icertis or from CPI.
A call to Icertis for the 'latest version' of an agreement is not possible (this is due to the structure of the parent agreement, amendments and tracking attribute updates).

Technical Error Handling:

Any functional errors including inability to lock the custom table will not result in a failed web service execution. Instead, functional errors in SOAP message processing will be sent back to CPI as a response as part of the synchronous process. CPI will, in turn, mark the message as error. The failed message will be reprocessed in the next iteration of CPI processing. Similarly, the web service in ECC will provide a success response to indicate the the execution in ECC side has been completed as successful.

In case of other technical errors in SOAP message processing in ECC environments such as an unexpected short dump, an existing BAU process will retrieve these errors and send it as an email to the specified support group. In addition, a SyRA ticket will be raised with the same information. Nevertheless, in case of any unexpected issues with SOAP in ECC side, CPI will retry the messages again in ECC environment as a retry functionality since it failed to receive a successful response. There is no need to monitor the SOAP messages via SRT_MONI in ECC since a new message will be sent back as part of the retry functionality

Testing

How to Test

In order to unit test the interface, the events will have to be initiated in Icertis for the execution of new contracts, execution of amendments, renewals, terminations and update of tracking attributes.

This is dependent on the metadata having been configured in Icertis, and on developments in Icertis mentioned previously.

Batch jobs in Icertis are required to be defined and active in order for renewals and terminations of contracts to take place at the scheduled dates.

Z-table entries can be reset manually in order to reuse payloads from Icertis.

Test conditions are the same for the ERP-260 development and both can be unit tested concurrently.

Sample integration files from CPI will be stored as they become available for the different agreement types and the different events so they may be re-used for unit testing.

Test Conditions and Expected Results

ID	Condition	Expected Results
*Execution*
1	Execute Master Agreement	Execution event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Creation of new entry in custom table with field values as defined.
2	Execute Sub Agreement (single) for single purchasing organization	Execution event received in CPI Successful call to Icertis for agreement details Successful call to Icertis for association details Successful retrieval of agreement details Successful retrieval of association details Creation of new entry in custom table with field values as defined. Check association of Sub Agreement to the relevant Master Agreement is correct
2a	Execute Sub Agreement (single) for multiple purchasing organizations	Execution event received in CPI Successful call to Icertis for agreement details Successful call to Icertis for association details Successful retrieval of agreement details Successful retrieval of association details Creation of new entry in custom table with field values as defined. Check association of Sub Agreement to the relevant Master Agreement is correct Creation of new entries for each purchasing organization and System ID in the purchasing org custom table.
3	Execute an agreement for a confidential contract (Sub Agreement)	Execution event received in CPI Successful call to Icertis for agreement details Successful call to Icertis for association details Ensure filtering in CPI removes record for processing. No entry processed in SAP ECC.
4	Execute Stand Alone Agreement for single purchasing organization	Execution event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details No call for association details Creation of new entry in custom table with field values as defined. Creation of new entry for purchasing organization and System ID in the purchasing org custom table.
4a	Execute Stand Alone Agreement for multiple purchasing organizations	Execution event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details No call for association details Creation of new entry in custom table with field values as defined. Creation of new entries for purchasing organization and System ID in the purchasing org custom table.
5	Execute Supporting Agreement (NDA) for single purchasing organization	Execution event received in CPI Successful call to Icertis for agreement details Successful call to Icertis for association details Successful retrieval of agreement details Successful retrieval of association details Creation of new entry in custom table with field values as defined. Check association to the relevant Master Agreement is correct Creation of new entry for purchasing organization and System ID in the purchasing org custom table.
5a	Execute Supporting Agreement (NDA) for multiple purchasing organizations	Execution event received in CPI Successful call to Icertis for agreement details Successful call to Icertis for association details Successful retrieval of agreement details Successful retrieval of association details Creation of new entry in custom table with field values as defined. Check associations to the relevant Master Agreement is correct Creation of new entries for purchasing organization and System ID in the purchasing org custom table.
6	Execute Sub Agreement (multiple for the one Master Agreement) for single purchasing organization	Execution event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Creation of new entries in custom table with field values as defined. Check association of Sub Agreements to the relevant Master Agreement is correct
6a	Execute Sub Agreement (multiple for the one Master Agreement) for multiple purchasing organizations	Execution event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Creation of new entry in custom table with field values as defined. Check association of Sub Agreements to the relevant Master Agreement is correct Creation of new entries for purchasing organization and System ID in the purchasing org custom table.
Renewal
7	Agreement for single purchasing organization with auto renewal is renewed when the renewal date is reached	AutoRenewed event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table with expiry updated to the renewal date.
7a	Agreement for multiple purchasing organizations with auto renewal is renewed when the renewal date is reached	AutoRenewed event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table with expiry updated to the renewal date.
Termination
8	Existing active Agreement for single purchasing organization is terminated with notice (method 1)	Termination event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table with expiry updated to the termination notice date.
8a	Existing active Agreement for multiple purchasing organizations is terminated with notice (method 1)	Termination event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table with expiry updated to the termination notice date.
9	Existing active Agreement for single purchasing organization is terminated without notice (method 2)	Termination event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table with expiry updated to the termination date.
9a	Existing active Agreement for multiple purchasing organizations is terminated without notice (method 2)	Termination event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table with expiry updated to the termination notice date.
*Amendment Executed*
10	Execute an amendment for a Master Agreement	Amendment event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table for Parent Agreement & Parent SysId entry
11	Execute an amendment for a Sub Agreement with Master for single purchasing organization	Amendment event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table for Parent Agreement & Parent SysId entry
11a	Execute an amendment for a Sub Agreement with Master for multiple purchasing organizations	Amendment event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table for Parent Agreement & Parent SysId entry
12	Execute an amendment for a Stand Alone Agreement for single purchasing organization	Amendment event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table for Parent Agreement & Parent SysId entry
12a	Execute an amendment for a Stand Alone Agreement for multiple purchasing organizations	Amendment event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table for Parent Agreement & Parent SysId entry
13	Execute an amendment for a Supporting Agreement (NDA) for single purchasing organization	Amendment event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table for Parent Agreement & Parent SysId entry
13a	Execute an amendment for a Supporting Agreement (NDA) for multiple purchasing organizations	Amendment event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table for Parent Agreement & Parent SysId entry
Executed Updated
14	Update one or more tracking attribute fields for a Sub Agreement with Master for single purchasing organization	Updated event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table
14a	Update one or more tracking attribute fields for a Sub Agreement with Master for multiple purchasing organizations	Updated event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table
14b	Update one or more tracking attribute fields for a Sub Agreement or Standalone agreement where there has already been an amendment executed.	Updated event received in CPI Successful call to Icertis for agreement details Successful retrieval of agreement details Update of existing record in custom table
Other
15	Custom table can be updated by support user	Support user using Firefighter access process is able to update the contents of the custom table. User id without the relevant authorization group is not able to update the custom table.
16	Contract in Icertis is executed in a language other than English	Confirm the update of the relevant table entries are the same regardless of the language.
17	Test lock error for custom table in ECC, retry successful	Error stops processing, subsequent events stopped, retries executed, lock cleared, restart correctly, messages processed in correct sequence
18	Test lock error for custom table in ECC, retries unsuccessful	Error stops processing, subsequent events stopped, retries executed, lock not cleared, message moved to Dead Letter Queue and alerts issues
19	Test multiple executed update records for the same contract in rapid succession	Records processed in correct sequence
20	Test multiple renewal updates for multiple contracts on the same day -processed via the Icertis background job	Records received and processed separately.