| Status | |
|---|---|
| Owner | |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
Purpose
The purpose of this document is to define the conversion approach for Quota Arrangements to be uploaded into SAP S/4HANA as part of the Procurement Data Migration. Quota Arrangements are used to determine the distribution of procurement quantities across multiple sources of supply, providing control over vendor sourcing allocations.
---CHECKLIST---
- Logical Source and Target Systems are identified.
- Processing Type is specified (i.e. Direct Input, BAPI, IDoc, Web Service, OData API, etc.)
- Standard or custom load program name/BAPI/IDoc is specified to support this functionality.
- Data Mapping is provided for mappings which are not obvious to a suitably-skilled and experienced developer
- All translation requirements are clearly defined (including data validation rules, data derivation/calculation and default values, if applicable)Input and/or Output file layouts are provided for all record types possible
- Transaction volume is specified Execution frequency is specified Restart/Recovery requirements have been defined
- Error handling requirements are specified, including alerting requirement and expected action on failure.
- Application log requirement if applicable to be specified.
--- Additional topics to check---
- Rules for Data Merging (all systems)
Conversion Scope
This conversion approach covers active and relevant Quota Arrangements maintained at the material, plant, and source (vendor or source list) level. Records from legacy ECC systems (e.g., PF2, WP2) will be extracted, validated, transformed, and loaded into the S/4HANA system.
Only quota entries linked to valid material and vendor combinations and with an active allocation percentage will be considered in scope. Obsolete, deleted, or inactive quota records will be excluded. The harmonization process will align multiple legacy records into a consistent target format.
The data from legacy system includes:
- Materials that are in scope for conversion
- Vendors that are valid and active in the target system
- Quota Arrangements with non-zero quota % and valid plant/material/vendor combinations
- Entries with recent procurement activity (last 3–5 years)
- Quota arrangements for a valid contract.
- Validity dates that are still in the active period.
The data from legacy system excludes:
- Entries falling with a expired validity period - to be checked by the business for valid records that should be extended.
- Obsolete vendors or materials not migrated
- Quotas with zero quota allocation
| Source | Scope | Source Approx No. of Records | Target System | Target Approx No. of Records |
|---|---|---|---|---|
| PF2 | Only open/valid documents will be migrated | 8 (HDR) | S4/Hana | 6(HDR) 4(Item) |
| WP2 | Only open/valid documents will be migrated | Total 206 Validity period active: 20 | S4/Hana | 20(HDR) 38(Item) |
| PF2 | Validity date expired | 2 | |
| WP2 | Validity date expired | 186 | |
| WP2 | Vendor flagged for deletion | 175 |
Quota Arrangement Views to be migrated (if any)
N/A
Predecessor Objects
Business Partners - General (3007) → Business Partners (Vendor)- Intercompany (3027) → Purchase Info Record/Pricing Conditions (1094) → Quota Arrangements (1098) → Operational Contracts (9040) → Purchase Requisitions (9044)
Additional Information
Multi-language Requirement
Descriptions are not applicable for Quota Arrangement, but Plant and Purchasing Organization descriptions may be presented in English and logon language if available.
Document Management
N/A
Legal Requirement
N/A
Special Requirements
Processing Type ETL:
The extraction and transformation will be done by Syniti, while the loading will be executed by a Standard tool of SAP Migration Cockpit.
- E - Extraction: Data will be Extracted from at least two source systems. This process will be executed by Syniti
- T - Transform: Data will be Cleansed by Syensqo / Transformed, Merged, and generate a migration file (CSV - comma delimited) by Syniti
- L - Loading: Data will be Loaded using a custom Z-BAPI, custom function module, or BDC (Batch Data Communication) using MEQ1 that wraps this logic for reusability (no FM / BAPI / IDoc encountered)
Target Design
Quota Arrangement will be loaded into SAP S/4HANA using standard structures:
- Table: QMAT (Quota Arrangement by Material)
- Fields: MATNR, WERKS, LIFNR, KNTTP, KZUST, ANZQU, DATBI, DATAB, etc.
- The data must match the material master, vendor master, and source list configurations.
The technical design of the target for this conversion approach.
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement |
|---|---|---|---|---|---|---|
| EQUK | MANDT | MANDT | Client | CLNT | 3 | Required Key Field - Automatically updated |
| EQUK | MATNR | MATNR | Material Number | CHAR | 18‑40* | Required Key Field - Automatically updated |
| EQUK | WERKS | WERKS_D | Plant | CHAR | 4 | Required Key Field - Automatically updated |
| EQUK | BDATU | QUOBI | Quota arrangement period valid until | DATS | 8 | Required Key Field - Automatically updated |
| EQUK | VDATU | QUOAB | Quota arrangement period valid from | DATS | 8 | Required |
| EQUK | QUNUM | QUNUM | Number of quota arrangement | CHAR | 10 | Automatic |
| EQUK | ERDAT | ERDAT | Date on which record was created | DATS | 8 | Automatic |
| EQUK | ERNAM | ERNAM | Name of person who created the object | CHAR | 12 | Automatic |
| EQUK | SCMNG | SCMNG | Minimum quantity for splitting quota | QUAN | 15.3 | Conditional. Syensqo user need to specify the minimum quantity that a lot must have in order to be apportioned among several sources of supply in the planning run.
|
| EQUK | CHANGEDON | TIMESTAMPL | UTC timestamp when record was changed | DEC | 21 | Automatic |
| EQUP | MANDT | MANDT | Client | CLNT | 3 | Required Key Field - Automatically updated |
| EQUP | QUNUM | QUNUM | Number of quota arrangement | CHAR | 10 | Required Key Field - Automatically updated |
| EQUP | QUPOS | QUPOS | Quota arrangement item number | NUMC | 3 | Required Key Field - Automatically updated |
| EQUP | BESKZ | QBESK | Procurement type | CHAR | 1 | Required. Allowed procurement type will be based on material master data set-up. So if material master is set-up as External procurement, then user can only choose External procurement during quota arrangement creation. |
| EQUP | SOBES | SOBES | Special procurement type | CHAR | 1 | Conditional. If any special procurement such as consignment or subcontracting exist for a supplier, then choose relevant type in this field. |
| EQUP | LIFNR | ELIFN | Vendor account number | CHAR | 10 | Required |
| EQUP | BEWRK | BEWRK | Plant from which material is procured | CHAR | 4 | Not Required. Syensqo will not need quota arrangement for materials provided within internal production plants |
| EQUP | QUOTE | QUOTE | Quota | DEC | 3 | Required in case of multiple suppliers exist for particular material. Quota will be used to identify portion of quantity to be procured from particular supplier. |
| EQUP | QUBMG | QUBAS | Base quantity of quota arrangement item | QUAN | 15.3 | Conditional. Set quota base quantity if to avoid changes in the quantity to be allocated in case new source is added. If quota base quantity is not specified, then system will automatically allocate quantity to supplier(s). |
| EQUP | QUMNG | QUMNG | Allocated quantity of quota arrangement item | QUAN | 15.3 | Conditional |
| EQUP | MAXMG | QUMAX | Maximum quantity of quota arrangement item | QUAN | 15.3 | Conditional |
| EQUP | VERID | VERID | Production version | CHAR | 4 | Conditional |
| EQUP | MAXLS | MAXLS | Maximum lot size per quota item | QUAN | 13.3 | Conditional |
| EQUP | MINLS | MINLS | Minimum lot size per quota item | QUAN | 13.3 | Conditional |
| EQUP | RDPRF | RDPRF | Rounding profile | CHAR | 4 | Conditional |
| EQUP | KZEIN | KZEIM | Once‑only indicator | CHAR | 1 | Conditional |
| EQUP | ABRMG | ABRMG | Maximum release quantity per period | QUAN | 13.3 | Conditional |
| EQUP | ABPER | ABPER | Period related to release quantity | CHAR | 1 | Conditional |
| EQUP | ABANZ | ABANZ | Number of periods for release quantity | NUMC | 2 | Conditional |
| EQUP | PREIH | PREIH | Priority for determination sequence | NUMC | 2 | Conditional |
| EQUP | EMATN | EMATN | Manufacturer part number's material number | CHAR | 18 | Conditional |
| EQUP | PLIFZ | PLIFZ | Planned delivery time in days | DEC | 3 | Conditional |
Data Cleansing
All data cleansing should take place in the data source system as defined in this document, unless system limitations prevent it.
If data cleansing is managed outside of the source system (e.g. Syniti Migrate, 3rd Party Vendor, DCT), the necessary documentation must be produced and appended to this deliverable for sign-off.
| ID | Criticality | Error Message/Report Description | Rule | Output | Source System |
|---|---|---|---|---|---|
| 001 | Medium | Ensure RFQ types (e.g., AN, ANQ) are valid and configured in S/4HANA | - Delete or correct RFQs using types that are not configured in S/4HANA - Map to valid types if migration logic allows | PF2/WP2 | |
| 002 | Medium | Consistent numbering scheme, no duplicates | -Identify duplicates via RFQ number (e.g., EBAN-BANFN or custom RFQ ID) - Keep only one version, preferably the most recent - Renumber only if permitted by target system config | PF2/WP2 | |
| 003 | Medium | RFQ dates (creation, validity from/to) must be consistent and within allowed range | - Correct invalid dates (e.g., validity end before start) - Delete expired RFQs if beyond retention cutoff (e.g., older than 5 years) - Flag records with future-dated creation or unrealistic validity ranges for review | PF2/WP2 | |
| 004 | Medium | Material (MATNR) not in the approved Material Master scope | Delete the line item from the RFQ | PF2/WP2 | |
| 005 | Medium | Material flagged for deletion (MARA–LVORM = X or MM03 deletion flag) | Exclude the RFQ line | PF2/WP2 | |
| 006 | Medium | Material belonging to an obsolete Material Group (MATKL) | Validate with business, likely delete | PF2/WP2 | |
| 007 | Medium | Non-stock/service items without master data in S/4HANA | Exclude or replace with valid alternatives | PF2/WP2 | |
| 008 | Medium | Vendor flagged for deletion or blocked. | Exclude or replace with valid alternatives | PF2/WP2 | |
| 009 | Medium | Quota quantity = 0 | Investigate, exclude or replace with valid quota. | PF2/WP2 | |
| 010 | Medium | Validity periods must be investigated and possibly extended. Format not aligned (31/12/9999 or 31/12/2999 or 31/12/2099) | QA valid to date (EQUK.BDATU) = 31/12/9999 | Investigate and cleanse | PF2/WP2 |
| 011 | Medium | One valid from date was created on 30/06/2023, but the Valid-From date is 02/06/1983. There are 54 records where the Quota Valid-From date is earlier than the QA created date. | EQUK.VDATU < EQUK.ERDAT | Investigate and cleanse | PF2/WP2 |
| 012 | Medium | This is a required field, but the ECC data has some instances where the Supplier is blank. (e.g. Proc Type = E) | EQUP.LIFNR != BLANK | Investigate and cleanse | PF2/WP2 |
Summary of Cleansing
Inactive Materials
Inactive Vendors
Quotas with 0 quantity
Validity end date
Validity to date
Data Governance Rules
| These governance rules apply to the object overall. They relate to the creation, blocking or deletion, or duplicate checks that must be applied. | |||
| Rule # | Activity | Rule description | Validation Method |
| Sample | Change | Change information inhouse bank if necessary | Ongoing Manual |
| 1 | Create | 1) When Syensqo has multiple suppliers providing the same key supplies, Quota Arrangements should be utilized to automate the distribution of work, eliminating the need for manual intervention. This approach minimizes the risk of excessive dependence on a single vulnerable supplier. Quota arrangements are manually created within the S/4 Hana system. 2) A distinct quota arrangement must be established for each specific combination of material and plant. 3) The quota arrangement could be based on contract and / or purchase info records created with supplier. 4) When purchase requisitions are created manually or automatically for these materials, the system selects a supplier according to the predefined quota arrangement. This arrangement is valid for a specific time period and, once expired, will no longer be used to determine the source. | |
| 2 | Create | Quota arrangements are always created against material and plant combination | |
| 4 | Change | Quota arrangements can be changed via S/4 Hana system adopted at Syensqo. Scenarios at Syensqo which trigger updating of Quota arrangement master data: 1) New supplier is identified for the material which needs to be added in the Quota arrangement 2) Contract with the supplier against particular material is renewed for new validity period. Quota arrangement needs to be aligned with the new validity period. 3) Contract with the supplier against particular material is expired and/or new contract is created with separate supplier. Quota arrangement needs to be updated to add new supplier and period. 4) Purchase Info Record with the supplier against particular material is renewed for new validity period. Quota arrangement needs to be aligned with the new validity period. 5) Purchase Info Record with the supplier against particular material is expired and/or new Purchase info record is created with separate supplier. Quota arrangement needs to be updated to add new supplier and period. | |
| 5 | Deletion | If the quota arrangement is no longer required, the quota arrangement validity period can be reduced to past data and allocated quantity/quota can be reduced to zero via the S/4 HANA system adopted at Syensqo | |
| Validation Method | |||
| These validation method apply to the object overall. They relate to the creation, blocking or deletion, or duplicate checks that must be applied. | |||
| Method # | Validation Method | Definition | |
| 1 | Ongoing Manual | Manual checks only by MDO. | |
| 2 | Upfront Automated | SAP validates upon entry. | |
| 3 | Ongoing Automated | Automated method to check data against standards and report KPIs | |
| 4 | Hybrid | Combination of Automated activities and manual intervention in DSP | |
| 5 | Upfront manual/Default on the form | Manual check upon data entry | |
| Field Governance Rules | |||||
| These governance rules apply to the individual fields within the data record. | |||||
| Rule # | Field Label | Rule Description | Validation Method | Conditional Logic | Cleansing Rule |
| Sample | Account ID | The first 3 characters are to represent the currency of bank account number. Please refer to currency codes as per ISO 4217. (https://www.iso.org/iso-4217-currency-codes.html) The fourth and fifth characters are to be sequential starting at 01 ending at 99. | Upfront Manual | ||
| 1 | Quota arrangement number | The Quota arrangement record number is 15 characters and is automatically generated in S4 | Upfront Automated | ||
| 2 | Material | The material no is required to be specified by the user and is validated against relevant Material masters available in S/4 HANA. | Upfront Automated | ||
| 3 | Plant | The plant id is required to be specified by the user and is validated against relevant plants available in S/4 HANA. | Upfront Automated | ||
| 4 | Valid to | The date is updated as the date until the quota arrangement will be kept valid. This needs to be manually inputted. | Upfront Automated | Validity periods must be investigated and possibly extended. Format not aligned (31/12/9999 or 31/12/2999 or 31/12/2099) | |
| 5 | Valid from | The date is updated as the date on which the record was created. Its automatically updated in database basis the record creation date in S/4 HANA. | Upfront Automated | One valid from date was created on 30/06/2023, but the Valid-From date is 02/06/1983. There are 54 records where the Quota Valid-From date is earlier than the QA created date. | |
| 6 | Min. Qty for Splitting Quota | Syensqo user need to specify the minimum quantity that a lot must have in order to be apportioned among several sources of supply in the planning run. Note: The allocation by quota using splitting quotas is only carried out via a requirement planning run. | Upfront manual/Default on the form | No fixed rule. User should populate depending on the quantity to be procured from supplier. | |
| 7 | Quota arrangement item | Uniquely identifies the quota arrangement item within a quota arrangement period. | Upfront manual/Default on the form | ||
| 8 | Procurement Type | At Syensqo, majority of the quota arrangement will be using External procurement as Planning Engine - Kinexis will identify internal procurement requirements. Procurement type indicates procurement that is, in-house manufacture, i.e. "making in", or external procurement, i.e. "buying out" for the quota arrangement item. Values available: - 1) External Procurement 2) Internal Procurement. Allowed procurement type will be based on material master data set-up. So if material master is set-up as External procurement, then user can only choose External procurement during quota arrangement creation. | Upfront Automated | ||
| 9 | Special procurement | At Syensqo, any special procurement exist for material in the quota arrangement against the supplier, then choose relevant type in this field. This field value is optional and if not chosen, then it is considered to be Standard. Values Available:- 1) For External Procurement - Standard, Consignment, Subcontracting, Stock Transfer 2) For Internal Procurement - In house Production, Production in plant | Upfront Automated | Optional field - if not chosen, then value = STANDARD (1). Otherwise either 1) For External Procurement - Standard, Consignment, Subcontracting, Stock Transfer 2) For Internal Procurement - In house Production, Production in plant | |
| 10 | Supplier | The Supplier is a business partner or organization that provides goods or services to your company. At Syensqo, automatic validation of the supplier number will be carried out during creation of Quota Arrangement. | Upfront Automated | This is a required field, but the ECC data has some instances where the Supplier is blank. (e.g. Proc Type = E) | |
| 11 | Procurement Plant | Syensqo will use procurement plant information in quota arrangement for materials sourced from internal production plants. Key for the factory or branch of a company (that is, a company code), from which the material is to be procured. You can only enter one supplier number or one plant per quota arrangement item. In the case of process orders, this field should remain empty if the quota arrangement is being used to select a production version. | Upfront Automated | For materials sourced from internal production plants. Key for the factory or branch of a company (that is, a company code), from which the material is to be procured. You can only enter one supplier number or one plant per quota arrangement item. In the case of process orders, this field should remain empty if the quota arrangement is being used to select a production version. | There are instances where no procurement plant is specified for an internal Procurement type (E) and Special procurement type (E) |
| 12 | Quota | At Syensqo, quota will be needed In case of multiple suppliers exist for particular material. Quota will be used to identify portion of quantity to be procured from particular supplier. | Upfront Automated | No fixed rule. User should populate depending on the quantity to be procured from supplier. | |
| 13 | Quota Base Quantity | At Syensqo, set the quota base quantity manually or have it determined by the system. This controls quantity for a quota arrangement. The quota base quantity regulates the quota arrangement without having to change the quota if, for example, a new source is to be included in the arrangement. | Upfront manual/Default on the form | No fixed rule. User should populate depending on the quantity to be procured from supplier. | |
| 14 | Allocated Quantity | No inputs required. System will keep updating this field in real-time based on allocation. Total quantity procured to date from the quota arrangement item source. This value is updated in planned orders, purchase requisitions, purchase orders, and scheduling agreement delivery schedule lines. | Upfront Automated | ||
| 15 | Maximum quantity | At Syensqo, only provide if there is a need to restrict maximum quantity to be allocated using the quota arrangement to the particular supplier. Once this quantity is allocated, then quota arrangement will not suggest the source. | Upfront manual/Default on the form | ||
| 16 | Production Version | Syensqo will use production versions (if applicable) in case of Internal procurement i.e. material sourced from Syensqo's plant and procurement type is maintained as Internal Procurement. Key which determines the various production techniques according to which a material can be manufactured. The production version determines the following: 1)the BOM alternative for a BOM explosion 2)the task list type, the task list group and the task list group counter for allocation to task lists 3)lot-size restrictions for repetitive manufacturing | Upfront manual/Default on the form | When procurement type is Internal, and the material is sourced from a Syensqo plant. If applicable??? then a production version is used | |
| 17 | Maximum Lot Size | Maximum PO quantity that may be allocated to a source of supply per order proposal in the planning run. If the shortage (undercoverage) quantity exceeds the maximum lot size, the quota system is re-applied to the remaining quantity. At Syensqo, lot size will only be used in case material to be purchased in specified lots from the respective supplier. When material is subject to lot size purchasing and there is a need to provide upper limit of lot size during supplier allocation using quota arrangement. System will create multiple orders if quantity to be purchased is more than maximum lot size. Note: This information will override information maintained in material master data | Upfront manual/Default on the form | No fixed rule. User should populate depending on the quantity to be procured from supplier. | |
| 18 | Minimum Lot Size | Minimum order quantity that may be allocated to a source of supply per order proposal in the planning run. If the shortage (undercoverage) quantity is less than the minimum lot size, the latter quantity will be allocated to the source instead of the former. At Syensqo, lot size will only be used in case material to be purchased in specified lots from the respective supplier. When material is subject to lot size purchasing and there is a need to have lower limit lot size during supplier allocation using quota arrangement, provide minimum lot size quantity. System will create procurement proposal for minimum lot size quantity if requirement quantity if smaller. Note: This information will override information maintained in material master data | Upfront manual/Default on the form | No fixed rule. User should populate depending on the quantity to be procured from supplier. | |
| 19 | Rounding Profile | At Syensqo, when rounding profile is specified, system will create procurement proposal based on the rounding profile. Note: This will take preference over material master information. | Upfront manual/Default on the form | If available in Material master, will be defaulted to this value, otherwise, manual input by user if required. | |
| 20 | Indicator: "Once-Only" | Specifies that a source may only be taken into account once in the apportionment of a lot. This option will avoid situation where multiple procurement proposals will be generated by the system depending upon maximum lot size. At Syensqo, please maintain if needed only when maximum lot size quantity is maintained. | Upfront manual/Default on the form | Only maintained when the maximum lot size is maintained, if needed. | |
| 21 | Max. Release Qty | The maximum release quantity defines the maximum available capacity of a source of supply. At Syensqo, if supplier has provided limit on quantity capacity, then maintain the values. The "maximum release quantity" defines the maximum quantity that a source of supply can make available/supply within a specified timeframe. The maximum release quantity is only taken into account in the planning run within MRP, not when purchase requisitions or planned orders are created manually. | Upfront manual/Default on the form | if supplier has provided limit on quantity capacity, then maintain the values. | |
| 22 | Period for Release Quantity | Period to Which the Release Quantity Relates. At Syensqo, maintain this info if supplier provides the maximum release quantity for a certain period of time. | Upfront manual/Default on the form | maintain this infor if supplier provides the maximum release quantity for a certain period of time | |
| 23 | Number of Periods | In this field, you determine the number of periods for which the maximum release quantity is valid. At Syensqo, when maximum release quantity and period for release quantity are maintained, then maintain number of periods. | Upfront manual/Default on the form | when maximum release quantity and period for release quantity are maintained, then maintain number of periods. | |
| 24 | Priority | This priority will define sequence of source of supply irrespective of quota rating and quota allocated quantity. At Syensqo, maintain priorities based on preference of supplier to be allocated as a source using quota arrangement. | Upfront manual/Default on the form | maintain priorities based on preference of supplier to be allocated as a source using quota arrangement. | |
| 25 | MPN: Material | MPN Material field (Manufacturer Part Number) in Quota Arrangements is relevant if using MPN material procurement — a setup where procurement manufacturer-specific parts under a manufacturer part profile (MPN profile). At Syensqo, MPN material will only be used if quota to be managed at individual MPN material level. There is no need identified at Syensqo. | Upfront manual/Default on the form | MPN material will only be used if quota to be managed at individual MPN material level. There is no need identified at Syensqo | |
| 26 | Planned delivery time in days | Planned Delivery Time in Days field in the Quota Arrangement plays a key role in source determination and scheduling, particularly when you have multiple sources of supply for a material. At Syensqo, maintain planned delivery time at Quota arrangement in case there is a need to override the delivery time maintained in vendor master. | Upfront manual/Default on the form | maintain planned delivery time at Quota arrangement in case there is a need to override the delivery time maintained in vendor master. | |
Conversion Process
The high-level process is represented by the diagram below:
Summarize High-Level Process. Include diagrams, where applicable. Include information supporting details of Extract, Transform and Load specific to the Data Object
Data Privacy and Sensitivity
Summarize Data Privacy and Sensitivity Requirements, if anyExtraction
Extract data from a source into Syniti Migrate. There are 2 possibilities:
- The data exists. Syniti Migrate connects to the source and loads the data into Syniti Migrate. There are 3 methods:
- Perform full data extraction from relevant tables in the source system(s).
- Perform extraction through the application layer.
- Only if Syniti Migrate; cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
- The data does not exist (or cannot be converted from its current state). The data is manually collected by the business directly in Syniti Migrate. This is to be conducted using DCT (Data Collection Template) in Syniti Migrate
The agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads
Extraction Run Sheet
| Req # | Requirement Description | Team Responsible |
|---|---|---|
| 001 | The material exists and is in scope | Syniti Team |
| 002 | The plant exists and is in scope | Syniti Team |
| 003 | The vendor is active and valid | Syniti Team |
| 004 | The quota is > 0 | Syniti Team |
| 005 | The record is not marked for deletion | Syniti Team |
| 006 | The record has not expired (DATBI >= current date) | Syniti Team |
| 007 | Select records where EQUK-ERDAT >= 01.01.2023 | Syniti Team |
Selection Screen
If applicable, this section will give the details on any selection screen parameters, including the parameter type, that are required to be entered to ensure consistent data extracts.| Selection Ref Screen | Parameter Name | Selection Type | Requirement | Value to be entered/set |
|---|---|---|---|---|
| N/A | ||||
Data Collection Template (DCT)
Target Ready Data Collection Template will be created for Data Object data with exception of some fields which require transformation as mentioned in the transformation rule.<Object> DCT Rules
| Field Name | Field Description | Rule |
|---|---|---|
| N/A TBC | ||
Extraction Dependencies
Quota Arrangements depend on the successful migration of the following objects:
| Item # | Step Description | Team Responsible |
|---|---|---|
| 001 | Material Master | S2P |
| 002 | Vendor Master | S2P |
| 003 | Source List (EORD) - TBC | S2P |
| 004 | Purchasing Info Records | S2P |
These must be loaded prior to the execution of Quota Arrangement upload.
Transformation
The Target fields are mapped to the applicable Legacy field that will be its source, this is a 3-way activity involving the Business, Functional team and Data team. This identifies the transformation activity required to allow Syniti Migrate to make the data Target ready:
- Perform value mapping and data transformation rules.
- Legacy values are mapped to the to-be values (this could include a default value)
- Values are transformed according to the rules defined in Syniti Migrate
- Prepare target-ready data in the structure and format that is required for loading via prescribed Load Tool. This step also produces the load data ready for business to perform Pre-load Data Validation
Transformation will involve harmonizing supplier codes, plant IDs, and units of measure across systems. Where multiple legacy entries exist for the same material/plant, the most recent or business-prioritized record will be retained.
Quota percentage (ANZQU) will be recalculated if source values are inconsistent or incomplete. Date fields will be reformatted to YYYYMMDD and adjusted to cover valid procurement windows.
Transformation Run Sheet
| Item # | Step Description | Team Responsible |
|---|---|---|
| 1 | Release - Load signoff and go-ahead by Functional/Data Owner | Functional/Data Owner - S2P |
| 2 | Approval to stage/Pre-stage steps | Functional/Data Owner - S2P |
| 3 | Cross references | Developer - Syniti or Data Specialist - S2P |
| 4 | Extraction from source | Developer - Syniti or Data Specialist - S2P |
| 5 | Extraction from S4 where needed | Developer - Syniti or Data Specialist - S2P |
| 6 | Stage data for transformations | Developer - Syniti or Data Specialist - S2P |
| 7 | Run transforms | Developer - Syniti or Data Specialist - S2P |
| 8 | Execute pre-load report | Data Specialist/Functional - S2P |
| 9 | Validate preload report - release | Data Specialist/Functional - S2P |
| 10 | Prepare and simulate | Data Specialist - S2P |
| 11 | Pre-load verification and approval to load | Functional/Data Owner - S2P |
| 12 | Load to S4 | Data Specialist - S2P |
| 13 | Complete Jira steps, Volumes and Timings | All - where applicable |
| 14 | Execute post-load report | Developer - Syniti or Data Specialist - S2P |
| 15 | Post-load report verification/validation | Data Specialist/Functional/Data Owner - S2P |
| 16 | Object load completion approval | Data Owner - S2P |
Transformation Rules
| Rule # | Source system | Source Table | Source Field | Source Description | Target System | Target Table | Target Field | Target Description | Transformation Logic |
|---|---|---|---|---|---|---|---|---|---|
| 1 | PF2/WP2 | EQUK | BDATU | Valid end date | S4H | EQUK | BDATU | Valid end date | If data format = 31/12/2099 or 31/12/2999, transform to 31/12/9999 |
| 2 | PF2/WP2 | EQUK | VDATU | Valid from date | S4H | EQUK | VDATU | Valid from date | One valid from date was created on 30/06/2023, but the Valid-From date is 02/06/1983. There are 54 records where the Quota Valid-From date is earlier than the QA created date. Valid From date = Create date where Valid From date> Create date |
Transformation Mapping
Use the exact name and reference this section in the “Transformation rules” above| Mapping Table Name | Mapping Table Description |
|---|---|
| Material | XREF |
| Plant | XREF |
| Supplier | XREF |
Transformation Dependencies
List the steps that need to occur before transformation can commence| Item # | Step Description | Team Responsible |
|---|---|---|
| 1 | MM - Purchase info record settings and data is migrated into the target system | S2P/Syniti |
| 2 | PV - Production version settings and data is migrated into the target system (if PV's are being used) | S2P/Syniti |
| 3 | Product - Check that settings and data is migrated into the target system | S2P/Syniti |
| 4 | Supplier - Check that settings and data is migrated into the target system | S2P/Syniti |
Pre-Load Validation
Project Team
The following pre-load validations will be performed by the Project Team.Completeness
| Task | Action |
|---|---|
Verify count | The number of records presented after relevancy checks and validation needs to be correct compared to the staged data in dspMigrate |
Completeness check | All fields required as per mapping template rules must be completed. Validity reports checking each field in DSP must be built. |
Accuracy
| Task | Action |
|---|---|
Conversion accuracy | Data team to verify that the data staged in the preload tables are correct in terms of the mapping rules. This will be done via Syniti DSP reports. |
Business
The following pre-load validations will be performed by the business.Completeness
| Task | Action |
|---|---|
Count and Completeness check | All fields required as per mapping template rules must be completed. Validity reports checking each field in DSP must be built to help check. |
Accuracy
| Task | Action |
|---|---|
Conversion accuracy | Business team to verify that the data staged in the preload tables are correct in terms of the mapping rules. This will be done via Syniti DSP reports/SAP reports |
Load
The load process includes:
- Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation;
- The data will be loaded using SAP LSMW leveraging BAPI_QUOTA_CREATE. No standard Migration Cockpit object exists for quota arrangements.
- The BAPI supports creation of records based on target-aligned templates. Staging Tables or Source Files will be handled by Syniti.
Load will occur in mock and production phases, with logs captured and reviewed for consistency, completeness, and errors.
As part of the Loading Strategy, the data will be loaded using SAP LSMW leveraging BAPI_QUOTA_CREATE. No standard Migration Cockpit object exists for quota arrangements. The BAPI supports creation of records based on target-aligned templates. Staging will be handled by Syniti.
Load will occur in mock and production phases, with logs captured and reviewed for consistency, completeness, and errors.
Load Run Sheet
| Item # | Step Description | Team Responsible |
|---|---|---|
| Material | Check applicable materials loaded | Syniti/S2P |
| Vendor | Check applicable suppliers loaded | Syniti/S2P |
| Plants | Check applicable plants loaded | Syniti/S2P |
Load Phase and Dependencies
Identify the phase as to “when” the load for this object will occur. <Pre-Cutover, Cutover, Post Cutover> and list the steps that need to occur before the load can commence
Configuration
List the Configurations required before loading can commence
| Item # | Configuration Item |
|---|---|
| 1 | Vendors BP's - Check that this is loaded in target system |
| 2 | Materials - Check that this is loaded in target system |
| 3 | Plants - Check that this is loaded in target system |
Conversion Objects
| Object # | Preceding Object Conversion Approach |
|---|---|
| 1 | Purchase Info Record/Pricing Conditions (1094) |
Error Handling
The table below depicts some possible system errors for this data object during data load. All data load error is to be logged as defect and managed within the Defect Management
| Error Type | Error Description | Action Taken |
|---|---|---|
| Data | Vendor blocked for the material in the Source List - no source determined | Either exclude the Quota record, or unblock the Vendor |
| Config | Quota number ranges not correct | Internal numbering must be set. |
| Pre-req | Missing PIR records - vendor has no corresponding info record, cannot be included in quota | Create missing PIR or exclude quota record |
| Data | Incorrect quota arrangement values | Fix incorrect data or missing entries |
| Data | Missing quota base quantities | Fix incorrect data or missing entries |
| Data | Incorrect allocated quantities | Fix incorrect data or missing entries |
| Data | Missing material master purchasing view settings. | Fix incorrect data or missing entries |
| Load | Cannot sue LSMW with a simple BDC recording for a multi-line item scenario | Ensure the LSMW is built correctly, using a BAPI. |
Post-Load Validation
Project Team
The following post-load validations will be performed by the Project Team.Completeness
| Task | Action |
|---|---|
Verify count | The number of records presented in the preload needs to be compared to the postload. – Syniti report |
Accuracy
| Task | Action |
|---|---|
Conversion accuracy | Data team to verify that the data staged in the preload tables are correct in terms of the mapping rules. This will be done via Syniti DSP reports/SAP reports |
| Load failures | Value presented for load must be in the system |
Business
The following post-load validations will be performed by the business.Completeness
| Task | Action |
|---|---|
Verify count | The number of records presented in the preload needs to be compared to the postload. – Syniti report |
Accuracy
| Task | Action |
|---|---|
Conversion accuracy | Business team to verify that the data staged in the preload tables are correct in terms of the mapping rules. This will be done via Syniti DSP reports/SAP reports |
| Load failures | Value presented for load must be in the system |
Key Assumptions
- Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
- Data Object is in scope based on data design and any exception requested by business.
Any additional key assumptions.
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.