Executing Production Orders

When an order is created, the system automatically creates a reservation for the required material components. Each material component of the order receives a separate item number within the reservation. You can only withdraw the reserved materials from the warehouse if the operation to which the materials are assigned in the order has already been released. For each reservation item, the following information is available:

• Material number
• Quantity
• (Issue) Storage location

The system automatically tries to determine the issue storage location. Also, it might be necessary to organize material staging from a central storage location to the issue storage location before you can post the goods issue in the system, for example, if purchased components are delivered to a central warehouse, but your shop floor is assigned to a different storage location. We will discuss both at a later point in this chapter.

In the figure, the goods issue process to a production order is displayed. Assuming that the materials are already available at the production storage location, 101B in our example, you can post a goods issue to a production order using one of the following options:

• Manual goods issue posting, for example, using the Post Goods Movements or Pick Components for Production Order apps.
• Automatic goods issue posting together with the order confirmation, for example, using the Confirm Production Order app.
• Automatic goods issue posting together with the operation confirmation, for example, using the Confirm Production Order Operation app.

In case of manual goods issue posting, the system proposes the component quantity and the issue storage location as both are maintained in the reservation. You can either accept the proposed values or change the quantities and/or storage locations as required. You can withdraw a lower quantity if, for example, you only manufacture a fraction of the ordered quantity, or a higher quantity if, for example, some components were destroyed during the assembly process.

In case of automatic goods issue posting (→ materials with a 'backflush' indicator) together with a confirmation posting, the system automatically posts a goods issue at the storage location maintained in the reservation. The withdrawn quantity scales linearly with the confirmation quantity. For our bike example, confirming five bikes would result in a goods issue posting of five frames and ten wheels, respectively.

In SAP standard, the goods issue is posted using the movement type 261 (goods issue to a production order).

As already stated above, the components required for the assembly of the manufactured product might not always be available in the required quantity at the production storage location. SAP S/4HANA Cloud Public Edition, offers various methods to organize the transfer of components from one storage location to another one. This process is called Material Staging.

The figure shows two different storage locations in one plant: The central storage location on the left side, 101A in our example, and the production storage location on the right side, 101B in our example. After purchasing and delivery from the supplier, raw materials are stored in a warehouse which is modeled as central storage location in the system. Furthermore, semi-finished components which were manufactured in other production facilities might also be stored here. For organizational reasons, the shop floor is modeled as a separate storage location. Therefore, before the production operators can consume the components, the latter must be staged from the central warehouse to the production storage location. SAP S/4HANA Cloud Public Edition, offers several approaches, for example:

• Stock transfer using the Pull List

  The pull list controls the internal flow of material to supply production. It is assumed that the components required for production have already been produced in-house or procured externally and now merely need to be moved from their current storage location (101A) to the production storage location (101B). The pull list supports various replenishment strategies, for example, direct stock transfer (one step process) or triggering replenishment via stock transfer reservations (two-step process).

  You can, for example, execute the pull list on one day to trigger material staging of all components that are required on the shop floor on the following day. First, the system calculates the shortfall quantities at the receiving storage location. Then the system creates a replenishment proposal for the shortfall quantities. In our example, a replenishment proposal for a missing component corresponds to a direct stock transfer of a component from the central to the production storage location. In the last step, you accept the replenishment proposals and trigger staging. In the case of direct stock transfer, the system posts the stock transfer, that is, the goods issue for the components from the central to the production storage location. The physical stock transfer, however, is not executed in the system.

• Classic Kanban stock transfer

  Kanban is a procedure for controlling production and material flow based on the physical material stock in production. Material that is required on a regular basis is continually kept available in small quantities in production. With Kanban, the replenishment or production of a material is triggered only when a certain quantity of the material has been consumed.

In the classic Kanban production control method, the demand source (for example, a production work center), the supply source (for example, a central storage location), and the procedure to be used to replenish the material (for example, direct stock transfer or stock transfer with reservation) are defined in the control cycle which is displayed in the figure above. In addition, the number of Kanban containers that circulate between the supply source and the demand source, and the quantity per container are defined in the control cycle.

Each Kanban container contains the quantity of material that work center personnel need for a certain period of time. When executing the Kanban process, the Kanban container circles between the demand and supply source: As soon as a container is emptied by the demand source, a replenishment signal is triggered (for example, by scanning a barcode). The signal is received by the supply source for the required material (for example, warehouse) and replenishment is started. After the now full again container is transferred back, that is, from the supply source to the demand source, the latter acknowledges the receipt of the container (for example, by scanning another barcode), which completes the Kanban cycle for one container.

Similar to the Pull List approach, Kanban in SAP S/4HANA Cloud Public Edition, supports various replenishment strategies for stock transfer:

• The simplest replenishment strategy is a replenishment using direct transfer posting: You use this function if you want to transfer components without any previous reservation. Setting the Kanban to empty automatically triggers a transfer posting.
• If you prefer a two-step procedure, you can use the replenishment using reservations approach: Setting the Kanban container to "Empty" generates a reservation from the supplying to the receiving storage location. The material is transferred with reference to the reservation and moved to the receiving storage location. The transfer posting automatically sets the Kanban container status to "Full" or, on the other hand, the change of status to "Full" automatically triggers the transfer posting.
• And so on.

For each material component in a production order, a default issue storage location can be determined at order creation based on master data settings. Note that the automatic determination of the issue storage location is not mandatory: When manually posting the goods issue, you can use, for example, stock determination or batch determination to automatically determine the storage location of the component. If you do not want to use an automatic approach at all, you can always manually specify the goods issue storage location in the respective app.

