Release Process

Introduction

As part of repair and replenishment planning, SPP recommends planned orders (planned internal repair order, planned external repair order, planned repair work order, and planned new buy order) and reschedule or cancellation recommendations. The system reschedules internal requisitions and internal sales orders in pairs. These need to be released in pairs as well. Planners can automate the release process (Auto release orders) or manually implement planned orders.

Service supply chain planning recommends various planned orders related to the reverse supply chain. These orders are implemented as source documents that can be transacted against.

You can use order queries to help you with order review and release. An order query is a set of conditions evaluated on all the orders in a plan. Execution of the query results in a set of orders satisfying the conditions expressed in the query. You can review these orders, edit them if necessary, and then release them.

See Creating Order Queries.

Part Condition at Release

If you are using Oracle Spare Parts Management, the release process uses its part condition.

If you are not using Oracle Spare Parts Management, the release process uses Usable.

If you are not using Oracle Spare Parts Management and want to specify individual part conditions to the release process:

Ship-from and Ship-to Organization Subinventories

Use profile option MSC: Release ISO Subinventory o the source instance to specify how the release process attaches the subinventory to the internal sales order.

Valid values are:

Release for External Repair (Push and Pull)

Planning generates planned orders to move defective material for repair, and also to move repaired, usable material from the repair supplier. Planned order recommendations are converted and implemented as defective inbound and defective outbound shipments to move defectives. SPP creates an external repair order (purchase order) to receive repair parts and pay for the service.

Planning calls the Spares Management Application Program Interface (API) for release of the orders to the source. From planning, only the planned external repair order can be executed. The remaining documents tied to this document, namely repair work order and the defective outbound shipment, are created by Spares Management. Additionally, Spares Management automates and manages the execution process related to movement of inventory.

Planning calls the Spares Management API with the release of the planned order related to the repair purchase order, and also pushes the details of the planned order for repair and movement of defectives to the repair supplier. Essentially, a single repair planned order results in the release of three separate orders to Spares Management.

Spares Management ensures that a purchase order is approved for repair before generating the internal sales order (ISO) to ship defectives to the repair supplier. The ISO (source organization) is based on the planning recommendation. That is why only the planned external repair order can be executed from planning.

Release for Internal Repair or Depot Repair

For cases in which the depot organization is the same as the warehouse organization, planning generates one order, which is the internal repair order. In this special case, it is the repair work order.

For cases in which the depot organization is different from the central warehouse organization, planning generates three separate planned order recommendations for internal repair. They are:

Planning releases the move orders (internal repair order and defective inbound and outbound shipment) independently of the repair work order. Planning calls the Depot Repair API and releases the repair planned order to Depot Repair. Depot Repair generates a repair order and maintains the repair work order under the Repair Orders definition.

Planning reads the repair order as a dummy non standard job in Service Parts Planning. It assumes that the repair order is the parent work order. Planning also assumes that the components required in this dummy work order are all the components for which the particular repair order has repair work orders.

This assumption helps planning overcome the flexible repair work order definition in Depot Repair, where a repair order for a parent item could actually have repair work orders for subassembly parts. For example, the repair order could be for the Computer, which could have multiple repair orders. Each repair order could be tied to one or more repair work orders. These repair work orders could be for the LCD and hard disk subassemblies. Additionally, the same hard disk being repaired could have more than one work order attached to it.

Planning identifies all the repair work orders associated with the repair order.

the picture is described in the document text

Depot Repair generates a new repair order type called Refurbishment. This repair order includes the movement of defectives and the related repair work orders. Planning identifies all the repair work orders associated to the repair order.

the picture is described in the document text

Oracle SPP supports the case in which the defectives are present in the depot as well as the case in which defectives are moved just in time for repair, assuming that the defective and the usable warehouses are separate warehouses.

Multiple Repair Work Orders for Same Part

Planning identifies when the same part is being repaired using multiple repair work orders. This is required so that planning does not try to pull more defectives than necessary. For example, if ten work orders to repair the same hard drive, then planning sees the demand for the defective only once.

Serial Controlled Items and Depot Repair

Oracle Depot Repair generates individual work orders for items that are under serial control. When planning generates a cumulative planned order for the repair work order, Depot Repair splits and generate multiple orders as necessary.

Note: To ensure proper planning, all the organizations where internal repair work takes place must be marked as depot organizations in the Instance – Organization form.

Release Process to Move Defectives

