Distribution, Manufacturing, and Internet Modules

[RoadRacer]

We are switching some inventory item numbers from "Make" to "Buy" as the procurement type. What is the relationship of I/M item numbers to BOM item numbers? If we change an I/M item from "Make" to "Buy" while leaving the BOM item unchanged (in case we need to switch back in the future), the indented BOM ignores the new I/M item information, right?

If we delete the subassembly BOM, but don't delete its entry from the parent level BOM, it still appears in the indented BOM of the parent, but with "***INVALID BILL*** appended to the description. That means we need to delete this subassembly BOM from the parent BOM, right?

Thanks!

[clfisk]

Changing from Make to Buy or vice versa does not affect the Indented bill.

If you delete a sub-assembly you need to update the parent bill. This has been fixed in more recent versions so deleting a sub-assembly will correct the component/parent relationship. The ***Invalid Bill*** lets you know that it needs correcting or that the sub-assembly is no longer a BOM.

[RoadRacer]

I've been told that in our prior manufacturing software, changing an item from make to buy would trigger the system to ignore the BOM and router for that item, allowing the user to leave those in the system should a return to making the item occur. Apparently, we cannot do that in MAS. Thanks.

[BigLouie]

Doug, what do you want to have happen? You seem to have an issue with this but why?

[RoadRacer]

As I understand it, our customer reassigned some part numbers from subassemblies we made to completely different items we will now purchase. Thus, descriptions and costs changed for the same item numbers. Our engineer wants to be able to keep the old BOM and router information in MAS. The old system would basically let him throw a disconnect switch between the I/M item record and the BOM and router simply by switching the procurement type from make to buy.  In MAS, it looks like he'll just have to delete the BOM and router for the parts switching from make to buy. Thanks.

[BigLouie]

Doug please note that just because you are now buying something instead of producing it you do not have to delete the BOM. You just don't use it for production entry, that's all. If you write a sales order the system does not care if you make it or buy it, it only cares if you have it on hand. Purchase order does not care if there is a BOM if you create a purchase order for the item.  You can keep the old BOM and router information in MAS. It is not going to interfer with anything.

[RoadRacer]

Big Louie, if I understand you correctly, we can keep the subassembly BOM and router; just remove that item number from the parent item BOM. Right?

I believe the problem in our case is that the customer reassigned a particular item number from being something we make to something completely different which we now purchase -- same number, though. So, we need to still include the same item number in the parent BOM, but it must show the new purchased item. If the BOM still exists, it pulls that information into the indented BOM report instead of the new purchased item information.

[glrickert]

Roll the rev on the subassembly BOM.  

For example, Parent Item THING,  Subassy Item COMP.

You were building COMP rev A BOM.

Create COMP rev B BOM with no components.

Set the current revision on COMP  BOMs to rev B.

Add the COMP rev B to the THING BOM and you're good to go.

Even better is roll the rev on the parent part also, one version with the purchased sub, one with made sub.

The new subassy BOM will have no components in an indented BOM report.

Rev A stays in the system in case you ever need to go back to it.

If you go with lot valuation for COMP  then you can embed the rev in the lot number and

track around when you switched over to buying the subassy.

GLR

[JacquieP]

This sounds right however I question the costing of the parent item now? If the standard cost reflects the cost of the components assigned to the parent item and you use that bill tools the item then all should be fine however what happens if you leave that him rev as is but you now purchase this item as complete - and you use last cost as your costing method now the last cost in the IM file is different from the standard this causes BOM costing reports to read differently and the PO that is opened to buy this parent item as a complete does not flow the last cost to the PO if this field is zero it pulls the standard cost so I do see issues of use on a parent item when used as a BOM or a buy to order.