Access Management

Data Flow

Overview

Sales Order Book

Sales Order Book is a presentation in a detailed level of all sales orders placed in SAP/PF1 system, being possible to determine:

• Sales order on going and open
• Sales Orders Shipped Not Billed
• Sales Orders invoiced

The sales order book is defined at most detailed level. That means at the schedule line level. The concept of line is very important to understand how the order book works. Each sales document can generate an item, the combination of document number / item number is a line.

To generate the sales order book the documents lines below are used:

• Order line
  • Schedule line
    • Delivery line
    • Shipment⁽¹⁾
    • Billing line

Document line generation:

• Each sales order document can generate n order line.
• Each scheduled line can generate n delivery document.
• Each delivery document can generate n delivery line.
• Each delivery line can generate n billing document.
• Each Billing document can generate n billing line.

⁽¹⁾Global Sales doesn't use the shipment line. Informations which are necessaries to generate the sales order book are at the shipment to the end customer in the header level. For more detail please refer to Definitions and concepts (Shipment to the end customer).

The data flow is generated from Performer Suite. The data visualization is done on the multiprovider MVSDSO41 (MP: Sales order book).

Global Sales data layers:

• Propagation Layer
• Business Layer
• Reporting Layer
• Virtual Layer
• Master Data

Propagation layer

List of InfoProviders used by the Sales order book:

Technical point: We never use the propagation layer for reporting. No SIDs are generated in the propagation layer.

Business layer

List of infoproviders used by the Sales order book:

List of infoproviders used by the Sales order book:

Virtual layer

List of infoproviders used by the Sales order book:

IMPORTANT: In the multiprovider MVSDSO41, there are data coming from DYNASYS (CRDYN11 and CRDYN12). These data are not used in the Order book.

Master data

List of master data used to generate the Sales order book:

Purchase order (Transfers) order book

The data flow is based on the LSA method. The data visualization is done on the multiprovider MVSDSO47 (MP: Transfers Order Book (Global Sales)).

Global Sales data layers:

• Propagation Layer
• Business Layer
• Reporting Layer
• Virtual Layer
• Master Data

See the detailed data flow here for the MultiProvider MVSDSO47 generated from Performer Suite.

Propagation layer

IMPORTANT: To build the PO's transfers order book, we use data coming from the propagation of SPRINT.

List of infoproviders used by the PO's transfers order book:

Business layer

List of infoproviders used by the PO's transfers order book:

Reporting layer

List of infoproviders used by the PO's transfers order book:

Virtual layer

List of infoproviders used by the PO's transfers order book:

Master data

Just the master data of C_PO_ITM is used. Please refer to SPRINT documentation for more information.

Order Book (PO+SO)

The order book (PO+SO) contains data from sales order (SO) and data from transfers order (PO). It is the combination of the order book to be issued (SO) and the order book to be issued (PO).

The view To be issued is the only one which exists for the order book (PO+SO).

The reports (snapshot and detail) are based on the Multi Provider MVSDSO49.

The data flow is based on the LSA method. Please see here generated from Doc Performer.

Reporting layer

List of InfoProviders used by the order book (PO+SO):

Core rules

Sales Order Book

All rules used in Global Sales were determined by SAP experts.

IMPORTANT:

• The sales order book excludes the order line which has a rejection code.
• The sales order book is defined at the most detailed level (the schedule line).
  
  
• Order line classification: An order line can be in one of the three class:

1. If the country of legal company is diference than the country of plant.
2. If the transportation mode is "SEA" (Export).
3. The others cases

Order line status

• The status of the order line (from SAP) is not used in Global Sales.

 It's because in PF1, an order line is with the status "C" (completed). When the deliveries regarding the total confirmed quantity of the order line is planned or issued .

To be invoiced date

The to be invoiced date is used to know when an order line will be billed. This concept is used in the order book for the Open order and the Shipped but not billed part.

Important: the to be invoiced date can be calculated only if the type of sales order will generate a delivery document. That means the credit/debit memo are not included in the Open order and the shipped but not billed part. The returns are not considered in the Open order and shipped but not billed part.

The to be invoiced date is calculated by use the more updated document in the document flow.

• More updated document:

1. The shipment document.
2. The delivery document.
3. The sales order document at the schedule line level.

C_ITM_SD.C_RULES(DBSDSO11 -> C_ITM_SD(PF1);DBSDSO51 -> C_ITM_SD(WP1))

