Status
Owner	VIDWANS-ext, Sauradh
Stakeholders	PILLAY-ext, Lawrence

Purpose

The purpose of this document is to define the conversion approach to create Stock Transactions in S/4 HANA.

Stock are equity investments where the company acquires shares of entities. These entities can be either subsidiaries or external companies that are either listed on the stock exchange or closely held. Such investments will have an investment value as part of the Units or number of shares purchased at a given rate per share.

These instruments are create under a certain Product Type (Instrument Number) and a Transaction Type (Kind of action i.e. buying or selling) against a counterparty (BP Number) in a Company Code for a Security ID and held in a Security Account.

For loading Stocks, SAP has provided a standard BAPI which will have all the necessary fields for successful creation of Stocks. The said BAPI has various Sub-Sections which will form a Load Template and a mapping rule between the DCT and BAPI load format. 

BAPI Name : BAPI_FTR_SECURITY_CREATE

Key Fields of the BAPI used in the DCT are as under:

Key Field	Description
COMPANY_CODE	Company Code in which this deal must be created. This will need to be provided by the business. This is a configuration item.
PRODUCT_TYPE	This is the Product Type for which the deal needs to be created. This again needs to be provided by the business. For this instrument there is a default value for this field = “FTD” This is a configuration item.
TRANSACTION_TYPE	This is the action performed for this transaction i.e. Buy/Sell. This again needs to be provided by the business. For this instrument there is a default value for this field= “100”.
PARTNER	This is the counterparty with which the deal is booked. This information is to be captured in the DCT by the business. However there needs to be a check table which needs conversion between Quantum BP number vs SAP BP Number.
CONTRACT_DATE	This is the date when the deal is created. Data to be captured in the DCT in date format as “YYYYMMDD”
TRADER	This defines the trader who concluded the deal.
PORTFOLIO	This is a code to be used for bucketing these deals under the same kind of transactions. It is used for reporting purposes.
VALUATION_CLASS	This defines the Valuation Class under which this deal needs to be Accounted for i.e. IFRS, US GAAP, etc.
SECURITY_ID	This is the name of Security in itself. In our Case it can be Stock Held External Companies or Stock held in subsidiaries. There will be separate Security Classes for this.
SECURITY_ACCOUNT	This is the Depository Account that will hold the equity shares for investment.
POSITION_VALUE_DATE	This is the Value Date on which the position is valued at
NOMINAL_AMOUNT	This is the Amount invested to buy the given Equity Shares of Entities.
NUMBER_UNITS	These are the number of shares held for investment in External Companies or Subsidiaries
PRICE_UNIT	This is the currency of the Stock Investment Amount.
PAYMENT_DATE	This is the date on which payment for the investment is due on.
PAYMENT_AMOUNT	This is the payment amount which needs to be paid for making the investment in shares good.
EXCHANGE	This is the Exchange (if applicable) which has the invested Equity registered in.

Conversion Scope

The scope of this document covers the approach for converting active Stocks from Legacy Source System (Quantum) into S/4HANA. 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

List of source systems and approximate number of records

Source	Scope	Source Approx No. of Records	Target System	Target Approx No. of Records
Quantum	Live Stock Investment Contracts	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 Stock data from source system i.e. Quantum is to be done manually
2. Cleansing by business team in the source system (Quantum) to ensure that only active and in use records for Stocks are provided in DCT
3. The extracted records to be converted into a DCT and stored in the Syniti for Transformation
4. Below Configuration Check Tables needs to be referenced in Syniti to validate the data in the DCT:
1. Counterparty to Business Partner - BUT100
2. Company Code - T001
3. Product Type - TZPA
4. Transaction Type -  AT10
5. Trader - TZDEA
6. Portfolio Code - TWPOB  
7. General Valuation Class - TRGC_COM_VALCL
8. Security Account – TWD01
9. Security ID – VWPANLA
5. Amount and date format from source system to align with S4HANA 
6. As the target structure in S4HANA involves dependency on various Configuration and BP Master Data objects (CNV 3040), all this data needs to be loaded before Transactions Data loads.

