The new wiki link for this data flow is here:

Marketing and Sales

Please update the doc there and no longer here.

General presentation

Objective of the application

Develop a new reporting solution for Sales & Distribution data coming from SAP/ERP/PF1&WP1 with a first deliverable the ORDER BOOK REPORT (Sold & Pending).

Detail on: Sales Orders, Purchase Orders (transfers), Sales Order Lines, Schedule Lines,Deliveries, Invoices.

Innovation: Process Core Rules integrated to the Order Book Report, generating 4 views:

1. Order Book Business View: Determine for each sales order item when it will BE INVOICED, so determine the best estimation for the billing date                                                                                          → FOCUS: BUSINESS / TOP MANAGEMENT / FINANCE
2. Order Book Business View + contrib: Available for WP1, this order book combine the figures of the order book and the contribution (actual for the invoiced part, estimated for the to be invoiced part).
3. Order Book to Be Issued: Determine for each sales order item when it will be issued, so determine the best estimation when the product will leave the plant                                                                        → FOCUS SUPPLY CHAIN TEAM
4. Order Book to Be Issued (PO+SO): Determine for each sales order item and transfers order item when it will be issued, so determine the best estimation when the product will leave the plant                 → FOCUS SUPPLY CHAIN TEAM
   
   

Usage information

History

Global Sales started to replace BI4. This project is extension of OBAS project (PF1). At the end Global Sales is able to offer sales report for the ERPs PF1 and WP1.

Roles & Access

Roles and access

Two roles were created. The first one is the application role and the other one is the role menu.

Authorization objects

The authorization is done regarding the BFC GBU, the legal company and the sales office.

WARNING: For the PO part the notion of sales offices doesn't exist. The restriction in sales offices will not be considered for the reports PO and PO+SO.

Order book

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).

Core rules

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 update 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.
   
   

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

PF1 rules:

