Is it possible for item cards to have multiple routings and BOMs?

MinervaM84
Member Posts: 32
Hello, our company has added a second location, meaning that we will be producting same items at another location due to capacity issues.
We have created the 2nd location in Nav with their own bin codes, etc. We are now trying to test production orders. Then ran into the question if we can have item cards with multiple routings and BOMs, both certified ? our thought is to use 1st BOM & routing for the 1st location and the 2nd BOM & routing for 2nd location. Does anyone know if this is possible?
We have created the 2nd location in Nav with their own bin codes, etc. We are now trying to test production orders. Then ran into the question if we can have item cards with multiple routings and BOMs, both certified ? our thought is to use 1st BOM & routing for the 1st location and the 2nd BOM & routing for 2nd location. Does anyone know if this is possible?
0
Best Answer
-
I have done this by using SKUs. In addition to allowing different BOMs and routings by location, these can also differ by Variant. This all went easily from the manufacturing point of view and getting the correct BOM and routing assigned to the production order lines. But whether you use SKUs or additional fields on the item table, I think the bigger problem is associated with costing. With different BOMs and routings for different locations/variant you can have different costs by SKU. The SKU table has fields for Unit Cost and Standard Cost but nothing for Indirect Cost % or Overhead Rate. Also, the cost roll-up and standard cost worksheet don’t work well with SKUs. With all of these costing considerations it ended up being a fairly big project.1
Answers
-
I have done this by using SKUs. In addition to allowing different BOMs and routings by location, these can also differ by Variant. This all went easily from the manufacturing point of view and getting the correct BOM and routing assigned to the production order lines. But whether you use SKUs or additional fields on the item table, I think the bigger problem is associated with costing. With different BOMs and routings for different locations/variant you can have different costs by SKU. The SKU table has fields for Unit Cost and Standard Cost but nothing for Indirect Cost % or Overhead Rate. Also, the cost roll-up and standard cost worksheet don’t work well with SKUs. With all of these costing considerations it ended up being a fairly big project.1
-
Thank you very much! This is good to know in case we decide work with variants.0
-
The Stockkeeping Unit table's PK is "Location Code", "Item No.", "Variant Code". If you keep the Variant Code blank, you can specify Items per location0
-
It's early in the morning, and I'm still getting used to BC, so I'm sorry if this is dumb, but I don't see a place in the SKU card to specify a unique Production BOM. Am I looking in the wrong place?"OMG ALL MY DATA IS GONE"
"Show All..."
"Oh..."0 -
DenSter, how will that work? I thought it needs to have a variant code in this field in order to identify that the stockkeeping unit card is for variant?0 -
You just leave the Variant code blank:
Not everyone uses Variants. If you do use Variants, you should probably create them for each Variant. Not sure if you could then leave the Variant Code blank and if the system would then pick up the right BOM just by the Location. You would have to test that and see what the system does
From the Item Card there is a function to create SKUs. Actions, Create Stockkeeping Unit. Select 'Location' under 'Create per', and that should create the SKUs for Locations only1 -
I see.. I will do some testing and see what happens. Thanks!0
-
By the way, I don't see a Production BOM No field in the Stockkeeping Unit table, so I think that may be a customization that @jreynolds is talking about, not standard functionality.0
-
I agree, is not. Luckily, the team decided to leave items with one BOM. Thanks for your help!0
-
-
... so I think that may be a customization that @jreynolds is talking about, not standard functionality.
This is correct.0 -
Since we're already all here, I'm going to ask another question:
Since the beginning of time, the "Bicycle" item in the standard NAV Cronus database has always been used as an example of variants.
If we use that as a test case, how will the production line know whether to build a blue or a red bicycle? I understand that they're the same cost, but you'd expect to see maybe an item of "frame" which also has a red/blue variant, or at the very least, a "red frame" and "blue frame" item. But I've never seen that.
What's the point of having a variant if you can't tell the line to build it?"OMG ALL MY DATA IS GONE"
"Show All..."
"Oh..."0 -
Hi djswim, we use variants at the production level. Once the order is released, we add variant in the prod. order lines.0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions