The BOM (Bill of materials) tree problem

[Dean D. Babic]

Hi, 

I asked Andrew this before, but since A. left, need some ideas.

The problem with Jam is a BOM. 

From github.com/mpkasp/django-bom:

This app represents the Master/Detail in indefinite number of "branches" or Details.
The LEVEL is used for that, I think.

The minimum View is this:

Thoughts how to go with this?
Thanks

[Dean D. Babic]

Here is the BOM database from above github
and the admin.sqlite for V7
Create new V7 project, replace admin.sqlite with this one.

Looks like on original App, the "Part Number" is combined number from 3 fields.

[Dean D. Babic]

Here is the "Part Number". in bom_part Client Module:
function on_field_get_text(field) {
    if (field.field_name === 'number_item' && field.value) {
        return field.owner.number_class_id.lookup_value + '-' + field.owner.number_item.value + '-' + field.owner.number_variation.value;
    }
}

[Dean D. Babic]

Updated the App.
looks like  Bom_assembly_subparts table is intermediaterry table for sub parts. 
This table can be seen as detail.

However, 

- 100-0001-02 part is made of 4 subparts, of which ONE with id=4 is made of another 14 PARTS, of which TWO are made of other parts.
- this can be seen in RED color.

So in total, there more than 30 parts for ONE main part.

I have no idea how to show this unfortunately. 

[Dean D. Babic]

Here is the video what I'm trying to explain.
On right side corner, there is a PLUS sign where part (or an assembly),  can be added to current item.

IMO this is a multi master view, since one master item can contain any number of other master items with details.

The idea is to know the cost and other details like "Where used" , which can be seen as:

Subparts without costs: 36

With Jam, the representation of subparts number is 4 (Assembly, Top Level SKU's, Finished Goods) +14 (Assembly, Final, Elec/Mech) , which is not true, since second one has 2 other assemblies with more parts. 

Cheers

[Maxwell Morais]

Hi Dean, have been a while!

Sounds you guys are doing a great job on the project!

I didn't understood properly what's the issue you are trying to bring?!

Is your question "How can we handle data in a tree format on backend?"

Or are you talking purely about frontend?

Or I didn't understood anything!

--
You received this message because you are subscribed to the Google Groups "Jam.py Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jam-py+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jam-py/2cdd5ef3-c6cb-4610-b2fa-50e5274a473dn%40googlegroups.com.

[Dean D. Babic]

Hi Maxwell, 

yes, long time my friend.

It is a tree representation of the data in a grid. 

The attached database is a Django app, did not change a bit. 

Django is showing the tree representation as clickable green Arrow.

Because the data is "nested", the Qty on grid is showing a small number initially. 

But when we expand the grid, the Qty is much larger, because of the tree.

That functionality is not easy (impossible), to implement with no-code in Jam.

Unless we redesign the original database somehow to include more details.

Right now, the assembly ( the group of items), is constructed in table with:

id, assembly_id,  part_id

1 1 1
2 3 2
3 4 3
4 5 4
5 5 5
6 5 6
7 5 7
8 5 8
9 5 9
10 5 10
11 5 11
12 5 12
13 4 13
14 4 14

...

See the problem? The assembly #5 has item 4 in it. But item 4 is constructed with 3, 13, 14, etc

The rest of #5 are single items. There is more into it but I simplified.

There can be even more levels, indefinite levels to show.

Hence we do not know in Jam how many Details to show.

Hope this helps.

[Maxwell Morais]

I think we are mixing subjects here!

We can approach this functionality in Jam using Nested Sets, but the data you showed is a Graph, not a tree, since it has cyclical references!

Graphs can be reduced to an small form and represented as Nested Sets, but, it will directly imply into data duplication!

An alternative is also to split down the reference in another table eg:

Item
  -id
  -name
  -description
  -contains(ItemComponents)

ItemComponent
  -id
  -item_id

With those approaches you can model the similar functionality!

Of course it's not so direct like in Django, but it works dealing with the Jam's limitations

--

You received this message because you are subscribed to the Google Groups "Jam.py Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jam-py+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/jam-py/882bfee1-24cb-4c5a-a3fe-8c291d6cc69an%40googlegroups.com.

[Dean D. Babic]

Thanks Maxwell

Cheers

[Dean D. Babic]

Here is the database diagram.

On Wednesday, March 12, 2025 at 2:24:30 PM UTC+8 Dean D. Babic wrote:

Thanks Maxwell

Cheers

[Dean D. Babic]

Hi all, 

since I think there might be some interest in this, here is an update:

Because the Django App is combining Part Number from 3 variables (to generate them automatically),

I added a number_item_full column and a Button to update those. The code is super simple for that,

and comes from the NWT2 App (search here for it), "Update Year" on Orders table.

The Part Number on the LEFT is:

function on_field_get_html(field){

    if (field.field_name === 'number_item' && field.value) {

        return '<h5><span class="badge bg-primary">' + field.owner.number_class_id.lookup_value + '-' + field.owner.number_item.value + '-' + field.owner.number_variation.value + '</span></h5>';
    }

...

Because it is combined number, the Search does not work - just like FirstName does not work on Demo Invoices/Customers. 

It does work for searching ie. 0027 tho.
It does work in full on right hand side.

This is not the Jam limitation but more the chicken and egg situation with the above code on_field_get_html

and Django App design.

Then added the Bom Subpart column as KEYS type.

Now that we can add subparts as Assembles (the collection of items), we should be able to work on a solution for displaying those.

In practice, up to now, no code would be needed if Django App stored number number_item  in full.
Yes, Django logic still needs to be implemented, like preventing adding part to itself :)
Plus other logic. A bit of code here is for CSS.

The idea here is to show MVP with no-code at all. Or a minimum code. 

Here is the new app. 

[Dean D. Babic]

Almost done!

We can have unlimited details here with ONE single add to the template:

    <div class="card-body form-body">
        <div class="view-table"></div>
        <div class="view-detail"></div>
        <div class="view-subdetail"></div>
    </div>

Look closely the number matching! On the right hand side is Django app.
When we click on left "Bom Subpart" with items in it, the bottom detail will list all parts for all items in as assembly. 
When we click on bottom item, the "Bom parr" table will display as usual.


Just a minor additions and all done. 
Almost no code in this except as usual display of details with create_table. With width:

            column_width: {'assembly_id': '25%', 'subpart_id': '25%', 'bom_part_qty': '10%', 'bom_ref': '10%'},

The layout is matched with above on Details form Width parameter -  no code.


Enoy