| Status | Approved |
|---|---|
| Owner | ROWLINSON-ext, Kerry |
| Stakeholders | |
| Jira Request ID | ERP-228 - Getting issue details... STATUS |
| Jira Development ID | ERP-261 - Getting issue details... STATUS |
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:
| 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. | 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. | 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" 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: 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.: 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: 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.: |
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) |
| 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. |
</Start CR0397>
Testing Scenarios
Testing of the changes need to carried out in conjunction with the ERP-260 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:
- Testing of the details in this specification can only be done at the same time as ERP-260. The process is initiated from contract executions and amendments in Icertis.
- 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
Development Details
Package
| Package Name | Parent Package |
|---|---|
| ZWPU_5_08 | |
Other Development Objects
| Object Type | Object Name | Purpose/High Level Logic | Design Rationale Reference |
|---|---|---|---|
| Function Group | Z_MM_ICM_CONTRACT_FG | Interface Function Module | |
| Service Definition | ZMMSD_ICM_CONTRACT_UPD | SOAP Proxy for Icertis Interface |
1 Comment
BEZEMER-ext, Wytse
ROWLINSON-ext, Kerry as mentioned on the chat. Completed review. Just one open thought in the comment.