Confirming Production Orders

Confirmations are the premise for progress control and the basis for cost charging of internal activities performed for the order. For this reason, confirmations should be carried out by the shop floor workers as promptly as possible. You can confirm individual operations or entire orders. As a prerequisite, the orders and/or operations must be released. Due to the different requirements that arise in practice, SAP provides several confirmation apps and transactions, for example:

• Confirm Production Order
• Confirm Production Order Operation

Also, mass processing can also be used to confirm operations and orders:

• Collective Entry of Confirmations
• Mass Processing Production Orders

In the figure, an example of an operation confirmation and the effect of the confirmation posting to the order is displayed. When confirming the operation, you provide, for example, the following information:

• Operation quantities: Yield, scrap, and rework

  The yield quantity is the amount of partially manufactured items which was produced during this operation and can be transferred to the next work center. The scrap quantity is the amount of partially manufactured items that had to be scrapped when you executed this operation. If required, you can provide additional information in text form or even create quality notifications. The rework quantity is the amount of partially manufactured items that cannot be transferred to the next manufacturing operation due to, for example, quality reasons. After you've executed the repair, the respective items reenter the planned production flow.

• Actual dates

  You enter the actual start and finish date of an operation which can be used for analysis purposes or rescheduling of subsequent production operations.

• Operation activities

  You enter operation activities, for example, setup time, machine time, labor time, and so on, to confirm how much time effort was invested into the operation. For each operation activity, the system calculates the respective costs using information maintained in the work center and charges these internal activities to the order.

After posting the confirmation, the order and operation status values are updated to either partially confirmed (PCNF) or confirmed (CNF). An order is partially confirmed if at least one but not all of the operations that require confirmation have been confirmed (operation status PCNF or CNF). An order is also partially confirmed if all the operations requiring confirmation have been finally confirmed, but there are confirmable operations that have been partially confirmed. An order is finally confirmed when all operations for which confirmation is required have been finally confirmed (status CNF) and when there are no confirmable operations that have been partially confirmed (status PCNF).

If configured, for example, in the operation control key, the confirmation also triggers the automated goods receipt of the manufactured items. The goods receipt quantity corresponds to the yield quantity. Furthermore, if components are marked as backflushed, the confirmation triggers the goods issue posting of the respective components. The goods issue quantity corresponds to the sum of all three operation quantities multiplied by the number of components required for the manufacturing of one item. In our bike example, posting a yield of five bikes would consume ten wheels and five frames, respectively.

In the figure above, the production order consists of three manufacturing operations (10, 20, and 30). In the order, you assign a control key to each operation, for example, control key PP01. The control keys, which you set up in Customizing, contain information whether an operation is a milestone operation, or whether an operation must, can, or cannot be confirmed. Usually, you flag an operation as "confirmation required" if you are interested in the progress of this operation. If you do not want to confirm all operations, but are only interested in the progress of a subset of operations, for example, the most important ones, you define the respective operations as milestone. Operations for which are of minor interest for you could be flagged as "confirmation possible". If so, the confirmation is optional and the system issues a warning if you try to post a confirmation for such an operation. If you explicitly want to forbid the confirmation of operations, you can flag the respective operations as "confirmation not possible". From a business perspective, you would use the last scenario for an order with milestone operations and flag the non-milestone operations as confirmation not possible. Following this approach, you can ensure that the operators are only able to post confirmations for milestones.

Depending on your business requirements, the system offers various variants for order confirmation:

• Production order confirmation on order header level

  In this scenario, you enter a confirmation for the entire order. From a business perspective, you usually use this scenario for orders with only one or few operations, or for orders where you are not interested in the detailed order progress. If you enter a confirmation on order header level, the system confirms all operations that have a control key in which confirmation is possible or required. The quantities confirmed in the operations are proportional to the quantities confirmed in the order header. You can either confirm the order in one confirmation posting or post multiple order confirmations until the order quantity was reached. After posting an order confirmation, the system sets a respective confirmation status on order header level.

