| Status | Revision in Progress |
|---|---|
| Owner | |
| Stakeholders |
| Team Involved | Area |
| Metawat Sawasdee | Business |
| Technical | |
| Laura Santamarta | Functional |
| Functional |
Purpose
The purpose of this document is to define the conversion approach to migrate Vendor Doc Attachments to S/4 HANA.
This allows to associate relevant documents, like contracts or certifications, with specific vendors.
Attachment Functionality at Syensqo
The GOS functionality is set up to store documents into an ECM (Enterprise Content Management) system. This is a separate system from ECC and S4/HANA, but is natively integrated to ECC.
Assumption
KDD085 recommends the use of OpenText ECM for storage of documents attached to transactions in SAP, e.g. via GOS if supported. The KDD doesn't cover whether this should be a new instance of ECM, or reuse the existing ECM, or implement a totally new SaaS offering from OpenText; this is a more complex topic which also requires consideration of regulatory requirements and cybersecurity, which needs a separate design document.
However this determines what kind of migration is needed - for example do we leave the documents in-situ and only migrate the open items from ECC and their metadata links? Or do we also need to physically move the documents as well?
Open Points:
1) Jira PDM-543
PDM-543 - Getting issue details... STATUS
2) Jira ticket what 'Documents' should be attachments? Jira Ticket PDM-688
PDM-688 - Getting issue details... STATUS
Key tables for Attachments are:
| Table | Name | What is the table for? | To be included in migration? |
| SRGBTBREL | Relationship Table for GOS Objects | This table links the GOS Object (like a vendor) to the actual attached document, storing the object type, instance ID, and document details. | YES |
| SOOD | Object definition | The SOOD table consists of various fields, each holding specific information or linking keys about SAPoffice: Object definition data available in SAP. These include OBJTP (Code for document class), OBJYR (Object: Year from ID), OBJNO (Object: Number from ID), OBJLA (Language in Which Document Is Created). | YES |
| TOJTB | Business object repository: Basic data | The TOJTB table consists of various fields, each holding specific information or linking keys about Business object repository: Basic data data available in SAP. These include ACTIVE (Object type generated), ACTIVELANG (Language Key), PARENT (Supertype), PROGNAME (Implementation program)... | TBC |
| SOFFCONT1 | SOFF: Table for Document Contents (import/export) | The SOFFCONT1 table consists of various fields, each holding specific information or linking keys about SOFF: Table for Document Contents (import/export) data available in SAP. These include RELID (Region in IMPORT/EXPORT Data Table), PHIO_ID (Physical document), SRTF2 (Next record counter in EXPORT/IMPORT data tables), PH_CLASS (Physical document class) | TBC |
| MDOBLREL | Model data: Relationship types | The MDOBLREL table consists of various fields, each holding specific information or linking keys about Model Data: Relationship Types data available in SAP. These include ROLEA (Role That an Object Takes in the Relationship), ROLEB (Role That an Object Takes in the Relationship), CARDA (Role Cardinality), CARDB (Role Cardinality) | TBC |
| LFA1 | Vendor master (General Section) | GOS info is linked to this table | NO |
| LFB1 | Vendor master (Company Code) | GOS info is linked to this table | NO |
| LFM1 | Vendor master record purchasing organization data | GOS info is linked to this table | NO |
Relevant T-Codes for extraction
| Vendor Type | Tcode | Function Module (Mass extraction) | Instuctions |
|---|---|---|---|
| Finance | FB03 | BDS_GOS_CONNECTIONS_GET SO_OBJECT_READ |
|
| General | XK03 |
|
Finance Vendors:
T-code FB03
All Vendors:
T-code XK03
Function Modules
BDS_GOS_CONNECTIONS_GET
SO_OBJECT_READ
TABLE LINKS
Link between the SOOD and SRGBTREL tables.
SRGBTBREL's INSTID_B field, often by parsing it to extract the document type, year, and number, to then retrieve the corresponding record from the SOOD table.
Identify the Attachment Link:
In the SRGBTBREL table, the fieldsINSTID_AandTYPEID_Aidentify the business object (e.g., a sales order), andINSTID_Bidentifies the attachment.Parse the Attachment Information:
TheINSTID_Bfield in SRGBTBREL contains the key information for the SOOD table. This field needs to be parsed to extract the document's attributes, including:Link to SOOD:
Use the parsed values to find the corresponding record in the SOOD table.SOOD-OBJTY = SRGBTBREL-INSTID_B+17(3)SOOD-OBJYR = SRGBTBREL-INSTID_B+20(2)SOOD-OBJNO = SRGBTBREL-INSTID_B+22(12)
Example
If you are looking for an attachment to a material, you might select from SRGBTBREL where RELTYPE = 'URL' and INSTID_A is the material number. The INSTID_B field will then hold the information to link to the document in SOOD.
OBJECT TYES RELEVANT (TBC - with Laura Santamarta)
LFA1
LFB1
LFM1
These would cover documents such as Bank account details, Qualification details, Registration details, etc.
Attachment Types
Any type of document can be an attachment, and can be attached when the user creates a PO from the shopping cart.
In most cases this is a PDF type attachment, and includes Invoices, Specs, Emails....
Conversion Scope
The scope of this document covers the approach for converting active Attachments for Vendors from Legacy Source Systems into S/4HANA following the S2P Master Data Design Standard.
The data from legacy system includes:
- The basis of this object's legacy data is Active Vendor Business partners that will be migrated. This is handled in CNV-3007 Business Partner - General Section (0000)
- The vendor in point 1 must have an attachment maintained.
The data from legacy system excludes:
- Attachments for Vendors not in scope to be migrated.
- Only approved list of Documents can be attached to Vendors (List of documents to be confirmed by Functional Consultant)
- Only vendors that do have attachments.
| Source | Scope | Source Approx No. of Records | Target System | Target Approx No. of Records |
|---|---|---|---|---|
| WP2 | Attachment for Vendors | 418 | S4 Hana ROW/China/CUI | 418 |
| PF2 | Attachment for Vendors | 265 | S4 Hana ROW/China/CUI | 265 |
Additional Information
Multi-language Requirement
N/A
Document Management
Generic Object Services (GOS) is a functionality that allows users to attach documents, notes, and other objects to business objects like purchase orders. It provides a standard way to manage and access these attachments within various SAP transactions, including those related to purchase orders.
The following are the key concepts for POs.
Attachment Management:
GOS enables users to add attachments (like PDFs, Word documents, etc.) to purchase orders, either directly within the transaction or through a separate DMS (Document Management System) if configured.Viewing Attachments:
GOS also allows users to view the attachments associated with a specific purchase order.Object Relationships:
GOS can also show relationships between the purchase order and other objects, like IDocs, workflows, or other related documents.Toolbar/Button:
The GOS functionality is typically accessed through a toolbar button or a menu option within the vendor transaction (e.g., XK01, XK02, XK03).Customization:
In some cases, the GOS button or functionality might need to be activated for specific transactions or user roles using customizing settings.- Other:
- GOS also allows for other functions like adding private notes, sending the object to another user, or viewing related workflows.
The Business Object Repository (BOR) in SAP is a central access point for SAP business object types and their corresponding Business Application Programming Interfaces (BAPIs). It provides an object-oriented view of data and processes within an SAP system and is crucial for integrating SAP with external applications. The BOR also plays a role in SAP Business Workflow, ArchiveLink, and output control.
Key aspects of the BOR and Vendor:
Centralized Access:
The BOR acts as a single point of access for all business objects and their associated BAPIs.Object-Oriented View:
It provides an object-oriented perspective of business processes, allowing for modular and reusable components.Purchase Order Object:
The purchase order business object (type BUS2012) is a key object within the BOR, representing purchase order data and operations.BAPIs and Methods:
BAPIs, which are remote-enabled ABAP function modules, are used to implement the methods of business objects. For example, a BAPI might be used to change a purchase order item or retrieve purchase order details.Attributes and Parameters:
Business objects have attributes that store object properties (e.g., purchase order number, vendor) and methods use import/export parameters to pass data between different parts of the system.BOR Browser:
The Business Object Repository Browser (transaction code SWO1) allows users to browse, display, and maintain business objects and their components.Integration:
The BOR facilitates the integration of SAP with other systems, such as through middleware.Workflow and Other Services:
The BOR is used in SAP Business Workflow, ArchiveLink, output control, and other generic object services.
The DMS approach is elaborated in KDD "Document Management in the SyWay Solution".
Legal Requirement
CMMC 2.0 is a mandatory DoD cybersecurity certification for contractors handling Controlled Unclassified Information (CUI) and Federal Contract Information (FCI). CUI includes sensitive technical data (e.g., design specs, system info) related to U.S. military and space applications. The Composites Business handles CUI and is therefore within CMMC scope. Without certification, the business risks disqualification from existing and future DoD programs.
It is mandatory to implement CMMC-compliant systems and processes to for all the organizations that are dealing with CUI.
Therefore, there will be one SAP instance specifically for CUI related entities. The migration for CUI related entities will be covered by US based data consultant using separate tools.
Special Requirements
Different SAP Instance Migration Approach - Separate document required
Due to compliance requirement, there will be one SAP instance for Rest of the World, one for China and one for CUI.
- For entities in China, the data will be loaded into SAP China instance while the entire migration process will remain the same as rest of the world.
- For entities which will reside in CUI, the migration will be handled by US based data consultant.
Please refer to the link for the entity mapping for each instance. In case the data object is applicable for multiples instances, what business rule to follow?
Cybersecurity - Separate document required
Target Design
The technical design of the target for this conversion approach.
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement | Format |
|---|---|---|---|---|---|---|---|
| SRGBTBREL | CLIENT | CLIENT | Client | C | 3 | Internal (Mandatory) | Three digit client number (Linked SAP table T000) |
| SRGBTBREL | BRELGUID | BRELGUID | GUID | X | 16 | Internal (Mandatory) | RAW: Binary data — used here for GUID; generally used internally. |
| SRGBTBREL | RELTYPE | RELTYPE | Relationship type | C | 10 | Mandatory | Check table MDOBLREL (ensures only valid relationship types are used) |
| SRGBTBREL | INSTID_A | INSTID_A | Instance ID | C | 70 | Mandatory | Length 70 (CHAR) |
| SRGBTBREL | TYPEID_A | TYPEID_A | Object Type | C | 32 | Mandatory | Length 32 (CHAR) |
| SRGBTBREL | CATID_A | CATID_A | Object Category | C | 2 | Mandatory | Length 2 (CHAR) |
| SRGBTBREL | INSTID_B | INSTID_B | Instance ID | C | 70 | Internal (Mandatory) | Length 70 (CHAR) |
| SRGBTBREL | TYPEID_B | TYPEID_B | Object Type | C | 32 | Internal (Mandatory) | Length 32 (CHAR) |
| SRGBTBREL | CATID_B | CATID_B | Object Category | C | 2 | Internal (Mandatory) | Length 32 (CHAR) |
| SRGBTBREL | LOGSYS_A | LOGSYS_A | Logical System | C | 10 | Not in use | |
| SRGBTBREL | ARCH_A | ARCH_A | Object Archived | C | 1 | Not in use | |
| SRGBTBREL | LOGSYS_B | LOGSYS_B | Logical System | C | 10 | Not in use | |
| SRGBTBREL | ARCH_B | ARCH_B | Object Archived | C | 1 | Not in use | |
| SRGBTBREL | UTCTIME | UTCTIME | Short Time Stamp | P | 8 | Internal (Mandatory) | Format YYYYMMDDhhmmss |
| SRGBTBREL | HOMESYS | HOMESYS | Logical System | C | 10 | Not in use | |
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement | Format |
| SOOD | OBJTP | OBJTP | Document class | C | 3 | Internal | Length 3 (CHAR) Linked SAP table TSOTD for ref data |
| SOOD | OBJYR | OBJYR | Object year | C | 2 | Internal | Length 2 (CHAR) |
| SOOD | OBJNO | OBJNO | Object number | C | 12 | Internal | Length 12 (CHAR) |
| SOOD | OBJLA | OBJLA | Doc. language | C | 1 | Internal | Length 1 (LANG) |
| SOOD | OBJSRT | OBJSRT | Sort field | C | 10 | Not in use | |
| SOOD | OBJNAM | OBJNAM | Document Name | C | 12 | Internal | Length 12 (CHAR) |
| SOOD | OBJDES | OBJDES | Document title | C | 50 | Mandatory | Length 50 (CHAR) |
| SOOD | OWNTP | OWNTP | Owner type | C | 3 | Internal | Length 12 (CHAR) Linked SAP table TSOTD for ref data |
| SOOD | OWNYR | OWNYR | Owner year | C | 2 | Internal | Length 2 (CHAR) |
| SOOD | OWNNO | OWNNO | Owner number | C | 12 | Internal | Length 12 (CHAR) |
| SOOD | OWNNAM | OWNNAM | Owner name | C | 12 | Internal | Length 22 (CHAR) |
| SOOD | CROTP | CROTP | User Type | C | 3 | Internal | Length 3 (CHAR) Linked SAP table TSOTD for ref data |
| SOOD | CROYR | CROYR | User year | C | 2 | Internal | Length 2 (CHAR) |
| SOOD | CRONO | CRONO | User number | C | 12 | Internal | Length 12 (CHAR) |
| SOOD | CRONAM | CRONAM | Created by | C | 12 | Internal | Length 12 (CHAR) |
| SOOD | CRDAT | CRDAT | Date created | D | 8 | Internal | Length 8 (DATE) YYYYMMDD |
| SOOD | CRTIM | CRTIM | Created at | T | 6 | Internal | Length 6 (TIME) hhmmss |
| SOOD | FILE_EXT | FILE_EXT | File extension | C | 3 | Mandatory | Length 3 (CHAR) |
Data Cleansing
| ID | Criticality | Error Message/Report Description | Rule | Output | Source System |
|---|---|---|---|---|---|
| 1 | High | Review and remove the obsolete attachments/links from the load. | Exclude where Vendor Out of scope. | In-scope vendor attachments only | PF2/WP2 |
| 2 | High | Review and remove the OOS object types. | Exclude where object types not in "LIST". | Applicable Objects type only | PF2/WP2 |
| 3 | High | Only vendors with attachments | Exclude in-scope vendors with no attachments | Only vendors with attachments | PF2/WP2 |
Conversion Process
SAP's document migration process involve three parts:
- Moving the documents to a storage area.
- Creating the entries in the S4 HANA system, such as purchase orders, etc
- Linking the attachments to the purchase documents.
Various tools are used in the migration process, which are TBC.
The Rest of the World and China follows the process below, using Syniti ADMM.
1. Extraction
The process begins with extracting metadata and raw data from source systems, such as Syensqo ECC system (i.e., WP2/PF2) periodically. The extracted data is then staged for transformation.
2. Transformation
Once extracted, the data undergoes cleansing, consolidation, and governance. This step ensures data integrity, consistency, and compliance with business rules. The transformation process includes:
- Data validation to remove inconsistencies.
- Standardization to align formats across datasets.
- Business rule application to refine data for operational use.
3. Loading
The transformed data is then loaded into the target S4 Hana system. For attachment, it will be migrated via a custom program. The table below captures the major steps to perform this ETL process.
| Step | Step Descr | Owner | Remarks |
| 1 | Extract the table SRGBTBREL / SOOD for attachment information (such as attachment type, file name etc.) | Syniti | The Attachment is saved in the content server, this is just to capture the link between the attachment and customer master data. |
| 2 | Apply the relevancy rule and define the scope of attachment to be migrated | Syniti | The output will be an excel file includes the ECC attachment information relevant for migration |
| 3 | Based on Step 2, download the attachment to local | A custom program will be developed in ECC (WP2/PF2). By reading the excel file in step 2, it will download the attachments to local | |
| 4 | Perform transformation, i.e., convert the ECC customer number to S4 BP number | Syniti | The output will be an excel file includes the S4 data object and the attachment information (i.e., file name from step 2) |
| 5 | Based on Step 4, upload the attachment in S4 | A custom program will be developed in S4. By reading the excel file in step 4, it will upload the attachment from local (saved from Step 3) |
The high-level process is represented by the diagram below:
For CUI instance, the ETL process will be similar, but it will not use Syniti tool.
Data Privacy and Sensitivity
For SAP CUI instances, the data will be processed by US Based consultants.Extraction
Extract data from a source systems into ADMM:
- The vendor documents exist in the GOS environment and have to be extracted and transferred to the S2 GOS.
- The files are linked to the data objects via the SAP data tables. These records need to be extracted and migrated to the S4H environment. There are 3 methods:
- Perform full data extraction from relevant tables from the PF2/WP2 source system(s), using Syniti ADMM.
- Stage data in SQL server
All records need to be extracted but due to the high volumes, the agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads.
Extraction Run Sheet (for data extraction portion)
| Req # | Requirement Description | Team Responsible |
|---|---|---|
| 3004-001 | - Identify the source systems WP2/PF2 and databases involved. - Define the data objects (tables SRGBTBREL / SOOD) to be extracted. - Establish business rules for data selection. | Syniti |
| 3004-002 | - Specify the extraction approach (full extraction). - Determine the tools and technologies used. - Define data filtering criteria to exclude irrelevant records. | Syniti / |
| 3004-003 | - Establish execution timelines and batch processing schedules. - Assign responsibilities for extraction monitoring. - Document dependencies on other migration tasks. | Syniti / |
| 3004-004 | - Define error handling mechanisms for extraction failures. | Syniti / |
| 3004-005 | Run custom program based on the template below to download the attachments to local. Syniti will generate the file after applying the relevancy rule before extraction. | P2FData |
Sample template to download the attachment from SAP (final template to be confirmed by technical team)
| System ID | Relationship Type | Object Type | Object category | Object Key | GUID | Instance ID | File Name | MIME Type |
| WP2 | ATTA | LFA1 | BO | 0000091278 | 011249526B2AE102E10000000A8F7697 | FOL27000000000004EXT38000000696606 | ENDRESS+HAUSER.pdf | application/pdf |
The Instance ID - SRGBTBREL.INSTID_B contains the details to link the SOOD table. It needs to be parsed into the following.
OBJECT DOC TYPE = EXT
OBJECT YEAR - 38
OBJECT NUMBER: 000000696606
Extraction Run Sheet (for files extraction portion)
| Req # | Requirement Description | Team Responsible |
|---|---|---|
| - Identify the source systems and databases involved. | S2P/GOS | |
| - Specify the extraction approach (full, incremental, or delta extraction). | S2P/GOS | |
| - Determine the tools and technologies used. | S2P/GOS | |
| - Define data filtering criteria to exclude irrelevant records. | S2P/GOS | |
| - Establish execution timelines and batch processing schedules. | S2P/GOS | |
| - Assign responsibilities for extraction monitoring. | S2P/GOS | |
| - Document dependencies on other migration tasks. | S2P/GOS | |
| - Define error handling mechanisms for extraction failures. | S2P/GOS |
Selection Screen
| 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 with exception of some fields which require transformation as mentioned in the transformation rule.DCT Rules
| Field Name | Field Description | Rule |
|---|---|---|
| N/A | ||
Extraction Dependencies
| Item # | Step Description | Team Responsible |
|---|---|---|
| 1 | Source Systems Availability
| Syensqo IT |
| 2 | Extraction Methodology
| Syniti/S2P Data |
| 3 | Data
| Syniti/S2P Data |
| 4 | Performance and Scalability Considerations
| Syniti/S2P Data |
| 5 | Security and Compliance
| Syniti/S2P Data |
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 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
- 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 (S2P)+ Data Team (S2P) |
| 2 | Map legacy field values to S/4HANA target values (including field-level mapping and technical names) | Data Team (S2P), Data Team (Syniti) |
| 3 | Define value mapping rules for fields requiring standardization or harmonization across the two source systems WP2, PF2 | Functional Team (S2P)+ Data Team (S2P) |
| 4 | Identify and agree on default values where legacy data is incomplete or inconsistent | Business Team + Functional Team (S2P) |
| 5 | Configure transformation rules in Syniti Migrate | Data Team (Syniti), Data Team (S2P) |
| 6 | Review transformation logic and mappings with Business for confirmation | Business Team + Functional Team (S2P) |
| 7 | Perform initial transformation run and generate draft target-ready dataset | Data Team (Syniti), |
| 8 | Review draft target-ready data for structure and completeness | Data Team (S2P), Functional Team (S2P) |
| 9 | Share transformed data with Business for Pre-load Validation | Business Team |
| 10 | Incorporate feedback from Business and refine mappings or transformation logic as needed | Data Team (S2P) |
| 11 | Finalize and approve transformed data as Target Ready Load File | Business + Functional (S2P) + Data Team (S2P) |
| 12 | 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 | Add Info about field | Target System | Target Table | Target Field | Target Description | Transformation Logic |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | PF2/WP2 | SRGBTBREL | CLIENT | Client | Internal (Mandatory) | S4H | SRGBTBREL | CLIENT | Client | System generated |
| 2 | PF2/WP2 | SRGBTBREL | BRELGUID | GUID | Internal (Mandatory) | S4H | SRGBTBREL | BRELGUID | GUID | System generated |
| 3 | PF2/WP2 | SRGBTBREL | RELTYPE | Relationship type | Mandatory | S4H | SRGBTBREL | RELTYPE | Relationship type | Copy (Standard Value = ATTA) |
| 4 | PF2/WP2 | SRGBTBREL | INSTID_A | Instance ID | Mandatory | S4H | SRGBTBREL | INSTID_A | Instance ID | Copy |
| 5 | PF2/WP2 | SRGBTBREL | TYPEID_A | Object Type | Mandatory | S4H | SRGBTBREL | TYPEID_A | Object Type | Copy Will include LFA1, LFB1, LFM1 |
| 6 | PF2/WP2 | SRGBTBREL | CATID_A | Object Category | Mandatory | S4H | SRGBTBREL | CATID_A | Object Category | Copy (Std value = BO) |
| 7 | PF2/WP2 | SRGBTBREL | INSTID_B | Instance ID | Internal (Mandatory) | S4H | SRGBTBREL | INSTID_B | Instance ID | Copy |
| 8 | PF2/WP2 | SRGBTBREL | TYPEID_B | Object Type | Internal (Mandatory) | S4H | SRGBTBREL | TYPEID_B | Object Type | Copy (Std value = MESSAGE) |
| 9 | PF2/WP2 | SRGBTBREL | CATID_B | Object Category | Internal (Mandatory) | S4H | SRGBTBREL | CATID_B | Object Category | Copy (Std value = BO) |
| 10 | PF2/WP2 | SRGBTBREL | LOGSYS_A | Logical System | Not in use | S4H | SRGBTBREL | LOGSYS_A | Logical System | N/A |
| 11 | PF2/WP2 | SRGBTBREL | ARCH_A | Object Archived | Not in use | S4H | SRGBTBREL | ARCH_A | Object Archived | N/A |
| 12 | PF2/WP2 | SRGBTBREL | LOGSYS_B | Logical System | Not in use | S4H | SRGBTBREL | LOGSYS_B | Logical System | N/A |
| 13 | PF2/WP2 | SRGBTBREL | ARCH_B | Object Archived | Not in use | S4H | SRGBTBREL | ARCH_B | Object Archived | N/A |
| 14 | PF2/WP2 | SRGBTBREL | UTCTIME | Short Time Stamp | Internal (Mandatory) | S4H | SRGBTBREL | UTCTIME | Short Time Stamp | System generated |
| 15 | PF2/WP2 | SRGBTBREL | HOMESYS | Logical System | Not in use | S4H | SRGBTBREL | HOMESYS | Logical System | N/A |
| 16 | WP2/PF2 | SOOD | OBJTP | Document class | Internal (Mandatory) | S4 Hana | SOOD | OBJTP | Document class | Internal. SOOD can be joined with SRGBTBREL using SRGBTBREL-INSTID_B field, the underscore part in below sample value. FOL25000000000004EXT41000000440415 |
| 17 | WP2/PF2 | SOOD | OBJYR | Object year | Internal (Mandatory) | S4 Hana | SOOD | OBJYR | Object year | Internal. SOOD can be joined with SRGBTBREL using SRGBTBREL-INSTID_B field the underscore part in below sample value. FOL25000000000004EXT41000000440415 |
| 18 | WP2/PF2 | SOOD | OBJNO | Object number | Internal (Mandatory) | S4 Hana | SOOD | OBJNO | Object number | Internal. SOOD can be joined with SRGBTBREL using SRGBTBREL-INSTID_B field, the underscore part in below sample value. FOL25000000000004EXT41000000440415 |
| 19 | WP2/PF2 | SOOD | OBJLA | Doc. language | Internal (Mandatory) | S4 Hana | SOOD | OBJLA | Doc. language | System generated (linked to table T002) |
| 20 | WP2/PF2 | SOOD | OBJSRT | Sort field | Not in use | S4 Hana | SOOD | OBJSRT | Sort field | N/A |
| 21 | WP2/PF2 | SOOD | OBJNAM | Document Name | Internal (Mandatory) | S4 Hana | SOOD | OBJNAM | Document Name | System generated |
| 22 | WP2/PF2 | SOOD | OBJDES | Document title | Mandatory | S4 Hana | SOOD | OBJDES | Document title | Copy for both upload and download template |
| 23 | WP2/PF2 | SOOD | OWNTP | Owner type | Internal (Mandatory) | S4 Hana | SOOD | OWNTP | Owner type | System generated |
| 24 | WP2/PF2 | SOOD | OWNYR | Owner year | Internal (Mandatory) | S4 Hana | SOOD | OWNYR | Owner year | System generated |
| 25 | WP2/PF2 | SOOD | OWNNO | Owner number | Internal (Mandatory) | S4 Hana | SOOD | OWNNO | Owner number | System generated |
| 26 | WP2/PF2 | SOOD | OWNNAM | Owner name | Internal (Mandatory) | S4 Hana | SOOD | OWNNAM | Owner name | System generated |
| 27 | WP2/PF2 | SOOD | CROTP | User Type | Internal (Mandatory) | S4 Hana | SOOD | CROTP | User Type | System generated |
| 28 | WP2/PF2 | SOOD | CROYR | User year | Internal (Mandatory) | S4 Hana | SOOD | CROYR | User year | System generated |
| 29 | WP2/PF2 | SOOD | CRONO | User number | Internal (Mandatory) | S4 Hana | SOOD | CRONO | User number | System generated |
| 30 | WP2/PF2 | SOOD | CRONAM | Created by | Internal (Mandatory) | S4 Hana | SOOD | CRONAM | Created by | System generated |
| 31 | WP2/PF2 | SOOD | CRDAT | Date created | Internal (Mandatory) | S4 Hana | SOOD | CRDAT | Date created | System generated |
| 32 | WP2/PF2 | SOOD | CRTIM | Created at | Internal (Mandatory) | S4 Hana | SOOD | CRTIM | Created at | System generated |
| 33 | WP2/PF2 | SOOD | FILE_EXT | File extension | mandatory | S4 Hana | SOOD | FILE_EXT | File extension | Rule. For both download and upload template "MIME Type" field, Concatenate 'application/' & this field value |
Transformation Mapping
| Mapping Table Name | Mapping Table Description |
|---|---|
| MAP_LIFNR | BP Vendor mapping table |
Transformation Dependencies
List the steps that need to occur before transformation can commence| Item # | Step Description | Team Responsible |
|---|---|---|
| 1 | Source Data Integrity - Ensure extracted data is complete, accurate, and consistent. - Validate that data types and formats align with transformation requirements. | Syniti / US Based Consultant for SAP CUI instance |
| 2 | Referential Integrity - Ensure dependent records are transformed together or in advance, such as CNV-3007 Business Partner General and DMS server migration | Syniti / US Based Consultant for SAP CUI instance |
| 3 | Transformation Logic and Mapping - Define data mapping rules between source and target schemas. | Data Team |
| 4 | Performance and Scalability Considerations - Optimize transformation processes for large datasets. - Ensure system resources can handle transformation workloads | Syniti / US Based Consultant for SAP CUI instance |
| 5 | Logging and Error Handling - Maintain detailed logs of transformation activities. - Define error-handling procedures for failed transformations | Syniti / US Based Consultant for SAP CUI instance |
Pre-Load Validation
Project Team
Completeness
| Task | Action |
|---|---|
| Compare Data Counts |
|
| Validate the mandatory fields | Validate there is value for all the mandatory fields |
| Validate Primary Keys and Unique Constraints |
|
| Test Referential Integrity | Confirm dependent records exist in related tables |
| Count and Completeness check | Verify that vendors with attachments still have the applicable attachments |
Accuracy
| Task | Action |
|---|---|
| Validate the transformation | Validate the fields which require transformation have the value after transformation instead of the original field value |
| Check Data Consistency |
|
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 ADMM must be built to help check. |
| Count and Completeness check | Verify that vendors with attachments still have the applicable attachments |
Accuracy
| Task | Action |
|---|---|
| Validate the transformation | Validate the fields which require transformation have the value after transformation instead of the original field value |
| Check Data Consistency |
|
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 |
|---|---|---|
| 1 | Verify Attachment files are available in source system to be copied | Data Specialist/Functional - S2P/GOS |
| 2 | Verify copy tool & scripts are operational | Data Specialist/Functional - S2P/GOS |
| 3 | Verify Target System ready to receive files | Data Specialist/Functional - S2P/GOS |
| 4 | Verify file count. | Data Specialist/Functional - S2P/GOS |
| 5 | Approval to copy | Functional/Data Owner - S2P |
| 6 | Copy files | Data Specialist/Functional - S2P/GOS |
| 7 | Verify files copied in target | Data Specialist/Functional - S2P/GOS |
| 8 | Verify data extracted is ready - agree volume | Data Specialist/Functional - S2P |
| 9 | Verify Config is in the system TBC | Data Specialist/Functional - S2P |
| 10 | Verify other necessary data has been loaded int he system (TBC) | Data Specialist/Functional - S2P |
| 11 | Release - Load signoff and go-ahead by Functional/Data Owner | Functional/Data Owner - S2P |
| 12 | Approval to stage/Pre-stage steps | Functional/Data Owner - S2P |
| 13 | Extraction from source | Developer - Syniti or Data Specialist - S2P |
| 14 | Extraction from S4 where needed | Developer - Syniti or Data Specialist - S2P |
| 15 | Stage data for transformations | Developer - Syniti or Data Specialist - S2P |
| 16 | Run transforms | Developer - Syniti or Data Specialist - S2P |
| 17 | Execute pre-load report | Data Specialist/Functional - S2P |
| 18 | Validate preload report - release when signed off | Data Specialist - S2P |
| 19 | Pre-load verification and approval to load | Functional/Data Owner - S2P |
| 20 | Load to S4 | Data Specialist - S2P |
| 21 | Complete Jira steps, Volumes and Timings | All - where applicable |
| 22 | Execute post-load report | Developer - Syniti or Data Specialist - S2P |
| 23 | Post-load report verification/validation | Data Specialist/Functional/Data Owner - S2P |
| 24 | Object load completion approval | Data Owner - S2P |
This object might be/will be loaded via a custom program. The custom program will use the upload template below. (final template to be confirmed by technical team)
| Object Type | Object Key | File Path (to-be filled by uploader) | File Name | MIME Type |
| LFA1 | BP Vendor Number* | C:\GOS\ENDRESS+HAUSER.pdf local directory | ENDRESS+HAUSER.pdf | application/pdf file type |
*The transformation involved will need to translate the old vendor number to the new vendor number.
Load Phase and Dependencies
Configuration
| Item # | Configuration Item |
|---|---|
| 1 | SRGBTBREL-RELTYPE: Relationship type. Check table MDOBLREL (E.g. ATTA) |
| 2 | SRGBTBREL-TYPEID_A: Object Type. Check table TOJTB (E.g. LFA1) |
| 3 | SRGBTBREL-CATID_A: Object category. (e.g. BO)* |
| 4 | SRGBTBREL-CATID_B: Object category. (e.g. BO)* |
| 5 | S4 GOS system config in place |
*Possible values
| BC | Instances of Business Classes (ABAP Objects) |
| BO | Instances of BOR Object Types |
| CL | Instances of ABAP Objects Classes - Internal Use Only! |
| NN | Category (still) Not Known - Internal use only!!! |
Conversion Objects
| Object # | Preceding Object Conversion Approach | Direct/Indirect |
|---|---|---|
| 1 | Bank master (1083) | Indirect |
| 2 | GL Account Operation COA at CCd | Indirect |
| 3 | Vendor Hierarchy (3024) | Indirect |
| 4 | Supplier Risk (3023) Supplier Segmentation (3030) Supplier Qualification (3029) Category Strategies (1096) | Indirect |
| 5 | Business Partners - General (3007) | Indirect |
| 6 | Business Partners - 3rd Party Supplier (FLVN01) (3026) | Direct |
| 7 | Vendor doc attachments (3031) |
Error Handling
| Error Type | Error Description | Action Taken |
|---|---|---|
| Technical | GOS system not available | Contact standby GOS system support |
| Technical | Copy tool and scripts fails, due to access issues or volumes | Developers to fix the error |
| Data | Load fails | Fix and retry load |
| Data | Duplicates | Fix incorrect data or missing entries |
| Data | Transformation misses | Build transformation and retry. |
| Load | Authorization errors | Apply for the applicable authorization permission and retry |
| Load | Technical load failures - If using MC - Simulation errors, etc | Investigate error and rectify. Retry simulation and/or load |
| Load | Missing config | Set up config check validation jobs |
| Technical | Unable to create the link between attachment and object | Verify system is functional, data correct and access is valid. |
Post-Load Validation
Project Team
Completeness
| Task | Action | Team |
|---|---|---|
| 1 | Execute post-load report | Developer - Syniti or Data Specialist - S2P |
| 2 | Post-load report verification/validation | Data Specialist/Functional/Data Owner - S2P |
| 3 | Object load completion approval | Data Owner - S2P |
| 4 | SIT & UAT test | S2P/Business |
Accuracy
| Task | Action |
|---|---|
Verify count | The number of records presented in the preload needs to be compared to the postload. – Syniti report |
| Field by field check | Compare source data to target data. |
| Verify count | Verify copied file count |
Business
Post-load validation is a critical step in data migration, ensuring that transferred data is accurate, complete, and functional within the target system.
1. Ensuring Data Integrity
After migration, data must be consistent with its original structure. Post-load validation checks for missing records, incorrect mappings, and formatting errors to prevent discrepancies.
2. Business Continuity
Faulty data can disrupt operations, leading to financial losses and inefficiencies. Validating post-load data ensures that applications function as expected, preventing downtime.
3. Error Detection and Resolution
By validating data post-migration, businesses can detect anomalies early, reducing the cost and effort required for corrections
Completeness
| 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 reports/SAP reports |
| File quantity | Verify the quota quantities are correctly migrated |
Verify count | The number of records presented in the preload needs to be compared to the post load. – Syniti report |
| Missing data | Check missing data which was supposed to be loaded |
| Reconciliation | Participate in Post-load walkthroughs |
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 reports/SAP reports |
| Load failures | Value presented for load must be in the system |
| Copy failures | Verify all files are copied and attachments available in target |
Key Assumptions
- Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
- Attachment for customer master data is in scope based on data design and any exception requested by business.
- There will be 3 SAP instances, one for ROW, one for China and one for CUI only.
See also - additional info
Attachment Functionality in SAP ECC
- Storage Method: Attachments are typically stored using Generic Object Services (GOS), which allow users to link files to vendor documents (via transaction codes like ME21N, ME22N, ME23N).
- Technical Reference: The attachments are managed via the Business Object Repository (BOR) object. The Business Object Repository (BOR) in SAP is a central access point for SAP business object types and their corresponding Business Application Programming Interfaces (BAPIs). It provides an object-oriented view of data and processes within an SAP system and is crucial for integrating SAP with external applications. The BOR also plays a role in SAP Business Workflow, ArchiveLink, and output control.