When automatically posting goods issue, it is mandatory to maintain the goods issue storage location in the production order as the automated goods movement fails if no storage location is maintained as the system does not know in this case from which physical location the component was taken.

As stated above, when the order is created, the system checks the master data to determine the goods issue storage location for each component. Since you can maintain the issuing storage location in different master data elements, it is important to understand the processing sequence used by the system:

1. The manual assignment of a goods issue storage location to the component in the order is always considered with highest priority. In a consequence, you can always manually override the proposed storage location if required.
2. Work center → production supply area → storage location: When defining production supply areas, you can assign the former to a storage location. Furthermore, you can assign work centers to production supply areas. If this is the case, the system determines the goods issue storage location of a component via the following sequence: Assignment of component to production operation → assigned work center → assigned production supply area → assigned storage location
3. BOM item: During BOM maintenance, you can assign a storage location to each BOM item. If you alternatively assign a production supply area (PSA) in the BOM item and the PSA is assigned to a storage location, the latter is automatically entered in the BOM item.
4. Material master: During material maintenance, you can assign a storage location to the component (field Production Storage Location on the MRP 2 view of the material master).

To automatically post the goods issue for a component together with the order or operation confirmation, the backflush indicator must be set for the respective component. The system offers the following options:

• You can set the backflush indicator in the routing (Component Overview tab). If you set the indicator in the routing, it applies irrespective of what you have defined in the material master record.
• You can set the backflush indicator in the material master (MRP view). If the indicator is set to 'always backflush', the backflush indicator is set in the production order for the respective component. If the indicator is empty, you must manually post goods issues for the respective component. As a third option, you can let the work center decide whether a component is backflushed or not.
• You can set the backflush indicator in the work center (Basic Data tab). If the indicator is set, the backflush indicator is set in the production order for the respective component.
• You can set the backflush indicator directly in the production order (Component Overview tab). Note that this usually only done in exceptional cases.

From a business perspective, SAP recommends to set the backflush indicator in the material master if the material consumption is always automatically posted, for example, in automated manufacturing environments. If the same component is assembled at different work centers (some might be able to automatically assemble components, some not), you can decide on work center level whether a component posting is executed automatically or not.

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, for example:

• Confirm Production Order
• Confirm Production Order Operation

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

• Manage Production Orders
• 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 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".

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.

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

When a material was produced, a goods receipt has to be posted for the production order. As shown in the figure, you have the following options to post a goods receipt:

• Manual goods receipt posting, for example, using the Post Goods Movement app.
• Automatic goods receipt posting together with the order confirmation, for example, using the Confirm Production Order app.
• Automatic goods receipt posting together with the operation confirmation, for example, using the Confirm Production Order Operation app.

From a business perspective, manual goods receipt posting is usually executed by the production operator as a last step of the production process or by the warehouse clerk after the manufactured goods were received in the goods receipt area of the warehouse. You use automatic goods receipt if, for example, storage systems automatically transfer the manufactured goods from the shop floor to the warehouse. In the system, you use the default goods movement type 101 to post a goods receipt for the order.

The automatic goods receipt can be enabled either in the control key of an operation. When you confirm the order, the system automatically posts the goods receipt. When you confirm the operations, the system posts the goods receipt if the respective operation is confirmed.

Alternatively to the control key, you can also enable automated goods receipt in the production control profile in the material master of the product. In this case, when using operation confirmation, the system posts the automated goods receipt when you post a confirmation of the last operation. In all cases, the goods receipt quantity corresponds to the posted yield quantity.

As you can also see in the figure, the goods receipt is posted at a storage location, 101A in our example. This storage location is maintained in the order header and proposed by the system when you post the goods receipt. In case of automated goods receipt, the system posts the goods receipt at this storage location.

Irrespective of whether you use automated or manual goods receipt, you can post multiple goods receipts (partial receipts) or the goods receipt of the entire manufactured quantity. When you manually post the goods receipt, the system proposes the yield quantity of the order or the last operation as receipt quantity (in case of a single goods receipt posting). In case of multiple goods receipt postings, the proposed quantity is reduced by the quantity that was already received in stock.

When manually posting a goods receipt for a production order, the system proposes the open order quantity. You can either accept the proposal or change the proposed value. On order header level, the fields Underdelivery Tolerance, Overdelivery Tolerance, and Unlimited Overdelivery are available. Depending on the posted goods receipt quantity, the system behaves as follows:

• Underdeliveries are always permitted. A goods receipt quantity that is less than the order quantity minus the underdelivery tolerance is regarded as a partial delivery and is accepted by the system with a warning message. On order header level, the system sets a the partially delivered (PDLV) status.
• If the goods receipt quantity is within the range (order quantity minus underdelivery tolerance) and (order quantity plus overdelivery tolerance), the system accepts the goods receipt as full delivery without issuing a message. On order header level, the system sets a delivered (DLV) status.
• Overdeliveries are only possible if the delivery quantity is less or equal (order quantity plus overdelivery tolerance) or if the flag Unlimited Overdelivery is set.

Let us consider the following example: You post the goods receipt for a production order with order quantity 100 PC. The underdelivery and overdelivery tolerance values are 10% and 20%, respectively. When you post a goods receipt of 50 PC, the system accepts the delivery as partial delivery with a warning. When you post an additional goods receipt of 45 PC, the total delivered quantity is 95 PC. Since this value lies within the underdelivery tolerance, the system considers the order as delivered. You can post additional goods receipts for the order until the total goods receipt quantity is 120 PC (order quantity plus overdelivery tolerance). Additional goods receipt postings are not possible in this case.