• Time ticket confirmation

  In this scenario, you enter a confirmation for each (confirmation relevant) operation in the order. From a business perspective, you usually use this scenario for bigger orders containing many manufacturing steps where you want to get a detailed overview about the progress of each manufacturing operation. Similar to the previous case, you can either confirm each operation in one confirmation posting or post multiple operation confirmations until each operation of the order is fully confirmed. After posting an operation confirmation, the system sets a respective confirmation status on operation and order header level.

  When using time ticket confirmations, it is important to understand the behavior of the system if, either on purpose or by mistake, the user tries to post an operation confirmation, for example, operation 20, but the confirmation of an earlier operation, for example, operation 10, was not entered: Depending on your business scenario, you can either enforce that the user must confirm the operations in the sequence in which they are defined in the order or let the user decide in which order the operations are confirmed.

  Note

  The system behavior is set up in Customizing (Define Confirmation Parameters).

• Milestone confirmation

  In this scenario, you also confirm the order on operation level. However, by assigning a respective control key to the operations, you define some of the manufacturing operations as milestones. From a business perspective, these operations represent important steps in the order flow and you explicitly want to monitor the status of these steps. The non-milestone operations which lie in between the milestones are of minor interest to you. When you post a confirmation, you must therefore only post confirmations for milestone operations. At the same time, the system automatically confirms the non-milestone operations.

  Depending on the complexity of your order, you can define one or several operations as milestones: If only one milestone is required, usually the last operations is flagged as milestone. When posting a confirmation for this operation, the earlier operations are automatically confirmed with planned data. If you define more than one milestone, you must confirm each milestone operation individually in the sequence in which they are defined in the production order. Assume a production order with six operations (10, 20, 30, 40, 50, and 60). Operations 30 and 60 are milestones. In this case, you must first confirm operation 30 before you can confirm operation 60. When posting a confirmation for operation 30, the system automatically confirms operations 10 and 20. When posting a confirmation for operation 60, the system automatically confirms operations 40 and 50.

  When posting yield, scrap, and rework quantities for a milestone, the scrap and rework quantity is attributed to the milestone operations. Earlier operations are confirmed with the yield quantity without scrap and rework. This is due to the fact that the system cannot know where to attribute scrap and rework quantities to since there is no explicit confirmation for the non-milestone operations.

• Time event confirmation

  In this scenario, you confirm time events (for example setup start, setup finish, processing start, processing finish, and so on) for each operation. The system calculates the duration based on the time difference between the start and end event of the respective operation segment. For example, the setup duration is the time between the setup start and the setup finish time event, respectively.

  From a business perspective, you can understand the time event confirmation as a confirmation process where operators inform the system every time they start, stop, and restart an operation segment. Using this approach, they do not need to manually keep track of operation durations and/or operation activities. Instead, the system automatically determines this information based on the start and end events. Technically, time event confirmations can be implemented, for example, using a manufacturing execution system where the operator confirms the start and stop of each operation segment which is performed on the shop floor.

When comparing milestone confirmations to order and operation confirmations without milestones, the milestone confirmation approach requires more confirmations than the former, but less confirmations than the latter. Therefore, the operator effort is reduced when you use milestones instead of time tickets, but you are still able to get a reasonable insight into the progress of each order.

On the other hand, time event confirmations follow a different confirmation philosophy than order confirmations or operation confirmations: In the former, the operator informs the system about every start and stop of an activity he/she executes on the shop floor; in the latter the operator informs the system only about net times required for each order and/or operation.

Irrespective of which of the three confirmation types you use, each confirmation is entered with a confirmation type (partial confirmation, final confirmation, or automatic final confirmation). You use partial confirmations if you want to post a progress report for an order or operation. You use final confirmations if the respective order or operation was completely manufactured. As a third option, you can let the system decide whether the current confirmation is a partial or a final confirmation: It the confirmed quantity (yield + rework + scrap) is less than the quantity to be confirmed, the system posts a partial confirmation. Otherwise, the system posts a final confirmation. Note that if you produce a higher quantity than initially planned, you can post as many final confirmations to an operation or order as required.