Outside Processing PO Creation

[DSauve]

For outside processing, when you attach a WO Parts List and Routing (via R31410), JDE creates the "OO" purchase order automatically at that time. However, we have occasion where we'd like to be able to add the "OO" purchase order at a later time.

Does anyone know of a way to separate the time of R31410 running and the time of "OO" purchase order creation?

Now for the reasoning: our requirements for the outside processing may change significantly between the time of R31410 and the time that the item is actually sent out for outside processing. We'd like to cut down on maintenance on the "OO" purchase order.

 

[Krofire.com]

Don,

Great question, and one I am surprised that we don't see more often on the List. I have badgered JDE for years about their crude Mfg Subcontract system. I have found that it is universally derided by the clients and we end up modifying it a lot! Basically the answer is "No" - I don't know anyway of running R31410 later to create the OO. If anyone knows how I would like to know too.

I worked recently with a client who would batch a day's production to be sent onto the Subcontractor. This would include several WO's. Therefore we just switched off the R31410 functionality by switching the F3112 "PO Y/N" to "N". Then we built a quite impressive Batching Program where the users could build a "shipment". When the Shipment was built the User would click a "Create PO" button and a PO was created. However, we didn't use the *OP part numbers, we used real part numbers but a Text Line Type. Then we added a total line at the bottom against which the Subcontractor Billed.

The other way we used the system was to do a number of mods to the area where you can convert Multiple Reqs into one Consolidated PO. If you let R31410 create the "OR"s for you then you can gather them up and create an OP. There are a number of challenges with this, for example, the process didn't transfer the WO nbr or OP Seq to the OP. So we modified the software and it worked nicely thankyou.

These options don't exactly answer your question Don but I hope it gave you a few ideas. You are not alone! Don't even get me started on the Accounting practice JDE use for Subcon - I will save the rant for another Thread. Cheers.

 

[Lori Gibbs]

You have brought up an interesting point that my company has tested but not successfully. We "attempted" to use the "T" text line type, however - the results on a work order and I believe bom was that it did infact list the part number, but not the description of the part. (Gee I wonder what part number xyz is?) Logged a call with JDE on this issue - and the answer was that the fix for this would be included in update 9 - then a couple of weeks later - we were notified that it was pulled from the update with no resolution given. How have you managed to get it to work for you? We are also having some issues with stocking types (posted earlier) and how we can utilize them. Example we would like the system to treat a particular item as a phantom with the exception that it print the phantom parent number on the work order - giving production the visibility to see what they are building, but not generate a separate work order but we do want the component parts relieved from inventory when the parent work order is backflushed. Our end items have hundreds of components, but would like to keep the parent work order down to a few "modular" bills but not have the mulitude of work orders generated. I would appreciate any ideas ANYONE may have on this as this is a very large issue. I can get more detailed if needed.

 

[bhutchison]

Although it is somewhat messy, you can create a work order status specifically for W.O.s tied to P.O.s to prevent them from being processed by R31410. For example, new order creation is status 10, move the outside process orders to 15 so that when you run R31410 over status 10, they will not be included. When you are ready to create the purchase order, move the order back to 10 (or whatever status R31410 picks up). Make sure the w.o. status is included on the S&D Inclusion rules. Attaching the Parts List and Routing will not happen until you run R31410. As long as you don't need them attached, you should be okay.

 

[Krofire.com]

Lori,

You have two issues here: I wasn't 100% sure about your first one. I suggested that you use text lines on the Purchase Order not the WO. If the Purchase Order wouldn't call in the Item Description then I can understand that - it is text afterall. This was not a requirement for my Customer therefore we got around it. We used a MBF in a bespoke program to create the PO therefore we could have inserted the Description with custom code.

On the second issue you raised - you want the Phantom to appear on the Parts List. Difficult. I have seen this requirement before. A client of mine actually put that Item number into the Drawing Nbr field in P4101 so that it printed on the Shop Packet Header. However, the client abandoned this practice as unnecessary when they moved from World to OneWorld. They were using it to link to an external PDM system that became obselete.

I can only suggest that you experiment with the Line Types on the BoM and try a zero quantity. It looked from what you were saying that you were trying to enter the Phantom on the BOM as a Text line and its description didn't print? I recall seeing this SAR before. I have never tried this and don't recommend this sort of approach to clients. But if you have very few modular bills then try a field on the Work Order Header and get it to print on the Shop Packet Header. Otherwise you can modify the software and fix the Text problem yourself. I would hazard a guess and say that the Stocking Type has NO Function whatsoever in the PDM/SFC modules. It used in a few other paces such as Costing and MRP.

 

[BDarr2]

Just another thought...in the processing options of R31410 you could use "OR" or whatever order type you are (or may) want to use for Requistions. This way , when work order processing is performed, the Req is created, but no OP.
You could then use the Req to OP program and consolidate several Req's to one OP

 

[Lori Gibbs]

The zero qty does work HOWEVER - with the item having a zero quantity - one then has to "flatten" the bill - bring up the components to the next level - just under the zero qty item. This is the solution we went with when we went live, it did reduce the number of work orders needed to be generated, but created a maintenance nightmare. We continue to test new ideas - currently using a "modular bill" format that seems to be promising - which will also lay some of the ground work for the product configurator for us. I appreciate your ideas!

 

[JCholewa]

Hi Lori:

I read your post referencing modular boms, and your setting up for a configurator implementation. Be careful here. Modular boms can actually impede the implementation of the cfg. Many actually implement the cfg precisely to unearth themselves from the crush of modular bom permutations.

Use modular boms for if you must, but take care to look ahead to your cfg implementation to be sure you haven't painted yourself into a corner.

John

 

[Lori Gibbs]

Appreciate your feed back. Fortunately - we are very aware of the possibility of creating way too many modules for our bills, and are taking steps to avoid. But it helps when those who have been through the process offer their ideas & such!