[Need validation] Product lifecycle management

Hi All

we are planning to create an app for PLM and are going ahead with the following use cases:

  • New item code creation process
  • Engineering change for Items, BOMs and Routings
  • Maintain versions
  • ‘Where used’ report to assess the impact of the item being changed.
  • Allow impact of change on ‘where used’: certain items of user’s choice, all the items, do not allow the impact but disable them instead

New Item Code creation

  • Propose new item, with design files. Standard Workflow is applied. On approval, new Item code is created.
  • New Item also have BOM properties (RM and routing), which can enable new BOM creation. Perhaps we can use same tables created for Engineering Change Order.

Engineering Change Order form

  • This will allow updation of RM and Workstation property in the existing BOM, with design file attached.
  • Also, this will be used as a tool to replace on redundant RM with another RM in multiple BOMs at once. Same will apply to workstation and operation as well. On updation of BOM, design file will be attached / replaced in BOM master.
  • A new Attach field for updating design, which will keep getting over-written on each iteration.

Please suggest and let us know what can be improved or other use-cases that can be incorporated.


will the project be open sourced via github?

I will happy to contribute technically.

1 Like


We are also thinking of making a standard feature for making changes in the doctypes. This will allow selection of a DocType, selection of a field (parent / child), allows editing and then put it through standard approval workflow.
This can be a common change request for masters like Customer, Supplier, Employee etc. Like a generic Document Change Request.
Please let me know your thoughts.


can you provide more technical details ?

Thanks for sharing @sharma_nakul

We gave further thoughts on this and understood that this feature could be given the shape of generic feature, instead of restricting it’s use-case to just Item and BOM approval.

There will be many masters which will need approval matrix. Also, for updating the values in the masters / (transactions?) similar tool could be used. Here is the final solutioning we came-up with, and would like to know your thoughts on the same.

Change Request

  1. If we try and make this feature generic, it will look somewhat like Employee Transfer / Promotion. Perhaps we will give an option to:
  2. Select a DocType, and then select a record (say Item Code) to be updated.
  3. Select a field in which values are to be updated.
  4. See current value, and then set a new Value in the field. It will also allow selection of value in the child table. Also, user could attach a design file, which will be updated as a new value in the field
  5. Save > workflow approval > submit
  6. On submit, the document gets updated.
  7. With the tool of update value in a specific record, it will also cover the use-cases like of BOM Replacement Tool.

New Record Creation

This refer to the first use case described in the Nakul’s post.

  • Just like above, the use-case for new record, specially masters creation can be generalised with another form “New Document Request”.
  • After selecting a doctype, we can fetch all the mandatory fields at once, where users can enter the values.

Do let us know if this use-cases will be good enough for the first version of PLM and will cover the most required use-cases.


The product lifecycle management is a very good concept!

Our company productsavants.com can help test if needed, we use projects to develop products now and it’s…clunky… If you need features tested we’re happy to help as it relates especially to physical products sourcing. We can also provide translations in Tagalog and Mandarin and Cantonese if needed for new field sets.

We like the idea of approval flows for other documents as well.

We agree that the version 1.0 for change request is useful as you have described it.

The idea of product development for us has several stages - this graphic is a contract manufacturing sourcing concept vs. a BOM for internal manufacturing in case it helps show what many of us deal with.



perhaps it’s better to move “has-bom” to the category tree making up item code’s ← → part/component categories. it’s quite common to have cats like ‘finished goods’ (which has a bom) while a category ‘capacitors’ is not structural so no bom items can be added to it

added some ideas and essential features for a PLM module here

  • most important thing is strict revision control across the board with full traceability
  • second is flexible data-structure where items, boms & sourcing-relations are seen as separate things.
  • changes ties things together, i.e. when changing or adding a sourcing relation to a new revision of a given bom.


