How to enforce the system to have same NUMBER across multiple versions of master

[mpasumarti]

@dvirh, @gasevsm,

As you know an item in a revision controlled workspace can have multiple versions with different revision letters and/or different statuses. In a typical system implementation NUMBER field on items in Items and BOMs workspace is set as UNIQUE to avoid items with duplicate numbers created in the workspace. That is good up to some extent only because there is a no rule/configuration (not sure, if I am missing anything here) to enforce the system to make sure the same NUMBER is used across all versions of a master. Because of this loop hole, multiple versions of a master could end up with multiple NUMBERs as opposed to single number across them. I am still wondering how to configure the system to have same number across all versions of a master? 

One way which I could think off is to have an OnEdit script to perform the required validation. But, OnEdit script can't alert the user like a condition script.

Any thoughts on it?

[dvirh]

Hi Madhav,

Thanks for the question that I think is very important for many users and is frequently configured incorrectly.

I highly recommend never to use Auto-Numbers in Revision Controlled workspaces unless there is a very good reason to have a unique number for each Revision/Version of the items.

Recommend is really the wrong word to use here. One should never use Auto Number in a revision controlled workspace.

A better way to do it is to rely on the OnCreate script. When a new item is created, use the OnCreate script to add a unique Item (Master) number to the field only if the field is empty. Make that field non-editable. When the item is released, the new WIP is cloned from the released item which will ensure that it has the same 'master' identifier.

[mpasumarti]

@dvirh,

Thanks for your quick response.

The configuration recommended by you holds good for customers who have standard item numbering scheme in place. I still see another drawback in that approach where in item number can't be changed/renamed. Just imagine a situation where in an item is used in multiple assemblies/BOMs which needs to be replaced with other item, then one has to create a new item and update each BOM has an instance of older item with it. Which is quite cumbersome than simple change of number of across all versions of item/master.

Coming back to our issue, we have manual numbering implemented for our items and made NUMBER field as unique. As the number field is editable (in this configuration) user has always an option to edit/change the number on working version without worrying about the number on prior released versions. Because of this we ended up with some item/masters with different number across multiple versions/revisions causing confusion to users. If any of such item (with multiple numbers across revisions) is used in a BOM, the BOM would show different numbers for the same item based on it's configured effectivity date, like an add/cancel, which is strange.

Given our current situation could you recommend a feasible way to enforce same number across multiple revisions of an item?

[dvirh]

Madhav,

One way to resolve both of the issues that you identified is by creating a script that will traverse all items in a Lineage and change all of them to a new part number. For example you can do it by having a field called 'New Part Number' and an OnDemand script that will traverse all the items in a Lineage and change the Part Number to the new number. I realize the ideally we would want to do that by allowing a script to request input from a user, which FLC cannot do today, but it will work just as well by storing the new value in a field.

[tony.mandatori]

Madhav, 

How about a workflow driven solution?  If a user makes a change to any of the part numbers on a change order, the change order is routed to an admin for approval.  This assumes a few things:

1. Users are not able to modify numbers after they are released,
2. Jitterbit or similar is used to check all items on a change for number change (using script would timeout).

I agree that I would prefer to see unique numbering across item versions be enforced via ootb configuration and that the ability to reidentify items be controlled by a renumber/rename permission.  This isn't the way the product currently works, so we should put it on ideastation and vote it up.

Thanks,

Tony

[patrick.kennedy14 · Accepted solution]

Dear Madhav,

We’ve contacted you a couple of times about this issue. We haven’t heard back from you—we hope that means your issue is resolved! We’re going to mark this Case “on hold” for now. If you still need some assistance, just reply to this email within 30 days to open your Case back up and we’ll be happy to help you work toward the solution. (After 30 days, the Case will close automatically and we’ll need to open a new one.)