General presentation
Objective of the application
BW Demand Planning Scheduling (DPS)
Tool Leader: Antoine Roy
IT leader of the application: Guillaume Thevenet
Name of project: Dynasys
PMO Project: 6046 S&OP with Dynasys - Core model and pilot
UR: UR335513 DYNASYS Sales Forecast / UR333365 DYNASYS Demand Planning
Reporting Coordinator: GONZALEZ-ROUX, Célia <celia.gonzalez-roux@solvay.com>
Usage information
Number of users: tbd
Critical period: none
Geographical perimeter: worldwide
InfoArea:
- Demand Planning Scheduling
IA_DPS
Process chain Display Component:
- 127 - PROJECT - DPS - Demand Planning Scheduling
COMP_DPS_PC
Roles & Access
Roles and access
| Role Id | Role Title | Explanation |
|---|---|---|
| ZR_RCS_CA_M52 | DP - Demand Planning | Role Menu Dynasys Currently (Nov 2016), only 2 queries published in this role |
| ZBI_RCS_DP_A02 | Demand Planning - Dynasys | Role utilisateur Dynasys Authorization object ZBI_DPS
|
| ZBI_RCS_DP_A03 | Demand Planning - Dynasys Keyuser | Authorization object ZBI_DPS_K
|
See also file maintained by Authorization team : BW Catalog of Roles / link: https://drive.google.com/open?id=10GEfKYqrT1eeTO_uHYAheL1GX7L5y_pvH0KQU64qh5I
Authorization objects
List of autorisation objects mandatory for the application.
| Authorization object | Explanation |
|---|---|
GBU (CPFCTR1_2) | ZR_*_CA_P05 |
Dataflow presentation
Overview
Reporting Part DataFlow
Functional and Technical rules on Workbench
General presentation
Most DSO / Cubes are used to extract data to the Dynasys tool.
Data are extracted from a source outside BW dynasys (it could be another BW application, ECC table, query etc), loaded into DSO and/or Cubes. Then data are transformed through an APD and loaded into flat files which are loaded into the Dynasys tool.
Useful file to understand dataflow from APD to source, and check filters applied all along the dataflow:
Conversion in KG unit
Only conversion in two steps are managed in Dynasys (UOM then T006; conversion in Three or more steps are not managed in Dynasys and should be updated by the business)
The different step of the routine are the following:
Creation of internal table
Creation of internal table between T006and T006D (T006D provide the fields MSSIE, base unit of a dimension DIMID)
Creation of internal table for DSO UOMCMAT2, filled with both conversion from UOM to UNIT and UNIT to UOM and joined with T006 to get Dimension DIMID
Conversion in KG (if possible)
Quantity needs to be converted to KG.
The routine check:
- if Quantity is already in KG, nothing is done
- if Quantity is equal to 0, Unit is set to KG
- if Unit is in dimension MASS (the same dimension as the one for KG), then conversion is done in KG using T006
- if Unit is not in MASS, we check in UOMCMAT2 if we have a direct conversion from UNIT to KG
- if no direct conversion exists, we check if there is a conversion from Unit to any MASS unit and after conversion we apply another conversion from MASS to KG using T006
If no conversion exists, Unit remains empty and will be manage as an error (see below)
Catch missing conversion
The flow uses Error DTP. When Unit can't be converted, the routine raise an exception "cx_rsrout_skip_val". The error is loaded in the error queue with text from the message class ZDYN_CONV_ERROR
Not all error will be fixed. Most of these error are linked with BU outside of Dynasys perimeter.
Transformation from ZWPPTDYS ECC table
Documentation
Functional specification are available in the following spreadsheet:
In the following tabs:
ECC process
The ZWPPTDYS is loaded on ECC side through the transaction ZWPPTMRPOUT (which load the ZWPPMRPOUT program)
This transaction use the program RMDMRPEXTRACT01 which create a list of material to extract.
Then, for each material, the program RMDMRPEXTRACT01 run through the exit ZCL_PP_IM_MD_SR_LIST_EXTRACT.
This exit reads the database for each material and loads in memory several table among which is table IT_MDPSX.
Then, through specific code, the table ZWPPTDYS is loaded from IT_MDPSX using method IF_EX_MD_SR_LIST_EXTRACT~EXTRACT_SR_LIST_INFOS
BW Process
This table is loaded from PF1/WP1 into WBP in the DPDYN02 DSO (Propagation) and then in the DBDYN14 (Propagation).
All rules are available in the following transformation
ODSO DPDYN02 -> ODSO DBDYN14
See short description of this rules below
Begin of global
- Declaration of types
- Declaration of table & variable
Begin of routine
- Declaration of field-symbols
- Refresh internal table
- Clear variable
- Get Source system using class oref_dynasys_utils, method get_source_systems
- Get Systems extensions using class oref_dynasys_utils, method get_system_extension
Phase 0: Table preparation
Load each required table into hashed table.
Phase 1: DSO Enrichment
Depending on value of field c_delkz:
- Step 1: Ship/Rec Shipto ID (PARTNER_CUST_ID)
- Step 2: Ship/Rec plant ID (PARTNER_PLANT_ID)
- Step 3: Complement ID (COMPL_ID)
- Step 4a: BU Source
- Step 4b: BU Destination
- DOC_TYPE
- ITEM_CATEG
Remarks:
- Step 1 to 4 depends on result of previous step. No simplication is done in the code.
- If in Step 1, PARTNER_CUST_ID equals source_field-X, in step we will use PARTNER_CUST_ID and not source_field-X
- This means any error in the code will raise error in further rules. This is a choice in all the routine and this logic must be kept.
- For Step 1,2,3, value are loaded without modification in variable ended by*_origin (and later in the script, these value are saved in dedicated infooject to ease debugging)
- Even useless rules are loaded to keep homogeneity in the code, example: loading a field at null even if this field is already null.
Between phase 1 and 2:
Fields are assigned for expert routine (source to result)
System extension is added to field (Material, Plant, Partner plant ID etc) and remove unneeded 0 using function conversion_exit_alpha_output. These new value are stored in dedicated infooject to e used later in Phase 2 of script
A check is done to find any correspondance with content of specific tale zmatplant and zmatvendor
Phase 2: Flag determination
Once Phase 1 is finished, depending on DELKZ value, several fields are loaded:
- File flag fields: these flag will be used in APD to dettermine which data needs to be loaded in flat file
- Flowid identify which rule has been applied regarding the specification
- SKU R in FS (C_FLGSRF), filled from PARTNER_CUST_ID / PARTNER_PLANT_ID / COMPL_ID depending on flow id value.
All rules are checked one after the other. Once one check is validated, the check stop
Remarks: c_pfctr2 = BU SOURCE and c_recptbu = BU DESTINATION
Global Filter C_GLBFILT
Stream: DPS
Main filter : C_PFCTR2 (BU) and PLANT
These 2 filter may be extended regularly due to the extension of Dynasys perimeter (RCS in january 2016, Soda in june 2016)
Other filters: C_MGN_ACC, DEL_TYPE, ITEM_CATEG, MATL_TYPE, REASON_REJ, REC_TYPE
Usage of error stack
Error stack are used in relation with Unit and Currency conversion.
Most if not all error are linked with BU outside current perimeter of project and won't be fixed.
Each DTP has the following settings:
DTP
Error DTP
Package Size is lower than Maximum Number of Errors per Pack as the number of error won't decrease (example in may 2016: 2567 records from DP_PUSL2 to DPDYN22, 17618 records from DPSD001 to DPDYN21 and 530 from DSO_DLV1 to DPDYN21)
Specific table
Two specific table have been created in SM30 to manage following rules
The 2 tables are:
- ZMATPLANT
- ZMATVENDOR
Two customised transaction have been created in SE93:
- ZMAINT_MATPLANT
- ZMAINT_MATVENDOR
"UD connect" connection
Dynasys is a MSSQL tool, BW WBP is on an AIX server. No ODBC driver exists between BW and MSSQL server in Linux / AIX.
This problem was solved setting an UD connect connection
User ID for Dynasys connection is Dynasys_Interface / Password : 791hB6zi8Rk1DBSV3uNG
Main server:
- Dynasys Production server: WDCCLSLBV01\SLV1_DBPRD
- Dynasys Development server: WDCCLSLBV01\SLV1_DBDEV
Remark: contact for management of UD Connect connection is Adaggio team.
Management of file through APD
Files are created in the following folder in AL11
/exploit/depart/Dynasys
To avoid problem with quotes, routines have been added in APD to encapsulate existing quotes in description fields
Data loadings
Loading frequency
Daily: launched by the LO_DAILY_MASTER_DATA process chain around 6:00 AM each day.
- PC_DPS_DYNASYS_01
DPS Dynasys: META - D - Daily Meta-Chain
Weekly: launched on saturday, 9:00 AM
- PC_DPS_DYNASYS_03
DPS Dynasys: META - W - Weekly Meta-Chain - Remark: Dynasays tool is awaiting data between 6:00 AM and 8:00 AM
Yearly: launched the 15th of January at 9:00 AM
- DPS Dynasys: META - Y - Cleaning Historical Data
PC_DPS_DYNASYS_04
Flag end of process chain: For both daily and weekly process chain, at the end of APD execution, a command is sent to the Dynasys tool. This command must be executed in productive environnement only and is not effective in other environnement (it will raise an error). The Decision process prevent execution of the command in non productive environnement.
| Process Chain | Code | Type | Frequency | Comments |
|---|---|---|---|---|
| DPS Dynasys: META - M - 6.Reporting DynaSys (Snapshots) | PC_DPS_DYNASYS_09 | MAIN |
| Based on Table EXP_FORE (daily update, by 1.45am) The SnapShot month (End of Month View/C_FCSTMTH) is automatically set to previous month. Global filter variable (C_GLBFILT) DPS/PHOTO_MTH can be used to fix another SnapShot month. Caution : do not launch this chain several times a month without cleaning previous loadings |
| DPS Dynasys: META - D - 6.Reporting DynaSys (Dynamic KPIs) | PC_DPS_DYNASYS_15 | MAIN |
| Based on Table EXP_FORE_DR (daily update, by 1.45am, even if BW loading is monthly))
|
| DPS Dynasys: META - M - 6.Reporting DynaSys (MasterData) | PC_DPS_DYNASYS_23 | MAIN |
| Not YET PLANNED |
Average performance
Most DSO & Cubes are loaded in full mode due to the low amount of data and/or calculation rules.
Exception:
- DPDYN21: 2,1 M lines loaded in delta mode
- DPDYN22: 2,2 M lines loaded in delta mode
Average duration (may 2016):
- Daily chain usually run for 25 to 45 minutes.
- Weekly chain usually run for 40 minutes to 1,5 hour
Remark: on going evolution will transfer most process in the weekly chain to the daily one (increasing duration of daily chain and decreasing weekly chain).
Historization
No data below 3 year before beginning of current year are kept. Ex: in Aprl 2016, only data greater than or equal to 01.01.2013 are loaded in Dynasys.
Reporting
Queries Documentation or user guide
No dedicated documentation on queries
Main queries
| Query | Description | Type | Role Menu | Comments |
|---|---|---|---|---|
| BW_QRY_MVDYN11_0005 | BW - DP - Forecast Accuracy (Core query) | QRY | DP - Demand Planning | Version 1. Version 2 is planned mid December 2016. |
| BW_QRY_MVDYN11_0002 | BW - DP - Forecast Accuracy (Core query) | QRY | Previous FA. query to be deleted | |
| BW_QRY_MVDYN11_0001 | QRY | Previous Demand Review => query to be deleted | ||
BW_QRY_MVDYN11_0006 | BW - DP - Demand Review (Core query) | QRY | DP - Demand Planning | Version 1 (some GBU affectation missing. DBDYN02 issue) Version 2 is planned end November 2016. |
Main functionnalities
n/a
Broadcast
n/a
Maintenance
Known bugs
Data loading in DSO DBDYN33
DSO DBDYN33 is loaded by 2 DTP in this order :
- DPDYN22 => DBDYN33 - Full with filter
- DBDYN18 => DBDYN33 - Full with filter
Sometimes an error appears with a dump when DTP DBDYN18 => DBDYN33 is launched.
In this case, to fix the issue, follow the steps bellow :
- Delete data in DSO DBDYN33
- Launch manually DTP "DPDYN22 => DBDYN33".
- Repeat the process chain step in error DTP " DBDYN18 => DBDYN33".
Customer Sales empty or inexact (C_CUSTSAL or 0CUST_SALES)
Due to loading routine in the propagation level of DPSDSO05 / DSO_SD02 which are loaded in delta mode, this field is not correctly updated
Customer Sales attributes empty or inexact (0CUST_SALES)
Modification on ZZ fields are not taken by the delta. Only full loading can fix this problem.
A specific extractor has been created based on KNVP table from WP1_400 in order to feed ZZ fields correctly.
This data loading is done everyday with the process chain ZPC_MD_ATTR_RCS.
After that we have to retreat data stored in DSO DPDYN22 to update ZI PArtner only if we have a modification. TO do that a new transformation have been created :
A new DTP have been created too, launching it ZI partner is reading into master data 0CUST_SALES and updated in DPDYN22.
This DTP is in daily and weekly Dynasys process chain :
- PC_DPS_DYNASYS_08
- PC_DPS_DYNASYS_12
Update of UD Connect datasource
Data loaded from Dynasys tool are using "UD connect" connection type (Java).
Datasource updated in Udconnect can encounter problem in WBQ / WBP due to Metadata cache (whereas everything is ok in WBD)
S:RSSDK:300 Field GHFF_QUANTITY is not a member of /BIC/CADTS_ EXP000010000001
Message no. RSSDK300
Ask Addagio team for a « cache clearance for quality / production system (BW) on this JCO connection”
This issue can also appear in WBD on an existing datasource, when a new field is added in the Dynasys table.
Ask adagio to clear the cache in all systems, otherwise you will get the issus when moving the datasource in WBQ/WBP
Recurring procedure
n/a
Planned Evolution
Several minor evolution managed by the Dynasis project team

























