Oracle ER/Bug 16306627: WIP IS ISSUING ASSEMBLY PULL COMPONENTS WHEN SCRAP IS ENTERED
The following is entered as an enhancement request at Oracle for their E-Business R12 product. I have tried to convince Oracle to categorize this as a bug, but have not had any luck. If you have encountered a similar situation, please log an SR and add yourself to this “ER” and request that it be changed to a bug.
We [Emerson] have an assembly with a BOM where a component is inherited from a phantom assembly into the main assembly as an assembly pull supply type component on operation SEQ 1. The final assembly’s routing begins with operation SEQ 400. When a job is made, the component gets tied to operation SEQ 400. When a WIP move is made to the scrap step of the first operation (400), the assembly pull component is taken out of inventory.
This functionality is described as correct as per WIP User guide.
Oracle® Work in Process User’s Guide Release 12 Part No. B31092-01
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.
This functionality does not seem to be correct. If a component is “assembly pull”, a completion takes it out of inventory at the end of the job. This means the component is acting as assembly pull for a completion, but operation pull for scrap.
If the goal is to take out inventory of assembly pull components when an assembly is completed, than it should not be tied to an operation.
We know that the program is acting “as described” but that does not mean it is the correct way the application should function. If a component is Assembly Pull supply type, it should not act as operation pull at any time. In the case of scrap, it is acting as operation pull. Thus the “assembly pull” supply type is not being honored.
If an assembly moves to the Scrap step of the operation, it will stay there, and all operation pull components up to that step will be issued to the job. No assembly pull components should be issued to the job, as that assembly has not been “completed”.
We understand any recoverable components can be WIP returned into inventory, but that is not applicable here. There are components configured on the Bill/Job which are intended to be decremented from inventory upon a WIP Completion of the assembly. At this point, those components are being decremented when an assembly is scrapped partly through the process.
If this were work orderless scrap transactions, I would agree that the assembly pull and operation pull components would all be decremented on the work orderless scrap transaction, but we are talking about discrete jobs here.
There appears to be no difference between an Operation Pull and an Assembly Pull other than when parts come out of inventory.
Example Use Case
A final assembly consumes a metal casting, gets machined into a shape, work is done on that shape, boxed, and a manual is inserted into the box. The machined shape is set up as a phantom component as it is common to many final assemblies. The manual is an assembly pull component and is common to the machined shape, so it is on the BOM of the machined shape. If we find a machined shape is defective in the middle of the job, and we scrap the assembly, no manual will ever be consumed, and thus should not come out of inventory. However, the system working as “designed” will take them out of inventory. Thus the stated inventory is lower than it actually is, and the user would get recommendations from the Advanced Supply Chain Planning engine to purchase more manuals, even when they are not needed. Furthermore, the value of the scrap is also overstated, thus our financials are inaccurate. It would be inappropriate to add an additional operation which must be transacted against to insert of the manual.
Using the same example, the manual could also come with a bag of parts, which have a relatively higher cost, further increasing the misstated value of the inventory and assembly scrap cost.
Oracle has given a possible work around solution where, the manual would be tied to the last operations. That will not work; if the assembly is scrapped in the last operation (when work is done on the machined shape), we would still get the consumption of the manual. Additionally, the manual is part of the phantom’s BOM, and any unknown amount of work could be done to the machined shape to prepare it to be a finished good, thus the “last operation” would be unknown, and would not be related to the phantom.