TO-BE-INVOICED

TOLERANCE BY GBU

• PIPIN
• TOLERANCE = 4   IF PLANT IN ('7822','8055')
• TOLERANCE = 10 IF PLANT IN ('7544','7852')
• TOLERANCE = 3   IF PLANT IN ('7673')
• TOLERANCE = 2   IF PLANT IN ('7603')

• PMEPL
• TOLERANCE =7   IF PLANT COUNTRY ='BR'
• TOLERANCE =7   IF PLANT COUNTRY !='BR' AND PLANT IN ('7822')
• TOLERANCE =4   IF PLANT COUNTRY !='BR' AND PLANT IN ('0228')
• ELSE TOLERANCE = 3
• PA
• TOLERANCE =14  IF C_SHIPCD2 IN ( 'AA','AB','AC','AD','AE','AF','BQ','BP','8','10','0') AND Plant Zone = 'NA'
• TOLERANCE =10  IF C_SHIPCD2 IN ( 'AA','AB','AC','AD','AE','AF','BQ','BP','8','10','0') AND Plant Zone != 'NA'
• TOLERANCE =7    IF C_SHIPCD2 IN ( '40','AG','AH','AI','AZ','BA')
• SI
• TOLERANCE = 7
• RERES
• TOLERANCE = 9   IF C_SHIPCD2 IN ( 'AA','AB','AC','AD','BQ','BP','8','10','0')
• TOLERANCE = 5   IF C_SHIPCD2 IN ( 'AE','AF')
• TOLERANCE = 3   IF C_SHIPCD2 IN ( 'AH','AI')
• CS
• TOLERANCE = 11 IF Company Zone = 'NA'
• TOLERANCE = 7   IF Company Zone != 'NA'
• TS
• TOLERANCE = 7   IF Plant Zone = 'NA'
• TOLERANCE = 5   IF Plant Zone = 'EU'
• TOLERANCE = 2   IF Plant Zone = 'AP'
• TOLERANCE = 3   IF Plant Zone = 'LA'
• CH
• TOLERANCE = 0   IF TRMODE = 'AIR'
• TOLERANCE = 13 IF TRMODE != 'AIR' AND C_SHIPCD2 IN ( 'AA','AB','AC')
• TOLERANCE = 7   IF TRMODE != 'AIR' AND C_SHIPCD2 IN ( 'AD','AE','AF')
• OTHER GBU
• TOLERANCE = 0   IF Company Country  = 'BR'
• TOLERANCE = 4   IF Company Country != 'BR'

Regarding the order line classification, the to be invoiced is calculated following the rules below:

PF1 rules(exists in the field routine of DBSDSO11 -> C_ITM_SD and the end routines of DBSDSO01→ DBSDSO16, 17, 18):

• If the order line classification is "1" (the country plant is difference than the ship-to country):

1. If a shipment document exist. To be invoiced date = shipment end date (planned or actual)
2. If a delivery document exist with an actual GI date, but no shipment document. To be invoiced date = the actual GI date + transit time.
3. If a delivery document exist without an actual GI date, but no shipment document. To be invoiced date = the planned GI date + transit time.
4. If the delivery document not exist. To be invoiced date = the scheduled GI date of the order line (at the schedule line level) + transit time.

• If the order line classification is "2" (the transportation mode = "SEA" (Export)):

1. If a shipment document exist. To be invoiced date = shipment start date (planned or actual)
2. If a delivery document exist with an actual GI date, but no shipment document. To be invoiced date = the actual GI date.
3. If a delivery document exist without an actual GI date, but no shipment document. To be invoiced date = the planned GI date.
4. If the delivery document not exist. To be invoiced date = the scheduled GI date of the order line (at the schedule line level).

• If the order line classification is "3" (the others cases):

1. If a shipment document exist. To be invoiced date = shipment completion date (planned or actual)
2. If a delivery document exist with an actual GI date, but no shipment document. To be invoiced date = the actual GI date.
3. If a delivery document exist without an actual GI date, but no shipment document. To be invoiced date = the planned GI date.
4. If the delivery document not exist. To be invoiced date = the scheduled GI date of the order line (at the schedule line level).

WARNING: A shipment document can be created without the shipment dates. If this case appears, the shipment document will be ignored in the determination of the to invoiced date.

PF1+WP1 rules:

