High- Level Specification

Functional Overview

Icertis Contract Intelligence is the contract management and authoring application for Syensqo's purchase contracts. Purchase orders are created in SAP ECC 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 SAP ECC.  The integration between Icertis and SAP ECC for release 2 is a custom table in SAP ECC to hold key header field content from Icertis (ERP-260 Integration Process - Icertis to SAP ECC Contract Data Replication & ERP-261 System Interface - Icertis Contract Data Replication to SAP ECC). This custom table supports the main objectives:

1. To enable a relationship between the Icertis Agreement Code and the SAP outline agreement number.
2. To report where there are inconsistencies in the data between the two systems.

This enhancement is to provide a convenient method for the users to update the SAP outline agreements with their corresponding Icertis Agreement Code numbers in bulk. A custom field to hold the ICM Agreement Code has been defined in ERP-259 Enhancement for Storage of Icertis ID on OA Header and the program to be created on this spec will allow contract specialists and GBS to update those contracts in bulk and 

This enhancement will provide a convenient method for contract specialists and GBS to bulk edit two fields in Outline Agreements in PF2 and WP2.

• ICM agreement code (EKKO-ZZICMAGREEMENTCODE)
• OA Verification Status (a new custom field that will need to be defined in EKKO as part of this enhancement - eg: ZZOAVERIFSTAT). 

It is expected that the new field "OA Verification Status" can be updated via MASS Tcode and also from ME32K (to consistent same behaviour as EKKO-ZZICMAGREEMENTCODE) 

Scope and Objectives

Detail the functional scope and objectives of the Enhancements. Please also describe the gap that will be addressed by this enhancement (Compared to SAP Standard)

For one purchase contract in Icertis, there can be multiple outline agreements created in SAP ECC (one per relevant purchasing organization). The Icertis Agreement Code is to be entered on the header of each outline agreement. This can be done during the creation of each one, or via ME32K Change Outline Agreement after creation and one outline agreement at a time. This enhancement allows contract specialists and also GBS members to update in bulk the ICM Agreement code and also the OA Verification status via a new transaction code.

The intended business process is for all new outline agreements created in SAP ECC after the introduction of Icertis Contract Management to be assigned to the respective Icertis legal contract via the entry of the ICM Agreement Code on the header when the outline agreement is created. Currently active outline agreements exist in SAP ECC which may not have a signed legal contract, and many outline agreements have an open-ended validity period which makes it difficult to determine which outline agreements are relevant to be migrated to S/4 HANA.

To assist with the process of identifying outline agreements which have been verified for migration, this enhancement will provide an additional field on the header to allow the classification of the outline agreement for migration without a legal contract, or not for migration. The population of this field will assist Syensqo to categorize outline agreements:

• which have been verified as not having a current legal contract but require migration to S/4 HANA
• which have been verified to not be migrated
• which still require verification for migration or not, and association to an Icertis agreement

The categorization of outline agreements in this way will assist in the management of activities relating to the migration of outline agreements to S/4 HANA. Agreements which have already been categorized as 'not for migration' or 'migrate without a legal contract' can be identified on the report of outline agreements without an ICM contract (ERP-503 Consolidation Report Icertis SAP ECC Outline Agreements - Story) to avoid repeat analysis of them. From a business process point of view, it is recommended that users enter a more detailed reason in an internal text for the required omission of a legal contract.

Both the ICM Agreement Code and the OA Verification fields are available to update via the standard mass maintenance transaction for outline agreements (MEMASSCONTRACT). However, mass maintenance is more complex, makes available the mass update of all header and line-item fields, and is mostly used only by GBS for specific outline agreement changes. This custom developed transaction will make updates to these two fields only in a user-friendly, low-risk format.

For the correction of other key data in SAP ECC which is not aligned with Icertis, the existing upload programs for change outline agreement can be used, or the contract can be changed directly in transaction ME32K.

Process Flow Diagram

Insert the flowchart and fill in the steps

Assumptions

N/A

Dependencies

In order to assign an ICM Agreement code to the Outline agreement, the ICM Agreement code must exist in the ZMM_ICM* Tables. 

Security, Integrity and Controls

The new program will need to be assigned to a transaction code so that contract specialists and GBS employees can run this new application. 

We do not require to create any new authorization objects given that when trying to change the Outline Agreement, SAP will check that the user has access to modify the document (including Org checks).

The new transaction will be added to an existing role in WP2 and PF2.

It is suggested to use a BAPI to change the outline agreements, which can also help us to run the program in test run mode and leverage the error log coming from table RETURN. 

Configuration Requirements

The new field OA Verification Status which will need to be included in the contract header screen on ME31K / ME32K and ME33K will need to have the following behaviour:

