I took a look at the internal notes of the SPR mentioned in that article. It seems that this issue occurs if you use different OIRs for project and the PDM context (product/library). If the numbering scheme differs between the OIRs for the two contexts then when the object is checked in to PDM the OIR for the PDM context will be used to rename it per the naming convention for that context. If the numbering convention is the same for both project and product then no renaming occurs.
thank you for your detailed reply. Unfortunately, the problem is that the numbering scheme is the same for all contexts (be products, libraries, projects) and 10.1 M040 does not behave the same than 9.1M050. It is for me a regression that cost time and money.
As explained, I had in 2014 to place a temporary process but that is still in used because no solution has been brought in.
Another rules is that normal users can't renumber and so as a consequence, everytime they send to PDM a new CAD/PDM to PJL, they need to ask an admin to do it. PDMLink renumbers and the admin renumbers again to the original number. We created a special product context were rename is possible and after rename the data is moved to the correct product context. This steps were not necessary when 9.1 was used. User could simply send from PJL directly to the correct context as number remained the same.
So you can imagine how long things take
The process I put in place, which was supposed to be temporary, so we do not delay the Go Live of 10.1 was:
0) User create data in PJL
1) They request the data to be sent to PDM (using helpdesk)
2) Admin team send to PDM to a temporary context
3) Admin team renumber to original
4) Admin team move data to appropriate context
5) Admin team inform initiator
I would expect that point 1 to 5 can take a time to execute of about 5min. In addition, there could be hours between 1 and 2
So you can imagine the waste and the time wasted to get the data available in PDM.
Previously it was
0) User create data in PJL
1( User send to PDM as and when data is ready for PDM
I had a similar issue when going from 9.1 to 10.2. After extensive troubleshooting, I found that some of our Projectlink contexts were causing this renumbering when sent to PDM, and others were not. This helped me narrow it down to an OIR problem, and I was able to correct it.
If this is still an issue for you, I'd like to recommend that you post the OIRs used for one of the object types that is affected (as long as this does not violate any security requirements on your end). I'd be happy to take a look.
Edit: Make sure that whatever OIRs on both the ProjectLink side & PLM side match and point to the same object type. if you have an OIR pointing at DoctypeA on ProjectLink side, but pointing at a subdoctype of DoctypeA on the PLM side, this caused renumbering for me. Once the two OIRs were either both pointing to DoctypeA, or the same subtype of DoctypeA, it worked like a charm. This should hold true at the Application context level, Org level, or Site level.
thank you for your post and sorry for the delay in replying. I do not work for that company anymore so I do not know if they have fixed it or not since then.
I will nonetheless contact the guy in charge now with your solution.
As far as I can remember the DocTypeA in PJL and PDM were the same, it was not as you described that in one Context it is a doctype and another it is a subtype.
I recall in the past our external consultant who worked for a PTC premium reseller told me that it should have never worked that way when we were with 9.1 He was actually surprised he did and for me what we experienced with 10.1 was the normal behaviour.
Anyway, Windchill is still a great tool. Just see their market shares that keep increasing.
Same issue here. Did you already find a solution or work around? Very annoying that send to pdm generate's new numbers!
I left that company in 2014. I know they have stopped using ProjectLink but it is unclear if that was due to this issue or not.
If you read the various responses some solutions got suggested but I have not tried them as it was too late as I had already left that company.
Best of luck.
Tell PTC that with Enovia, such issue do not exist 🙂