So far so good... what's your question?
I think when an item is selected in the BOM (bill of materials) and happens to be an "assembly" (part with many parts and services) - all sub-parts need to be shown. The BOM typically pushes out ALL the sub parts, too. It's not an invoice (for client to pay), but an accounting/inventory/ordering way of tracking parts and components of parts - what material (an labor) is used to make the part.
We need to know how the Product is stored and all the parts associated with it.
p.s. my mom was a Cost Accountant and BOM was her specialty.
How do i go about linking a BOM to a BOM?
Does this mean just creating a self join table?
I'm stuck at this point hah
what kind of report example can you show us and perhaps we can show you how to get there?
what entirely do you need to show on the BOM beside product, part nos., etc.?
there are threads on this forum and elsewhere about Hierarchical reporting, if that helps
What I intend to do is use the BOM's to reduce stock levels, obviously the report would come hand in hand.
I just don't quite understand how everything is going to be linked up to take things out of stock.
What I am trying to achieve is a like for like copy of SAGE's allocate stock and check BOM.
This would mean
- Check there is enough stock to create a - GSE300-1-12G
- When order is being for-filled use a script or calculation to deduct what ever values from stock. Which would take out the Final-Assemblies / Sub-Assemblies and parts.
when I looked at it, the "sub-assemblies" seem to be the sticky wicket. I'm nearly certain that there's some circular definition, function, or script that can be used to come up with a complete list of parts. I just haven't found it yet.
1 of 1 people found this helpful
You can treat a sub-assembly as just another part on the list and this then becomes a recursive structure where any item can be a product with a BOM and it's BOM can contain sub assemblies.
I've even encountered this with recipes where an ingredient in one recipe has it's own recipe ad infinitum.
Here's a link to a discussion on this from several years ago: Recursive BOM
Yes a lot of our products that are not sub-assemblies or final assemblies also may have a BOM.
I'll check out the discussion out now thanks.
Do the scripts still work within this solution?
As your Build Part List script seems to loop endlessly? or does this not need to be ran?
It's been years since I produced that example file so the details are hazy.
It should work in today's version.
It shouldn't loop endlessly. It should stop when there are no more BOMs to recurse through in order to build the needed list.
There is, however, no scripted limit on the number of times it can recurse in order to list out all materials from all assemblies and assemblies of assemblies--though I'm sure that you'll hit some type of limit--memory probably if you were to test a very extreme case with a huge number of assemblies that each list another assembly in their BOM. You can probably get an endless loop if you listed an assembly in its own BOM come to think about it. (That would be like putting "ford mustang" into the BOM for a Ford Mustang...)
This is not a finished solution, just a proof of concept that allows you to have materials in your BOM that also have their own BOM and yet be able to get a full "parts list" should that be needed.
Even on your solution it doesn't work correctly. I've removed all the lists that get created from the build part list script and it still loops.
I don't fully understand how it is made yet but I guess if I spend a little bit of time going through your code I will be able to create something similiar. Otherwise I'm screwed
I did manage however to get the layout that displays the BOM working on my solution.
The only problem was I have to populate the PartsList that corresponds to the BOM. I guess all that needs re-doing is the generation of the BOM lists.