Golden Rules
Forecast and User models
- User models in DP (SCO)
| DP | Model | Main data tables | Details | |
|---|---|---|---|---|
| DP1 | Forecast Models | F01C-1.Material:Shipto@DC | Stat. Forecast and additional data tables linked to the collaborative process | Forecast Model at Level 1 (Material:Ship-to@DC) |
| F02C-2.Material:Shipto@BU | Stat. Forecast data tables | Forecast Model at Level 2 (Material:Ship-to@BU) | ||
| F03C-3.ProductGroup:Shipto@BU | Stat. Forecast data tables | Forecast Model at Level 3 (ProductGroup:Shipto@BU) | ||
| F04C-4.ProductGroup:CustomerGroup | Stat. Forecast data tables | Forecast Model at Level 4 (ProductGroup:CustomerGroup) | ||
| User models | x. Currency Management | User model to import and apply currency conversion | ||
| x. Master table updates | One data table by Master data update | User model to register Master table with potential manual maintenance (ex. override) | ||
| x. Supersession | User model dedicated to supersession process | |||
| y. GBU User model | GBU specific | User model to store GBU dedicated data tables/date | ||
| z. Process User model | Specific processes (ex. Budget, Contribution Margin, CRM Opportunities,...) | User model to store data tables for specific processes |
| DP | Model | Main data tables | Details | |
|---|---|---|---|---|
| DP2 | Forecast Models | F01C-1.Material:Shipto@DC | Stat. Forecast and additional data tables linked to the collaborative process | Forecast Model at Level 1 (Material:Ship-to@DC) |
| F02C-2.Material:Forecast Customer@Spec | Forecast Model at Level 2 (Material:Forecast Customer@Spec) | |||
| F03C-3.Program | Forecast Model at Level 3 (Program) | |||
| F04C-4..Market | Forecast Model at Level 4 (Market) | |||
| User models | x. Currency Management | User model to import and apply currency conversion | ||
| x. Master table updates | One data table by Master data update | User model to register Master table with potential manual maintenance (ex. override) | ||
| x. Supersession | User model dedicated to supersession process | |||
| y. GBU User model | GBU specific | User model to store GBU dedicated data tables/date | ||
| y. GBU PMI model | GBU specific | User model to store specific related to PMI process | ||
| z. Process User model | Specific processes (ex. Budget, Pricing...) | User model to store data tables for specific processes |
| DP | Model | Main data tables | Details | |
|---|---|---|---|---|
| DP3 | Forecast Models | F01C-1.Material:Shipto@DC | Stat. Forecast and additional data tables linked to the collaborative process | Forecast Model at Level 1 (Material:Ship-to@DC) |
| F02C-2.Material:Shipto@BU | Stat. Forecast data tables | Forecast Model at Level 2 (Material:Ship-to@BU) | ||
| F03C-3.ProductGroup:Shipto@BU | Stat. Forecast data tables | Forecast Model at Level 3 (ProductGroup:Shipto@BU) | ||
| F04C-4.ProductGroup:CustomerGroup | Stat. Forecast data tables | Forecast Model at Level 4 (ProductGroup:CustomerGroup) | ||
| User models | x. Condition Update Datafields | |||
| x. Currency Management | User model to import and apply currency conversion | |||
| x. Master table updates | One data table by Master data update | User model to register Master table with potential manual maintenance (ex. override) | ||
| x. Supersession | User model dedicated to supersession process | |||
| x. User Scope Management | User model to set-up Demand planner scopes | |||
| y. GBU User model | GBU specific | User model to store GBU dedicated data tables/date | ||
| z. Process User model | Specific processes (ex. Budget, Contribution Margin, MTP, CRM Opportunities, Pricing...) | User model to store data tables for specific processes |
- User model naming
For technical user model = x. User model name
For specific GBU user model = y. GBU User Model
For process user model = z. User model name
Naming rules
Data Table
> Data Table should not contain more than 30 datafields.
- Data Table naming
Generic Data Table
Data Table = User model | Datatable name
Examples :
F1C.1 Material:ShipTo@DC | Forcing Loop (ETD)
MTP | DFU Data
Master Table Update
Data Table = Master Tables Update | Masterdata - "dimension" level
Example :
Master Tables Update | Business Customer - Material:Forecast Customer@Spec level
Import/Export Datable
Data Table = Import/Export | "System / Report" - "Dimension" level
Example :
Export | BW DR/BR - Material:Ship-to@DC
Calculation Naming
> Calculations should be added to the model where the output has been created. Except for GBU specific manual calculation launched by a Shortcut (for example Demand Review initialisation/validation) which should be created in the GBU user model.
Calculations = Data Table name (of output data) | 00x. "Output Data" ["All GBUs/GBU", "Past/Future/(Start > End)"]
Conditions Naming
Conditions Naming must be coherent in order to find them quickly on a list. Conditions might be grouped and so naming should start identically as well.
Linked to DFUs Management
- 'Active "data" | All GBUs' = for all Active DFUs L1/L2 in the data base.
- 'Active "data" | GBU' = for Active DFUs L1/L2 only for GBU
- 'Planned "data" | All GBUs' = for to all Planned DFUs L2 in the data base.
Note - in order to avoid any confusion:
- if your condition is directly linked to Material:Shipto:Spec@DC or Material:ForecastCustomer@Spec Master Tables as parent, you must specify "DFUs L1" or "DFUs L2"
- if your condition is for all DFUs, you must specify "| all GBUs" whereas if your condition is for one specific GBU, you must specify the GBU code "| CM" (example for Composites).
Linked to DFUs Management
Note: refer to the User Management section for more details
Sequences Naming
Sequences ran by Interfaces
Each sequence must be named based the following scheme:
- on which batch will launch it: [STATIC IMPORT] or [DYNAMIC IMPORT].
- on which frequency: [DAILY] or [WEEKLY] or [MONTHLY].
- on which scope: [AERO] or blank.
- on which related topic.
Sequences ran Manually
Each sequence must be named based on the following scheme: ["code GBU"] "Topic".
Continuous Cleaning
In order to prevent any regression, objects should be deactivated and then deleted. It is a two-steps process done on each Monthly Release. Deactivation and deletion should be done on a monthly basis based on promoted evolutions and analyzed processes.
- Deactivation step: right click on the object and select "Deactivate"; and/or rename the object with "zzz" at the beginning (depending on the object, both actions are mandatory or only the renaming one);
- Deletion step: right click on the object and select "Delete" (if "Delete" is grey out, it means that it can't be deleted because it is still linked to other active objects. In this case, the whole process needs to be re-analyzed).
Each Monthly Release should start by deleting all the deactivated objects from last Monthly Release. Then, while promoting evolutions, other objects might be deactivated. They will be deleted on the next Monthly Release.
Note: beware deletion is a definitive action which should be used wisely.