hot-copy below of my feedback in the github issue:

  • hierarchical category structure
    • flexible numbering scheme, prefix/suffix, revision-sequences
    • global attributes, inherited from the level above or category specific
    • rules (mandatory, optional, validation, formatting)
  • editable life-cycle phases + changes function
    • configurable with auto-numbering, i.e. ECO-000123 (engineering change order)
    • a change could encapsulate: life-cycle, specs, bom, sourcing related, files
    • routings / approval requirements / approval roles
    • life-cycle defines if a formal change is required or not
  • ensure all data is “event sourced” / ledger based
    • items, supplier-items, boms, changes, plm configuration
    • offering full history & difference-view down to field level
    • a smart data-structure like this will also allow subscribing to any data-change (great for custom api integrations)
    • view to show global activity, filter down per user, item, etc
  • revision control & releases
    • git flows, versions (incremental work), tags (releases), merge (changes)
    • staging state prior to release (candidate) > review / diff-view > approval workflow > new release
  • separate items structure from supplier items / sourcing relations
    • i.e. one bom-item must be able to reference one or many supplier-items
    • sourcing should be able to be either direct or two levels via a specific vendor/distributor
    • when multiple sources exist, system should offer to select approved, potential, etc
    • supplier items must have their own life-cycle, i.e. new, prototype, production, eol
    • inherited parameters from supplier item data to items to avoid duplicate data-entry, (example component description)
  • BOM features
    • hierarchical bom’s, flat, expanded (showing one or many sourcing relations)
    • difference view between two released bom revisions
    • bom-substitutes (important feature!)
      • most other PLM’s just offer to add relations globally, but substitutes in real world are often tied to a specific manufacturer/country or specific project. so it’s important that one bom item can point to alternative supplier items while another defaults to the pre-assigned relationships.
  • files/attachments
    • versioned storage
    • configurable file-types, hierarchical
    • supplier files should live in a separated tree from internal data
    • granular file access history
  • enable scientific data-types to ensure data is stored as such and can be presented/configured as wanted
    • i.e. storing value separate from unit type
    • this offers better and smarter search, i.e. resistors between 500R and 2.5K
    • fields should parse & transform input data like resistor.resistance “4K7” → 4700 Ohms
  • make it possible to configure triggers to run async jobs upon any change, item, state change, etc
    • i.e. fetch meta-data from digikey, mouser, octopart based on supplier-item.mfg-part-no
    • this way creating an item would just require a full “MPN” that in its turn would fetch and auto-populate other relevant fields automatically
  • import preview & dry-run (essential feature!)
    • offer full preview of what will happen when a item-list, bom or supplier-items are imported
    • show before vs. after import, colorized for add, update, remove
    • allow auto-creation of PLM item-numbers as long as full category-path is included in import

Hi Sharma,

This would be a huge improvement to ERPNext functionality!

Some of the things you touch on that I consider to be “fundamentals”:

  • Maintain a history of item revisions, with associated BOM and item data being saved and retrievable for all revisions.
  • Have a “Current Revision” that is the default when viewing item information, adding the item to BOM’s, etc.
  • Where-used report: YES! Bonus if this could be a multi-level graphical browser :slight_smile:
  • Implement new revisions via engineering change order. It is also very useful to be able to send notifications when engineering changes are released.

There are a couple of items that I see differently:

  • Routing revisions are a separate thing from item revisions, since the steps to manufacture an item can change but still result in an identical product. In my own view, routing must follow product design engineering, but not vice-versa.
  • The “Attach Design File” point seems like it may be too tailored to a specific idea of how to do things. Maybe the “Design File” term can be dropped in favor of “File”?

Has there been progress on the project since November?

1 Like

checking in!

Hi Nakul

this will be a great improvement
for documents like BOM - can we have a Change request made mandatory to carry out additions deletions or modifications and maintain a revision history

Hello everyone!
Is there any movement on this subject? There are so many manufacturing companies who are eager to have ECO and Product Lifecycle Management.

We’re also looking to have a Product Lifecycle Management.

time to do this perhaps? seems there are a few companies interested.
can we setup a scope and pool of $$$ to fund this project?

1 Like

Shall we discuss more on this?

you have dm