The new wiki link for this data flow is here:

Technical Documentation - Sales & distribution - OTIF report

Please update the doc there and no longer here.

General presentation

OTIF is sub function of Global Sales (analysis of all documents for sales handling costumers or transfer with plants and GBUs).

The term OTIF means On Time In Full, that is an analysis if the delivery was done in correct time and the quantity was delivered as requested, considering the tolerances. 

This sub function works with data handled by Global Sales about sales order lines, scheduled lines and deliveries.

The load is done daily using the process chain scheduled with delta process inside Global Sales Process Chain. 

List of contacts

• Functional Owner of this report: Jose Pablo Leyva (Supply Chain Excellence Project Leader) and Raphael Forlini (Logistics expert)
• IS Reporting Leader: Diogo Paiva (IS Supply Chain M&S Data)
• BW Coordinator: Guillaume Thevenet  (SBS IS) 
• BW Developer: Nestor Araujo (SBS IS) , Mathieu Lambert (SBS IS)

Objective of the application

• The main purpose is to have a detailed core report for all GBU's and also be the data source for SCE Dashboard in Qlikview. 
• Analyze the behaviour of sales processes since the goods issue until the shipment end process.
• Understand the reasons why the process was not finished with OTIF 
• One common & consolidated reporting space for the group
• Rationalization of the “live” solutions and reduction of evolutions requested
• Maintainable and sustainable solution.
• Enabler for productivity actions on OTIF process
• Drillable solution - allowing possibility to detect & analyse problems by showing the link from aggregated figures down to document in SAP.
• Few “core” queries/workbooks design for application (=> Use BW analysis functionalities and not just as extractor).

History

The OTIF analysis is generated in BI 4 with data based on PPS application just for Rhodia side and load QV application for SBS SCE (Supply Chain Excelence).

The OTIF for Solvay was created in 2016 in BW after OBAS implementation and it is the source for SBS SCE also.

Usage information

Around 300 users, worldwide with daily update 

General Rules

Functional Specificationsain Rules

SCE defines 6 different OTIF indicators:

• OTIFD CR : On Time Delivery in Full (Customer Request) : Concatenates In full Requested and OTD CR
• OTIFD FC : On Time Delivery in Full (1st Confirmed) : Concatenates In full Confirmed and OTD FC
• OTIFD LC : On Time Delivery in Full (Last Confirmed) : Concatenates In full Confirmed and OTD LC
• OTIFS CR : On Time Shipment in Full (Customer Request) : Concatenates In full Requested and OTS CR
• OTIFS FC : On Time Shipment in Full (1st Confirmed) : Concatenates In full Confirmed and OTS FC
• OTIFS LC : On Time Shipment in Full (Last Confirmed) : Concatenates In full Confirmed and OTS LC

All calculation in this query is managed at Order line level. When several schedule lines matching with one same order lines we consider the sum for quantities and maximum for dates.

1 - Rules for OTIF Calculation

1.1 - On Time Delivery "On Time Delivery: it means that the calculation is based on date of arrival, they compare an achieved arrival date with a target arrival date. Achieved Delivery Date:

Achieved Delivery Date

=If([Transportation mode]="PICK UP" Or [Order Document Type Code]="KE";[V_Max Actual GI Date];If(IsNull([V_Max End of Shipment Calculated]);[V_Max Actual GI Date];[V_Max End of Shipment Calculated]))

For “PICK UP” transportation mode, Rhodia (WP1) : Last transfer order confirmation date for the order line --> FIELD LTAP-QDATU else Last Good Issue date

For “PICK UP” transportation mode, Solvay (PF1) : Last Good Issue date

For any other transportation mode : The last “Actual Shipment end” if it exists else the last “ planned shipment end” if it exists else the last “Actual good Issue”

OTD CR: If Difference between Achieved delivery date and Order line requested delivery Date is lower than – Early tolerance then “EARLY” else if Difference between Achieved delivery date and Order line requested delivery Date is greater than Late tolerance then ""LATE"" else ""OTD""

=If([Transportation mode]="PICK UP";If(DaysBetween(Last Req Delivery];[Achieved Delivery Date])<0;0;DaysBetween(Last Req Delivery];[Achieved Delivery Date])))

OTD FC: If Difference between Achieved delivery date and Orderline 1st confirmed delivery Date is lower than – Early tolerance then “EARLY” else if Difference between Achieved delivery date and Order line 1st conf delivery Date is greater than Late tolerance then ""LATE"" else ""OTD""

=If([Transportation mode]="PICK UP";If(DaysBetween([V_Max 1st ATP];[Achieved Delivery Date])<0;0;DaysBetween([V_Max 1st ATP];[Achieved Delivery Date])))