Target Design

For a Transaction Load DCT, since there are no standard LTMC objects that we can use for loading this data, we will be using BAPI’s for this purpose. In a BAPI there are multiple fields, off which all are not necessary to be utilized as part of DCT.

In this section, we will see the full list of fields that are part of the BAPI and DCT. This section will also explain field by field mapping of the BAPI structure and where the data will come from for each field for the BAPI.

The technical design of the target for this conversion approach.

Table Name	Field	Field Description	Data Type	Length	Requirement
VTBFHA	BUKRS	COMPANY_CODE	CHAR	4	This is a Required Field
VTBFHA	SGSART	PRODUCT_TYPE	CHAR	3	This is a Required Field
VTBFHA	SFHAART	TRANSACTION_TYPE	CHAR	3	This is a Required Field
VTBFHA	KONTRH	PARTNER	CHAR	10	This is a Required Field
VTBFHA	DBLFZ	CONTRACT_DATE	DATS	8	This is a Required Field
VTBFHAZU	RDEALER	TRADER	CHAR	12	This is a Required Field
VTBFHA	RPORTB	PORTFOLIO	CHAR	10	This is a Required Field
VTBFHA	ZUOND	ASSIGNMENT	CHAR	18	This is Optional Field
VTBFHAZU	NORDEXT	EXTERNAL_REFERENCE	CHAR	16	This is Optional Field
VTBFHA	REFER	INTERNAL_REFERENCE	CHAR	16	This is Optional Field
VTBFHA	MERKM	CHARACTERISTICS	CHAR	25	This is Optional Field
VTBFHA	FACILITYBUKRS	VALUATION_CLASS	NUMC	4	This is a Required Field
VTBFHA	RANL	SECURITY_ID	CHAR	13	This is a Required Field
VTBFHA	RLDEPO	SECURITY_ACCOUNT	CHAR	10	This is a Required Field
VTBFHAPO	DBESTAND	POSITION_VALUE_DATE	DATS	8	This is a Required Field
VTBFHAPO	BNWHR	NOMINAL_AMOUNT	DEC	23	This is a Required Field
VTBFHAPO	ASTUECK	NUMBER_UNITS	DEC	15	This is a Required Field
VTBFHAPO	WZBETR	PAYMENT_CURRENCY	CHAR	5	This is a Required Field
VTBFHAPO	DZTERM	PAYMENT_DATE	DATS	8	This is a Required Field
VTBFHAPO	BNWHR	PAYMENT_AMOUNT	DEC	23	This is a Required Field
VTBFHAPO	RHANDPL	EXCHANGE	CHAR	10	This is Optional Field

In the above table we saw fields in the DCT. Now we will check the fields in the BAPI and the data logic how it will correspond to the DCT.

The BAPI has 2 structures. Fields in each structure needs to be populated as under:

BAPI Main Flow Data Structure:

