This application extract the forecasts from tool DynaSys prepared in dedicated DynaSys tables :
.Tool Leader + IT leader of the application: Celia Gonzales
How many users? Which user category ? Is there critical period ? Which geographical perimeter? Describe in one sentence: around 50 users, worldwide or 200 users / European Site
Provide some history of the application : When was it created ? What was the initial project ? Who was the original requestor ? If possible provide link to the project information
| 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
List of autorisation objects mandatory for the application.
| Authorization object | Explanation |
|---|---|
GBU (CPFCTR1_2) | ZR_*_CA_P05 |
RCS notion, IECRA is only determined for RCS records.
Get IECRA (0G_CWWE01) from masterdata C_CDSA which is distribution channel (0DISTR_CHAN) compounds with division (0DIVISION).
Determination done at Business Level (EndRoutine)
Both BU and GBU are determined at Business Level (EndRoutine) by reading mastersdata C_DYN_005 / Material with System Extension.
The link Material / BU is given by DynaSys interface part : DSO DBDYN02.
The link BU/GBU is given by C_SUBACT2 / Sub-Activity 2
BU = ERP Group of activities (C_PFCTR2)
GBU = BFC Global Business Unit (CPFCTR1_2)
Rule for RCS records was changed the 13/11/2017 (item #58). BU/GBU is now determined reading IECRA (0G_CWWE01)
The Sold-to is determined at Business Level (EndRoutine) by reading mastersdata C_DYN_014 / Ship-to with System Extension.
The link Ship-to / Sold-to is given by DynaSys (table EXP_DP_SHIPTO) and stored daily in masterdata C_DYN_014.
The commercial product is needed to be able to use attributs of masterdata C_GBR14 / GBR: Customer end-use Mat Grp (Ship-to)
The commercial product is determined by reading masterdata C_MATNR2 / Material
Sales Office, Sales Document Type, Company code can not be determined for DynaSys, they are set by constant DYN because axis are needed in reporting Sales Follow-up.
Caution Sales Office is autorization relevant for Sales Reporting (Obas, Global Sales), it has been added in Application role, auhorization object ZBI_SD
Company Code also, it will be added ( item #39)
Dependencies with other application (BW, QV, Externals tools like PVelocity or Dynasis etc...
| 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 even if BW loading is monthly) 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 Info : started at 3am changed to 6am on DynaSys Team request (07/07/2017). EXP_FORE was not ready at 3am due to longer treatments on DynaSys side |
| DPS Dynasys: META - D - 6.Reporting DynaSys (Dynamic KPIs) | PC_DPS_DYNASYS_15 | MAIN |
| Based on Table EXP_FORE_DR 05/01/2017: On DynaSys side, the treatment which prepares table EXP_FORE_DR takes more time, and now finishes around 2.45 (previously 1.45) => BW chain starter changed 2.30 am => 3.00 am 23/01/2017: The chain is planned hourly (with Calendar 14), but the loading will apply only for following time intervals (Decision Block)
21/02/2017: Run of 3 am has been cancelled because the DynaSys table was frequently empty when BW was collecting the data 31/10/2017: Still 4 runs a day, but whole loading will be done ONLY is DynaSys table EXP_FORE_DR has been updated (timestamps in table SYS_TIMESTAMP) Decision block explanation : Block 1
1) Check if Decision Block has to be bypassed
Variable can be activated If chain has to be forced to run 2) Else get loading times
Block 2
1) Check if Decision Block has to be bypassed Variable can be activated If chain has to be forced to run 2) Else get loading times. And check timestamps loaded from DynaSys (table SYS_TIMESTAMP / info for EXP_FORE_DR) If timestamps between 2 loadings, the chain has to carry on
Message send at chain's end Without issue a message is send to following users :
Message detail
Previous message
NB : message has been settled in WBP. Waiting for group email adress to manage it from WBD |
| DPS Dynasys: META - M - 6.Reporting DynaSys (MasterData) | PC_DPS_DYNASYS_23 | MAIN |
| Not YET PLANNED A remaining issue :
Issue solved :
|
| DPS Dynasys: META - D - 6.Reporting DynaSys (Obas data) | PC_DPS_DYNASYS_20 | MAIN |
| Temporarly schedulling! this chain has to be added in Obas chain or launched via an Obas event |
Detail of frequency : monthly; weekly or else
if possible, give some information on average process chain duration, amount of data loaded and total data volume example: daily process chain loaded in 30 min, weekly chain loaded in 1h15, with around 2k to 10k lines in DELTA mode for a total of 10M lines in cube. The purpose is to give a general overview of the volume of data managed y the application
| Key Figure | Estimation |
|---|---|
| ~ Average Process Chain Runtime | |
| ~ Average nb of rows loaded per load | |
| ~ Total nb of rows loaded (if full) | |
| ~ Average Runtime for 10k lines |
Give details if any historisation is done, example: keep only data greater than beginning of Y-3
Query end user documentation should be created in the public "Customer Support Wiki" space under the corresponding BW application page : BW - Application. Technical query query documentation, if necessary should be added as a sub-page of this documentation using the BW Technical Query Documentation template.
| Query | Description | Type | Role Menu | Comments |
|---|---|---|---|---|
| BW_QRY_MVDYN11_0005 | BW - DP - Forecast Accuracy (Core query) | QRY | DP - Demand Planning |
|
BW_QRY_MVDYN11_0006 | BW - DP - Demand Review (Core query) | QRY | DP - Demand Planning |
|
| QVSBS_BW_QRY_MVDYN11_0001 | BW - DP - Demand Review for SBS Dashboard (QV) | QRY | This query is used to provide Qlik View Forecast informations from APO / DynaSys and Logility. QV application : CRM Analytics | |
| BW_QRY_MVSDSO01_0006 | BW - Sales Follow-Up ALL DYN (V2) | QRY |
Give detail on all complex functionalities: list most important and/or complex KPI, query jump, alerts
Indicate if there are broadcasts and give some details on the broadcast settings.
Give the list and explanation on the known, not-solved, bugs.
Change values in Global Filter (C_GLBFILT)
Put Active = 'N' to unactive an existing loading.
Add a new line for an extra loading. Please keep the same logic, all loading times are recorded chronologically to make reading easier.
Do not forget to record your modifications in paragraph "Process Chains" in PC_DPS_DYNASYS_15 comments
RSA1 / Chain PC_DPS_DYNASYS_15
Unschedule chain before doing modification
right click => maintain message => Successful => Maintain Recipient List
Do not forget to schedule again chain + record your modifications in paragraph "Process Chains" in PC_DPS_DYNASYS_15 comments
RSA1 / Chain PC_DPS_DYNASYS_15
Unschedule chain before doing modification
right click => maintain message => Successful => Edit Document
Do not forget to schedule again chain + record your modifications in paragraph "Process Chains" in PC_DPS_DYNASYS_15 comments
Detail planned major evolution if already known. Example: complete decommissioning of application is planned in 2017 / Extension to solvay perimeter planned in 2nd semester of 2016