OTD LC: If Difference between Achieved delivery date and Order line last confirmed delivery Date is lower than – Early tolerance then “EARLY” else if Difference between Achieved delivery date and Order line last conf delivery Date is greater than Late tolerance then ""LATE"" else ""OTD"" "

 

1.2 - On Time Shipment "On Time Shipment: it means that the calculation is based on date of good issue, they compare an achieved shipment date with a target shipment date (calculated in SAP from requested delivery date, 1confirmed delivery date and last confirmed delivery date). Achieved Shipment Date: For “PICK UP” transportation mode : Last transfer order confirmation date for the order line --> FIELD LTAP-QDATU else Last Good Issue date For other transportation mode : The last “Actual GI” date

 

Achieved Shipment Date

=If([Transportation mode]="PICK UP" Or [Order Document Type Code]="KE";[V_Max Actual GI Date])

OTS CR: If Difference between Achieved shipment date and Order line requested GI Date is lower than – Early tolerance then “EARLY” else if Difference between Achieved shipment date and Order line requested GI Date is greater than Late tolerance then ""LATE"" else OTS.

=If([Transportation mode]="PICK UP";If(DaysBetween([V_Max Last Req GI]; ";[V_Max Actual GI Date] )<0;0;DaysBetween([V_Max Last Req GI]; ";[V_Max Actual GI Date]

 

OTS FC: If Difference between Achieved shipment date and Order line 1st confirmed GI Date is lower than – Early tolerance then “EARLY” else if Difference between Achieved shipment date and Order line 1st Conf GI Date is greater than Late tolerance then ""LATE"" else ""OTS""

=iF([Transportation mode]="PICK UP";If(DaysBetween([V_Max 1st ATP GI]; ";[V_Max Actual GI Date] <0;0;DaysBetween([V_Max 1st ATP GI]; [V_Max Actual GI Date] )))

 

OTS LC: If Difference between Achieved shipment date and Order line last confirmed GI Date is lower than – Early tolerance then “EARLY” else if Difference between Achieved shipment date and Order line Last confirmed GI Date is greater than Late tolerance then ""LATE"" else ""OTS"""

 

=iF([Transportation mode]="PICK UP";If(DaysBetween([V_Max 1st ATP GI]; ";[V_Max Actual GI Date] <0;0;DaysBetween([V_Max 1st ATP GI]; [V_Max Actual GI Date] ))) 

 

1.3 - Tolerances:

"Number of days based on Transportation Mode (Order Shipping Condition) OCEAN = 7 RAIL = 3 BARGE = 3 INTERMODAL = 2 ROAD = 1 AIR = 0 OTHER = 0 "

DAYS DELAY NET (APPLY THE TOLERANCE)

TOLERANCES by Shipping Conditions

AB";"AC";"AE";"AF => 7 days   (ocean)

AJ => 1 day  (LTL)

AK AH AI => 0  (FTL)

AU AP => 3          (Barge / Rail)

AV => 2       (multimodal)

“AL” “AW” “AX” => 0 999 days)     (Pick Up)

=If([OTD CR - Delay Days]=999;999;If([OTD CR - Delay Days]=0;0;If(Abs([OTD CR - Delay Days])<=[Tolerance Days];0;If([OTD CR - Delay Days]<0;[Tolerance Days]+[OTD CR - Delay Days];[OTD CR - Delay Days]-[Tolerance Days]))))

1.4 - Exceptions:

"Customer Pick Up: uses Last transfer order confirmation date in calculation Customer Pick Up Early = OTIF Order Non OTIF Reason code starting with 7 = OTIF "

1.5 - IN FULL

In Full Calculation "In Full Request Order Quantity fits with Delivery Quantity In Full Confirmed Scheduled Line Confirmed Quantity fits with Delivery Quantity "

IN FULL REQUESTED – IFR

(Order line qty – Sum Delivery quantity) + tolerance that comes from the sales order

IN FULL CONFIRMED – IFC

(Sum Scheduled Confirmed Qty by sales order item  – Sum Delivery quantity) + tolerance that comes from the sales order

1.6 - LEAD TIMES

 

7 lead-times have been defined by SCE (to be challenged for rationalisation)

Leadtime 1 : The Lead-time is the difference, in days, between the customer PO Date (order line level - VBKD-BSTDK), and the requested material availability date (Max in the scheduled line level).

=DaysBetween([V_Max Cust PO];[V_Max Req Material Availability])

Leadtime 2 : The Lead-time is the difference, in days, between the customer PO Date (VBKD-BSTDK), and the achieved GI date

=DaysBetween([V_Max Cust PO];[Max Actual GI Date])

Leadtime 3 : The Lead-time is the difference, in days, between the customer PO Date, and the requested delivery date.

=DaysBetween([V_Max Cust PO];[V_Max Last Req Delivery])

Leadtime 4 : The Lead-time is the difference, in days, between the customer PO Date, and the achieved delivery date

=DaysBetween([V_Max Cust PO];[Achieved Delivery Date])

Leadtime 5 : The Lead-time is the difference, in days, between the creation date and the last customer req Goods Issue date

Leadtime 6 : The Lead-time is the difference, in days, between the creation date and the schedule line 1st ATP (confirmed) GI date

Leadtime 7 : The Lead-time is the difference, in days, between the creation date and the actual GI date

1.7 - DOCUMENTS TYPES

The document types to be considered are:

GCTA	Standard Order
KE	Consig issue
SB	SB Third-p.dir order
SO	SO Rush Order
TA	Standard Order
TAF	Standard Order (FPl)
TAM	Delivery Order
TAV	Standard Order (VMI)
TD	TD Standard Order
TDIV	TDIV Misc Op
TSA	Telesales
ZITI	Sales Order ITI BR
ZORB	Standard Order BR
ZOUT	Other Outputs BR
ZPVA	ZPVA Ord.immed.ship.
ZVEX	Fut. Dely Invoice BR
ZVEY	Fut. Dely Shipmnt BR
NB	Standard PO
UB	Stock transport ord.

1.8 - QUERY FILTER

1.8.1 – Flag Intra GBU = NO

1.8.2 – Reason for rejection: VBAP-ABGRU is null or equal 98

 

Roles and access

List of application role + menu role  and explanation if we have several applications role with specials rules.

Authorization objects

List of authorization objects mandatory for the application.

See also file maintained by Authorization team : 

• BW Catalog of Roles: Authorization catalog
• BW Authorization:       BW Authorizations

Statistics by infoproviders

Statistics by queries

Dataflow overview

Multi Provider MVSDSO50 - OTIF Global - DATA FLOW

This multi provider is used to manage the OTIF indicators for all sales processes (Solvay & Rhodia)

MP Details - characteristics

Details - Key Figures

Cube CRSDSO10 - OTIF Sales (Solvay)                                        Cube CRSDSO50 - OTIF Sales (Rhodia)

Multi Provider MVSDSO51 - OTIF Transfer Global - DATA FLOW

This multi provider is used to manage the OTIF indicators for all sales and transfer processes (Solvay & Rhodia)

Cubes:

CRSDSO54: PO: OTIF Transfer (Rhodia) 

As part of the change # 4028391,excluded return items from this cube .Added filter in below DTP's to exclude Return Items.

 DTP: DBSDSO91 -> CRSDSO54 (Rhodia)

DTP: DBSDSO91 -> DBSDSO9E (Rhodia)

DTP: DBSDSO98 -> CRSDSO24 (Solvay)

DTP: DBSDSO98 -> DBSDSO9F (Solvay)

CRSDSO24: PO: OTIF Transfer (Solvay) 

As part of the change # 4028391,excluded return items from this cube .Added filter in below DTP's to exclude Return Items.

 DTP: DBSDSO91 -> CRSDSO54 (Rhodia)

DTP: DBSDSO91 -> DBSDSO9E (Rhodia)

DTP: DBSDSO98 -> CRSDSO24 (Solvay)

DTP: DBSDSO98 -> DBSDSO9F (Solvay)

CRSDSO50: SO: OTIF Sales (Rhodia) 
CRSDSO10: SO: OTIF Sales (Solvay) 

Multi Provider MVSDSO60 - MP Sales & Transfer for OTIF with Order Book dates - DATA FLOW

This multi provider is used to manage the OTIF indicators for all sales and transfer processes (Solvay & Rhodia) matched with order book snapshot data, in order to know the opened orders 

Details - DSO's used in MP

This multi provider is based on two cubes that receive data from DSO's that mix data from OTIF and order book snapshot. The DSO's used here are: DBSDSO9A (OTIF Sales & order book Solvay), DBSDSO9B (OTIF Sales & order book Rhodia), DBSDSO9E (OTIF Transfer & order book Solvay), DBSDSO9F (OTIF Transfer & order book Rhodia)

MP Details - Characteristics

MP Details - Key figures

Functional and Technical rules on Workbench + Reporting

Rules & Explanations

Main documentation:

Preparation

Global Sales Presentation

Design

OTIF Requirements

OTIF Specification for Rhodia (BI4)

Deployment

OTIF Proofing

Business Rules

Using distribution channel and division from material, get the IECRA code in master data C_CDSA

Using IECRA code, get the sub-activity in master data g_cwwe01 

For Solvay

using business area, get the technical business area in master data c_techba

The function above is used to fill zeros left

The code below takes the GBU code from master data sub-activity (g_cwwe01)

Calculation Rules

Define the ship end date type according to the content of fields actual shipment, planned shipment of GI date

Define the good issue date reference

Redefine the good issue date reference when the order is a pickup

Define the achieved delivery date and achieved shipment datte

Determine In Full requested considering the lower and upper tolerance 

Generate the in full requested detailed with terms light, heavy or yes 

Determine In Full confirmed measure considering the lower and upper tolerance 

Generate the in full confirmed detailed with terms light, heavy or yes

Determine the differences between delivery quantity and requested quantity

Generate on time delivery customer request (OTD CR)

Consider special NON OTIF reasons as OTIF

Generate group of delays for OTDCR

Generate OTDCR delay days

The same rules are applied for OTDFC, OTDLC, OTSCR, OTSFC, OTSLC just changing the date to be considered, see below:

For OTDFC uses the dates → v_dif_date = v_fstatp - v_shp_eact (difference between max first ATP and shipment end date)

For OTDFC uses the dates → v_dif_date = v_lstatp - v_shp_eact (difference between max last ATP and shipment end date)

Define the dates used in OTS CR (ON TIME SHIPMENT Customer request)

For OTSCR uses the dates  → v_dif_date =  v_lstrqgi - v_gi_date (difference between max actual GI date and last req delivery)

For OTSFC uses the dates  →  v_dif_date =  v_firstgi - v_gi_date(difference between max actual GI date and first ATP GI)

For OTSLC uses the dates  →  v_dif_date =   v_lastgi - v_gi_date (difference between max actual GI date and last ATP GI)

Generate OTIF necessary comment or reason 

Generate NON OTIF Type 

Determine LEADTIME calculations

Leadtime 6 : LeadTime FirstCommitted = Order line creation date - schedule line 1st ATP (confirmed) GI date

Leadtime 7 : LeadTime Actual = Order line creation date - actual GI date

Leatime 8 : Last Req GI date - Customer PO 

Leatime 9 : First Req GI date - Customer PO 

Unit conversions

The Unit conversion is done in the Bex queries (Quantity Conversion Type), after user chooses the unit conversion on reports

Transactionnal data are stored in sales unit

• if base unit / po unit is managed in dimension MASS, conversion within table T006 works well

• if base unit / po unit is not managed in dimension MASS, conversions for KG/LB/TO have to be managed on ERP side (MM03 / Alternative Conversion).

There are many "special" units on Solvay ERP, ie: 1KG, 1TN, VKG, KRE, 

Important : 

Quantities are not converted when loading data, and are not store into cubes (The conversion is done when running the report)

So, if a conversion is missing for a material ask the material referent to 

1- manage the conversion on ERP Side by managed the material master (MM03) / unit of measure tab

2- the day after, when the DSO UOMCMAT2 is filled, the conversion is applied in the reports. It applies to whole data without any reloading.

The conversion type created by Global Sales queries is QCT_MATNR4 (see below the setup for it).

BW Quantity Conversion

BW Updated Qty Unit by Material

Dependencies with other applications

• It was created some master data in order to have the attributes shared with several applications: Sales Order line (C_ITM_SD), PO Line (C_ITM_GS)
• Data is consumed by Qlikview dashboard. The loadings in QV are daily. It runs a fixed scheduled, the loadings must be finished when the next start.
• There is an integration with SPRINT (purchase schedule lines) in order to take the PO schedule lines and identify all the transfers
• There is a link with TIERS in order to get the main shipment for each delivery

Data loadings

Info providers and objects loaded

1 - Main Process Chain

This process chain is responsible to trigger and syncronize all Global Sales processes chains for Solvay and Rhodia. It is scheduled to run every workday inside the Daily process chain (RSP_DAILY) after general master data PC, around 3AM (French time) and TIERS.    

Sales - Part Solvay: PC_SD_MAIN (SD - Main Process Chain - UPTDATE DATA -)

Sales - Part Rhodia : PC_GLOBAL_SALES_MAIN (PC: Global Sales: Main (Rhodia))

Transfer - Part Solvay: PC_OBAS_TRANSFERS_MAIN (OBAS: Transfers Orders Main chain)

Transfer - Part Rhodia: PC_GL_SALES_MAIN_PO (PC: Global Sales: Main transfers (Rhodia))

2 - Propagation Layer

This process chain is responsible to run the loads between source system and first layer in BW.

For OTIF process, all the processes in propagation layer are run in general Global Sales Process Chain

3 - Business Layer

This process chain is responsible to load the second and third layers from propagation layer.

Main Processes for OTIF    

PC_GL_SALES_DBSDSO20 (SD - Global Sales: OTIF (Solvay)) and PC_GL_SALES_DBSDSO60 (SD - Global Sales: OTIF (Rhodia))

PC_GL_SALES_DBSDSO9A (SD - Global Sales: Sales OTIF w/ Orderbook (Solvay)) and PC_GL_SALES_DBSDSO9B (SD - Global Sales: Sales OTIF w/ Orderbook (Rhodia))

4 - Reporting Level

This process chain is responsible to load all the cubes 

The must important ones are:PC_GL_SALES_CRSDSO10 (SD - Global Sales: Cube CRSDSO10 OTIF Sales (Solvay)) and PC_GL_SALES_CRSDSO50 (SD - Global Sales: Cube CRSDSO50 OTIF Sales (Rhodia))

PC_GL_SALES_CRSDSO30 (Global Sales: CRSDSO30 (OTIF w/order book Solvay)) and PC_GL_SALES_CRSDSO70 (Global Sales: CRSDSO70 (OTIF w/order book Rhodia))

5 - Master data

The most part of master data loads are splitted inside business process chains

6 - Text & maintenance

 This process chain is responsible to load all the master data texts in BW.

Loading frequency

Daily loading inside the daily process chain

Average performance & monitoring

Daily process chain is loaded in 2 hours with around 30k lines in DELTA mode for a total of 10M lines in cubes. 

See below an extract of 1 month of monitoring

For details about application load monitoring, click in following link: Application Monitoring

Record Keeping

User defined that 3 full years stored is enough to be maintained in BW.

There is no automatic process to remove historical data, so any request about historical deletion should be done by user using Freshdesk ticket.

Modeling

Virtual Layer

MVSDSO50

MVSDSO51

MVSDSO60

Main datasources based on SAP tables

• 2LIS_11_VAHDR - Sales Document Header Data
• 2LIS_11_VAITM - Sales Document Item Data
• 2LIS_11_VASTI - Sales Document Item Status
• 2LIS_11_VASCL - Sales Document Schedule Line
• 2LIS_11_VAKON - Sales Document Condition
• 2LIS_11_V_SSL   - Sales order delivery
• 2LIS_12_VCITM - Delivery Item Data
• 2LIS_13_VDITM - Billing Document Item Data
• 2LIS_13_VDKON - Billing Document Condition
• DTS_BW_EKKO_EKPO - PO Order & details (EKKO/EKPO/EKET)
• DTS_BW_VBAK_VBAP - Sales Order & Items

Main dimensions for the data

• C_ITM_SD    - Order Line

• C_ROUTE     - Route

• C_SHIPNU2  - Shipment Number
• C_DELITM2  - Delivery Item
• C_SHIPCD2  - Shipping conditions
• 0TRZONE     - Transportation Zone 
• C_GBR11      - GBR: Customer gbu account type (Sold-to)
• C_GBR12     - GBR: Customer gbu account type (Payer)
• C_GBR13     - GBR: Customer gbu account type (Ship-to)
• C_GBR14     - GBR: Customer end-use Mat Grp (Ship-to)
• C_GBR15     - GBR: Ship-to KA
• C_GBR19     - GBU Material Group
• C_GBR20     - GBU Material Sub-group
• C_GBR21     - GBR Enterprise segment (CS)
• C_CUSTSAL - Customer (Sales View)
• C_CUSTSA2 - Customer sales area (ship-to)
• C_CUSTSA3 - Customer Sales area (Payer)
• C_ITM_GS    - PO / SO order line

Reporting

Calculated & Restricted key figures

PS: same calculated and restricted key figures were created for MVSDSO51 and MVSDSO60 multi providers.

Main queries

• None

Maintenance

Known bugs

• Sometimes the unit conversion is not done in query due the unit is not mapped correctly in table UOMCMAT2 by material.

Recurring procedure

• When the process chain fails, the process type must be analyzed and repeated if possible.
• Sometimes a full load by period is required by user in order to syncronize all global sales data.

Planned Evolution

• The Global Sales is deployment phase and sometimes the GBU key user requests additional informations to be added in project.
• The New field ZI Partner will be available for reporting in the queries:Queries- BW_QRY_MVSDSO51_0001 and QVSCE_BW_QRY_MVSDSO51_0001 with the requirement in the FD 4699751.

Useful transactions to be used for checking data

https://wiki.solvay.com/display/TECHREP/BW+Authorizations?src=contextnavpagetreemode