Field Name	Description	Mapping Logic
VVRANLW	SECURITY_ID	From DCT field "SECURITY_ID"
VRLDEPO	SECURITY_ACCOUNT	From DCT field "SECURITY_ACCOUNT"
TB_DBESTAND	POSITION_VALUE_DATE	From DCT field "POSITION_VALUE_DATE"
DVALUT	CALCULATE_DATE	Keep Blank or Ignore the field
BAPITM_BNWHR	NOMINAL_AMOUNT	From DCT field "NOMINAL_AMOUNT"
TB_ASTUECK	NUMBER_UNITS	From DCT field "NUMBER_UNITS"
BAPITM_BUPRC	PRICE	Keep Blank or Ignore the field
TB_RUNIT	PRICE_UNIT	From DCT field "PRICE_UNIT"
ISOCD	PAYMENT_CURRENCY_ISO	Keep Blank or Ignore the field
TB_WGSCHFT	PAYMENT_CURRENCY	Keep Blank or Ignore the field
DVALUT	PAYMENT_DATE	From DCT field "PAYMENT_DATE"
BAPITM_BZBETR	PAYMENT_AMOUNT	From DCT field "PAYMENT_AMOUNT"
VVRHANDPL	EXCHANGE	From DCT field "EXCHANGE"
VVSFLAT	TRADED_FLAT	Keep Blank or Ignore the field
VVSCOUPON	COUPON_INFO	Keep Blank or Ignore the field
SSTCKTG	ACC_INT_CALC_METHOD	Keep Blank or Ignore the field
TB_DORDER	ORDER_DATE	Keep Blank or Ignore the field
TB_SFHAZBA	BEWEG_ART	Keep Blank or Ignore the field
TPM_ROUNDING_RULE	ROUND_RULE	Keep Blank or Ignore the field
TB_SINCL_CHAR	INCLUSIVE_INDICATOR	Keep Blank or Ignore the field
BAPITM_HWBETR	LOCAL_AMOUNT	Keep Blank or Ignore the field
BAPITM_ORIG_BNWHR	NOMINAL_ORIG_AMT	Keep Blank or Ignore the field
BAPITM_BWBETR	POSITION_AMOUNT	Keep Blank or Ignore the field
TB_INDEX_PRICE	IND_PRICE_VALUE	Keep Blank or Ignore the field
TFMSKALIDWT	ACC_INT_CALC_CALENDAR	Keep Blank or Ignore the field
SEFFMETH_NEW	YIELD_METHOD	Keep Blank or Ignore the field
TB_SFHAZBA	PAYMENT_FLOWTYPE	Keep Blank or Ignore the field
TB_ZUOND	PAYMENT_ASSIGNMENT	Keep Blank or Ignore the field
TB_ZUOND	QUANTITY_ASSIGNMENT	Keep Blank or Ignore the field
TB_ASTUECK_L	NUMBER_UNITS_LONG	Keep Blank or Ignore the field
BAPITM_BUPRC_L	PRICE_LONG	Keep Blank or Ignore the field

 BAPI General Data Structure:

