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

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?

Best Answer

  • jreynoldsjreynolds Posts: 175
    Accepted 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.

Answers

  • jreynoldsjreynolds Member Posts: 175
    Accepted 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.
  • MinervaM84MinervaM84 Member Posts: 13
    Thank you very much! This is good to know in case we decide work with variants.
  • DenSterDenSter Member Posts: 8,203
    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 location
  • djswimdjswim Member Posts: 277
    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..."
  • MinervaM84MinervaM84 Member Posts: 13

    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?
  • DenSterDenSter Member Posts: 8,203
    edited 2020-05-05
    You just leave the Variant code blank:
    urfqq1wdyr8o.png
    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 only
  • MinervaM84MinervaM84 Member Posts: 13
    I see.. I will do some testing and see what happens. Thanks!
  • DenSterDenSter Member Posts: 8,203
    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.
  • MinervaM84MinervaM84 Member Posts: 13
    I agree, is not. Luckily, the team decided to leave items with one BOM. Thanks for your help!
  • jreynoldsjreynolds Member Posts: 175
    DenSter wrote: »
    ... so I think that may be a customization that @jreynolds is talking about, not standard functionality.

    This is correct.
  • djswimdjswim Member Posts: 277
    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..."
  • MinervaM84MinervaM84 Member Posts: 13
    Hi djswim, we use variants at the production level. Once the order is released, we add variant in the prod. order lines.
Sign In or Register to comment.