1. Field is optional.
2. Only allowed values are:
   1. 01 - Verified without ICM Contract
   2. 02 - Do Not Migrate

Language Requirements

N/A

Special Requirements

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

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

Design Rationale

Functional Requirements

Detail the functional requirements that are desired to be achieved by the Enhancement compared to current functionality

jlkjl

Proposed Technology to Use

It is suggested to:

• Create a new custom field in EKKO table for "OA Verification status" under the same append structure used for field ZZICMAGREEMENTCODE (append structure ZSMM_ICMAGREEMENT_EKKODB).
• Replicate similar behaviour for screen interaction used with ZZICMAGREEMENTCODE (User Exits ZXM06U36, ZXM06U37 and ZXM06U43).
• Create a new abap program which will be responsible to modify the Outline Agreement fields which need to be managed by this functional spec (ICM Agreement Code and "OA Verification Status"). Ideally this program calls BAPI_CONTRACT_CHANGE which will allow to run program in test mode to get things validated before changing the contract and also to get a good error log to be displayed on the screen for users to verify if updates are fine or failed for different reasons.
• Create a new Transaction code which invokes this new program.
• Include the new transaction code in existing roles so that relevant users have access to the new developed program.

Data Source Considerations

Include an overview of the source

Data Validation Considerations

The standard BAPI to change contract should validate the fields according to the logic already defined in user exits which validate format of ZZICMAGREEMENTCODE and the new field introduced under this spec (OA Verification Status).

Custom Tables

N/A

Master Data

N/A

Configuration Table

The new field "OA Verification Status", which will be included in table EKKO, will need to have 2 allowed values (+ blank):

Selection Screen Enhancement

The selection screen of the new program will allow the user to either select between two radio buttons:

• Update ICM Agreement Code
• Update OA Verification Status

Also, we suggest to have a parameter  field called "Test Run" which will help users running this program to verify if all records can be updated before doing the final update. 

Once we update the radio button, we should show below, table of two fields:

• When user selects "Update ICM Agreement Code, user should see a table with two fields next to each other: Outline Agreement & ICM Agreement Code.
• When user selects "Update OA Verification Status", user should see a table with two fields next to each other: Outline Agreement & Verification Status. 

User should be able in both cases to upload the two fields "from clipboard". 

Once the data is populated into the input table, user should be able to press execute (F8) and get a final pop-up message saying "You are about to change X number of Outline Agreements, Please Confirm".

Upon confirmation, logic should be applied to modify the outline agreement and present on screen status of the modification. 

Processing Logic

On the New TCODE →

Once the user has completed the Outline agreements + the field to be updated (either ICM Agreement Code or OA Verification Status), the program should prepare records to call BAPI_CONTRACT_CHANGE. 

The two custom fields are typically populated by table EXTENSIONIN.

The field Test Run will need to be populated from the parameter in the selection screen.

We suggest to read the output of table Return and provide a log in an ALV fashion so that users know for each OA Processed if there are any errors or if update is successful. 

Following blog can be used to see an example on how these structures are populated → How to update custom fields using BAPI_CONTRACT_CH... - SAP Community

In ME31K →

On ME31K user should be able to populate the new created field "OA Verification Status" and then it should be saved in EKKO. The allowed values are the ones defined by the data element (01, 02 or Blank).

In ME32K → 

On ME32K, if a value is already saved on EKKO for field "OA Verification Status", the content of the field will need to be retrieved by the DB Table EKKO and presented on screen.

If a user decides to change the value in ME32K, the value will need to be validated according to the data element and saved in table EKKO.

In ME33K →

On ME33K, if a value is saved on EKKO for field "OA Verification Status", the field will need to be retrieved from the DB and presented on Screen. 

In MASS -->

• Enable the update of the OA Verification field on the outline agreement header via the standard mass update transaction MEMASSCONTRACT (the same as has been done for ICMAGREEMENTCODE field in ERP-259 Enhancement for Storage of Icertis ID on OA Header.

Volumetrics

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

Performance Considerations

Specify if there are any specific performance factors that need to be taken into consideration during development i.e. enhancement must be able to be executed by 10 users at the same time, etc.

Error Handling

The new program will need to display the output of RETURN table from BAPI_CONTRACT_CHANGE in screen in an ALV so that users can see the status of their operation performed (either successful or with details errors to understand the issues).

Testing

How to Test

Test Conditions and Expected Results

Test Considerations/Dependencies

N/A

Other Information

Development Details

Package

Enhancement Implementation

Other Development Objects

Appendix

Custom Authorization Group Naming Convention

This table is based on the Syensqo development standards document. It provides the naming conventions for authorization groups to associated with custom reports and tables to comply with security requirements.

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log