Field Name	Description	Mapping Logic
BUKRS	COMPANY_CODE	From DCT field "COMPANY_CODE”
VVSART	PRODUCT_TYPE	From DCT field "PRODUCT_TYPE"
TB_SFHAART	TRANSACTION_TYPE	From DCT field "TRANSACTION_TYPE"
TB_RFHA	EXTERNAL_TRANSACTION_NUMBER	Keep Blank or Ignore the field
TB_KUNNR_NEW	PARTNER	From DCT field "PARTNER"
TB_DVTRAB	CONTRACT_DATE	From DCT field "CONTRACT_DATE"
TB_TVTRAB	CONTRACT_TIME	System Time at the time of Data Load
TB_GSPPART	CONTACT_PERSON	Keep Blank or Ignore the field
RDEALER	TRADER	From DCT field "TRADER"
RREFKONT_OBSOLETE	ACCT_ASSIGNMENT_REF	Keep Blank or Ignore the field
RPORTB	PORTFOLIO	From DCT field "PORTFOLIO"
TB_TFPROJ	FINANCE_PROJECT	Keep Blank or Ignore the field
TB_RGARANT_NEW	GUARANTOR	Keep Blank or Ignore the field
TB_RMAID	MASTER_AGREEMENT	Keep Blank or Ignore the field
TB_ZUOND	ASSIGNMENT	From DCT field "ASSIGNMENT"
TB_NORDEXT	EXTERNAL_REFERENCE	From DCT field "EXTERNAL_REFERENCE"
TB_REFER	INTERNAL_REFERENCE	From DCT field "INTERNAL_REFERENCE"
TB_MERKM	CHARACTERISTICS	From DCT field "CHARACTERISTICS"
TBEGRU	AUTH_GROUP	Keep Blank or Ignore the field
TB_CRUSER	CREATE_USER	Keep Blank or Ignore the field
TB_DCRDAT	ENTRY_DATE	Date on which the data is getting loaded.
TB_FACILITYNR	FACILITY	Keep Blank or Ignore the field
TB_FACILITYBUKRS	FACILITY_COMPANY_CODE	Keep Blank or Ignore the field
TPM_COM_VAL_CLASS	VALUATION_CLASS	From DCT field "VALUATION_CLASS”
FM_FUND	FUND	Keep Blank or Ignore the field
GM_GRANT_NBR	GRANT_NBR	Keep Blank or Ignore the field
TB_SPESEN	EXPENSE_KEY	Keep Blank or Ignore the field
TB_SANST	RESERV_REASON	Keep Blank or Ignore the field
TPM_TREA_CLEARING_OPT	CLEARING_OPTION	Keep Blank or Ignore the field
TPM_TREA_CLEARING_STATUS	CLEARING_STATUS	Keep Blank or Ignore the field
TPM_TREA_CLEARING_DATE	CLEARING_DATE	Keep Blank or Ignore the field
TPM_EXT_ACCOUNT	EXT_ACCOUNT	Keep Blank or Ignore the field
TPM_TREA_CLEARING_DATE_ACT	CLEAR_DATE_ACT	Keep Blank or Ignore the field
FTR_THRESHOLD_RISK_MITIGATING	RISK_MITIGATION	Keep Blank or Ignore the field
FTR_THRESHOLD_SCHEME	LEGAL_BASIS	Keep Blank or Ignore the field
FTR_TARO_TRADE_ID	EXTERNAL_TRADE_ID	Keep Blank or Ignore the field
PRCTR	PROFIT_CENTER	Keep Blank or Ignore the field
KOSTL	COST_CENTER	Keep Blank or Ignore the field
PS_PSP_PNR	WBS_ELEMENT	Keep Blank or Ignore the field
GSBER	BUSINESS_AREA	Keep Blank or Ignore the field
TOE_HEDGING_CLASSIFICATION_OLD	HEDGE_CLASSIFICATION	Keep Blank or Ignore the field
TRPA_INITIAL_STAGE	INIT_CLASSIFIER	Keep Blank or Ignore the field
LAND1	COUNTRY	Keep Blank or Ignore the field
INTCA	COUNTRY_ISO	Keep Blank or Ignore the field
FB_SEGMENT	SEGMENT	Keep Blank or Ignore the field
TRBA_BEHALF_OF_COMPANY	ON_BEHALF_OF_COMPANY	Keep Blank or Ignore the field
TOE_HEDGING_CLASSIFICATION	HEDGING_CLASSIFICATION	Keep Blank or Ignore the field
TOE_REQUEST_ID	HEDGE_REQUEST_ID	Keep Blank or Ignore the field
FTR_CFI_CODE	CFI_CODE	Keep Blank or Ignore the field
RANL_ISIN	ISIN	Keep Blank or Ignore the field
TBA_MIC	MIC	Keep Blank or Ignore the field
FTR_CONTRACT_TIMESTAMP_UTC	CONTRACT_TIMESTAMP_UTC	Keep Blank or Ignore the field
BUPLA	BUSINESS_PLACE	Keep Blank or Ignore the field
FKBER	FUNCTIONAL_AREA	Keep Blank or Ignore the field
TPM_CUST_DIFF_TERM_VALUE	CUSTOM_DIFF_TERM_1	Keep Blank or Ignore the field
TPM_CUST_DIFF_TERM_VALUE	CUSTOM_DIFF_TERM_2	Keep Blank or Ignore the field
TPM_CUST_DIFF_TERM_VALUE	CUSTOM_DIFF_TERM_3	Keep Blank or Ignore the field
TPM_CUST_DIFF_TERM_VALUE	CUSTOM_DIFF_TERM_4	Keep Blank or Ignore the field
TPM_CUST_DIFF_TERM_VALUE	CUSTOM_DIFF_TERM_5	Keep Blank or Ignore the field
TPM_CUST_DIFF_TERM_VALUE	CUSTOM_DIFF_TERM_5	Keep Blank or Ignore the field