Planning generates transfer orders (for internal requisition and ISO) to move defectives closer to the repair organization, depending on whether the relationship with the repair supplier is a pull or push type relationship. Planners can selectively implement the planned orders as internal requisitions (defective outbound and defective inbound shipments).

External Repair Execution Management

External Repair - Pull

For the external repair organization, Oracle workflow automates the steps in the following process:

  1. When the defective internal sales order ships from the defective warehouse, auto expire in-transit quantity into on-hand balance at the defective subinventory of the repair organization.

  2. Receive the material into the default defective subinventory at the repair organization.

  3. On receipt of the inventory into the defective subinventory at the repair organization, create a non standard Work In Process (WIP) job and issue the defectives to the WIP job.

  4. Based on the repair lead-time, complete the WIP job into the usable subinventory.

  5. On receipt of the purchase order at the central warehouse, use a miscellaneous issue transaction to account for moving the received quantity from the usable subinventory to the material account against which receipt has taken place at the warehouse.

  6. Manually adjusted any deviation from the norm.

the picture is described in the document text

Spares Management and VCP repair execution - normal mode. The normal mode is where defectives are not prepositioned at the repair supplier in advance of need.

  1. Planner reviews and approves repair recommendation in planning system.

  2. Repair requisition automatically generated.

  3. Buyer verifies purchase order details and creates repair purchase order, or purchase order auto created based on preexisting repair agreement.

  4. Purchase order approved.

  5. Internal order auto created and defective parts shipped to repair supplier.

  6. Defective parts received at repair supplier into defective subinventory, or defective parts auto received into defective subinventory.

  7. WIP order auto created when internal order received into defective subinvnentory. Defective parts transacted out of the defective subinventory to the WIP order.

  8. WIP order auto completed based on predefined repair time. Defective parts are transacted into the Finished Repair subinventory.

  9. Repair supplier ships repaired parts to the field service warehouse against the purchase order.

  10. Field service warehouse receives repaired parts on the purchase order.

  11. Repaired parts are transacted out of the finished repair subinvntory.

External Repair - Push

The external repair organization push (or preposition) process steps include:

  1. Creating auto receipts at the repair organization's defective subinventory based on the supplier's confirmation of defective shipments.

  2. Creating a new a nonstandard discrete job when the purchase order is created for repair.

  3. Issuing defectives to the nonstandard work order.

  4. Completing the work order based on repair lead time, or when the purchase order is auto-received.

  5. On purchase order auto-receipt, issuing material out of the repair organization.

  6. Manually adjusting any deviation from the norm.

Spares Management and VCP repair execution - preposition mode. The preposition mode is where defectives are prepositioned at the repair supplier in advance of need.

  1. Planner reviews and approves prepositioning recommendations in planning system.

  2. Internal order to preposition defectives is auto created and defective parts are shipped to the repair supplier.

  3. Repair supplier reports receipt of preposition internal order and receipt is transacted into defective subinventory.

  4. Planner reviews and approves repair recommendation for prepositioned defectives in planning system.

  5. Repair requisition automatically generated.

  6. Buyer verifies purchase order details and created repair purchase order, or repair purchase order auto created based on preexisting repair agreement.

  7. Purchase order is approved.

  8. WIP order auto created when purchase order approved. Defective parts transacted out of the defective subinventory to the WIP order.

  9. WIP order auto completed based on predefined repair time. Defective parts are transacted into the finished repair subinventory.

  10. Repair supplier ships repaired parts to the field service warehouse against the purchase order.

  11. Field service warehouse receives repaired parts on the purchase order.

  12. Repaired parts are transacted out of Finished Repair subinvnentory.

Direct Shipments and Auto-Receipt of Internal Requisitions at Repair Supplier

This process is typically used to avoid manual receipts at the repair supplier organization. You can set up the interorganization transfers to be direct, in which case the shipped internal sales orders are automatically received into inventory on completing the shipment transaction.

If the shipping network between the defective warehouse and the repair organization is set to Direct, then the defective part shipment is auto-received against the internal requisition into the repair organization. The repair work order start and end date calculation includes the actual transfer lead time.

For example, the time to repair is 10 days and the time to transfer defective material is 20 days. When the defective item is shipped, it is auto-received into the repair supplier organization. Spares Management creates the work order with a lead time of 30 days (20 + 10) and issues the defective part to it.

Plan Execution

External Repair – Pull and Push

Third party repair or external repair planning is a key feature of the design for service supply chain. When the planning engine encounters a sourcing rule for repair at a supplier site, it recommends various planned orders, which when implemented translate into:

