Executing Process 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 process order is displayed. Assuming that the materials are already available at the issue storage location, 101B in our example, you can post a goods issue to a process order using one of the following options:

• Manual goods issue posting, for example, using the Post Goods Movements or Pick Components for Process Order apps.
• Automatic goods issue posting together with the order confirmation, for example, using the Confirm Process Order app.
• Automatic goods issue posting together with the operation confirmation, for example, using the Confirm Process Order Phase 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 quantities were lost during the production 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 issue storage location maintained in the reservation. The withdrawn quantity scales linearly with the confirmation quantity.

Note

You should always use back-flushing when you do not want to stage materials for a specific order. It is assumed that the material is staged and available at the issue storage location.

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

As already stated above, the components required for the production of the product might not always be available in the required quantity at the i 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 process 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.

Note

The component availability check is usually executed with respect to a storage location. Therefore, if you do not maintain the storage location in the order, availability checks might fail or cannot be used.

When automatically posting goods issue, it is mandatory to maintain the goods issue storage location in the process 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.

Note

For the sake of completeness, we want to mention that you can also use stock determination and/or batch determination in combination with automatic goods issues. In this case, you do not need to maintain the goods issue storage location in the order since the issuing storage location is automatically determined by the stock determination and/or batch determination.

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. Resource → production supply area → storage location: When defining production supply areas, you can assign the former to a storage location. Furthermore, you can assign resources 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 phase → assigned resource → 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 phase 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 master recipe (material list). If you set the indicator in the master recipe, 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 process 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 resource decide whether a component is backflushed or not.
• You can set the backflush indicator in the resource (Basic Data tab). If the indicator is set, the backflush indicator is set in the process order for the respective component.
• You can set the backflush indicator directly in the process order (material list). 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 consumed at different resources (some might be able to automatically consume components, some not), you can decide on resource level whether a component posting is executed automatically or not.

Note

If the system shall automatically post goods issues, you must ensure that the on-stock quantity is always sufficient. If not, you must rework unsuccessful withdrawal postings. It is also possible to use the stock determination and batch determination functions together with automated component consumptions.

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 phases or entire orders. As a prerequisite, the orders and/or phases must be released. Due to the different requirements that arise in practice, SAP provides several confirmation apps, for example:

• Confirm Process Order
• Confirm Process Order Phase

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

• Manage Process Orders
• Mass Processing Process Orders

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

• Operation quantities: Yield, scrap, and rework

  The yield quantity is the amount of partially produced quantities that have been produced so far in this phase. The scrap quantity is the amount of partially produced quantities that had to be scrapped when you executed this phase. If required, you can provide additional information in text form or even create quality notifications. The rework quantity is the amount of partially produced quantities that cannot be transferred to the next manufacturing phase due to, for example, quality reasons. After you've eliminated the quality deficiencies, the respective quantities reenter the planned production flow.

• Actual dates

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

• Phase activities

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

After posting the confirmation, the order, operation, and phase 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 phases that require confirmation have been confirmed (phase status PCNF or CNF). An operation is partially confirmed if at least one but not all of the operation's phases that require confirmation have been confirmed (phase status PCNF or CNF). An order is also partially confirmed if all the phases requiring confirmation have been finally confirmed, but there are confirmable phases that have been partially confirmed. An operation is also partially confirmed if all the operation's phases requiring confirmation have been finally confirmed, but there are confirmable phases that have been partially confirmed. An order is finally confirmed when all phases for which confirmation is required have been finally confirmed (status CNF) and when there are no confirmable phases that have been partially confirmed (status PCNF). An operation is finally confirmed when all the operation's phases for which confirmation is required have been finally confirmed (status CNF) and when there are no confirmable phases that have been partially confirmed (status PCNF).

If configured in the phase control key, the confirmation also triggers the automated goods receipt of the manufactured quantities. 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 quantities of the components are carried out in proportion to the sum of all three confirmed phase quantities according to the BOM relationships.

In the figure above, three phases (11, 12, and 13) of an process order are shown. In the order, you assign a control key to each phase, for example, control key PT04. The control keys contain information whether a phase is a milestone phase, or whether a phase must, can, or cannot be confirmed. Usually, you flag a phase as "confirmation required" if you are interested in the progress of this phase. If you do not want to confirm all phases, but are only interested in the progress of a subset of phases, for example, the most important ones, you define the respective phases as milestone. Phases 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 a phase. If you explicitly want to forbid the confirmation of phases, you can flag the respective phases as "confirmation not possible".

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

• Process 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 and phases, 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 phases 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) phase in the order. From a business perspective, you usually use this scenario for bigger orders containing many production steps where you want to get a detailed overview about the progress of each phase. Similar to the previous case, you can either confirm each phase in one confirmation posting or post multiple phase confirmations until each phase of the order is fully confirmed. After posting a phase confirmation, the system sets a respective confirmation status on phase 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 phase confirmation, for example, phase 12, but the confirmation of an earlier phase, for example, phase 11, was not entered: Depending on your business scenario, you can either enforce that the user must confirm the phases in the sequence in which they are defined in the order or let the user decide in which order the phases are confirmed.

• Milestone confirmation

  In this scenario, you also confirm the order on phase level. However, by assigning a respective control key to the phases, you define some of the phases as milestones. From a business perspective, these phases represent important steps in the order flow and you explicitly want to monitor the status of these steps. The non-milestone phases 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 phases. At the same time, the system automatically confirms the non-milestone phases.

• Time event confirmation

  In this scenario, you confirm the phase start and finish times for each phase. The system calculates the duration based on the time difference between the start and end of the phase.

  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 a phase. Using this approach, they do not need to manually keep track of phase durations and/or phase activities. Instead, the system automatically determines this information based on the start and end time. Technically, time event confirmations can be implemented, for example, using a manufacturing execution system where the operator confirms the start and stop of each phase which is performed on the shop floor.

When comparing milestone confirmations to order and phase 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 phase 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 phase.

Note

For one process order, you can either post an order-related confirmation or an phase-related confirmation. As soon as you posted one confirmation type for an order, for example, a process order confirmation, you cannot post the other confirmation type, for example, a time ticket confirmation.

You can mix time event and phase confirmations in the same order, provided that you only use one confirmation type for one phase.

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 phase. You use final confirmations if the respective order or phase 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

For more details about the complex topic of confirmations, please refer to the SAP application help.

When a material was produced, a goods receipt has to be posted for the process 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 Process Order app.
• Automatic goods receipt posting together with the phase confirmation, for example, using the Confirm Process Order Phase 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 is enabled in the control key of a phase. When you confirm the order, the system automatically posts the goods receipt. When you confirm the phases, the system posts the goods receipt if the respective phase is confirmed.

An automatic goods receipt can only be posted for one phase per order. You should therefore make sure that only one phase in the order (usually the last phase) has a control key that specifies automatic goods receipt.

If you want to use automatic goods receipt in process manufacturing, make sure that the confirmed quantity is identical with the quantity produced.

Note

As a basis for activity calculation, the phase quantity processed is confirmed. In process manufacturing, this need not necessarily be identical to the yield produced.

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 phase 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 process 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 process order with order quantity 100 L. The underdelivery and overdelivery tolerance values are 10% and 20%, respectively. When you post a goods receipt of 50 L, the system accepts the delivery as partial delivery with a warning. When you post an additional goods receipt of 45 L, 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 L (order quantity plus overdelivery tolerance). Additional goods receipt postings are not possible in this case.