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:

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

Provide some history of the application : When was it created ? What was the initial project ? Who was the original requestor ? If possible provide link to the project information

Roles & Access

Roles and access

Two roles were created for OBAS. The first one is the application's 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.

Order book

Sales order book

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:

1. If the country of legal company is diference than the country of plant.
2. If the transportation mode igual "SEA" (Export).
3. 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 .

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 document will generate a delivery. 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:

• 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 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 document will generate a delivery. 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 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

Data flow

Data update

Reporting

Data selection

Core queries

Core workbooks

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

Data update

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

Data update

Reporting

Data selection

Core queries

Core workbooks

Detail of process chain, list + link between or special event done for the loading

Loading frequency

Detail of frequency : monthly; weekly or else

Average performance

if possible, give some information on average process chain duration, amount of data loaded and total data volume example: daily process chain loaded in 30 min, weekly chain loaded in 1h15, with around 2k to 10k lines in DELTA mode for a total of 10M lines in cube. The purpose is to give a general overview of the volume of data managed y the application

Record Keeping

Give details if any historisation is done, example: keep only data greater than beginning of Y-3

Concepts and definitions

Maintenance

Known bugs

Give the list and explanation on the known, not-solved, bugs.

Recurring procedure

List recurring procedures

Planned Evolution

Detail planned major evolution if already known. Example: complete decommissioning of application is planned in 2017 / Extension to solvay perimeter planned in 2nd semester of 2016