To be issued date

The to be issued date is used to know when an order line will be billed. This concept is used in the order book to be issued for the Open order and the Shipped but not billed part.

Important: like the to be invoiced date, the to be issued date can be calculated only if the type of sales ordert will generate a delivery document. That means the credit/debit memo are not included in the Open order and the shipped but not billed part. The returns are not considered in the Open order and shipped but not billed part.

The to be issued date is calculated by use the more update document in the document flow.

• More updated document:

1. The delivery document if the quantity is issued.
2. The shipment document.
3. The delivery document if the quantity is not issued.
4. The sales order document at the schedule line level.
   
   

To calculate the to be issued date we use the rules with the hierarchy below:

1. If a delivery document exist with an actual GI date. to be issued date = the actual GI date.
2. If a shipment document exist, and the delivery is not issued. to be issued date = shipment completion date (planned or actual).
3. If a delivery document exist without an actual GI date. to be issued date = the planned GI date.
4. If the delivery document not exist. to be issued date = the scheduled GI date of the order line (at the schedule line level).

WARNING: A shipment document can be created without the shipment dates. If this case appears, the shipment document will be ignored in the determination of the to issued date.

The rest to be delivered

The rest to be delivered is the quantity which need to be delivered to the customer to complete the requested quantity. The rest to be delivered is defined at the schedule line level. It is used in the Open order part, to determine the to be invoiced/issued quantities and the values. The calculation is done following the rules below:

• If the confirmed quantity = 0.
  • The rest to be delivered = the schedule line quantity - ( the issued quantity + delivery tolerance)
• If the confirmed quantity <> 0.
  • The rest to be delivered = the schedule line confirmed quantity - ( the issued quantity + delivery tolerance)

IMPORTANT: If the rest to be delivered is negatif, the quantity: rest to be delivered is forced to 0.

Not invoiced

Definitions

The notion of Not Invoiced (or not billed) is very important to generate the order book. That will define the sales documents lines which are Open or Shipped not billed.

To know if a document line is invoiced or not (billed or not billed) 2 checks are done:

• The first check is done regarding a delivery line. If a billing document exist with reference the delivery line. The corresponding delivery line is billed (invoiced).
• The second check is done regarding the sales document line. If a billing document exist with reference, the sales order line. The corresponding order line is billed (invoiced).

IMPORTANT: An order line can be partially billed.

Open order

Definitions

If a rest to be delivered exist for an order line. The order line is open.

Two cases:

• The order line is open and no delivery is planned.
• The order line is open and a delivery is planned.

Open order without planned delivery

This case appear when an order line was created, but no delivery is yet planned.

Example:

The order line 4268469/20 has no delivery created. This order line is at the beginning of the sales process.

Open order with planned delivery

This case appear when an order line was created, and delivery is planned.

Example:

The order line 4311472/20 has the delivery lines 87743333/10 and 87743333/900001 created.

The delivery is planned but the material is not yet issued. The order line 4311472/20 is open.

Shipped but not billed

Definition

Order line which has a delivery line with an issued quantity but the issued quantity is not yet billed.

Example:

The order line 4357166/10 has the deliveries lines 70367763/10 and 70367763/900001 created.

The material was issued, no billing exist for the delivery. The order line 4357166/10 is shipped not billed.

Billed

Definition

An order line is billed, when a billing line is created with reference document:

• the order line 
• the order line's delivery

Example:

The order line 4204405/10 has a billing document created in reference of the delivery line. The order line is billed.

Not Scheduled

The not scheduled part exists when a quantity is not yet scheduled in the ERP. For this part, it's not possible to determine a to invoiced date or a to be issue date.

Order book with estimated contribution:

Link documentation

Master data

List of mater data:

IMPORTANT: The object C_ITM_SD AND C_ITM_GS are critical due to it uses to generate the order book. 

C_ITM_SD__C_MANPLNT was designed at the time of Global Sales project back in 2018 at the request of Special Chem GBU (project sponsor). It is based on the batch assigned in the delivery of the order line, or if not available from the order line Shipping Plant:

