Nope. Part number is a key field and may not be repeated. What are you attempting to accomplish?

No.  The database schema is specifically set up to NOT allow duplicate part/document numbers, change numbers, manufacturer names or manufacturer part numbers (in the PC module, but this also applies to  most objects created in the PQM and PG&C modules).

It is not good business practice to name things (even related ones) to all have the same number in a PLM database. If someone gives you a number, which record should you look at?? The part, the design document, the manufacturer part? Each object having a distinct number makes the system easier to search for things (seeing 11 records that *all* show the same number can be confusing). And since ITEM_NUMBER is usually indexed as it is searched on quite often, making sure it is unique makes the database much more efficient.

You could drop the constraints in the database, but I would highly recommend that you DO NOT do that. A much better solution would be to configure a “Related Object” field in P2 that could then be set to show the “parent” object that carries the number you want as the “master” value. Or use the same base number plus a suffix that designates what the subordinate object is (like “CD” for Configuration Document, so the document number would be “XYZ1234-CD”). Or use the Relationship tab to link related things to the parent object (the part, in most cases).

Having the exact same number all over the place might sound simple, but in fact it can be both confusing and inefficient.

In the current legacy system (Enovia), they are currently allowing same part number with multiple types (eg : Part and Part Documents), which we have to migrate.

One of the use case why we are doing this is that Part Documents is merely a spec that can be modified without having to rev the Part, eg : They may create a typo or adjusting a small process change in the document without having to revise the Part.

One solution we thought of is just attaching the document in the part attachment. However it will results in Part Revision every time the document is updated.

If no other possible way to do this, then we may have to use the solution that Kevin suggested which is having a slightly different part name eg : XYZ1234-CD

Thanks,

Along the lines of Kevin’s response…. you do not need an intelligent number for your document. Simply allocate a document number for the document and link the part and document. Typically, this is done on the BOM tab of the part.

Although a lot of good information here there is one thing we are missing and that is the legacy documentation. Quite usually the numbers are on the docs and when you marry this with an ‘altered’ number scheme you can create another issue.  The way I have tackled this is to create a legacy part number attribute for the legacy data only (using field level read to hide it if empty) and then force all new items to use the new Agile number schemes.  This will preserve the legacy data and allow you to match numbers to docs without issue.

Thank you everyone for your feedback.