Status
Owner	BAJAJ-ext, Manoj GANESAN-ext, Shivkumar
Stakeholders	PILLAY-ext, Lawrence

Purpose

The purpose of this document is to define the conversion approach to create Securities Account (object 1185) in S/4 HANA.

Securities Account is a master data in Treasury and Risk Management module of S4HANA, that serves as a central place to log all details of securities held by an entity. This master data facilitates the recording and management of buying, selling, and other events related to securities. In S4HANA, the transaction code to create a Security Account is TRS_SEC_ACC

The document details out the field list, extraction criteria, scoping, mapping, transformation logic, generation of the pre-load file and loading of the same with respect to the object 1185- Securities Account, to be used in treasury module of S4HANA.

Key tables and fields: 

There are two tables involved in S4HANA with respect to the maintenance of Securities Account.

These tables are TWD01 (Treasury: Securities Account Master Data) and TRST_SECACC_BANK (Payment Details for Securities Account).  The payment details for the securities transaction are firstly checked in Securities account. If the same is not available, it is sourced from Business Partner master data.

Table TWD01 stores master data related to securities accounts, which are essential for managing financial instruments like bonds, stocks, and other securities. The key fields of this table are:

• BUKRS - Company Code - The company code is an organizational unit within financial accounting. This field along with Security Account (RLDEPO) acts as primary key for link with table for Payment Details (Table: TRST_SECACC_BANK)
• RLDEPO -Securities Account - Securities account identifier. An ID to be entered as per agreed design i.e. external number at the time of creating a Security Account. This field is also referenced along with BUKRS (Company Codes) in the table TRST_SECACC_BANK
  
• XLDEPO - Securities Account ID - Is the field to store the description of the Security Account
• SECACC_TYPE - Securities Acct Type - Each securities account type relates to a securities account category such as
  • Asset Securities Account,
  • Issuance Securities Account
  • Lending Securities Account
• RDPBANK - Depository Bank - The business partner with depository bank role with which a Security account is to be created.
• VERKONTO - Clearing Account - Account number of the cash clearing account for the depository bank. It also represents the securities account number for US securities accounts. It is free text field
• RDEPOTNR - Sec.acct number - This represents the number of the securities account at the depository bank. It is a free text field.
• EXT_SEC_ACC_NO - External Securities Account ID - The external securities account ID describes the number under which the securities account is managed by the depository bank. It also serves as the identifier for the securities account in case of external securities account statement load. It is a free text field.
• RPORTB- Portfolio - portfolio is an organizational element to group together various treasury transactions for reporting purposes.

Table TRST_SECACC_BANK stores payment details for securities accounts, which are used in managing financial instruments like stocks and bonds. It links to the TWD01 and gets updated while creating a Security Account. Its key fields are:

• BUKRS - Company Code - The company code is an organizational unit within financial accounting. This field along with Security Account (RLDEPO) acts as primary key for links back to table TWD01
• RLDEPO -Securities Account - Securities account identifier. An ID to be entered as per agreed design i.e. external number at the time of creating a Security Account. This field along with Company code (BUKRS) acts as primary key for links back to table TWD01
• CURRENCY - Payment Currency - Specifies the currency in which payments are made or received. 
• VALID_FROM - Payment Details Effective From - Indicates the start date from which the payment details are valid.
• DIS_FLOWTYPE - Update Type - Defines the update type for payment flows, used to categorise the Cash Flows.
• HOUSEBANK - House Bank - House bank of the company code 
• ACCOUNT - House Bank Account ID - The Account ID of the House bank which is to be used for the Security Account
• RPZAHL - Payer/Payee - Represents the payer/payee involved in the transaction.  Incoming and outgoing payments are settled using this business partner.
• RPBANK - Partner Bank - This field helps to identify the bank details of the Business partner
• SZART - Payment Transactions - This check box identifies if the payment posting happens via customer or vendor subledger
• ZLSCH - Payment Method - The payment method determines how payments are to be made, e.g. by check, bank transfer or bill of exchange.
• SPAYRQ - Payment request - This indicator is used to determine whether a payment request is to be created or not. If the indicator is not flagged, then no payment request is generated.

