Conversion Scope

 The GOS functionality is set up to store documents in an ECM (Enterprise Content Management) system. This is a separate system from ECC and S4/HANA, but is natively integrated to ECC.

The scope of this document encompasses the approach for migrating 'Attachments' linked to Vendors from Legacy to S/4HANA.

Relevancy Rules

The data from the legacy system includes:

1. attachments linked to Vendors in scope for migration based on 'Relevancy rules' referenced in CNV-3007 Business Partner - General Section (0000)
2. Type of documents listed in (approved Documents types) (Listed further below in the document)

The data from the legacy system excludes:

1. Vendors 'Attachments' not in (approved Documents types) will not be attached to the Vendor in S4HANA.
2. Old/obsolete attachments which are not valid for Vendor (anything not in the accepted list)

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 vendors . It provides a standard way to manage and access these attachments within various SAP transactions, including those related to vendors. 

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

N/A

Open Points

1) Jira PDM-543

2) Jira ticket PDM-688: What are 'Approved Document Types' which should be attached to Vendor?

Target Design

The technical design of the target for this conversion approach.

 Field Governance

Approved Document Types

ADDITIONAL NOTES: File extensions

Data Cleansing

Conversion Process

SAP's document migration process involve three parts:

1. Moving the documents to a storage area.
2. Creating the entries in the S4 HANA system, such as vendors, etc.
3. Linking the attachments to the vendor. 

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.

The high-level process is represented by the diagram below:

Data Privacy and Sensitivity

N/A

Extraction

Extract data from a source systems into ADMM:

1. The vendor documents exist in the GOS environment and have to be extracted and transferred to the target system ECM. Usually this will need to be a copy to a specified location. Currently we don't know where and what that will be.
2. The files are linked to the data objects via the SAP data tables (SRGBTBREL-GUID). These records need to be extracted and migrated to the S4H environment
   1. Perform full data extraction from relevant tables from the PF2/WP2 source system(s), using Syniti ADMM.
   2. Stage data in SQL server

All records need to be extracted according to the agreed Relevancy criteria contained in the previous section of this document.

 Key tables for Attachments are:

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. 

1. Identify the Attachment Link: 

   In the SRGBTBREL table, the fields INSTID_A and TYPEID_A identify the business object (e.g., a sales order), and INSTID_B identifies the attachment. 

2. Parse the Attachment Information: 

   The INSTID_B field in SRGBTBREL contains the key information for the SOOD table. This field needs to be parsed to extract the document's attributes, including: 
   • OBJTY (Object Type): For example, 'URL' or 'K' (for KPRO objects). 
   • OBJYR (Object Year): A two-character field. 
   • OBJNO (Object Number): A twelve-character field. 

3. 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)

Extraction Run Sheet (for data extraction portion)

Sample template to download the attachment from SAP (final template to be confirmed by technical team)

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

Selection Screen

Data Collection Template (DCT)

Extraction Dependencies

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:

1. Perform value mapping and data transformation rules.
   1. Legacy values are mapped to the to-be values (this could include a default value)
   2. Values are transformed according to the rules defined in
2. 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

Transformation Rules

Transformation Mapping

Transformation Dependencies

Pre-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Relevant T-Codes for validation against Legacy 

Load

The load process includes:

1. Execute the automated data load into target system using load tool.
2. Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation

Load Run Sheet

**Technical Load Sequence and Function modules for Vendor attachments

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)

*The transformation involved will need to translate the old vendor number to the new vendor number.

Load Phase and Dependencies

The Attachment for vendors data will be loaded in the pre-cutover period.

Configuration

DMS server set up is required before load'

Conversion Objects

Error Handling

Post-Load Validation

Project Team

Completeness

Accuracy

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

Accuracy

Key Assumptions

• Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
• Attachment for vendor 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.

Additional information

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? 

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. 

The following are the key concepts for Vendors.

• Attachment Management:

  GOS enables users to add attachments (like PDFs, Word documents, etc.) to vendors, 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 vendor. 

• Object Relationships:

  GOS can also show relationships between the vendor 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. 

• Vendor Object:

  The vendor business object (type LFA1) is a key object within the BOR, representing Vendor data. 

• 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 or retrieve vendor details. 

• Attributes and Parameters:

  Business objects have attributes that store object properties (e.g., 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".

Change log