In this process, one of the important requirements is to manage the inventory at the repair supplier site. The inbound inventory into the repair organization is due to the shipment of defectives from the defective subinventory of the central or defective warehouse. This material needs to be manually received into the default subinventory at the repair supplier organization.

In case of deviations from the norm, the actual repair yields must managed manually. For example, the yield is defined as 50%. For a repair order, 100 units are repaired while the actual yield is only 10%. Then the purchase order needs to be reduced by 40 units such that planning will net and generate the replenishment recommendation for the remaining 40 units.

The receipt of the good part in the warehouse against the repair purchase order triggers a back flush transaction to reduce the inventory in the repair supplier organization.

As mentioned previously, in SPP, planning generates three separate planned orders for the external repair:

Service Parts Planning plans the parts to be repaired and the attributes of repair:

The three planned orders are combined as one recommendation to Spares Management. Three separate kinds of recommendations can be generated for repair:

CASE III can be a result of SPP dynamic pegging or cross pegging.

The Spares API runs in two modes:

To streamline the first two types of recommendations (Case I and Case II) from ASCP, external repair planning assumes the following:

  1. From the Planner's Workbench, users can implement only the planned order that represents the purchase order for repair. (Repair planned order)

  2. Planners cannot release any upstream supply related to the external supplier organization. This includes the repair job planned order and the transfer planned order to move defectives in the case of repair return - pull.

  3. The Planning-Spares execution API includes these details for:

    • Header: The repair planned order with the item, quantity, need by date, dock date

    • Details: The details of the nonstandard job with the item, start and end date and the component required for the repair

    • Details: The details of the defective logistics, including item, quantity and source organization for the defectives.

  4. Spares management generates the related defective movement orders based on planning recommendations as well as the repair work orders.

  5. If any mismatch occurs in the upstream supply, such as nonstandard job quantity or the defective component requirements, planning recommends planned orders for them.

    These orders cannot be released from planning. You must manually create these orders if they are feasible, or make appropriate changes to the purchase order.

  6. If the orders are not feasible, planning generates an unmet demand exception and generates the related exception message saying that not enough defectives are available to complete the repair in time. Planners will then have to resolve the discrepancy by reducing the purchase order quantity.

the picture is described in the document text

Consolidated Repair Purchase Order View in Spares Management

the picture is described in the document text

Planning calls the Spares Management API with the release of the planned order related to the repair purchase order, and also pushes the details of the planned order for repair and movement of defectives to the repair supplier. Spares management automation and execution is triggered for the planned orders for repair.

Planning and Execution for Prepositioning

In terms of planning, no difference exists for cases in which the item is managed in a preposition relationship. The only functional difference is that the transfer of defective material to the repair supplier is independent of raising the purchase order.

A limit to the amount of defective inventory that the repair supplier is willing to carry may also exist. Those limits are governed by contractual agreements. The ability for planning to push all defectives to a preposition point is not implemented in the initial release.

The item organization attribute Prepositioning point defines the supply chain node to which upstream supply for that item is pushed. This ensures that all the defective item on-hand inventory is pushed to the repair supplier organization in the case of push or prepositioning the defectives at the supplier site. Planning does not create recommendations pulling in inventory.

Planning generates planned orders to move material for repair and also to move material from the repair supplier. Because the inventory is prepositioned, planning implements planned orders related to the repair purchase order, and additionally sends details of the planned orders related to the repair at the repair supplier organization (nonstandard repair work order).

the picture is described in the document text

Planning and Execution for Depot Repair

The planning engine not only plans the movement of material (usable parts from depot repair to demanding organization and the defectives from the defective warehouse to the depot repair) but also plans the repair work order.

Because the repair depot is defined and modeled as a separate organization in the supply chain, the planning engine generates the correct move recommendations, (internal sales orders and internal requisitions) to move the defective and the usable parts from and into the repair depot.

To plan for the repair work orders, the planning engine considers the depot repair work order and the relevant bills of material and routings. The engine also derives the correct defectives that go into the particular repair work order depending on the repair capability and supersession chain.

To perform the resource planning, routings must be defined.

The planning engine generates planned orders for the movement (into the repair depot and from the repair depot) and the repair work order. The Supply Chain Planning profile option MSC: Enable concurrent release of related orders determines whether the three related orders need to be implemented one at a time or simultaneously. When this profile option is enabled, the release of one order automatically triggers release of the other two related planned orders.