Re: Sending EPMDoc from ProjectLink to PDMLink

ChrisPLM · ‎Nov 27, 2015

Hello everyone AND PTC,

The context:

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

Best regards

Marco_Tosin · ‎Nov 27, 2015

Chris,

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.

Marco

ChrisPLM · ‎Nov 30, 2015

Hello Marco

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...

Best regards

Chris

ayadav-4 · ‎Nov 29, 2015

Chris,

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‌

Thanks,

Ankur

ChrisPLM · ‎Dec 01, 2015

Hi Ankur

that is the way and this is exactly how we moved from 9.1M050 to 10.1M040

They make me laugh somehow with their "

Works to product specification for Windchill PDMLink 10.1"

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.

Best regards

Arjen · ‎Jun 27, 2018

Hello Chris,
Same issue here. Did you already find a solution or work around? Very annoying that send to pdm generate's new numbers!
Regard.

ChrisPLM · ‎Jun 27, 2018

Hi

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 🙂

ChrisPLM · ‎Dec 01, 2015

Hello

For those of you using PJL and PDM, what is your numbering policy when you send newly created EPM in PJL to PDM ?

mdebower · ‎Dec 01, 2015

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.

ChrisPLM · ‎Dec 02, 2015

Hi Marc

that is the exact problem. While on maintenance. PTC still closed the case without bring any solution

https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS176393

ehowanice · ‎Dec 02, 2015

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.

LoriSood · ‎Dec 07, 2015

Chris,

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.

ChrisPLM · ‎Dec 07, 2015

Hi Lori

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

Best regards

Marco_Tosin · ‎Dec 03, 2015

Hi Chris,

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.

Marco

r.vanrootselaar · ‎May 28, 2017

Hi Chris,

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.

Cheers,

Rob

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.

ChrisPLM · ‎Nov 05, 2017

Hi Rob,

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.