General presentation
Objective of the application
Develop a new reporting solution for Sales & Distribution data coming from SAP/ERP/PF1 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 2 views:
- 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
- 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
Usage information
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
History
Roles & Access
Roles and access
Two roles were created for OBAS. The first one is the application role and the other one is the role menu.
| Role Code | Role Description | Explanation |
|---|---|---|
| ZBI_RCS_SD_A01 | Application role for OBAS project / SD data / Orderbook | Role for the application |
| ZR_RCS_CA_M49 | SD - Sales and Distribution | Role menu for the application |
Authorization objects
The authorization is done regarding the BFC GBU, the legal company and the sales office.
| Authorization object | Explanation |
|---|---|
| CPFCTR1_2 | GBU |
| C_COMPCDE | Legal company |
| C_SAL_OF | Sales office |
Order book
Sales order book
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. Each sales document can generate an item, the combinason of the document number and the item number is a line. To generate the sales order book the documents line below is used:
- Order line
- Schedule line
- Delivery line
- Billing line
- Schedule 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.
Comment: OBAS doesn't use the shipment line. The mandatories informations are at the shipment header level.
Core rules
All the rules used in OBAS were determined by SAP experts.
- The order book excludes the order line which has a rejection code.
- The 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:
- If the country of legal company is diference than the country of plant.
- If the transportation mode igual "SEA" (Export).
- The others cases
Order line status
- The status of the order line (from SAP) is not used in OBAS. 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:
- The shipment document.
- The delivery document.
- The sales order document at the schedule line level.
Regarding the order line classification, the to be invoiced is calculated following the rules below:
- If the order line classification is "1" (the country plant is diference than the ship-to country):
- If a shipment document exist. To be invoiced date = shipment end date (planned or actual)
- If a delivery document exist with an actual GI date, but no shipment document. To be invoiced date = the actual GI date + transit time.
- If a delivery document exist without an actual GI date, but no shipment document. To be invoiced date = the planned GI date + transit time.
- 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)):
- If a shipment document exist. To be invoiced date = shipment start date (planned or actual)
- If a delivery document exist with an actual GI date, but no shipment document. To be invoiced date = the actual GI date.
- If a delivery document exist without an actual GI date, but no shipment document. To be invoiced date = the planned GI date.
- 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):
- If a shipment document exist. To be invoiced date = shipment completion date (planned or actual)
- If a delivery document exist with an actual GI date, but no shipment document. To be invoiced date = the actual GI date.
- If a delivery document exist without an actual GI date, but no shipment document. To be invoiced date = the planned GI date.
- 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.
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:
- The delivery document if the quantity is issued.
- The shipment document.
- The delivery document if the quantity is not issued.
- The sales order document at the schedule line level.
To calcul the to be issued date we use the rules with the hierarchy below:
- If a delivery document exist with an actual GI date. to be issued date = the actual GI date.
- If a shipment document exist, and the delivery is not issued. to be issued date = shipment completion date (planned or actual).
- If a delivery document exist without an actual GI date. to be issued date = the planned GI date.
- 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.
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.
Master data
List of mater data:
| Technical name | Description |
|---|---|
| C_ITM_SD | Sales order item |
C_ROUTE | Route |
C_TRMODE | Transportation mode |
| C_SHIPCD2 | Shippment condition |
IMPORTANT: The object C_ITM_SD is cristal due to it use to generate the order book.
Data flow
The data flow is based on the LSA method. The data visualization is done on the multiprovider MVSDSO01 (MP: Sales order book).
OBAS data layers:
- Propagation Layer
- Business Layer
- Reporting Layer
- Virtual Layer
- Master Data
The draw below represente the data flow of the multiprovider MVSDS01:
Propagation layer
List of infoproviders:
| DSO tech. name | DSO description | DTS tech. name | DTS description |
|---|---|---|---|
| 2LIS_11_VAITM | |||
| 2LIS_12_VCITM | |||
| 2LIS_13_VAITM |
Business layer
Reporting layer
Virtual layer
Master data
Data update
Process chain
Loading frequency
Perfomance
Reporting
Data selection
Core queries
SNAPSHOT To Be Invoiced
SNAPSHOT To Be Issued
Open order to be invoiced
Open order to be issued
Shipped but no billed to be invoiced
Shipped but no billed to be issued
Billing
Core workbooks
Order book business view To Be Invoice
Order book business view To Be Invoice (consolidated view)
Order book To Be Issued
Purchase order (Transfers) order book
Core rules
Order line status
To be invoiced date
Open order
Definitions
Delivered quantity
Definition
Billed
Definition
Master data
Data flow
Propagation layer
Business layer
Reporting layer
Virtual layer
Master data
Data update
Process chain
Loading frequency
Perfomance
Reporting
Data selection
Core queries
Core workbooks
Historical data
Sales order
Sales documents types
Sales order
Delivery
Billing
Sales documents flows
Sales order
Schedule line
Delivery
Shipment
Billing
Master data
Data flow
Propagation layer
Business layer
Reporting layer
Virtual layer
Master data
Data update
Process chain
Loading frequency
Perfomance
Reporting
Data selection
Core queries
Core workbooks
Loading frequency
Average performance
| 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 |
Record Keeping
Sales follow-up
OTIF
Concepts and definitions
ATP DATES
- First ATPs dates, are the first dates received from a schedule line in PF1.
- Last ATPs dates, are the last dates received from a schedule line in PF1.
- The date of the restauration will be the starting date for the calculation of the ATP dates.
- All the ATP dates calculated before this date are loosed.
AGENT COMMISSIONS:
BILLED:
BILLING GROUP
BILLING LINE
BLOCK
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.
COMMISSIONS
A commission is part of the price, determined durring the pricing. This information provide from the billing document and it is retreived with the subtotal 4.
CONFIRMED QUANTITY
It is the quantity for which the system is able to do the delivery to the customer at the asked date.
CONSOLIDATED RATE
It is the percentage of Solvay in a legal company.
CONSOLIDATION METHOD
It is an financial information to know how the result of a legal company is counted in the overall group result. This characteristic is used to do the exclusion of sold entities.
CP (CURRENCY PROMPT)
CREDIT/DEBIT MEMO
CURRENCY CONVERSION
CUSTOMER
CUSTOMER GBR
CUSTOMER PICK-UP
CUSTOMER SALES VIEW
DEFERED BY ATP
DELIVERY LINE
DELIVERY TOLERANCE
DEPARTURE PLANT
DESTINATION PLANT
DISCOUNT & SURCHARGES
EXTRAPOLATION BY WORKING DAYS
FIRST CONFIRMED QUANTITY
FIRST CUSTOMER GI DATE
FIRST REQUESTED DATE
FIRST REQUESTED QUANTITY
GBU SHIP-TO ZONES
GROSS SALES
INTRA GBU
INTRA GROUP
IV DOCUMENTS
JUMP QUERY
LAST CONFIRMED QUANTITY
LAST CUSTOMER GI DATE
LAST REQUESTED DATE
NET SALES
OBAS AUTHORIZATIONS
OBAS CURRENT MONTH
OPEN ORDER
ORDER BOOK RULES
ORDER LINE
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.
SCREAN SHOT
PUQ (PROMPT UNIT QUANTITY)
PURCHASE ORDER LINE (TRANSFERS)
REBATES
REJECTED ORDER
REST TO BE DELIVERED
RESTATED BUSINESS AREA
RESTATED PARTNER BUSINESS AREA
ROUTE
SALES REPRESENTATIVE
SHIPMENT TO THE END CUSTOMER
SHIPPED BUT NOT BILLED
SNAPSHOT
TAXES
TO BE INVOICED
TO BE ISSUED
TRANSFERS ORDER
TRANSITE TIME
TRANSPORTATION MODE
UNIT CONVERSION
RETURN
Maintenance
Known bugs
Recurring procedure
Planned Evolution
OBAS interaction
TIERS
SPRINT
APO
DYNASIS