This BAPI has a simulation run provision. As part of the Pre-Load check when all the Syniti ADMM checks are performed, before making the production run of all the Stocks, a simulation run should be performed and all the standard BAPI errors needs to be documented.

A custom report, if required needs to be created for this. The report needs to have row reference and display the standard BAPI return messages successful as well as failed. This will make sure all the deposits successfully pass all checks.

Note: It is also assumed that the DCT will not bring in Payment Details of Stocks. This information will be loaded as part of CNV 3040 – Business Partner Counterparty and CNV . Under this CNV1185 – Security Account, Payment SI details are created and assigned to this instrument. If this is done, once the BAPI is executed, it will automatically get assigned to the deal as part of Standard BAPI processing. A Data Pre-Validation check has been introduced for this step.

Data Cleansing

For the Object 9109 – Treasury Stocks no specific data cleansing is applicable due to below reasons/assumptions:

1. The Source System is Quantum and therefore it will be a manual extract of relevant data in a DCT form

Data- Pre Load Validation Report

However, for the purpose of the object 3040 - Business Parter Counterparty, below validations reports should be available in Syniti so that the data as provided in DCT is validated before generating the pre-load file. 

Criticality	Error Message/Report Description	Rule	Output
High	Company Code is valid	Check if BUKRS is valid as per Company Codes created in the system in Table T001	Invalid Company Code
High	PRODUCT_TYPE	Check if VVSART is valid as per Product Types created in the system in Table TZPA. Value for Stock Product Type is “EAP”. If this is not, then the validation should fail.	Invalid Product Type
High	TRANSACTION_TYPE	Check if SFHAART is valid as per Transaction Types created in the system in Table AT10	Invalid Transaction Type
High	PARTNER	Check if KUNNR is valid as per Business Partners created in the system under CNV 3040 Business Partner Counterparty	Invalid Partner
High	CONTRACT_DATE	Check if DVTRAB is valid in YYYYMMDD Format and is < or = Load Date	Contract Date greater than Load Date
High	TRADER	Check if RDEALER is valid as per Traders created in the system in Table TZDEA	Invalid Trader
High	PORTFOLIO	Check if RPORTB is valid as per Portfolio Code created in the system in Table TWPOB	Invalid Portfolio Code
High	VALUATION_CLASS	Check if TPM_COM_VAL_CLASS is valid as per Company Codes created in the system in Table TRGC_COM_VALCL	Invalid Valuation Class
High	SECURITY_ID	Check if VVRANLW is valid as per Security ID created in the system in Table VWPANLA	Invalid Security ID
High	SECURITY_ACCOUNT	Check if VRLDEPO is valid as per Security Account created in the system in Table TWD01	Invalid Security Account
High	POSITION_VALUE_DATE	Check if DBESTAND is valid in YYYYMMDD Format and is > or = Contract Date	Position Value date greater than Contract date
High	PAYMENT_DATE	Check if DVALUT is valid in YYYYMMDD Format and is > or = Contract Date	Payment date greater than Contract date

Apart from the above, a custom report is required to be created for this. The report needs to have row reference for each STOCK loaded under this CNV and display the standard BAPI return messages successful as well as failed. This will make sure all the deposits successfully pass all checks. An additional check is needed if

• All dates loaded are correctly transformed into the deals created
• Payment Details are not going blank and if yes, the BAPI will return a warning for the same. If this warning appears, it will signify the BP Master Maintenance has been missed. Such records must fail and the maintenance needs to be done at the BP Master.

Conversion Process

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

Summarize High-Level Process. Include diagrams, where applicable. Include information supporting details of Extract, Transform and Load specific to the Data Object

Data Privacy and Sensitivity

Summarize Data Privacy and Sensitivity Requirements, if any

Extraction

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

1. The data exists. Syniti Migrate connects to the source and loads the data into Syniti Migrate. 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 Migrate; 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 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

Selection Screen

If applicable, this section will give the details on any selection screen parameters, including the parameter type, that are required to be entered to ensure consistent data extracts.

Selection Ref Screen	Parameter Name	Selection Type	Requirement	Value to be entered/set

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