• If the order line classification is "1" (the country plant is diference 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.

WP1 rules:

If incoterm CIP-CPT & order shipping condition group = SEA (New)

      If SHIPMENT      :     date of shipment COMPLETION (Exec-Planned)

      If DELIVERY-C   : Despatch actual good issue

      If DELIVERY-A   : Despatch planned good issue

      Else                   : Scheduled good issue

>>> POD - Proof of Delivery <<<

If POD + incoterm DAP-DDP-DDU + order shipping condition AC-AF (New)

              If SHIPMENT :  date END of shipment (Exec-Planned)  + 2 days

              If SCHEDULE : Schedule line delivery date when confirmed qty >0  - 2 days

              Else   : Order last Delivery date (ATP/Requested)  - 2 days

If POD (OTHERS)

      If SHIPMENT  : date END shipment (Exec-Planned)

      Else   : Schedule line delivery date  when confirmed qty >0

      Else               : Order last requested delivery date

Take in consideration just if there is a POD flag

>>> NON-POD <<<

If NON-POD + ROAD-RAIL-OTHER

      If SHIPMENT     :     date START shipment (Exec-Planned)

      If DELIVERY-C  : Despatch actual good issue

      If DELIVERY-A  : Despatch planned good issue

      Else               : Scheduled good issue

If NON-POD + AIR-SEA

If SHIPMENT + (shipment COMPLETION (Exec-Planned) = shipment START (Exec-Planned))

: date START shipment + 3 (in case there is no date in the

                           shipment doc, so GI date (actual or planned)

      If SHIPMENT + (shipment COMPLETION <> shipment START (Exec-Planned))

                              : date START shipment + 0

      If DELIVERY-C  : Despatch actual good issue + tolerance

      If DELIVERY-A  : Despatch planned good issue + tolerance

      Else               : Scheduled good issue + tolerance

>>> NON-POD Air-Sea TOLERANCE <<<

All GBU         Legal Company country = BR                   +0

P&I               Plant 7822   +4                                    Plant 7544   +10

                    Plant 7673   +3                                    Plant 7852   +10

                    Plant 7603   +2                                    Plant 0273   +4

                    Plant 8060   +0                                    Plant 8055   +0

                    Plant 7860   +0                                    Other          +0

EP                Plant country = BR                                                   +7

                    Plant = 7822                             +7

                    Plant =  0228                          +4

                    Other                                                                       +3

AROMA         Order delivery condition code AA-AB-AC-AD-AE-AF-BQ-BP

                       & Plant geo zone = AMERIQ                                     +14

                       & Plant geo zone <> AMERIQ                                   +10

                    Order delivery condition code 8-10-0

                       & Plant geo zone = AMERIQ                                     +14

                       & Plant geo zone <> AMERIQ                                   +10

                    Order delivery condition code 40-AG-AH-AI-AZ-BA        +7

                    Other                                                                           +0

SILICA                  +7

RES              Order delivery condition code AA-AB-AC-AD-BQ-BP     +9

                    Order delivery condition code 8-10-0                            +9

                    Order delivery condition code AE-AF                           +5

                    Order delivery condition code AH-AI                             +3

                    Other                                                                           +0

NOVECARE   Legal company zone "AMERIQ"                                   +11

                    sinon                                                                           +7

TS               Plant zone AP                                            +2

                   Plant zone NA                                           +7

                   Plant zone EU                                            +5

                   Plant zone LA                                            +3

Other GBU            +3

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 calcul 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

Data flow

The data flow is based on the LSA method. 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

The draw below represent the data flow of the multiprovider MVSDSO41:

Click on the draw to enlarge.

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:

Reporting layer

List of infoproviders used by the Sales order book:

For more detail on the propagation layer, click on this LINK.

Virtual layer

List of infoproviders used by the Sales order book:

IMPORTANT: In the multiprovider MVSDSO41, they 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:

For more detail on the master data layer, click on this LINK.

Data update

Process chain

IMPORTANT: The same process chain is used to update the Order book and the Historical sales data.

The processes chains below are used to update the multiprovider MVSDSO41 (Sales order book):

For Solvay:

• SD - Main Process Chain - UPDATE DATA - (PC_SD_MAIN)
  • SD - Propagation Update (PC_SD_PROPAG)
  • SD - Business Layer (Solvay) (PC_SD_BUSINESS_LAYER)
  • Global Sales: Reporting layer (PC_Global Sales_REPORTING)

For Rhodia:

• PC: Global Sales: Main (Rhodia) - (PC_GLOBAL_SALES_MAIN)
  • Global Sales: Propagation Layer (Rhodia) (PC_GL_SALES_PROP_01)
  • Global Sales: Business Layer (Rhodia) (PC_GL_SALES_BUS02)
  • Global Sales: Reporting Layer (Rhodia) (PC_GL_SALES_REP02)

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

Loading frequency

The data is updated every day. The process chain start after the end of TIERS update. 

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.

For more detail on the selections, click on this LINK.

Core queries

List of Queries

The core queries are used to build the workbooks and to have the detail at the documents lines level (jumps).

Purchase order (Transfers) order book

Core rules

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

IMPORTANT:

Solvay:

• The purchase order (Transfers) order book take in consideration just the PO's types UB and NB, the vendor must to 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:

• 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.

Data flow

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

The draw below represent the data flow of the multiprovider MVSDSO47:

Click on the draw to enlarge.

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:

For more detail on the propagation layer click on this LINK.

Business layer

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

For more detail on the business layer click on this LINK.

Reporting layer

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

For more detail on the reporting layer click on this LINK.

Virtual layer

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

For more detail on the vitual layer click on this LINK.

Master data

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

Data update

Process chain

IMPORTANT: The same process chain is used to update the PO's (transfers) order book and the Historical PO's (transfers) data.

The processes chains below are used to update the multiprovider MVSDSO47 (MP: Transfers order book):

PF1:

• Global Sales: Transfers Orders Main chain (PC_OBAS_TRANSFERS_MAIN)
  • Global Sales: Business Layer Transfers Orders (Solvay) (PC_OBAS_TRANSFERS)
  • Global Sales: Reporting Layer Transfers Orders (PC_OBAS_TRANSFERS_ODB)

WP1:

• PC: Global Sales: Main (Rhodia) (PC_GLOBAL_SALES_MAIN)
  
  • Global Sales: Propagation Layer (Rhodia) (PC_GL_SALES_PROP_01)
  • Global Sales: Business Layer (Rhodia) (PC_GL_SALES_BUS02)
  • Global Sales: Reporting Layer (Rhodia) (PC_GL_SALES_REP02)

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 purchase documents type.
• On the sales unit.

For more detail on the selections, click on this LINK.

Core queries

The core queries are used to build the workbook and to have the detail at the documents lines level (jumps).

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 multiprovider MVSDSO49.

Data flow:

Reporting layer

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

Core queries

The core queries are used to build the workbook and to have the detail at the documents lines level (jumps). All the queries are based on the multiprovider MVSDSO49.

Historical data

Sales order

This part of Global Sales is used to have the historical data (last 3 years) for:

• Sales orders
• Schedule lines
• Delivery
• Shipment
• Billing

Sales documents types

Sales order

All the sales documents types are in the historic. Regarding the sales document type, a sales order line can be in one of the categories below:

• Sales
• Return
• Consignment
• Credit/Debit memo

The categories are stored in the object C_DOCTYP2 with the attribute C_GRPDOC. The attribute is updated manually.

IMPORTANT: This concept of categories isn't standard. It was created for Global Sales.

Delivery

All the delivery types are in the historic. Nothing is done to group the delivery type.

Billing

All the billing document types are in the historic. Regarding the billing document type, a billing line can be in one of the categories below:

• Sales
• Pro Format
• Inter-company

The categories are stored in the object C_BILLTYP with the attribute C_BILLCL. The attribute is updated manually.

IMPORTANT: This concept of categories isn't standard. It was created for Global Sales. An exclusion is done between the propagation layer and the business to don't have the billing Pro-format..

Data flow

The data flow is based on the LSA method. The data visualization is done on the multiproviders:

• MVSDSO44 (MP: Global Sales) for the aggregated queries.
• MVSDSO45 (MP: Detail Jump Query) for the detailed queries.

Global Sales data layers:

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

The draw below present the data flow of the multiprovider MVSDSO44 (MP: Global Sales) :

Click on the draw to enlarge.

The draw below present the data flow of the multiprovider MVSDSO45 (MP: Global Sales) :

Click on the draw to enlarge.

Propagation layer

List of infoproviders used by the Historical data:

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 Historical data:

Reporting layer

List of infoproviders used by the Historical data:

Virtual layer

List of infoproviders used by the Historical data:

Data update

IMPORTANT: The same process chain is used to update the Sales order and the Historical sales data.

The processes chains below are used to update the multiproviders MVSDSO44 and MVSDSO45

For Solvay:

• SD - Main Process Chain - UPDATE DATA - (PC_SD_MAIN)
  • SD - Propagation Update (PC_SD_PROPAG)
  • SD - Business Layer (Solvay) (PC_SD_BUSINESS_LAYER)
  • Global Sales: Reporting layer (PC_Global Sales_REPORTING)

For Rhodia:

• PC: Global Sales: Main (Rhodia) - (PC_GLOBAL_SALES_MAIN)
  • Global Sales: Propagation Layer (Rhodia) (PC_GL_SALES_PROP_01)
  • Global Sales: Business Layer (Rhodia) (PC_GL_SALES_BUS02)
  • Global Sales: Reporting Layer (Rhodia) (PC_GL_SALES_REP02)

Reporting

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

The core workbooks give an aggregated view, 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 Historical data.

Core queries

The core queries are used to build the workbooks and to have the detail at the documents lines level (jumps).

IMPORTANT: The calendar Year/month corresponding to:

• the last requested GI date for the sales orders part.
• the actual Gi date for the sales deliveries part.
• the billing document date for the billing part.

BW Queries Feeding QV Queries 

1. QV_BW_QRY_MVSDSO45_SD0001  -    C_DOCNUMB_C_CUSTGR2 ia added to Rows as a part of change.

2. BW_QRY_MVSDTR01_0010 - C_DOCNUMB__C_SAL_ORG is added as free characteristics as a part of change.

PO's transfers

Puchase order documents types

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

IMPORTANT:

Solvay:

• PO's types UB and NB, the vendor must to be flagged as intra-group. Exception is done for purchase organization. The exception is done with the technical object C_POSD.

Rhodia:

• 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.
  
  
  

Purchase order

Global Sales uses the data coming from SPRINT to have the PO's transfers order.

Delivery

The deliveries are coming from the DSO DBSDSO29 "PO Global: Transfers orders delivery (Solvay)".

The deliveries are coming from the DSO DBSDSO69 "PO Global: Transfers orders delivery (Rhodia)".

Billing

The billing are coming from the DSO DBSDSO27 "PO: Transfers orders Invoices (Solvay)".

The billing are coming from the DSO DBSDSO67 "PO: Transfers orders Invoices (Rhodia)".

IMPORTANT:

• Transfers done with the PO type UB is always done between the same GBU.
• Transfers done with the PO type NB is always done between Solvay's entities.

Master data

The master data used, is the master data of SPRINT, with the object C_PO_ITM (Purchase Order Item). Please refer to SPRINT documentation for more detail.

Data flow

The data flow is based on the LSA method. The data visualization is done on the multiproviders MVSDSO42 (MP: Global PO (Global Sales)) and MVSDSO43 (MP: Detail PO Jump (Global Sales)).

Global Sales data layers:

• Propagation Layer
• Business Layer
• Reporting Layer
• Virtual Layer

The draw below present the data flow of the multiprovider MVSDSO42 (MP: Global PO (Global Sales)):

Click on the draw to enlarge.

The draw below present the data flow of the multiprovider MVSDSO43 (MP: Detail PO Jump (Global Sales)):

Click on the draw to enlarge.

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 Historical data PO's transfers:

Data update

Process chain

IMPORTANT: The same process chain is used to update the PO's (transfers) order book and the Historical PO's (transfers) data.

The processes chains below are used to update the multiproviders MVSDSO42 and MVSDSO43 :

PF1:

• Global Sales: Transfers Orders Main chain (PC_OBAS_TRANSFERS_MAIN)
  • Global Sales: Business Layer Transfers Orders (Solvay) (PC_OBAS_TRANSFERS)
  • Global Sales: Reporting Layer Transfers Orders (PC_OBAS_TRANSFERS_ODB)

WP1:

• PC: Global Sales: Main (Rhodia) (PC_GLOBAL_SALES_MAIN)
  
  • Global Sales: Propagation Layer (Rhodia) (PC_GL_SALES_PROP_01)
  • Global Sales: Business Layer (Rhodia) (PC_GL_SALES_BUS02)
  • Global Sales: Reporting Layer (Rhodia) (PC_GL_SALES_REP02)

Reporting

Core queries

The core queries are based on the multiproviders MVSDSO42 and MVSDSO43.

Historical data (PO+SO)

Data flow

The data flow is based on the LSA method. The data visualization is done on the multiproviders MVSDSO56 (Global Sales: Historical data (SO+PO)) and MVSDSO57 (Global Sales: Historical data JUMP (PO+SO)).

Global Sales data layers:

• Propagation Layer
• Business Layer
• Reporting Layer
• Virtual Layer

The draw below present the data flow of the multiprovider MVSDSO56 (MP: Global PO (Global Sales)):

Click on the draw to enlarge.

The draw below present the data flow of the multiprovider MVSDSO57 (Global Sales: Historical data JUMP (PO+SO)):

Click on the draw to enlarge.

Propagation layer

The propagation layer is same than for Historical data sales order and Historical data transfers orders

Business layer

List of infoproviders used in the business layer:

Reporting layer

List of infoproviders used in the reporting layer:

Virtual layer

List of infoproviders used in the virtual layer:

Data update

The update is done every working days

Process chain

The processes chains used are the same than for the Historical data Sales orders and Historical data Transfers orders.

Reporting

Core queries

The core queries are based on the multiproviders MVSDSO56 and MVSDSO57.

Sales follow-up

The sales follow-up is a report which mix data from Global Sales, APO, Dynasys and P&L. The report give a complete view of the forecast and the sales.

Data flow

The data flow is based on the LSA method. The data visualization is done on the composite provider CPSDSO54 (MP: Order book & Forecast & historical (PO & SO)), previously multiprovider MVSDSO54 .

Global Sales data layers:

• Propagation Layer
• Business Layer
• Reporting Layer
• Virtual Layer

The draw below present the data flow of the composite provider (MP: Order book & Forecast & historical (PO & SO)):

Click on the draw to enlarge.

Beside the BW 7 objects mentioned in the dataflow downwards, the composite provider has another 3 views.

Propagation layer

The propagation layer used is the propagation of Global sales, Dynasys, APO. The data from P&L are extracted with APDs.

APD:

APD_PL_GS_0030 (Netback Sales P&L), based on the query APD_QRY_MVCOPA01_NBACK_0001 (BW COPA Netback query APD (Core Query))

APD_PL_GS_0031 (Netback Sales P&L (w/o interval)), based on the query  APD_QRY_MVCOPA01_NBACK_0002 (BW COPA Netback query APD w/o month (Core Query))

Business layer

The propagation layer used is the propagation of Global sales (historical data, order book), Dynasys and APO.

Reporting layer

List of infoproviders used in the reporting layer:

Virtual layer

List of infoproviders used in the virtual layer:

CV_SD_SO_ORDER_LASTR - View created to provide a different last requisition date dynamically for the report.

ICM information are splitted between detailed and consolidated and treated by the normalized view to have allocated and unallocated data at same level of invoices.

CV_SD_SO_CPSDSO54_0001 - ICM (Detailed)

The P&L data is linked to APD process APD_PL_0006 from query APD_QRY_MVCOPA01_0007 into table DPSDSO75

CV_SD_SO_CPSDSO54_0002 - ICM (Consolidated)

The consolidate view uses DPSDSO95 as target and a different variable from the same query mentioned above by the APD APD_PL_0007

Data update

The data update is done every working day for data from Global sales, APO and P&L. For Dynasys the data are update 4 times per day.

Please refer to P&L and Dynasys documentation for more detail. 

Process chain

The processes chains of Global sales are used for the data historical and order book.

Please to P&L and Dynasys documentation for more detail on the process chain.

Reporting

Core queries

The core queries are based on the multiproviders MVSDSO54:

Important: a selection is done on the billing type and sales document type. The master data C_BILLTYP and C_DOCTYP2 with the attribute "Relevant for sales follow-up" contains the selection.

Corporate trade

The corporate trade report is a report which give an high level of details with a lot of information for all billing done by Solvay.

Data flow

The data flow is based on the LSA method. The data visualization is done on the multiproviders MVSDSO53 (MP: Corporate trade (Global Sales)) .

Global Sales data layers:

• Propagation Layer
• Business Layer
• Reporting Layer
• Virtual Layer

The draw below present the data flow of the multiprovider MVSDSO53 (MP: Corporate trade (Global Sales)):

Click on the draw to enlarge.

Propagation layer

The propagation Layer is same than the billing propagation layer of Global sales.

Business layer

List of DSOs used in the business layer:

Reporting layer

The reporting layer is the same than the business layer.

Virtual layer

List of infoproviders in the virtual layer:

Data update

The data update is done every working day.

Process chain

Same processes chain used in Global sales for Sales and for Transfers.

Reporting

Core queries

The core queries are based on the multiproviders MVSDSO53:

OTIF (On Time In Full)

See the complete content of OTIF process in link below:

BW OTC - Global Sales - OTIF /!\ Obsolete /!\

Concepts and definitions

ATP DATES

Available-to-promise (ATP) is a business function that provides a response to customer order inquiries, based on resource availability. It generates available quantities of the requested product, and delivery due dates.

BLOCKS

The sales process can be stop by block(s) on the sales document(s) or document(s) line(s).

If a block exists the sales process is stopped where the block is created (at the document or document level).

Types of blocks:

• Delivery block (Historic).
• Delivery block (Document item)
• Billing block (Document header)
• Billing block (Document item)
• Credit block (Historic)
• Credit block (Dynamic)

CLOSE ORDER

An order is close if the rest to be delivered = 0.

CO (CURRENCY ORIGIN)

it's the currency of the legal company responsible for the order line.

CONFIRMED QUANTITY

Is the quantity confirmed by the system. In other terms, what quantity the supply chain is able to deliver regarding the customer's requested delivery date. This quantity is defined at the schedule line level on the system. In BW the confirmed quantity is available on the data base, at the schedule line and at the sales  

CONSOLIDATED RATE

Is the percentage of Solvay in a legal company.

IMPORTANTE: The consolidated rate is maintained in the master data of the object C_COMPCDE (Company code). For more detail click on this LINK.

DELIVERY LINE

A delivery line is the combination of a delivery document and an item.

Example:

70367763/10 and 70367763/900001 are deliveries lines. The important delivery line is 70367763/900001 because is the quantity isn't null.

IMPORTANT: The delivery line with the "zero" quantity must to be in the data base (DSO DBSDSO14 (Global sales deliveries)). It because billing lines can be created regarding this delivery line.

DELIVERY TOLERANCE

DEPARTURE PLANT

The concept of departure plant is used for PO's transfers . The departure plant is the plant where the product is sent.

DESTINATION PLANT

The concept of destination plant is used for PO's transfers part. The destination is the plant where the product is delivered.

DISCOUNT & SURCHARGES

EXTRAPOLATION BY WORKING DAYS

An extrapolation by working days can be applied on the different keys figures. The objective is to be able in a commercial to know the number of working days for the curent month and the number of working days passes until the last update date> The determination of the working days is done at the country's SAP standard calendar calendar.

Applications: In the sales follow-up's workbook, an extrapolation is done on the monthly delivery quantity. The references dates (number of working days for the current month and number of working days passed until the last update) are based on the SAP standard calendar of the plant's country.  

IMPORTANT: The object C_TECHWD is calculated every day. If for a country code a SAP standard calendar exist. For more detail click on this LINK.

FIRST CONFIRMED QUANTITY

The first confirmed quantity is: the first quantity, confirmed for an order line, received in BW during an update.

IMPORTANTE: This quantity is avaible on the master data C_ITM_SD (Sales document item). For more detail click on this LINK.

FIRST CUSTOMER GI DATE

FIRST REQUESTED DATE

FIRST REQUESTED QUANTITY

GBU SHIP-TO ZONES

INTRA GBU 

An order is intra GBU when the sales is done in the same BFC GBU.

For WP1, we use the movement type from the table ZFAT0041/0042/0043/0044 to know this characteristic.

For PF1, we use the technical object C_TECPARA to know the GBU of the partner and we compare it with the GBU responsible of the sales.

INTRA GROUP

The intra group (flag) is defined a the customer level. The master data of the customer is used to know the characteristic.

For PF1, the intra group flag is defined regarding the Sold-to.

For WP1, the intra group flag is defined regarding the Payer.

IV DOCUMENTS 

The IV documents are the billing done between Solvay's entities for intercompany flow.

Gross value

The Gross value, is the basic price of the material without discount, surcharges, rebates.

Net value

The Net value, is the Gross value + discount + surcharges + rebates.

GS CURRENT MONTH

The variable used for the current month in the report is based on the today date - 1. Example; on 01 Jan 2018  the current month will be 12/2017. It's because the data are on day late in BW.

ORDER LINE

An order line is the combination of the order document and the item. In the report the order line is displayed like this: DOCUMENT/ITEM

MANUAL PRICING:

An order is considered as manual pricing when the flag "Changed manually" is flagged on the pricing condition.

PRO-FORMAT DOCUMENTS

This kind of billing document is not counted in the sales result by the business. The proformat document is mandatory to be aligned with specifics countries's laws.

REJECTED ORDER

An order is rejected when a reason for rejection is added at the order level. An order with a delivery/billing done can be rejected.

Definition of the structure (BFC GBU, ACTIVITY,...)

For sales order, we follow the same way than P&L:

-PF1: the structure is defined regarding the object C_TECPCTR.

-WP1: the structure is defined regarding the object C_CDSA.

For transfers order, the structure is defined regarding the material and the plant.

SCHEDULE LINE

A scheduled line is the more detailed level in a sales order. By default each sales order line has only one scheduled line. If the business function ATP is activated for the order line. More than one scheduled line line can be generated. 

SALES REPRESENTATIVE

The sales rep. is defined at the customer sales view. In PF1 it corresponds to the partner VE, in WP1 it corresponds to the sales group.

Partner CSR (customer sales representative)

The CSR is defined at the customer sales view. In PF1, it corresponds to the partner VW. In WP1, it corresponds to the partner ZI.

SHIPMENT TO THE END CUSTOMER

In Global sales we consider only the shipment which will deliver the goods to the customer. The preliminary shipment (if exists) is not considered. In Global Sales, on delivery document can have only on shipment document.

TRANSFERS ORDER

A transfers order is a purchase order. A transfers is always done between Solvay's entities. The transfers are done using the PO type NB and UB. With the type UB a transfers is done on the same GBU (restocking).

TRANSIT TIME

The transit time is defined at the route level.

TRANSPORTATION MODE

Transportation is a notion created for Global Sales, it depends of the shipping condition. 

Global Sales interaction

TIERS - Transportation Costs

SPRINT - Purchasing

APO & DYNASYS