Hello everyone AND PTC,
Global numbering scheme for all EPMDocument. Our policy is to automatically allocate a sequential number to any new CAD file created. The EPMDocument get assigned the same number than the cad file without the extension. This is unique across our entire Windchill regardless of the context. Our business process is so that Number (Part number) is generated when creating the CAD. This number is then unique across all other systems such as ERP.
That is, if I start creating a new part for a new design in a project, the Number is allocated "forever".
When we were with Windchill 9.1, everything worked perfectly fine. We could create new CAD/EPMDoc in project, send them to PDM without the number being changed (users could not change it and the system did not change it all).
We upgraded to 10.1 M040 in June 2014. During testing we noticed that Windchill behaved differently. When an EPMDoc is created in ProjectLink and send to PDM, Windchill allocated a new number. This was obviously not good at. As this was the only issue with the upgrade, we went live as planned expecting our VAR to fix the problem.
After 18 months the problem is still unsolved and the only reply we have is that Windchill behaves as expected and it was a bug in 9.1
It does not make anything from a process point of view to change Number as data is moved from container to container when the same Numbering scheme policy is used across the system. In addition, you can imagine the issues this creates when you allocate a partnumber, and later on the system allocate a new one.
This creates overhead as one must remember what was the number so after sending to PDM, we can renumber to the original number. This creates more issues as our policy is so that users cannot play with NUMBER it is locked down. This implies that only admin can renumber.
Why has PTC change Windchill behaviour . Can someone explain the logic is not allowing an EPMDocument to keep the same number when being sent to PDM. If that functionality never existed, it would be different but it worked fine for 4 years with 9.1 and a few datecode update.
Thank you for your feedback and maybe some PTC program can pop in and explain the rational ?. I would love to hear their view on product life cycle.
I am Chris since I was born and changing status (baby, toddler, child, teenage etc...) and even container (changed 3 times countries) my number (first name and first name) never changed. So why is it now different with Windchill.
Thanks a lot
regression in some old functionality is a constant for every new release of PTC SW.
We had a BIG regression in 10.2, now solved as you can read in this discussion.
Sometimes you have to shout to be heard.
I don't remember seeing the behaviour your report when we recently implemented Windchill 10.1 for a customer. We may not be on the exact same datecode, but its worth checking with tech support if there is a property (or preference) that controls the behaviour of using a new number when moving from ProjectLink to PDMLink. PTC does not implement any change without an SPR, and when they do, they normally add a way to control it. If tech support confirms that there is no such property/preference, it might still be possible to customize the numbering algorithm in the OIR. As for the rational for the change, it seems like they have it on the support website - https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS176393
thank you for your feedback.
I am glad your issue has been solved.
It sounds that if you have a good relationship with a Product Manager or can shout LOUD enough (with claiming a BIG maintenance fee), then you are listened to.
That is a shame really. A same problem can have different consequences depending on the size of the company. It seems that this is not taking into account. I hope I am wrong.
We are in the evaluation phase and while PTC is the strongest contender, if they can't prove good regression testing, this is worrying.
Hope PTC will get in touch...
For those of you using PJL and PDM, what is your numbering policy when you send newly created EPM in PJL to PDM ?
that is the way and this is exactly how we moved from 9.1M050 to 10.1M040
They make me laugh somehow with their "
Clearly in 9.1M050 the behaviour was different so they implement a change without considering the impact to their customer.
As we are talking about business processes, this is quite different than buying a iphone and found that apple remove a functionality. We can always go and buy a samsung instead. Migrating Windchill is a completely different story. In addition. PTC should be a partner and not simple supplier.
It is very surprising the way they split PDM and PJL, it is still within my PLM environment which is Windchill.
I am quite annoyed to be frank.
We routinely create EPMDocuments in ProjectLink and send them to PDMLink without having to change the name, number, or filename... We started on Windchill 8.0 and migrated to 9.0 then to 9.1 then 10.1 and have not seen this behavior.
If you are currently on maintenance, I would log a technical support call with PTC if you have not already. It isn't clear if this has been done yet from reading your post.
that is the exact problem. While on maintenance. PTC still closed the case without bring any solution
Chris C - Based on our experiences with Windchill updates and Wildfire to Creo updates, any shouts coming from a small company don't carry any weight.
Certainly had our share of regression issues over the years with virtually no solutions from PTC. I would hope the medium and larger size companies have it better than the small companies. Just something to think about.
we use ProjectLink to share our models with some of our mold makers.
To avoid issue you have described, they create WTParts to attached their CAD models.
These parts has a suffix (_PRJ) to distinguish them from those used in PDMLink and sent to our ERP.
When the supplier gives us the mold, and after positive testing in production, CAD models are sent to PDMLink and associated to WTpart without extension, while the project is closed and then the WTParts with extension are no longer visible.