Updates in description fields of BOM’ed items and description fields of materials to not reflect in a previously created BOM. It appears that the BOM is not normalised with database data.
Is there way to cause description updates to appear in BOM’s other than cancelling and created the BOM again from scratch?
description fields of BOM’ed items and description fields of materials
I don’t understand the difference between an “item” and “material” (I thought there were only items). Can you clarify?
I don’t understand why the “flexibility” you describe would be useful or allowed. I would think the canonical and only source of an Item description would be the Item itself, and only references used elsewhere (not copied as what you are describing seems to imply).
The BOM associated with a Production Order is usually a copy of the (manufacturing) BOM so that it can be modified for that specific order, but I wouldn’t think descriptions would ever need to be edited (or should be allowed to be edited), with only existence and quantities editable (so that if necessary, quantities of existing Items could be changed, existing Items deleted, or new Items added), for that specific order and without affecting the source BOM. It would be a nice touch to be able to easily see any differences between the BOM in a Production Order and the source BOM used when the order was created.
I’ll try and clarify:
Both the description of the item being produced and descriptions of all the material items in the BoM items list appear to be copied into the BOM fields at creation time and they do not reference the original records of the items the BOM relates to. Please correct me if I’m wrong on this!
The result of this is that if an item description is changed for any reason this does not propagate to the BOM’s listing as might be expected in a normalised relational database.
I’m not aware of any reason to copy data across to the bom at creation time besides giving the possibility to edit the texts and have different descriptions in the bom.
I prefer to have consistency in item descriptions wherever the item is referenced.
I think some users may want to keep BOMs in the condition they were created. For example, if they are created for a project and then the description changed for another project, then the old project BOM should reflect the older description.
In case of an error, keeping descriptions same would be ideal. But its hard to guess what is the use case. Maybe a button with “Update Item Info” could help (?)
@davidgal maybe you can quickly run an update query and fix this.
Hi rmehta,
I’m not sure that I understand the connection with project descriptions and BOMs.
A typical use case, as I see it, might be in a case where the description given to a raw material item includes a misleading error (in the description text). This misleading error is discovered after several months but in the meantime some 100 BOMs have been created that include this particular raw material item. The misleading item’s description is edited by an manager in the item master table and saved but the misleading description will still exists in 100 BOMs. To rectify this a relatively major undertaking is required.
Unless there is a clear need to have different texts for the description of an item between the item master and the inclusions of the same item in BOMs would it not be simpler to have a foreign key relationship between the BOM table and the item master table to always reflect the current texts of the particular item? If an item’s valuation rate can be consistent in BOMs why not the item’s description?
+1 !
Excellent example. BOMs should be collections of items, not copies of items. The collection should be editable within a job, but never the items themselves - and especially it shouldn’t appear the item is editable when it’s really a copy that is being edited.
P.s. I haven’t sorted out how to manage versions of items. Any ideas?
P.S. I will admit my view of how an ERP manages items and BOMs leans more towards formal configuration management (aka product data management PDM, product lifecycle management PLM, etc.), and my perspective is that of an engineering design and manufacturing organization.
As an example, assume I buy tables and chairs separately and then sell them together as a set, and that my product (a “table and chair set”) varies over time because I buy my “raw” tables and chairs based on price from the open market, and that they vary somewhat from one purchase to the next. In this situation, I might want to modify the Item descriptions in the BOM to reflect the tables and chairs I am currently including in a set. Alternatively, I might instead edit the items themselves based on what I can buy, and then create a new BOM which will have the new item descriptions, leaving the old BOM showing what I bought (and sold) last time. Make sense? Certainly it gets the job done with a minimum of admin work in the ERP.
However, this approach can make managing purchasing and production confusing and error prone if my product is to be consistent and identical. A fundamental rule of configuration management (btw, configuration management for materials, not software) is that an item NEVER changes (the purist would argue that if the physical “thing” changes, a new Item - or part number - MUST be created). However, a more pragmatic view is that an Item can be “revised” to correct a defect in its design, but 1) the item must carry a revision identifier to tell one revision from another (e.g. revision 1 → revision 2 → …), and 2) the new revision must be fit, form and function compatible with the previous version (if it is incompatible, it must be treated as a new item to avoid any possibility of confusion). In practise, a revision will be too subtle to affect the description, leaving the only acceptable reasons for changing a description to improve clarity or correct a mistake, and the description for an item should be the same wherever it is used.
Was this “feature” (to edit the description of an item in a BOM independently from the Item itself) intended and now crucial for users? If so, a possible solution might be to add a switch to the global stock setup to allow or disallow editing the item description in a BOM, and add “refresh description in all BOMs” button to the Item Master. However, I see this as a rather extreme hack and somewhat questionable.
If this “feature” is a byproduct of development, and not specifically intended or crucial to any users, do you think it would it be possible to change the implementation so that an Item description is the same everywhere?
Dale
Item descriptions should not change for sure in Quotes sent, for example.
They could be updated for BOMs though. Adding an Issue for this:
Hello rmetha,
I agree that any document that is sent to an external function needs to remain as created even if it includes a field that needs to be edited. This might also be the rule for internal transactional documents such as stock movements production orders etc. The historic records should not be changed if a field is edited in an item record.
However, I feel that BOM records like Item records not transactional but more infrastructure of the ERP system and as the one (BOM) is a set of the others (Items) - data shown needs to be consistent.
Hi all, my feeling is that a BOM and an Item are not separate entities. Some Items have child parts and some don’t, a BOM is simply the list of child parts when an Item has children.
I’m not sure how to manage modifying a BOM and identifying the new version (e.g. when version 2 of a BOM is created to update or correct the initial version). Instead of allowing an arbitrary number of BOMs per Item, usage can be constrained to allow only one BOM per Item, then BOM/10000001/002 can be interpreted as version 2 of the BOM for Item 10000001.
I haven’t experimented with MRP yet so I don’t know if this is a problem or not (or how much), but the default when creating a new order should be to follow the highest BOM revision available when walking the hierarchy of an Item.
I’m using “Parts&Vendors” (P&V), a Windows Jet4 client/server-like app now to manage manage BOMs for electronic circuit boards (and define mechanical part numbers). P&V constrains an Item to having none or one-and-only-one BOM, which is working for us. However, I’ve never worked with multiple-BOMs-per-Item, so maybe I’m not just seeing how useful/required this feature is. If the BOM for an Item must be changed, either a) the Item can be “revised” - when the “old” BOM will never be used again, or a new Item can be created - when it’s needed to treat the old and new BOMs as separate product (likely depending on some other factor).
I haven’t looked in any detail (or really looked at all) at how BOMs are constructed. Can changing ERPNext behaviour so that BOMs contain references to Items (instead of copies of Items) be done by editing a “BOM DocType” and changing some fields for Item information to links? Presumably there is business logic that copies Item data when a BOM is created, but would it be straightforward to essentially just delete it? Can this be a patch? A fork? Rolled back into ERPNext as the desired standard behavior?
Dale
We have already added updating of item description in v5
@Dale_Scott There are a whole lot of good ideas to implement, we are happy to take community contributions.
@rmehta, if someone felt the item description updating in v5 did not go far enough, or felt it was not the best architectural approach, what do you think the best solution would be? Would changes of the like discussed here be accepted into the project, or is it too late and the existing behavior must be maintained?
How do I edit a BOM that has already been submitted. It won’t let me.
Is there a way to edit Items in a BOM after they are made?
Installed Apps
ERPNext: v9.2.4
Frappe Framework: v9.2.6
Ixsystems Erpnext: v2.0.1
Not in the default system. If the BOM has no transactions you can deactivate it, then duplicate and delete the old BOM.
If BOM has transactions linked to it, you have to create new BOMs.
Also check the BOM replacement tool