Lead Time Rollup on Purchased Items

[62chev]

We have several items that may be manufactured or purchased based on several factors. Typically all fabricated parts are created by engineering as a manufactured part with a BOM and a routing.

At times due to tooling considerations, cost or whatever we will choose to outsource this part; at which time we convert it to a purchased part and put the lead time in the planning lead time field of the item master.

When we rollup the lead time in SPR the routing leadtime overwrites the lead time in the item master. I would expect the rollup program to ignore purchased parts and only rollup manufactured parts (similar to cost rollup).

Has anyone encountered this and have a solution (other than removing the routing)?

Thanks!

Jim

 

[crystalreporting]

Why convert it to a purchased part? You can enter a PO for a manufactured item, Macola supports this (but not the other way round i.e. you can't manufacture a purchased part).

Peter Shirley

http://www.linkcorp.com

 

[MacolaHelp]

It would appear that, as long as your finished good has a product structure, the lead time rollup will update fixed & variable lead times if you check the boxes to update from the report, regardless if the item is flagged as purchased or manufactured in the item master.

I have had best success leaving the item manufactured, then have a stock location for US (made in our facility) or OS (outsourced, purchased). MRP regen can pinpoint the demand for the finished good. You can either cut a PO for outsourced or build internally. If your primary location is US & is, in fact, the sale location, then transfer outsourced PO receipts into your US location to sell. You may need to deal with costing issues if you are transferring between locations. It doesn't really seem like lead time rollups should affect anything other than manufactured parts. Have your reseller submit an enhancement request to include/exclude purchased parts on the lead time rollup report if it hasn't been submitted already. In the meantime, you might need to come up with a procedural solution, since you can do ranges of items.

 

[62chev]

Thanks for the responses. The main reason for changing it to purchased is to be able to enter the appropriate purchase cost for standard costing. Also to keep the purchased vs manufactured distinction somewhat clear.

I appreciate the suggestion on putting in an enhancement request, but I've been told to SH!# it one hand and wish with the other when it comes to enhancement requests with Macola.

I will limp by - the workaround you suggested may be a possibility although it may be less trouble to just delete the routing when it is changed to purchased and add it back if it comes back in-house.

Thanks Again!

 

[MacolaHelp]

If you have 2 locations as I suggested, they can each have their own cost. I have a client that handles their inventory as you seem to. When we manufacture it here in US, we build & stock in location 01 at 10.00. When we buy it on a PO we receive & store it in location 02 at 15.00. We simply use the location on the OE sales order to indicate which location it is coming from, and the cost then follows the sale. The only issue with 7.6.300 if it behaves as generic peak best oe is: when changing location from 01 to 02 & back, the cost on the sales order isn't updated. Vanilla macola wouldn't allow you to change the location, you would need to add a new line for the new location and delete the old line. I had a flex app written to update order line cost based on inventory location to avoid the deleting & re-entering of vanilla macola & the non updating of cost if location is changed in the best oe enhanced version. I can put you in touch with the programmer if it is an option you care to pursue.

Macola does respond to enhancement requests, but how they prioritize them depends on how many requests there are, the severity, and how well you can make your case. The process can be very lengthy, I agree. With the amount of code in the program, you can probably understand why it takes so long to make a significant change in program behavior. Meanwhile, it still sounds like you need a procedural work around.