• ZWELS - Payment Methods - This field is only applicable to determine the payment method if the same is not identified in the Payer/Payee item details

The treasury function in legacy is carried out in the Quantum system and therefore for the conversion of this object i.e. Security Accounts, the data/details need to be sourced from Quantum and transformed as applicable for S4HANA in Syniti and load using a custom program as the LTMC for this object is not available in the Data Migration Cockpit.

Conversion Scope

The scope of this document covers the approach for converting active Treasury - Securities Account from Legacy Source Systems (Quantum) into S/4HANA following the Master Data Design Standard - DD-FUN-050 Master Data Standard_1185 - Securities Account

The relevancy criteria is not applicable for this object as the relevant data will be provided by business in a DCT (Data Collection Template)

List of source systems and approximate number of records

Source	Scope	Source Approx No. of Records	Target System	Target Approx No. of Records
Quantum	Active and in use Securities Accounts	100 <TBC>	S4HANA	100 <TBC>

Additional Information

Multi-language Requirement

Not applicable

Document Management

Not applicable

Legal Requirement

Not applicable

Special Requirements

As the conversion involves a source system which is non-SAP, the below area needs special handling:

1. Extraction of Securities Accounts from source system i.e. Quantum is to be done manually.
2. Cleansing by business team to mark the Securities Accounts in the source system to ensure that only active records are provided in DCT.
3. The extracted records to be converted into a DCT and stored in the Syniti for Transformation
4. Below Value mapping tables to be created in Syniti:
1. Counterparty to Business Partner 
2. Source and target company code
5. Amount and date format from source system to align with S4HANA 
6. As the target structure in S4HANA involves two tables-(TWD01 and TRST_SECACC_BANK), the load file needs to have the linkage at the Company Code and Security Account number.

 Target Design

The Target design of the object 1185 - Securities Account Master Data based on the MDS - DD-FUN-050 Master Data Standard_1185 - Securities Account is as below

<Note: The target design can change subject to business confirmation after 

The technical design of the target for this conversion approach. 

Table TWD01 -Treasury: Securities Account Master Data

Table	Field	Data Element	Field Description	Data Type	Length	Requirement
TWD01	BUKRS	BUKRS	Company Code	CHAR	4	Mandatory
TWD01	RLDEPO	VRLDEPO	Securities Account	CHAR	10	Mandatory
TWD01	XLDEPO	XLDEPO	Securities Account ID	CHAR	30	Mandatory
TWD01	SECACC_TYPE	TPM_ SECACC_TYPE	Securities Acct Type	CHAR	3	Mandatory
TWD01	RDPBANK	RDEPOTBANK	Depository Bank	CHAR	10	Mandatory
TWD01	VERKONTO	VERKONTO	Clearing Account	CHAR	15	Mandatory
TWD01	RDEPOTNR	ABNKR	Sec.acct number	CHAR	15	Mandatory
TWD01	EXT_SEC_ACC_NO	EXT_SEC_ACC_NO	External Securities Account ID	CHAR	35	Mandatory
TWD01	RPORTB	RPORTB	Portfolio	CHAR	10	Conditional
TWD01	RGSBER	GSBER	Business Area	CHAR	4	Not to be used

Table - TRST_SECACC_BANK - Payment Details for Securities Account

