Item Revision Number as Variant

We are trying to figure out how to best capture the revision number of items that we buy and make, and I think using Item Variants is the best option, but I wanted to hear from other people to see what they think.

Right now I am using a custom field to capture revision number. There are several problems with this:

  1. A revision number change can go unnoticed in the BOM. If I up the revision level of a part, I need that to be captured in a BOM (the BOM should reflect a specific set of items, each at a specific revision level). I think I can add a custom field in BOM Item to store this, but I think there could be interactions between the default BOM for itemsand the rev.
  2. There is no way to keep track of old revision information. Once I up the revision level and fill in the data (could be default supplier, weight, cost, attached drawings, etc), the old data gets overwritten, or worse yet it gets applied to the new one (cost for instance).

Can anyone point out any issues with using item variants to store the revision level of items?

Thanks!

1 Like

@raveslave

Hi guys,

Thought I’d pull you into this conversation raveslave because of your PLM topic you posted earlier. PLM type work in ERPNext?

I too am in the engineering/manufacturing business and am looking to wrestle some kind of PLM functionality out of ERPnext. I don’t have much experience with ERPnext yet since I’m just getting our company set up, but I plan to start developing myself AND coercing my CEO into funding useful modules.

I’d like to get a discussion going about what can be done for PLM now, and what could be developed in future to make our lives easier.

From what I’ve seen so far I can’t think of any reason NOT to set revisions up as variants. You still have the problem of creating new BOMs manually all the time though. Could be pretty error prone if you use multi-level BOMs.

If you set up your items as variants, a change in revision means you have to make a new BoM wherever there is the item that is changed. Then you have to make a new BoM for any that contains the BoM changed. It can lead to alot of work very quickly, but it’s the only reliable way that we have found to track revisions.

Agreed. We’ve had internal discussions here and decided that there is less overhead in marking revision changes in our ERPNext BOM docs and creating new ones any time a part gets a new revision, compared to including revision levels in drawings and having to rer-elease new drawings any time a revision of one part goes up.

Sounds like the consensus is to go with it.