| 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 to upload data in S/4 HANA.
Summarise how the data is currently utilized and set up in the legacy system/s and how object is intended to be represented in S/4, and any other relevant information
Conversion Scope
The scope of this document covers the approach for converting active Purchasing Info Records from legacy SAP ECC systems (PF2, WP2) into SAP S/4HANA, following the Procurement Master Data Design Standard.
For Syensqo, Info Records will be migrated to support operational purchasing, sourcing strategies, and integration with Ariba. These records will be validated, cleansed, and created centrally using the defined template and mapped fields.
From the current system landscape, Info Record data exists separately in the legacy systems (PF2 and WP2), with potential discrepancies in vendors, materials, pricing conditions, or purchasing organizations. Harmonization and validation are required to ensure accurate and consolidated data in S/4HANA. While PF2 and WP2 serve as source systems, extensive mapping and transformation logic will be necessary to produce properly formatted load templates in line with the target design.
The data from legacy system includes:
- Uncleansed data with Duplicated records
The data from legacy system excludes:
- EINA-LOEKZ - General Record marked for deletion
- EINE-LOEKZ - Purchasing Organization marked for deletion
- Vendors that are marked for deletion and are part of an Info Record
- Materials that are marked for deletion and are part of an Info Record
- Materials / Vendors / Plants that are Out of Scope
| Source | Scope | Source Approx No. of Records | Target System | Target Approx No. of Records |
|---|---|---|---|---|
PF2 | The Purchasing Info Records will be extracted/collected via DCT. An initial extract of the relevant data will be provided in Google Sheet format to assist business in decision making on including any relevant data from Source Systems. Any additional data that need to be created to support the new design may be added in the DCT. A data review and standardization will be done across all Info Records in the DCT. | 125,000 | S4H | 125,000 |
WP2 | S4H | |||
WXP | S4H |
Additional Information
Multi-language Requirement
Purchasing Info Records (PIRs) themselves do not directly support multiple languages within the same record. However, texts associated with an Info Record, such as purchase order texts, info record texts, or material descriptions, can be maintained in multiple languages. In that case the following languages can be applied:
International Version | Description |
C | Simplified Chinese |
R | Cyrillic |
K | Kanji (Japanese) |
A | Arabic |
3 | Korean |
T | Thai |
H | Hangul |
Document Management
Summarize Document Management requirement, if any
Legal Requirement
Legal requirements might be
Special Requirements
Specify any special requirements or considerations that may impact the data conversion process based on specific locations, regulatory compliance or system limitations. Clearly outline any regional or localization requirements such as country-specific data formats, legal reporting obligations or industry standards that must be adhered to (e.g., localization rules for countries like China).
If the data conversion involves third-party systems or external data sources, such as Icertis, describe any additional requirements related to data mapping, transformation logic, validation rules or security measures that must be followed.
Target Design
With Functional input, document the technical design of the target fields that are in the scope of this document.
The technical design of the target for this conversion approach.
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement |
|---|---|---|---|---|---|---|
S_EINA | INFNR | Legacy Number of Purchasing Info Record | Text | 80 | mandatory for sheet | |
S_EINA | MATNR | Product Number | Text | 80 | Deduplication Criteria for Info Records Criteria / Field: Vendor Number (LIFNR) + Material Number (MATNR) Match Type: Exact match (subjected to conversion) Context: Key combination for identifying Info Record duplicates | |
S_EINA | MATKL | Product Group | Text | 80 | ||
S_EINA | LIFNR | Supplier's Account Number | Text | 80 | mandatory for sheet Deduplication Criteria for Info Records Criteria / Field: Vendor Number (LIFNR) + Material Number (MATNR) Match Type: Exact match (subjected to conversion) Context: Key combination for identifying Info Record duplicates | |
S_EINA | TXZ01 | Short Text for Purchasing Info Record | Text | 40 | Optional | |
S_EINA | SORTL | Sort Term for Non-Stock Info Records | Text | 10 | Optional | |
S_EINA | MEINS | Order Unit (ISO Format) | Text | 80 |
| |
S_EINA | UMREZ | Numerator for Conversion of Order Unit | Number | 5 | Optional | |
S_EINA | UMREN | Denominator for Conversion of Order Unit | Number | 5 | Optional | |
S_EINA | IDNLF | Product Number Used by Supplier | Text | 35 | Optional | |
S_EINA | VERKF | Salesperson Responsible | Text | 30 | Optional | |
S_EINA | TELF1 | Supplier's Telephone Number | Text | 16 | Optional | |
S_EINA | MAHN1 | Days for First Reminder/Expediter | Number | 3 | Optional | |
S_EINA | MAHN2 | Days for Second Reminder/Expediter | Number | 3 | Optional | |
S_EINA | MAHN3 | Days for Third Reminder/Expediter | Number | 3 | Optional | |
S_EINA | LMEIN | Base Unit of Measure (ISO Format) | Text | 80 | Optional | |
S_EINA | VABME | Variable Purchase Order Unit Active | Text | 80 | Optional | |
S_EINAOptional | WGLIF | Supplier Product Group | Text | 18 | Optional | |
S_EINA | KOLIF | Prior Supplier | Text | 80 | Optional | |
S_EINA | URZLA | Country/Region of Origin | Text | 80 | Optional | |
S_EINA | REGIO | Region | Text | 80 | Optional | |
S_EINA | MFRNR | Manufacturer | Text | 80 | Optional | |
S_EINA | LIFAB | Available (Deliverable) From | Date | 8 | Deduplication Criteria for Info Records Criteria / Field: Available (LIFAB to LIFBI) Match Type: Overlapping / Redundant Context: Overlaps with same values may indicate duplicates; date ranges must be validated. | |
S_EINA | LIFBI | Available (Deliverable) Until | Date | 8 | Deduplication Criteria for Info Records Criteria / Field: Available (LIFAB to LIFBI) Match Type: Overlapping / Redundant Context: Overlaps with same values may indicate duplicates; date ranges must be validated. | |
S_EINA | RELIF | Indicator: Regular Supplier | Text | 1 | ||
S_EINA_TEXT | INFNR | Legacy Number of Purchasing Info Record | Text | 80 | mandatory for sheet | |
S_EINA_TEXT | TDSPRAS | Language Key | Text | 80 | mandatory for sheet | |
S_EINA_TEXT | TEXT | Text | Text | unrestricted | mandatory for sheet | |
S_EINE | INFNR | Legacy Number of Purchasing Info Record | Text | 80 | mandatory for sheet | |
S_EINE | EKORG | Purchasing Organization | Text | 80 | mandatory for sheet | |
S_EINE | ESOKZ | Purchasing Info Record Category | Text | 80 | mandatory for sheet Deduplication Criteria for Info Records Criteria / Field: Info Category (ESOKZ) Match Type: Exact Context: Different categories (Standard, Subcontracting, Pipeline, Consignment) should not be merged | |
S_EINE | WERKS | Plant | Text | 80 | Mandatory if plant-specific Info Records are used (Plant-specific flag is active in config) Deduplication Criteria for Info Records Criteria / Field: Plant (WERKS) Match Type: Exact match (subjected to conversion) Context: Relevant criteria when using plant-specific info records (EINE) | |
S_EINE | EKGRP | Purchasing Group | Text | 80 | Optional | |
S_EINE | WAERS | Currency Key(ISO Format) | Text | 80 | Deduplication Criteria for Info Records Criteria / Field: Currency (WAERS) Match Type: Exact Context: Currency mismatch may indicate different sourcing. | |
S_EINE | MINBM | Minimum Purchase Order Quantity | Number | 13 | Optional | |
S_EINE | NORBM | Standard Purchase Order Quantity | Number | 13 | mandatory for sheet | |
S_EINE | APLFZ | Planned Delivery Time in Days | Number | 3 | Optional | |
S_EINE | UEBTO | Overdelivery Tolerance Limit | Number | 3 | Optional | |
S_EINE | UEBTK | Indicator:Unlimited Overdelivery Allowed | Text | 1 | Optional | |
S_EINE | UNTTO | Underdelivery Tolerance Limit | Number | 3 | Optional | |
S_EINE | BWTAR | Valuation Type | Text | 10 | Optional | |
S_EINE | MTXNO | Ind: Prod. Master Rec. PO Text Not Rele. | Text | 1 | Optional | |
S_EINE | WEBRE | Indicator: GR-Based Invoice Verification | Text | 1 | Optional | |
S_EINE | KZABS | Ind: Order Acknowledgment Requirement | Text | 1 | Optional | |
S_EINE | MWSKZ | Tax on Sales/Purchases Code | Text | 80 | Optional | |
S_EINE | TXDAT_FROM | Valid-From Date of the Tax Rate | Date | Optional | ||
S_EINE | EVERS | Shipping Instructions | Text | 80 | Optional | |
S_EINE | BSTAE | Confirmation Control Key | Text | 80 | Optional | |
S_EINEOptional | XERSN | Ind: No Evaluated Receipt Settlem. (ERS) | Text | 1 | Optional | |
S_EINE | MHDRZ | Minimum Remaining Shelf Life | Number | 4 | Optional | |
S_EINE | IPRKZ | Period Ind. for Min. Remain. Shelf Life | Text | 80 | Optional | |
S_EINE | BSTMA | Maximum Purchase Order Quantity | Number | 13 | Optional | |
S_EINE | EXPRF_LAND1 | Foreign Trade: Country/Region | Text | 80 | Optional | |
S_EINE | EXPRF | Foreign Trade: Procedure | Text | 80 | Optional | |
S_EINE | RDPRF | Rounding Profile | Text | 80 | Optional | |
S_EINE | VENDOR_RMA_REQ | Supplier RMA Number Required | Text | 80 | Optional | |
S_EINE | AUT_SOURCE | Relevant for Automatic Sourcing | Text | 80 | Optional | |
S_EINE | SKTOF | Ind: Item Does Not Qualify for Cash Disc | Text | 1 | Optional | |
S_EINE | MEPRF | Price Determinat. (Pricing) Date Control | Text | 80 | Optional | |
S_EINE | INCOV | Incoterms Version | Text | 80 | Optional | |
S_EINE | INCO1 | Incoterms | Text | 80 | Mapping Table: Execute a mapping in order to identify the relevant Incoterm to be used This document (page 11) contains the valid Incoterms to be used: https://docs.google.com/document/d/1tlduZgiMCNiqAjiUA29J-KfihW7hPWAe/edit?tab=t.0 | |
S_EINE | INCO2_L | Incoterms Location 1 | Text | 70 | Most of the incoterms make this field mandatory. In case the source is empty for this field, raise an error in a report. List of necessary Incoterms Location | |
S_EINE | INCO3_L | Incoterms Location 2 | Text | 70 | Optional | |
S_COND | INFNR | Legacy Number of Purchasing Info Record | Text | 80 | mandatory for sheet | |
S_COND | EKORG | Purchasing Organization | Text | 80 | mandatory for sheet | |
S_COND | ESOKZ | Purchasing Info Record Category | Text | 80 | mandatory for sheet | |
S_COND | WERKS | Plant | Text | 80 | Mandatory if plant-specific Info Records are used (Plant-specific flag is active in config) | |
S_COND | KOPOS | Condition Sequence Number | Number | 2 | mandatory for sheet | |
S_COND | COND_TYPE | Condition Type | Text | 80 | mandatory for sheet | |
S_COND | VALID_FROM | Valid From | Date |
| mandatory for sheet | |
S_COND | VALID_TO | Valid To | Date |
| mandatory for sheet | |
S_COND | KRECH | Calculation Type | Text | 80 | Optional | |
S_COND | KBETR_EXT | Amount | Number | 31 | Optional Deduplication Criteria for Info Records Criteria / Field: Net Price (NETPR) for Condition PB00 Match Type: Numeric match / tolerance Context: Tolerate small differences (e.g., ±1%) due to rounding across systems | |
S_COND | KONWA | Condition Unit (Currency or Percentage) | Text | 80 | mandatory for sheet | |
S_COND | KPEIN | Condition Pricing Unit | Number | 5 | mandatory for sheet | |
S_COND | KMEIN | Condition Unit of Measure ISO | Text | 80 | mandatory for sheet | |
S_COND | KUMZA | Numerator for Conversion | Number | 5 | Optional | |
S_COND | KUMNE | Denominator for Conversion | Number | 5 | Optional | |
S_COND | MEINS | Base Unit of Measure ISO | Text | 80 | Optional | |
S_COND | KONMS | Condition Scale Unit of Measure ISO | Text | 80 | Optional | |
S_COND | EXCLUSION_IND | Condition Exclusion Indicator | Text | 80 | Optional | |
S_SCALES | INFNR | Legacy Number of Purchasing Info Record | Text | 80 | mandatory for sheet | |
S_SCALES | EKORG | Purchasing Organization | Text | 80 | mandatory for sheet | |
S_SCALES | ESOKZ | Purchasing Info Record Category | Text | 80 | mandatory for sheet | |
S_SCALES | WERKS | Plant | Text | 80 | Optional | |
S_SCALES | KOPOS | Condition Sequence Number | Number | 2 | mandatory for sheet | |
S_SCALES | COND_TYPE | Condition Type | Text | 80 | mandatory for sheet | |
S_SCALES | VALID_FROM | Valid From | Date |
| mandatory for sheet | |
S_SCALES | VALID_TO | Valid To | Date |
| mandatory for sheet | |
S_SCALES | LINE_NO | Scale Item Number | Number | 4 | mandatory for sheet | |
S_SCALES | KSTBM | Scale Quantity | Number | 15 | Optional | |
S_SCALES | KBETR | Scale Rate | Number | 31 | Optional | |
S_SCALES | SCALE_VAL | Scale Value | Number | 28 | Optional | |
S_SCALES | KBETR_VAL | Scale Rate | Number | 31 | Optional | |
S_EINE_TEXT | INFNR | Legacy Number of Purchasing Info Record | Text | 80 | mandatory for sheet | |
S_EINE_TEXT | EKORG | Purchasing Organization | Text | 80 | mandatory for sheet | |
S_EINE_TEXT | ESOKZ | Purchasing Info Record Category | Text | 80 | mandatory for sheet | |
S_EINE_TEXT | WERKS | Plant | Text | 80 | Optional | |
S_EINE_TEXT | TDSPRAS | Language Key | Text | 80 | mandatory for sheet | |
S_EINE_TEXT | TEXT | Text | Text | unrestricted | mandatory for sheet |
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 |
|---|---|---|---|---|---|
1094-001 | C1 | PIR missing in required Purchase organisation/Plant | 1) For all Procured materials PIR should be created, identify the recods not having a PIR | ||
1094-002 | C1 | Duplicate PIRs should be removed | 1) Identify duplicate PIR's using the following criteria: | ||
1094-003 | C1 | Valid Period | 1) Only migrate PIRs with valid future dates. Like the Valid To date is in the future or not expired | ||
1094-004 | C1 | Missing Core Data | 1) Investigate/Exclude PIRs missing critical fields such as Vendor, Material, Purchase org, Plant, Info record type, Prices and conditions. Tolerance limits, Planned delivery time | ||
1094-005 | C2 | Archiving Indicator | 1) Exclude from selection of PIRs the ones marked for deletion or archiving | ||
1094-006 | C2 | Compare Supplier and PIR validity period/condition | 1) Exclude PIRs from the selection when the Vendor or Material is marked for deletion | ||
1094-007 | C2 | Check validity period of Purchasing Price (PB00) | 1) Check whether the Purchasing Price condition (PB00) has a valid From/To period (the range must include today's date). If the period is not within the valid range, skip the record and do not create it. | ||
1094-008 | C1 | Exclude records where the material is not active and/or Vendor is not active | 1) Exclude records where the material and Vendor is not active, | ||
1094-009 | C2 | PIR's without materials | 1) PIR without material is only allowed where the material is an indirect material. (Is this so in this project) | ||
1094-010 | C2 | PIR Intercompany in scope | 1) Vendor in info record must be the vendor assigned with supplying plant |
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 | Extract data from source system based on relevancy rule | SyWay Data Team |
002 | Google Sheet report pre-populated with PF2 and WP2 information to be generated based on relevancy criteria. | SyWay Data Team |
003 | Extract data from source system based on relevancy rule | SyWay Data Team |
004 | Google Sheet report pre-populated with PF2 and WP2 information to be generated based on relevancy criteria. | SyWay Data Team |
005 | Only extract data that is NOT marked for deletion Where: EINA-LOEKZ <> ”” | SyWay Data Team |
006 | Only extract records that are still valid Where: EINA-LIFBI >= Today’s date | SyWay Data Team |
007 | Extract Info Records for Vendors that are NOT marked for deletion and are part of an Info Record | SyWay Data Team |
008 | Extract Info Records for Vendors that are in scope | SyWay Data Team |
009 | Extract Info Records for Materials that are NOT marked for deletion and are part of the respective Info Record | SyWay Data Team |
| 010 | Extract Info Records for Materials that are in scope | SyWay Data Team |
| 011 | Extract Info Records for Plants that are in scope. Do this check when EINE-WERKS is different than initial | SyWay Data Team |
Selection Screen
A Target Ready Data Collection Template will be created for the required data, except for fields that need transformation as per the defined transformation rules. These templates will follow the format required by the target S/4HANA Info Record & Purchasing Pricing Configuration.| Selection Ref Screen | Parameter Name | Selection Type | Requirement | Value to be entered/set |
|---|---|---|---|---|
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.The creation of Data collection template must be aligned with the field status of Info Record + Calculation Schema (configurations) for Condition types, Access sequence and Associated Condition Tables. For now, the following Template is prepared based on Pricing Configurations from S/4HANA Sandbox environment. This will be replaced once the pricing configuration is ready.
| Field Name | Field Description | Rule |
|---|---|---|
Extraction Dependencies
List the steps that need to occur before extraction can commence
| Item # | Step Description | Team Responsible |
|---|---|---|
001 | Vendor - The Info Record is created for a specific vendor, therefore the vendor must exist and be active | S2P |
002 | Material - The Info Record is for a specific material, therefore the material must exist and be active | S2P |
003 | Purchasing Organization - Mandatory organizational level (configuration). Must be valid for both the vendor and material | S2P |
004 | Plant (optional) - If a plant-specific Info Record is used, the plant must be valid (included on scope) and maintained | FICO |
005 | Currency & UoM - Must align with vendor master and material master data | S2P |
006 | Tax Code - Should exist in system and be consistent with vendor's country and plant region | S2P |
007 | Conditions - Purchasing conditions (price, discounts, scales) are typically stored in condition records. Linked to Info Records via condition tables | S2P |
008 | Vendor Master Settings - The vendor must have the purchasing organization maintained in purchasing view | S2P |
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 Run Sheet
| Item # | Step Description | Team Responsible |
| 1 | Identify target S/4HANA fields and determine applicable legacy source fields from both ECC systems WP2, PF2 | Functional Team (L2C)+ Data Team (L2C) |
| 2 | Review condition types and access tables used in each ECC source systems WP2, PF2 | Business Team + Functional Team (L2C) |
| 3 | Map legacy field values to S/4HANA target values (including field-level mapping and technical names) | Data Team (L2C), Data Team (Syniti) |
| 4 | Define value mapping rules for fields requiring standardization or harmonization across the two source systems WP2, PF2 (i.e., USD, US$ mapped to USD, and ZD01 and ZDISC from ECC system mapped to ZD01 etc., | Functional Team (L2C)+ Data Team (L2C) |
| 5 | Identify and agree on default values where legacy data is incomplete or inconsistent | Business Team + Functional Team (L2C) |
| 6 | Configure transformation rules in Syniti Migrate (including calculated fields, formatting rules, etc.) | Data Team (Syniti), Data Team (L2C) |
| 7 | Review transformation logic and mappings with Business for confirmation | Business Team + Functional Team (L2C) |
| 8 | Perform initial transformation run and generate draft target-ready dataset | Data Team (Syniti), |
| 9 | Review draft target-ready data for structure and completeness | Data Team (L2C), Functional Team (L2C) |
| 10 | Share transformed data with Business for Pre-load Validation | Business Team |
| 11 | Incorporate feedback from Business and refine mappings or transformation logic as needed | Data Team (L2C) |
| 12 | Finalize and approve transformed data as Target Ready Load File | Business + Functional (L2C) + Data Team (L2C) |
| 13 | Handover final file to Load Team or trigger the load via Syniti Load Workbench | Data Team (Syniti), Data Load Team |
Transformation Rules
| Rule # | Source system | Source Table | Source Field | Source Description | Target System | Target Table | Target Field | Target Description | Transformation Logic |
|---|---|---|---|---|---|---|---|---|---|
Transformation Mapping
Use the exact name and reference this section in the “Transformation rules” above| Mapping Table Name | Mapping Table Description |
|---|---|
Transformation Dependencies
List the steps that need to occur before transformation can commence| Item # | Step Description | Team Responsible |
|---|---|---|
Pre-Load Validation
Project Team
The following pre-load validations will be performed by the Project Team.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Business
The following pre-load validations will be performed by the business.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Load
The load process includes:
- Execute the automated data load into target system using load tool or product the load file if the load must be done manually
- Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation
Load Run Sheet
| Item # | Step Description | Team Responsible |
|---|---|---|
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 |
|---|---|
Conversion Objects
| Object # | Preceding Object Conversion Approach |
|---|---|
| list the exact title of the conversion object of only the immediate predecessor – this will then confirm the DDD (Data Dependency Diagram) | |
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 |
|---|---|---|
Post-Load Validation
Project Team
The following post-load validations will be performed by the Project Team.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Business
The following post-load validations will be performed by the business.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
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.