| Status | Approved |
|---|---|
| Owner | ROWLINSON-ext, Kerry |
| Stakeholders | |
| Jira Request ID | ERP-228 - Getting issue details... STATUS |
| Jira Development ID | ERP-260 - Getting issue details... STATUS |
High-Level Specification
| Application System (Source) | Icertis Contract Intelligence |
|---|---|
| Application System (Target) | SAP ERP (PF2) & SAP ERP (WP2) |
| Source System Interface | standard ICertis webhooks and APIs |
| Target System Interface | ERP-261 |
| Business Process Reference | 03.04.04.01. Manage Outline Agreements (R2) |
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 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:
- 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 API Management (as CPI and APIM are components of Integration Suite and data flows via APIM to CPI) . 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. 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 AmendmentExecuted, AutoRenewed, Terminated and Updated require development within Icertis in order to be initiated and for a custom event job to send the default payload to CPI via API Management.
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:
- Validation that the correct Icertis Contract ID is entered on the outline agreement.
- 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 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 Agreements & associated Sub Agreements and Standalone 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.
Sequence Diagram
The sequence diagram below shows the data flow between Icertis Contract Management and SAP ECC:
The process is that events in Icertis transmit a record to CPI via API Management with ContractTypeName, SysId and ActionName.
With that information CPI makes two calls to Icertis to retrieve the agreement data and any associating instances (which exist between Sub Agreements, Supporting Agreements and their Master Agreements). There are no other associations which are relevant to be represented in the reporting structure in SAP apart from Master Agreements.
The ActionName field in the initial event received to CPI is the key controlling information which CPI needs to complete the mapping and transformation of some fields ready for SAP. The values in this field are:
- "Terminated" (update existing entry)
- "AutoRenewed" (update existing entry)
- "AmendmentExecuted" (update existing entry, but for the ICMParentContractId and ICMParentEntityInstanceId)
- "Executed" (create a new entry)
- "Updated" (update existing entry)
CPI does not need to provide the ActionName to ECC. The ABAP logic in ERP-261 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.
Call 1: To retrieve agreement details for the contract code sent in the event
GET /v{version}/agreements/{contractTypeName}/{agreementId}
If the agreement type received in the event is 'ICMSupportingAgreement' or 'ICMSubAgreement' then we must search for any Master Agreement which is an associated entity.
If ICMConfidentialContract = true, terminate processing. Contracts marked as Confidential must not be replicated to SAP ECC.
Call 2: To retrieve the associating entity details for ICMMasterAgreement
GET /v{version}/agreements/{contractTypeName}/{agreementId}/associatinginstances/{associatingEntityName}
In the call, associatingEntityName will always be ICMMasterAgreement.
Returned will be the full details for the associated Master Agreement.
In the case of amendments (ContractTypeName):
ICMMasterAgreementAmendment
ICMSupportingAgreementAmendment
ICMSubAgreementAmendment
ICMStandaloneAgreementAmendment
it is not necessary to make the second call for associations as there will never be an association to a master agreement for an amendment. When an amendment is created in Icertis, any associations are not copied from the parent contract to the amendment. The master agreement remains associated to the original contract. The associations defined in the custom table for the parent contract when it was first integrated to ECC will remain unchanged when the field values from the amendment contract are updated against the parent in ECC.
Call 2 for the associating entity details is not required for ActionName "Terminated" or "AutoRenewed" as both of these update only the expiry date.
A table detailing the scenarios and the calls made from CPI for the possible combinations of ContractTypeName and ActionName is provided:
| ContractTypeName | ActionName | Call 1 (Agreement Details) | Call 2 (Association to Master) |
| ICMMasterAgreement | Executed | Yes | No |
| ICMSupportingAgreement | Executed | Yes | Yes |
| ICMSubAgreement | Executed | Yes | Yes |
| ICMStandaloneAgreement | Executed | Yes | No |
| ICMMasterAgreementAmendment | AmendmentExecuted | Yes | No |
| ICMSupportingAgreementAmendment | AmendmentExecuted | Yes | No |
| ICMSubAgreementAmendment | AmendmentExecuted | Yes | No |
| ICMStandaloneAgreementAmendment | AmendmentExecuted | Yes | No |
| ICMMasterAgreement | Terminated | Yes | No |
| ICMSupportingAgreement | Terminated | Yes | No |
| ICMSubAgreement | Terminated | Yes | No |
| ICMStandaloneAgreement | Terminated | Yes | No |
| ICMMasterAgreement | AutoRenewed | Yes | No |
| ICMSupportingAgreement | AutoRenewed | Yes | No |
| ICMSubAgreement | AutoRenewed | Yes | No |
| ICMStandaloneAgreement | AutoRenewed | Yes | No |
| ICMMasterAgreement | Updated | Yes | No |
| ICMSupportingAgreement | Updated | Yes | No |
| ICMSubAgreement | Updated | Yes | No |
| ICMStandaloneAgreement | Updated | Yes | No |
CPI makes the necessary filters and translations required to prepare data in the format needed for the downstream interface ERP-261.
The availability of the key Icertis purchase contract information within the SAP ECC systems then makes it possible to report outline agreements associated to Icertis contracts and to compare key data objects.
</Start CR0397>
Events for Legacy Contract Loads in Icertis
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 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 CPI 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 produced in Icertis during the legacy contract loading, the action taken by CPI and the changes required in CPI.
Event Name | Legacy Load Stage | CPI Action | CPI Changes |
Published | In the first stage of legacy contract bulk load, the creation of each contract generates a Published event to CPI. | Calls for the contract details & association details and passes to SAP ECC. | 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. | Calls for the contract details & association details and passes to SAP ECC. | No Change Required |
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. | Calls for the contract details. The return from Icertis includes the Parent Contract details. CPI replaces the Amendment Agreement Code with the Parent Contract and passes to SAP ECC. | Update CPI to take the same action for 'AmendmentPublished' as it does for 'AmendmentExecuted'. This fills the ICMAgreementCode with the parent contract and results in the update to the existing line in the SAP table. |
Once the legacy contracts are loaded in Icertis, any subsequent lifecycle changes such as updates, renewals, terminations and amendments generate events in the same way as non-legacy loaded contracts.
</End CR0397>
Assumptions
It is assumed that all messages are processed in the sequence in which the events occurred in Icertis. This is to ensure that field values in the custom table remain aligned to the most recent updates in the Icertis agreement and we do not overwrite fields with previous values. Further details are provided in the Sequencing section of this document.
Dependencies
The following enhancement requests in Icertis are required to fully support the integration of the purchase contracts to the custom table in SAP ECC.
ERP-203: Icertis: Total Contract Value Calculation with Multiple Amendments
In order to correctly fill the target value ERP-203 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-508: Enhancement for Icertis Event Streams
Configure a custom event job to send the default payload (equal to the stream event payload) to SAP CPI from Icertis. This enhancement will support the following event types:
AmendmentExecuted
AutoRenewed
Terminated
- Updated*
This development in Icertis is required in order for integration to be tested for event types other than Agreement Execution.
*Icertis Contract Management has some fields for the purchase contracts which are defined as tracking attributes. Tracking attributes are fields which can be updated directly in Icertis without creating an amendment. These are typically internal fields. Examples of these type of fields are agreement name, purchasing organization and contract owner and are held in the custom table in SAP ECC. The logic will trigger on the "update" event, only when the agreement status is "Executed", and if any of the mentioned fields have changed. In such cases, Icertis sends the default payload with the action name "Updated".
Security, Integrity and Controls
Confidential contracts are to be filtered out in CPI and must not be visible in the custom table.
There are no other specific security, integrity or controls required for the processing of the interface.
Configuration Requirements
Icertis Configuration
Configuration in Icertis for the event stream definition and activation, the Webhook URL for the API endpoint is required in order for the event notifications to be available in CPI.
Special Requirements
Confidential Contracts
Icertis contracts which are identified as confidential (ICMConfidentialContract = true) are filtered out in CPI and must not have entries made in the custom table in SAP ECC. This check and filter needs to happen in the middleware to ensure there is no trace of the confidential contract details maintained outside Icertis. ICMConfidentialContract field in Icertis is changeable, for example via an amendment. The recommendation to contract specialists is if they need to adjust the confidential contract field they will create a new Sub Agreement instead of an amendment. The reason is that the contract contents may already have been passed to SAP (if not confidential); or may not have had an entry in the SAP table that can be changed with an amendment (if was originally confidential).
Design Rationale
CPI will take care of complex transformations and rules for the data from Icertis while the ABAP logic in the development ERP-261 System Interface - Icertis Contract Data Replication to SAP ECC will take care of minor manipulation of the data from CPI before updating the custom table.
Below is an example of the out-of-the-box payload sent from Icertis to CPI on the events:
{
"id": "c827d613-a5a5-4c2d-9d7d-8898abd92715",
"source": "/icertis/mycompany",
"type": "com.icertis.mycompany",
"data": {
"EventHash": "6R0AQ/viamcLKQ73E4/lXNrgPaIS8xStSHP7MPDpNW8=",
"EventMessage": {
"EventStreamId": "f64fc1fb-0ee6-41a2-8dd3-6727363a28a5",
"EventStreamName": "AutomationBasicAgreement-CreatedAndUpdate",
"EventId": "65638f47-42dc-4aee-85c5-aed814705121",
"ResourceType": "Agreement",
"ContractTypeName": "ICMMasterAgreement",
"ActionName": "Executed",
"FromState": null,
"ToState": null,
"EventBy": "d82605cb-cf47-4427-bed4-525fe568fdd3",
"EventDateTime": "2024-04-12T07:16:17.9661276Z",
"ExternalId": "",
"SysId": "35913105-9ae6-454e-aa59-ce13da70ee54",
"CorrelationId": "6f470533-f498-4f23-acb0-764da4cc2d31"
}
},
"time": "2024-04-12T07:16:23.5831003+00:00",
"specversion": "1.0",
"subject": "AutomationBasicAgreement-Executed"
}
Below is an example of the type of file received for the call to Icertis to retrieve the agreement information using the Contract Type Name and the System ID. The returned fields shown are just an example and are dependent on the configuration of the metadata in Icertis for Syensqo.
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. The exact sequence of the fields in the returned JSON files for each contract type is unknown at the time of writing and there will be many more fields in the file than those specified below.
| Field | Field Label | Description | Length/Format |
|---|---|---|---|
| n/a | 'Source' | For identifying the tenant, we can use the 'source' information provided in the initial event package from Icertis. For the development system: source: "/icertis/syensqo-dev" | 20 CHAR |
| ActionName | n/a | The ActionName is provided in the payload from the events which are sent to CPI. The content denotes whether the event is a creation, a renewal, a termination or an amendment. | n/a |
| EventDateTime | n/a | Each event message from Icertis has a date/time stamp which will be passed to SAP ECC to assist with traceability and testing "2024-04-12T07:16:17.9661276Z" | 30 CHAR |
| ContractTypeName | Contract Type Name | Possible values are: (supporting agreement is the NDA; no amendments possible for Baseline Agreements) Termination Agreements - we will receive notification to CPI of 'Terminated' for the original contract (Master/Sub etc.); call for the original contract will have termination date for the original contract. ContractTypeName is not a field seen by the users, but is more a title/heading | 224 CHAR |
| SysId | 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. This is important to have from Icertis in addition to the agreement code because it is used in backend table mapping in Icertis and is important to keep the relationship to the agreement code. Note: in the calls to Icertis, the field is labelled {agreementId} | 36 CHAR |
| ICMAgreementCode | Agreement Code | The naming convention for Icertis Agreements is defined; characters describe the type and the fact it is an amendment is in the structure of the code. The standard field ICMAgreementCode has been assigned a custom number range. It is understood then that the value of the ICMParentContractId field (used in amendments) will be the ICMAgreementCode for the parent contract. Calls to ICertis for associated entities (Master Agreements) will return the ICMAgreementCode of any Master Agreement. | 224 CHAR |
| ICMConfidentialContract | Confidential Contract | 'true' if the contract is confidential, 'false' if not (will not be blank) | 5 CHAR |
| Name | Agreement Name | Name field is fully user-defined with no default but it is expected to be descriptive and therefore a useful addition to the report to help users identify what the contract is for (eg. where there are multiple for a supplier and the consolidation report will have no line items for context). | 1000 CHAR |
| ICMParentEntityInstanceId | Parent Entity Instance Id | An 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 ICMParentContractId field, and the original contract system id is in the ICMParentEntityInstanceId field. This is not a field in Icertis, but more of a defined relationship between the parent contract and the amendment. NOTE: this field will only be visible in the file from Icertis if there is a parent (ie. for amendments) | 36 CHAR |
| ICMParentContractId | Parent Contract | An 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 ICMParentContractId field, and the original system id is in the ICMParentEntityInstanceId field. So the format of the ICMParentContractId field will be the format of the original agreement code field: This is not a field in Icertis, but more of a defined relationship between the parent contract and the amendment. Note: This is not the TYPE of the parent agreement, but the NUMBER of the parent agreement. NOTE: this field will be blank if there is no parent, but field still visible | 224 CHAR |
| ICMAppSrcSupplierID | Bidders/Supplier SAP ID | The 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. | 224 CHAR |
| ICMEffectiveDate | Effective Date | Start date of the agreement "YYYY-MM-DDTHH:MM:SS" If we receive an amendment agreement, we will use the ICMEffectiveDate and not the Amendment Effective Date (ICMAmendmentEffectiveDate) as the valid from date. The validity start date of an outline agreement should never be altered in SAP as there could be open documents. | DATE |
| ICMExpiryDate | Expiry | End date of the agreement "YYYY-MM-DDTHH:MM:SS" | DATE |
| ICMTotalContractValue1 | Total Contract Value | Is the total value of the contract (in ECC it is target value at header level) | INT(15 including 2 decimals) |
| ICMICMPreferredCurrencyUniqueName | Preferred Currency Unique Name | The currency codes in Icertis are aligned to SAP currency codes | 1000 CHAR |
| ICMLegalEntityCode/DisplayValue | Syensqo Legal Entity Code | Organizational data - company code and purchasing org are being aligned in Icertis to ECC - it is the 4 char code for company code which matches SAP | 1000 CHAR |
| ICMSupplierPurchaseOrg | Supplier Purchase Org | Organizational data - company code, and purchasing org are being aligned in Icertis to ECC- it is the 4 char code for purchasing organization which matches SAP ECC. Multiple values able to be selected by the user. Values will be provided in a single field with values separated by commas. Note: For master agreement type, the field is not defined as valid. The field will not appear in the file at all from Icertis in this case. | 1000 CHAR |
| ICMOrgTeam | Org Team | Icertis has values for each Organizational Team which will be useful for the consolidation report to enable filtering of the Icertis Z table records by procurement team. Possible values are: | 1000 CHAR |
| ICMContractOwner | Contract Owner | Use for filtering in the report on Z table so owners can find their own to work on. Email address of the Syensqo contract owner. | 1000 CHAR |
| ICMIncotermsCode | Incoterms Code | Incoterms are being aligned to correspond between Icertis and ECC. NOTE: The field ICMIncoterms holds the value that the user sees in Icertis which is the code and the description - this is not used for integration. | 224 CHAR |
| ICMIncotermslocation (confirmed already configured in Icertis with lower case L) | Incoterms Location | Free text for entry by the user. The location is the place where Syensqo takes ownership of purchased goods according to the terms agreed with the supplier. Note: For release 4, this will need to be a valid value configured within Transportation Management and is populated into the location ID field which then defaults the description into the location field. For release 2, the location field will be free text. | 1000 CHAR |
| ICMPaymentTerms/DisplayValue | Payment Terms | Payment terms are being aligned to correspond between Icertis and ECC. This is the 4 char code that matches to SAP's payment term codes in ECC. | 224 CHAR |
| ICMTerminationDate | Termination Date | When an Agreement in ICertis is scheduled for termination, a Terminated message is received (at the date when the termination occurs). The expiry date field remains same in ICertis but the termination date will have to become the expiry date in the custom table in ECC. If an Agreement in Icertis is terminated immediately, a Terminated message is received immediately. There is no ICMTerminationDate field provided. In this case, if the field is not available the expiry date will be the date stamp from the terminated event message. | DATE |
Target Structure
The fields defined in the target structure below will be the structure of the custom table in SAP ECC, named ZMM_ICMCONTRACT.
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.
Field Definitions
Field labels and field names are to correspond with the Icertis field labels and field names. It is understood there is a limit of 30 CHAR in SAP for a table name and all named fields are below the limit.
Parent Entity Instance 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.
Note: For clarity, the field System ID is not a 'system identifier', it is a unique 36 char code which is held in Icertis as a unique code for an agreement code. This is not the agreement code which the users see, but it is the code that represents the agreement in the database and it will need to be stored in SAP ECC.
Table Entries in Target SAP ECC
Icertis Amendments will not be stored directly in the custom table. Amendment events received will make the call to Icertis to obtain the amendment contract data, but the update of the table entries with the values retrieved will be made for the Parent Contract and Parent Entity Instance ID.
The key of the table will be Tenant ID, Contract Type Name, System ID and Agreement Code which will form a unique record. The two fields used for the calls to Icertis, are Agreement Type and System ID which form a unique record in Icertis. The key fields will be available for all events and will be considered mandatory in the table, whereas all other fields are optional entry. Agreement Code will be a unique record in its own right, but cannot be used alone as the database uses Agreement Type and System ID.
It is important to note that for Master Agreements, purchasing organization is not available for entry in Icertis and a 'blank' value will be passed for this field to SAP ECC.
One Icertis Agreement to One ZMM_ICMCONTRACT Entry
An Icertis contract can be defined for use by multiple purchasing organizations. The field in Icertis is defined for multiple selection and represents the organizations for which an operational outline agreement will be created in SAP. In SAP, an outline agreement is defined for a single purchasing organization. This means that for one Icertis Agreement Code there will be one outline agreement for each purchasing organization.
The field ICMPurchasingOrgCode is provided to CPI with all the values in a single field separated by commas. This will be held in the custom table in SAP in a single field in the same format (values separated by commas).
For the 'Execution' event, one new entry is created in the table. For the other events AmendmentExecuted, AutoRenewed, Terminated & Updated the existing table entry for TenantID, ContractTypeName, SysId, ICMAgreementCode, is updated.
AmendmentExecuted
AutoRenewed
Terminated
- ExecuteUpdated
It was considered whether the individual values for purchasing organization could be stored separately resulting in a row in the custom table for each purchasing organization. This would have required purchasing organization to be part of the key of the table to keep unique entries. Due to the way purchasing organization can be changed in Icertis, there are technical limitations for the accurate updating of the multiple rows. Instead, the individual values will be stored with the System ID in an additional table to be available for reporting. The original value in the purchasing organization field from Icertis will be all the values separated by commas. This will be stored in the custom table for reference but not reported.
| Field | Field Label | Description | Length/Format |
|---|---|---|---|
| TENANTID | Tenant ID | For identifying the tenant, we can use the 'source' information provided in the initial event package from Icertis. For the development system: source: "/icertis/syensqo-dev" | 20 CHAR |
| CONTRACTTYPENAME | Contract Type Name | Possible values are: (supporting agreement is the NDA; no amendments possible for Baseline Agreements) Termination Agreements - we will receive notification to CPI of 'Terminated' for the original contract (Master/Sub etc.); call for the original contract will have termination date for the original contract. ContractTypeName is not a field seen by the users, but is more a title/heading | 224 CHAR (3 CHAR in ECC, with view and coded values) |
| SYSID | System ID | Along withContractTypeName, SysId is the key with which CPI makes the call to Icertis to retrieve the complete contract field details. Example: 1343f2e0-9386-4fa7-aa5b-22abba04d35a (36 chars) | 36 CHAR |
| ICMAGREEMENTCODE | Agreement Code | The agreement code is the contract number in Icertis and is preceded by the agreement type. Example: Master Agreement: Master Agreement: PMAnnnnnnn This value from Icertis will be stored on the header of the outline agreement in SAP ECC. | 224 CHAR (25 CHAR in ECC) |
| ACTIONNAME | Action Name | The ActionName is provided in the payload from the events which are sent to CPI. The content denotes whether the event is a creation, a renewal, a termination or an amendment. | 20 CHAR |
| EVENTDATETIME | Event Date Time | Each event message from Icertis has a date/time stamp which will be passed to SAP ECC to assist with traceability and testing "2024-04-12T07:16:17.9661276Z" | 30 CHAR |
| ICMCONFIDENTIALCONTRACT | Confidential Contract | 'true' if the contract is confidential, 'false' if not (will not be blank) | 5 CHAR (1 CHAR in ECC with value selected for true and deselected for false) |
| NAME | Agreement Name | Description given to the contract (useful for reporting) | 1000 CHAR (First 100 CHAR in ECC) |
| ASSOCIATINGTYPE | Associating Agreement Type | This is the Icertis Agreement Type of the associated agreement (for example ICMMasterAgreement if the record is a ICMSubAgreement or SupportingAgreement. The call for associated entity 'ICMMasterAgreement' will return all the fields for the associated master agreement. The Agreement Type, the Agreement Code and System ID will be stored in the custom table to enable reporting of the hierarchical structure of contracts to their Master Agreements. The associating entity fields are not fields that exist in Icertis, but are defined in SAP in order to hold the information. In Icertis, the associations are held as types of relationships. | 224 CHAR (3 CHAR in ECC, with view and coded values) |
| ASSOCIATINGCODE | Associating Agreement Code | This is the Icertis Agreement Code of the associated agreement (for example ICMMasterAgreement if the record is a ICMSubAgreement or SupportingAgreement. The call for associated entity 'ICMMasterAgreement' will return all the fields for the associated master agreement. The Agreement Type, the Agreement Code and System ID will be stored in the custom table to enable reporting of the hierarchical structure of contracts to their Master Agreements. The associating entity fields are not fields that exist in Icertis, but are defined in SAP in order to hold the information. In Icertis, the associations are held as types of relationships. | 224 CHAR (25 CHAR in ECC) |
ASSOCIATINGSYSID | Associating System ID | This is the Icertis System ID of the associated agreement (for example ICMMasterAgreement if the record is a ICMSubAgreement or SupportingAgreement. The call for associated entity 'ICMMasterAgreement' will return all the fields for the associated master agreement. The Agreement Type, the Agreement Code and System ID will be stored in the custom table to enable reporting of the hierarchical structure of contracts to their Master Agreements. The associating entity fields are not fields that exist in Icertis, but are defined in SAP in order to hold the information. In Icertis, the associations are held as types of relationships. | 36 CHAR (36 CHAR in ECC) |
| ICMAPPSRCSUPPLIERID | Bidders/Supplier SAP ID | The 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 (10 CHAR in ECC) |
| ICMEFFECTIVEDATE | Effective Date | YYYYMMDD | DATE |
| ICMEXPIRYDATE | Expiry | YYYYMMDD | DATE |
| ICMTOTALCONTRACTVALUE | Total Contract Value | Is the total value of the contract (in ECC it is target value at header level) In the case of amendments, it is the updated overall total ERP-203 Icertis: Total Contract Value calculation with multiple amendments to enable ECC Integration | INT(15 including 2 decimals) |
| ICMCURRENCY | Supplier Currency | Confirmed the currency codes in Icertis are aligned to SAP codes | 5 CHAR |
| ICMLEGALENTITYCODE | Syensqo Legal Entity Code | Organizational data - company code and purchasing org are being aligned in Icertis to ECC - it is the 4 char code for company code which matches SAP | 1000 CHAR (4 CHAR in ECC) |
| ICMPURCHASINGORGCODE | Purchasing Org Code | Organizational data - company code and purchasing org are being aligned in Icertis to ECC- it is the 4 char code for purchasing organization which matches SAP. Multiple values able to be selected by the user. Values will be provided from ICertis in a single field with values separated by commas. Individual values will be stored in a separate table to enable the reporting of the separated values. Note: For master agreement type, the field is not defined as valid. The field will not appear in the file at all from Icertis in this case. | 1000 CHAR (224 CHAR in ECC) |
| ICMORGTEAM | Org Team | Icertis has values for each Organizational Team which will be useful for the consolidation report to enable filtering of the Icertis Z table records by procurement team. Possible values are: | 1000 CHAR (25 CHAR in ECC) |
| ICMCONTRACTOWNER | Contract Owner | Use for filtering in the report on Z table so owners can find their own to work on Email address of the Syensqo contract owner. | 1000 CHAR (224 CHAR in ECC) |
| ICMlNCOTERMSCODE | Incoterms Code | Incoterms are being aligned to correspond between Icertis and ECC NOTE: The field ICMIncoterms holds the value that the user sees in Icertis which is the code and the description - this is not used for integration. | 224 CHAR (3 CHAR in ECC) |
| ICMINCOTERMSLOCATION | Incoterms Location | Free text for entry by the user. For release 4, this will need to be a valid value configured within Transportation Management and is populated into the location ID field which then defaults the description into the location field. | 1000 CHAR (70 CHAR in ECC) |
| ICMPAYMENTTERMS | Payment Terms | Payment 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 (4 CHAR in ECC) |
Mapping and Calculation
Note: 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 for the custom fields in SAP ECC will correspond to the length of the fields in Icertis unless specified otherwise. In those cases where the ECC field is smaller than the Icertis field, it is known that the field values will fit in the defined length.
Important: The ActionName field in the initial event received to CPI is to be passed in the target structure to SAP ECC so the value of the most recent message for the agreement is stored. This will assist in traceability of the changes to field values in the table. The ABAP logic determines whether to update an entry or create a new one based on the existing entries rather than the ActionName itself.
The possible values for ActionName are:
"Terminated" (update existing entry)
"AutoRenewed" (update existing entry)
"AmendmentExecuted" (update existing entry, but for the ICMParentContractId and ICMParentEntityInstanceId)
"Executed" (create a new entry)
"Updated" (update existing entry)
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.
Icertis field contents are not case-sensitive.
| Source Table | API or Portlet Name | Source Field (Icertis) | Required (Y/N) | Description | Target | API or Portlet Name | Target Field (SAP ECC) | Required (Y/N) | Description (Label in SAP) | Rule Type | Rule Instruction |
|---|---|---|---|---|---|---|---|---|---|---|---|
| N/A | 'Source' | Y | Development system: source: "/icertis/syensqo-dev" Test system: source: "/icertis/syensqo-uat" | ZMM_ICMCONTRACT | TENANTID | Y | Tenant ID | Use what is received from Icertis in the Source field: Development system: source: "/icertis/syensqo-dev" Test system: source: "/icertis/syensqo-uat" | |||
N/A | ContractTypeName | Y | Contract Type Name | ZMM_ICMCONTRACT | CONTRACTTYPENAME | Y | Contract Type Name | If ActionName is 'Executed', then a new entry is made in the Z table for CONTRACTYPENAME and SYSID If ActionName is 'AutoRenewed', 'Updated' or 'Terminated', then one or more existing entries are updated for the CONTRACTTYPENAME and SYSID If the ActionName is 'AmendmentExecuted' then the existing entry for ICMAGREEMENTCODE = ICMParentContractId and SYSID =ICMParentEntityInstanceId is updated. | |||
| N/A | SysId | Y | System ID | ZMM_ICMCONTRACT | SYSID | Y | System ID | If ActionName is 'Executed', then a new entry is made in the Z table for CONTRACTYPENAME and SYSID If ActionName is 'AutoRenewed', 'Terminated' or 'Updated', then the existing entry is updated for the CONTRACTYPENAME and SYSID If the ActionName is 'AmendmentExecuted' then the existing entry for for ICMAGREEMENTCODE = ICMParentContractId and SYSID = ICMParentEntityInstanceId is updated. | |||
| N/A | ICMAgreementCode | Y | ICM Agreement Code | ZMM_ICMCONTRACT | ICMAGREEMENTCODE | Y | ICM Agreement Code | Direct Mapping | |||
| N/A | ActionName | Y | Action Name | ZMM_ICMCONTRACT | ACTIONNAME | Y | Action Name | Direct Mapping | |||
| N/A | EventDateTime | Y | Event Date Time | ZMM_ICMCONTRACT | EVENTDATETIME | Y | Event Date Time | Direct Mapping | |||
| N/A | ICMConfidentialContract | Y | Confidential Contract | ZMM_ICMCONTRACT | ICMCONFIDENTIALCONTRACT | Y | Confidential Contract | If the agreement has the value 'true' for confidential contract, then the file must not be processed; no entry is to be made or changed in SAP. | |||
| N/A | Name | Y | Agreement Name | ZMM_ICMCONTRACT | NAME | N | Agreement Name | Direct Mapping | |||
| N/A | N/A | N | N/A | ZMM_ICMCONTRACT | ASSOCIATINGTYPE | N | Associating Agreement Type | If the Agreement Type is ICMSupportingAgreement OR ICMSubAgreement we call Icertis for the associating entity ICMMasterAgreement If one is found, store the ContractTypeName for the associated master agreement in ASSOCIATINGTYPE | |||
| N/A | N/A | N | N/A | ZMM_ICMCONTRACT | ASSOCIATINGCODE | N | Associating Agreement Code | If the Agreement Type is ICMSupportingAgreement OR ICMSubAgreement we call Icertis for the associating entity ICMMasterAgreement If one is found, store the ICMAgreementCode for the associated master agreement in ASSOCIATINGCODE | |||
| N/A | N/A | N | N/A | ZMM_ICMCONTRACT | ASSOCIATINGSYSID | N | Associating System ID | If the Agreement Type is ICMSupportingAgreement OR ICMSubAgreement we call Icertis for the associating entity ICMMasterAgreement If one is found, store the SysId for the associated master agreement in ASSOCIATINGSYSID | |||
| N/A | ICMAppSrcSupplierID | N | Bidders/Supplier SAP ID | ZMM_ICMCONTRACT | ICMAPPSRCSUPPLIERID | N | Bidders/Supplier SAP ID | Direct Mapping | |||
| N/A | ICMEffectiveDate | N | Effective Date | ZMM_ICMCONTRACT | ICMEFFECTIVEDATE | N | Effective Date | Format received is YYYY-MM-DDTHH:MM:SS Remove the HH:MM:SS and 'dashes' to provide to SAP as YYYYMMDD | |||
| N/A | ICMExpiryDate | N | Expiry | ZMM_ICMCONTRACT | ICMEXPIRYDATE | N | Expiry Date | If ActionName is 'Executed', 'AutoRenewed', 'Updated' or 'AmendmentExecuted', direct mapping. If ActionName 'Terminated', fill with the value from ICMTerminationDate If the ICMTerminationDate is not provided for the Agreement in the 'Terminated' event, then the Date provided in the Date/Time stamp of the event is used as the Expiry Date. Format received is YYYY-MM-DDTHH:MM:SS Remove the HH:MM:SS and 'dashes' to provide to SAP as YYYYMMDD | |||
| N/A | ICMTotaIContractVaIue/Value | N | Target Value | ZMM_ICMCONTRACT | ICMTOTALCONTRACTVALUE | N | Total Contract Value | Direct Mapping | |||
| N/A | ICMPreferredCurrencyUniqueName | N | Preferred Currency Unique Name | ZMM_ICMCONTRACT | ICMCURRENCY | N | Supplier Currency | Direct Mapping | |||
| N/A | ICMLegaIEntityCode/DisplayValue | N | Syensqo Legal Entity Code | ZMM_ICMCONTRACT | ICMLEGALENTITYCODE | N | Syensqo Legal Entity Code | Direct Mapping | |||
| N/A | ICMPurchaseOrgCode | N | Purchase Org Code | ZMM_ICMCONTRACT | ICMPURCHASINGORGCODE | N | Purchasing Org Code | Direct Mapping (including blank value when field is not provided from Icertis at all) Note: the field name in Icertis is ICMPurchaseOrgCode, but in SAP ECC it is ICMPURCHASINGORGCODE | |||
| N/A | ICMOrgTeam | N | Org Team | ZMM_ICMCONTRACT | ICMORGTEAM | N | Org Team | Direct Mapping | |||
| N/A | ICMContractOwner | N | Contract Owner Name | ZMM_ICMCONTRACT | ICMCONTRACTOWNER | N | Contract Owner Name | Direct Mapping | |||
| N/A | ICMlncotermsCode | N | Incoterms Code | ZMM_ICMCONTRACT | ICMlNCOTERMSCODE | N | Incoterms Code | Direct Mapping | |||
| N/A | ICMIncotermslocation (confirmed already configured in Icertis with lowercase L) | Incoterms Location | ZMM_ICMCONTRACT | ICMINCOTERMSLOCATION | N | Incoterms Location | Direct Mapping | ||||
| N/A | ICMPaymentTerms | N | Payment Terms | ZMM_ICMCONTRACT | ICMPAYMENTTERMS | N | Payment Terms | Direct Mapping | |||
Processing Logic
Processing within Source
There is no processing requirement to be carried out in the Source System Icertis.
Processing within Middleware
All processing within CPI is defined in the mapping sheet.
Processing within Target
ERP-261 is the target interface being called by this integration process.
Interface Dependency
There are no dependent interfaces identified which require processing prior to this interface.
Interface Constraints
There are no constraints identified.
Delivery Requirements
The delivery requirements are expected to be as close to real time as possible, allowing just for processing time.
The triggering events from Icertis are received to CPI via API and is a push of the event information. There is then a pull of the contract information from Icertis by CPI based on the event data provided in the initial payload.
Sequencing
The sequencing of the messages for the same contract from Icertis to CPI and to SAP is important in some scenarios. In most cases there will usually be a lengthy time between messages for the same SysId (Icertis Contract Id) because it takes time to execute a contract or to execute an amendment. 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. Processing these types of messages out of sequence could result in overwriting values in the custom table and cause an inconsistency in the data between the two systems. This is, however, likely to only be possible in the event of an outage of the CPI system.
Icertis processes the event messages in the sequence in which they occurred and likewise, CPI will process the messages it receives from ICertis in the order they were received. In CPI, each event message is processed and completed, with calls to Icertis successfully completed before processing the next event.
In the event of a system outage of CPI, there is the potential for multiple event messages to be queued up on the Icertis side and in various schedules for retries. There is the possibility for these to be processed out of sequence. Currently there is no mechanism in Azure Event Grid to prevent this and to guarantee strict delivery order. It is unlikely that there will be multiple messages for the same contract unless multiple tracking attribute updates were made in quick succession during a system outage of CPI. Tracking attribute fields are always internal fields and present a low impact if they are updated out of sequence. In summary the risk of this happening is very low, and the impact is also low.
Delta or Full Load Requirements
This flow is triggered for each relevant event in ICertis, for the contract that generated the event.
Interface Alert & Monitoring
The following will be monitored:
- API endpoints are available to view all event details, including events that were successfully processed, those that failed, and those currently in the queue.
- Failures on inbound processing and outbound side need to be handled. Please refer to the Error Handling section for error management in both Icertis and CPI.
- 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. This is expected to be immediately after the execution of a new contract or the triggering of the relevant event, and will appear to happen in real time.
Interface Reporting
There are no specific reporting requirements identified to support this interface.
Language Requirements
There are no specific language requirements. The contract content from Icertis is predominantly text based and will therefore be shown in the language it which it was entered in Icertis.
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.
Volumetrics
Approx. 3,000 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 change.
Performance Consideration
Response time is less important as this interface is triggered as a background process, and not visible to users. However, the interface should operate in near-real-time to avoid delays.
Error Handling
Icertis Messages to CPI
Icertis event messages on execution of a contract or contract changes are handled by Azure Service Bus which is the message broker that facilitates communication between Icertis and CPI. Azure Service Bus queues store the messages until the receiving application is ready to receive and process them. Azure Event Grid has the webhook details and includes pre-defined rules for retrying of message. In the case of CPI being temporarily down, Event Grid will retry for up to 24 hours (up to 30 times), usually at exponentially increasing waiting times across the duration to resend the event messages. These rules for error handling and retrying are defined within Azure Event Grid and are not customizable for Syensqo. Events remain available until the 24-hour time period expires.
In the event of errors, alert messages are provided by Azure and include the ability to see the error details and the contents of the failed message.
If a message is still failed following all the retries, Azure Event Grid sends the message to the Dead Letter Queue and issues alerts. There is no reprocessing of the message from here, but the full contents are available. The message is marked with a failed status. The recovery process from an Icertis event message in the Dead Letter Queue would be to look up the Icertis Contract details and request for the table entries in ECC to be manually created or updated.
CPI Calls to Icertis
If CPI receives an error response from Icertis when calling for the Agreement details or Associations, it will retry the messages in sequence. There is a defined schedule for retries and the waiting period between attempts increases exponentially until the end of the defined time period. Any message still in error at the end of the allocated time will be sent to the Dead Letter Queue. Alerts are provided for any error messages and the full payload contents are available. There is no reprocessing of the message from the Dead Letter Queue and the recovery for these would be a request for the table entries in ECC to be manually created or updated.
Errors in the calls to Icertis are only expected in the event of a technical communication issue or a system outage for Icertis. It is generally expected that these errors would be resolved based on the alerts received, before the message was placed in the Dead Letter Queue.
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 tracking attribute field updates.
This is dependent on the metadata having been configured in Icertis, and on developments in Icertis mentioned previously.
Z-table entries can be reset manually in order to reuse payloads from Icertis.
Test Conditions and Expected Results
| ID | Condition | Expected Results |
|---|---|---|
| Executed | ||
| 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. |
| AutoRenewed | ||
| 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. |
| Terminated | ||
| 8 | Existing active Agreement for single purchasing organization is terminated with notice (method 1) | Terminated 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) | Terminated 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) | Terminated 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) | Terminated 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. |
| AmendmentExecuted | ||
| 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 |
| 13b | Agreement with an amendment already executed 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. |
| 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 |
| Errors | ||
| 15 | Simulate error sending event message Icertis to CPI | Retries and alerts as expected |
| 16 | Simulate error message when CPI calls to Icertis | Retries and alerts as expected |
</Start CR0397>
Testing Scenarios
Testing of the changes need to be carried out in conjunction with the ERP-261 changes in order to see the correct results received into SAP ECC.
ID | Event | Condition | Expected Result |
1 | Published | Load legacy master agreements | Published event is generated to CPI Calls are made to CPI for contract details and associations Details are successfully passed to SAP ECC for processing |
2 | Published | Load legacy subagreements | Published event is generated to CPI Calls are made to CPI for contract details and associations Details are successfully passed to SAP ECC for processing |
3 | Published | Load legacy standalone agreements | Published event is generated to CPI Calls are made to CPI for contract details and associations Details are successfully passed to SAP ECC for processing |
4 | Published | Load legacy supporting agreements | Published event is generated to CPI Calls are made to CPI for contract details and associations Details are successfully passed to SAP ECC for processing |
5 | AssociationPeerLinkage | Load associations to master agreements | AssociationPeerLinkage event is generated to CPI Calls are made to CPI for contract details and associations Details are successfully passed to SAP ECC for processing |
6 | AmendmentPublished | Load amendments for legacy loaded master agreements | AmendmentPublished event is generated to CPI Calls are made to CPI for contract details and associations Parent Contract details replace the Amendment Agreement Code Details are successfully passed to SAP ECC for processing |
7 | AmendmentPublished | Load amendments for legacy loaded subagreements | AmendmentPublished event is generated to CPI Calls are made to CPI for contract details and associations Parent Contract details replace the Amendment Agreement Code Details are successfully passed to SAP ECC for processing |
8 | AmendmentPublished | Load amendments for legacy loaded standalone agreements | AmendmentPublished event is generated to CPI Calls are made to CPI for contract details and associations Parent Contract details replace the Amendment Agreement Code Details are successfully passed to SAP ECC for processing |
9 | AmendmentPublished | Load amendments for legacy loaded supporting agreements | AmendmentPublished event is generated to CPI Calls are made to CPI for contract details and associations Parent Contract details replace the Amendment Agreement Code Details are successfully passed to SAP ECC for processing |
</End CR0397>
Test Considerations/Dependencies
Considerations and dependencies for testing:
ERP-203 Icertis: Total Contract Value calculation with multiple amendments to enable ECC Integration needs to be completed in order for the target value to reflect the total of all amendments and the original contract target value.
ERP-508 Enhancement for Icertis event streams need to be completed in order for the events for renewals, terminations, amendments to be generated from Icertis and send the initial payload to CPI.
Configuration of metadata is required to be completed in Icertis.
Other Information
There is no other information identified.
Development Details
Package
| Package Name | Parent Package |
|---|---|
| Icertis Agreements Replication to ECC | N/A |
Other Development Objects
| Object Type | Object Name | Purpose/High Level Logic | Configured/Externalized Parameters | Value - Development | Value - Test | Value - Production |
|---|---|---|---|---|---|---|
| API | Icertis_to_ECC_Agreements_Events | Receive the Webhook notification sent by the Icertis as part of the Event Stream. Validate the event data and pass it to the CPI iFlow | N/A | N/A | N/A | N/A |
| iFlow | Icertis_to_JMS_ProcessAgreementsWebhook | Receive the webhook and push it to JMS Queue | Address(Receiver Endpoint) | /Icertis/replicateAgreements | /Icertis/replicateAgreements | /Icertis/replicateAgreements |
| Queue Name | IcertisContractAgreementsQueue | IcertisContractAgreementsQueue | IcertisContractAgreementsQueue | |||
| iFlow | JMS_IcertisAgreements_Router | Route the message to the corresponding iFlow | Queue Name | IcertisContractAgreementsQueue | IcertisContractAgreementsQueue | IcertisContractAgreementsQueue |
| iFlow | JMS_To_Icertis_ExtractAgreementsData | Extract the Icertis contract data based on the webhook notification data received | Address(Receiver Endpoint) | /Icertis/extractAgreementData | /Icertis/extractAgreementData | /Icertis/extractAgreementData |
| Queue Name | IcertisContractAgreementsQueue | IcertisContractAgreementsQueue | IcertisContractAgreementsQueue | |||
| ECCPDEndpoint | /Icertis/UpdateDataToECC | /Icertis/UpdateDataToECC | /Icertis/UpdateDataToECC | |||
| IcertisEnvValue | /icertis/syensqo-dev | /icertis/syensqo-qas | /icertis/syensqo-prd | |||
| iFlow | JMS_To_ECC_UpdateAgreementsData | Receive the data and update it in ECC Systems | Address(Receiver Endpoint) | /Icertis/UpdateDataToECC | /Icertis/UpdateDataToECC | /Icertis/UpdateDataToECC |
| Wx2 URL | wd2.syensqo.com:44300 | wq2.syensqo.com:44311 | wp2.syensqo.com:XXXXX | |||
| Wx2ClientNo | 110 | XXX | XXX | |||
| Credential Name | BasicAuthFromAribaWx2 | XXX | XXX | |||
| xF2 URL | df2.syensqo.com:44369 | qf2.syensqo.com:44377 | pf2.syensqo.com:XXXXX | |||
| xF2ClientNo | 020 | 040 | XXX | |||
| Credential Name | BasicAuthFromAriba | XXX | XXX |
Support Components/Dependencies.
| Technical Name (iFlow/API/Script Collection) | Type | Description |
|---|---|---|
| Icertis_AgreementsReplication_CommonScripts | Script Collection | Collection of reusable scripts |
Security Material
| Name | Type |
|---|---|
| BasicAuthFromAribaWx2 | User Credentials |
| BasicAuthFromAriba | User Credentials |
1 Comment
BEZEMER-ext, Wytse
ROWLINSON-ext, Kerry review completed. just a couple comments created. we can discuss if needed. Also some open thoughts added in the comments.