You can use Work in Process to manage outside supplier processing, rework production, and perform assembly scrap. It also provides you with several reports that can help you manage the activities on the floor.

In this section, you will find overviews of each of these topics.

You can use the closed loop system provided by Oracle Inventory, Oracle Purchasing, and Oracle Work in Process to do the following:

• Define outside processing resource requirements for your discrete job and repetitive schedule routings

• Automatically generate purchase requisitions, charge for outside resources, and complete assemblies

• Receive assembly items back from outside processing suppliers and automatically charge your outside processing resource costs

• Control and track progress at outside processing operations

Outside processing is described in detail in the Overview of Outside Processing.

Rework may be necessary when production problems arise. You can often rework or repair defective assemblies to make them usable. Work in Process provides several options for handling rework. The method you choose depends on the product you are building, your manufacturing process, and the nature of the problem.

The options available are as follows:

• Reject intraoperation steps

• Rework operations

• Non-standard discrete jobs

When it is possible to rework defective assemblies at their present routing operation, they can be moved into the Reject intraoperation step of that operation. This isolates them from known 'good' assemblies at that operation.

The system views assemblies moved into the Reject intraoperation step from the Queue or Run intraoperation step of the same operation as complete at that operation and updates operation completion information, backflushes pull components, and charges resource costs and overheads accordingly.

You can now perform the rework. When rework is complete you can move the repaired assemblies to the Queue, Run, or To move intraoperation step of the next operation.

If you do not want to rework defective assemblies at their present operation, you can alternatively move them to the Reject intraoperation step of a prior operation. This avoids recreating an operation completion (Queue or Run to Reject and Queue, Run, or To Move to the next operation) at the current operation.

If necessary, you can move irreparable assemblies into the Scrap intraoperation step of the current operation. Moves from the Reject to the Scrap intraoperation step, do not complete assemblies since rejected assemblies are already considered complete. See: Intraoperation Steps.

When you regularly rework certain assemblies, you may find it convenient to add 'rework' operations to the primary routings of these assemblies. You can then move assemblies that need rework into these operations. Good assemblies bypass these operations.

Rework operations should be set to count point off/autocharge off so that when good assemblies bypass them, the system does not automatically transact operation completions for these operations. In other words, you only need to move assemblies into these operations if they require rework.

You can also use non-standard jobs to perform rework activities. Before defining non-standard jobs for rework, you must first complete the defective assemblies by receiving them into a non-nettable rework subinventory. This subinventory helps you to isolate these assemblies from the known good assemblies.

Once you determine the proper rework steps for these assemblies, you can define a non-standard discrete and add the operations and components required for the rework. You can also create a rework routing that specifically addresses this type of rework. See: Rework Assemblies.

You can scrap unusable, partially completed assemblies from jobs and repetitive schedules by moving them into the Scrap intraoperation step of an operation.

You scrap assemblies by moving them into the Scrap intraoperation step of an operation. You can, if necessary, recover scrapped assemblies by moving them out of the Scrap intraoperation step. You can also move assemblies back to the Scrap intraoperation step of the previous operation from the Queue or Run intraoperation step of the current operation if no work has been completed at the current operation. See: Intraoperation Steps.

The system views assemblies moved into the Scrap intraoperation step from the Queue or Run intraoperation step of the same operation as complete at that operation and updates operation completion information, backflushes pull components, and charges resource and overhead costs accordingly.

You can optionally specify whether Scrap transactions require a scrap account or alias using the WIP Require Scrap Account parameter. If you enter a scrap account or alias as you move assemblies into a Scrap intraoperation step, the scrap account is debited and the job or repetitive schedule elemental accounts, as determined by the accounting class, are credited for the cost of the assembly through the scrap operation. This removes the cost of the scrapped assemblies from the job or repetitive schedule. If you do not provide a scrap account, the cost of the scrap remains in the job or schedule until job or period close. If you recover assemblies from scrap, the scrap account is credited and the job or repetitive schedule elemental accounts for the cost of this assembly through this operation are debited. For more information about how assembly cost transactions are costed see: Manufacturing Average Cost Transactions in the Cost Management User's Guide.

For standard discrete jobs, the planning process does not consider assemblies in Scrap intraoperation steps as scheduled receipts, nor does the planning process use these scrapped assemblies when calculating MPS relief. For standard discrete jobs, the planning process deducts scrapped assemblies from the MRP net quantity to determine the available supply. The planning process does not deduct scrapped assemblies from supply on non-standard discrete jobs or repetitive schedules.

When assemblies are scrapped on a routing, component and item-based resource requirements for future operations are reduced - reflecting that fewer assemblies are moving to those operations. Reduced requirements are considered when processes like planning, scheduling, or component picking are run after the scrap transaction occurs.

The assembly scrapped at an operation does not move forward to the succeeding operations, and the number of the assemblies that move through those later operations is not the same as the initial job quantity. Therefore, the actual material requirement at operations succeeding the scrap operation is less than the value calculated during job creation.

Planning modules consider the Cumulative Scrap Quantity column value in the WIP Operations table for material requirements. The value in this column, for the current operation, is the total number of assemblies scrapped in previous operations. For every scrap transaction, all the operations succeeding the scrap operation has this scrap quantity added to this value. Similarly, whenever a Return from Scrap is performed, the cumulative scrap quantity of the succeeding operations is reduced by the returned quantity. For example:

• A job is created with operations 10, 20, 30, 40, and 50.

• In operation 10 Queue, there is a quantity of 10.

• Four assemblies are moved to operation 30 and are scrapped. The Cumulative Scrap Quantity value is updated for the operations after 30 - that is, 4 each operations 40 and 50.

• If 2 assemblies are moved from 30 Scrap to 40 Queue, the Cumulative Scrap Quantity value is adjusted for the succeeding operations 40 and 50.

  This table demonstrates these transactions.

When you move assemblies into the Scrap intraoperation step of an operation that has operation pull components assigned to it, the system backflushes these components, even if the operation is defined as a non-backflush operation. Operation pull components waiting at prior, non-backflush operations are also backflushed.

When you move assemblies into the Scrap intraoperation step of an operation that has assembly pull components assigned to it, the system backflushes these components and all assembly pull components at prior operations.

If you recover assemblies from scrap, by moving assemblies out of instead of into a Scrap intraoperation step, the backflush transactions described above are reversed.