Production/Manufacturing plant issued from the batch description (MSC3N / tab "Classification") :
- WP1 data = corresponding to the line "Manufacturing Plant"
- PF1 data = corresponding to the line "Industrial Origin" (even if manufacturing plant is existing, it's well the industrial origin taken as production plant.

In SAP, the batch number is :
- in the Order Line : tab "Sales A" of the order line for SO / tab "Material data" of the order line for PO
- in the delivery line

In the BW query we get the information Manufacturing Plant (ou Production Plant):
1. batch in the delivery
2. if more than one batch, we take the last one (the last in the document flow)
3. if no batch in the delivery, we take it in the order

4. if no batch in the order, by default we put the shipping plant

Global Sales - Data Dictionary

Purchase order (Transfers) order book

Core rules

All the rules used in Global Sales were determined by SAP experts.

IMPORTANT:

Solvay(DP_PUSL2 -> DBSDSO26):

• The purchase order (Transfers) order book take in consideration just the PO's types UB and NB, the vendor must be flagged as intra-group. Exception is done for purchase organization. The exception is done with the technical object C_POSD.
• The purchase order (Transfers) order book is defined at the purchase order line.

Rhodia(DP_PUSL1 -> DBSDSO66):

• The purchase order (Transfers) order book take in consideration just the PO's types UB and NB, the purchase organization 3200 is used for the type UB. The purchase organization 3001 to 3008, 3200 and 3400 are used for the type NB.
  
• The purchase order (Transfers) order book is defined at the purchase order line.

To be invoiced date

The to be invoiced date is calculated following the rules below (WP1 and PF1):

• If there is GR (good receipt) date, the to be invoiced date = the last GR date.
• If there is not yet a GR (Goods Receipt), the to be invoiced date = the scheduled delivery date of the last schedule line.

The rest to be delivered for PO's transfers

The rest to be delivered is the quantity which need to be delivered to the customer to complete the requested quantity. The rest to be delivered is defined at the purchase order line level. It is used in the Open order part, to determine the to be invoiced quantities and the values. The calculation is done following the rules below:

• If the confirmed quantity = 0.
  • The rest to be delivered = PO's line quantity -  the goods receipt quantity
• If the confirmed quantity <> 0.
  • The rest to be delivered = the PO's line confirmed quantity - the goods receipt quantity 

IMPORTANT: If the rest to be delivered is negative, the quantity: rest to be delivered is forced to 0.

Open order

Definitions

A PO transfers order is open if:

• the indicator Final delivery is empty (for NB document).
• the quantity of the PO line is issued (for UB document).

Example:

The PO's line 4512394035/10 is closed because the indicator Final Delivery is flagged.

Delivered quantity

Definition

Is the quantity issued (the delivery line has an actual GI date).

Example:

The delivery line 87422928/10 which contain the batch 900001 is issued. The quantity was delivered.

Billed

Definition

A PO transfers order line is billed, when a billing line is created with reference document:

• the PO transfers order
• the PO transfers order's delivery

IMPORTANT: On the transfers process, just purchase documents type NB will generate billing documents.

Example:

The PO 4511943102 has a billing document created in reference of the delivery document 86095478. The PO's transfers is billed.

Reporting

The reporting is based on Core workbooks based on Core queries.

The core workbooks give an aggregated view (SNAPSHOT), to have information on the documents detail jumps are done.

IMPORTANTE: The core queries are not published on the role menu. Only the workbooks are published on the role menu, folder Order Book.

Data selection

Data selections are done at the query level:

• On the sales documents type
• On the billing document type
• On the consolidated method
• On the sales unit

Sales order book

Purchase order (Transfers) order book

Order Book (PO+SO)

Data Loading

IMPORTANT: The sales order book is generated every day from scratch. No historic is done for the sales order book.

Data Quality Controls

Data comes from SAP system. To compare data between BW and sources systems, check propagation layers.

Operational Documentation

Procedures

<Describe the recurring procedures needed to operate the application (eg. start/pause/terminate/restart the app processes, data preparation, data ingestion, ETL, data visualization, data export, other manual activities)>

Scheduling

<Describe the scheduling in place for the application (eg. existing jobs, trigger time/event based, dependencies)>

Monitoring

<Describe the monitoring checks to confirm the application is performing well (eg. check the overall status, check performance metrics like runtime/data volume/memory/disk/CPU, maintain and react to alerts/notifications)>

Error Handling

<Describe how to handle errors (eg. error codes, description and respective resolution, alert users)>

Known Bugs

<List the existing bugs, its criticality, workarounds and resolution plan.>

Roadmap

<List past & future evolutions for the application (including links to MED/FSD/TSD)>