Table	Field	Data Element	Field Description	Data Type	Length	Requirement
TRST_SECACC_BANK	CURRENCY	TPM_PAYMENT_CURR	Payment Currency	CUKY	5	Mandatory
TRST_SECACC_BANK	VALID_FROM	TPM_VALID_PAYMENT_INFO	Payment Details Effective From	DATS	8	Conditional
TRST_SECACC_BANK	DIS_FLOWTYPE	TPM_DIS_FLOWTYPE	Update Type	DATS	8	Conditional
TRST_SECACC_BANK	HOUSEBANK	TB_RHABK1	House Bank	CHAR	5	Mandatory
TRST_SECACC_BANK	ACCOUNT	TB_RHKTID	House Bank Account	CHAR	5	Mandatory
TRST_SECACC_BANK	RPZAHL	TB_RPZAHL_NEW	Payer/Payee	CHAR	10	Mandatory
TRST_SECACC_BANK	RPBANK	TB_RPBANK	Partner Bank	CHAR	4	Mandatory
TRST_SECACC_BANK	SZART	TB_SZART	Payment Transaction	CHAR	1	Not to be used
TRST_SECACC_BANK	ZLSCH	DZLSCH	Payment Method	CHAR	1	Mandatory
TRST_SECACC_BANK	SPAYRQ	TB_SPAYRQ	Payment request	CHAR	1	Conditional
TRST_SECACC_BANK	ZWELS	DZWELS	Payment Methods	CHAR	10	Not to be used

Note: 

• The fields BUKRS and RLDEPO are the common fields linking the tables TWD01 and TRST_SECACC_BANK

Data Cleansing

 For the purpose of the Object 1185- Securities Accounts Master Data, the below data checks/cleansing reports will be used in Synitii based on the DCT provided by the business.  

1. The Depository Banks ID mentioned against the Security Accounts in DCT: Check that a Business Partner with Depository Bank role exists in S4HANA
2. The House Banks and Bank IDs assigned to the Security Accounts in the DCT are available in S4HANA
3. The Payer/Payee assigned in the DCT are having a valid Business Partner ID created in the S4HANA

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
01	High	Depository Bank Check	Check Depository Bank ID created as Business Partner with role TR0152	Show records in error	DCT
02	Medium	House Bank, Bank IDs check	Check the House Bank and Bank IDs given in the DCT are available as master records in table T012 and T012K respectively	Show records in error	DCT
03	Medium	Payer/Payee Check	Check the payer/payee as provided in DCT are available as Business Partner with role BUT000 and BUT100	Show records in error	DCT

Conversion Process

The generic high-level process steps for the conversion are as below:

1. Extraction:
1. Extract from the source systems: Apply the selection parameters and data relevancy as mentioned in this specification, from the relevant tables
2. DCT: The DCT to be prepared if the data to be transformed and is part of the load file is not available in the Source system
2. Transform 
1. Transform fields by applying the fields and value mapping in the Syniti 
2. Generate and validate Pre-load files
3. Load
1. Load the validated Pre-load file using SAP's LTMC or the custom upload program as applicable. 

However, with respect to object 1185- Securities Accounts Master Data - the conversion process will depend upon the DCT (Data Collection Template) which will be provided by the business based on the source data from Quantum system. This DCT will be used for transformation and generation of the pre-load file. 

The load will be done via a custom program <to be confirmed>, as LTMC for this object is not available as of now.

As there are two tables involved, the custom program should be able to link the information via the common fields i.e. BUKRS (Company Codes) and RLDEPO (Securities Account). 

Data Privacy and Sensitivity

None

Extraction

Extract data from a source into Syniti. There are 2 possibilities:

1. The data exists. Syniti connects to the source and loads the data into Syniti. There are 3 methods:
1. Perform full data extraction from relevant tables in the source system(s).
2. Perform extraction through the application layer.
3. Only if Syniti; cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
2. The data does not exist (or cannot be converted from its current state).  The data is manually collected by the business directly in Syniti. This is to be conducted using DCT (Data Collection Template) in Syniti.

The agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads

In case of the object 1185-Securities Account, the data is to be provided in a DCT by the business, therefore extraction related activity is outside Syniti. 

Extraction Run Sheet

Req #	Requirement Description	Team Responsible
01	Extract from relevant tables/details from Quantum all relevant information required to populate the DCT for Securities Account for relevant Company Codes	Business

Selection Screen

Not applicable

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

Extraction Dependencies

List the steps that need to occur before extraction can commence

Item #	Step Description	Team Responsible

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:

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 Syniti Migrate
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

Item #	Step Description	Team Responsible

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:

1. Execute the automated data load into target system using load tool or product the load file if the load must be done manually
2. 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.

Change log