2.0 Business Process

The order confirmation process in SAP typically involves confirming the details of a sales order, including product availability, delivery dates, and other relevant information. The process begins with the creation of a sales order in SAP. This involves entering details such as customer information, product quantities, delivery dates, and any other relevant specifications. SAP performs an ATP check to determine the availability of the products requested in the sales order. This check considers factors such as current stock levels, incoming goods, and production schedules. Based on the ATP check, SAP provides an initial confirmation to the customer. This confirmation includes details such as the confirmed delivery date and any other relevant information. If there are changes to the order, such as customer requests or adjustments to production schedules, the order confirmation may need to be revised. SAP facilitates the process of making these revisions while ensuring the impact on product availability and delivery commitments is considered. Order changes reports in BW provides reporting and analytics capabilities to track key performance indicators (KPIs) related to the order confirmation process. This allows Solvay to monitor the order fulfillment efficiency.

3.0 Application Feature Overview

Information about the existent Workbooks and the respective BW queries.

4.0 Functional Specification

4.1 General Data/Calculations 

There are indicators in the report that explores the time taken to confirm an order in SAP by comparing the order line creation date and the confirmation date. The target is to be less than 48 hrs (=< 2 business days).

Furthermore, the report assesses the 'Stability' factor, determining whether the first confirmation date has been altered subsequently. If so, the report provides insights into the frequency and extent of these changes, shedding light on the order's stability over time.

4.2 Process Detail 

Scope :  

• The scope has been aligned with the OTIF scope. See scope HERE

• Exclusion of material types services and packaging (i.e. units in KWH): PF1/Z703  WP1/ZDIE WP1/ZVER WP1/ZUNB

• Consolidation Method ≠ Sold (entities)

• Deleted order lines are excluded

• Order lines with a “Reason for rejection” have been excluded, except for the WP1 reason "98 - Incompleted delivery, tb closed-not OTIF" .

Reference Date : for the KPI % Order Promising and the Cycle Time the  reference date is Order Line Creation date . Order lines are taken into consideration as soon as they are entered in the system. (data load delay of 1 day, night batch)

Cycle Time :

• Order line creation date - > 1st ATP confirmation date (ATP stands for Available to Promise)

ATP in SAP helps businesses determine the quantity of a product that can be promised to a customer at a specific point in time. It takes into account the current stock levels, incoming goods, and existing customer orders to calculate the available quantity that can be promised for future delivery.

• In case of credit block the KPI measures: Cycle Time between FIRST credit release > 1st ATP confirmation date

  In SAP a "Credit Block" on a sales order refers to a restriction or hold that is placed on the order due to credit-related concerns. This mechanism is part of SAP's credit management functionality, which helps organizations control and monitor credit limits for their customers. When a sales order is subject to a Credit Block, it means that the system has identified a potential credit risk associated with the customer placing the order. This risk could be due to factors such as the customer exceeding their credit limit or having overdue payments. 

   

• If the order hasn’t been confirmed yet we calculate the cycle time with Today’s date

• Measured in business days (of server location: Belgian holidays excluded) 

Scenarios/ Rules  

1st ATP confirmation date :

• First Confirmed quantity date from Change Log in PF1

• If there is no quantity change in the change log and the order line has been delivered, BW takes the order line creation date assuming that the order was confirmed immediately
• in case the order line was created, deleted, recreated, we consider the last order line creation date
• If a schedule line comes from a value to zero, we assume the order line was confirmed immediately (1st conf. date = order line creation date)
• If a 1st confirmation date is inferior to the order line creation date then we read the change log and take the next quantity confirmed date as the 1st confirmation date.
• For WP1 BW uses a dedicated field ZZERDAT "1st committed delivery date" (Order line - Additional Data B)

4.2.1.  Report/Process Definition 

Promising Split : Each order line is categorized in 5 possible Confirmation Status

Details of Confirmation Status:

• GOOD : confirmed  =< 2 business days
• FAILED 3-9 business days
• FAILED 10-30 business days
• FAILED > 30 business days
• FAILED with ALLOCATION : 
• For WP1: if order line has failed to be confirmed within 2 business days and has ever had ZPEN flag on order line level
• For PF1: there is no common process, therefore this category is not defined for PF1 GBUs

KPI Order Promising percentage :   # of GOOD confirmed < 2 business days /  # total orders lines

Confirmed in 2 business days : KPI is based on 1st ATP confirmation (whether the order line has been updated or not)

# of Confirmations :  

• Count the # of distinct dates* the order line has been confirmed in the change log (after confirmed quantity or schedule line date change) 

*even if the change log shows several changes per day, we can count only 1 confirmation per day

• A change that goes from value to zero is considered as an instability, not a cancellation (+1)
• If there is no change in the confirmed quantity or schedule line date in the change log and the order line has been delivered, BW counts as 1 confirmation and assuming that the order line was confirmed immediately. (WP1) BW uses order line creation date in cycle time.

Stability (Stable confirmation) : 

Calculation: Based on KPI “# of Confirmations”, Stable Y = 1 confirmation and Stable N > 1 confirmation

If the order has no GI date, it is considered as not possible to calculate the KPI. 

5.0 Non-functional Descriptions 

5.1 Usability

5.2 Regulatory Compliance

5.3 Security

5.5 Reliability

5.6 Scalability

5.7 Compatibility

5.8 Availability

5.9 Refresh of the Data