Skip to main content
12-Amethyst
November 27, 2015
Question

Sending EPMDoc from ProjectLink to PDMLink

  • November 27, 2015
  • 5 replies
  • 5854 views

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

5 replies

Marco Tosin
21-Topaz I
21-Topaz I
November 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
ChrisPLM12-AmethystAuthor
12-Amethyst
November 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

1-Visitor
November 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

ChrisPLM12-AmethystAuthor
12-Amethyst
December 1, 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

12-Amethyst
June 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.

ChrisPLM12-AmethystAuthor
12-Amethyst
December 1, 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 ?

18-Opal
December 1, 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.

ChrisPLM12-AmethystAuthor
12-Amethyst
December 2, 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

Marco Tosin
21-Topaz I
21-Topaz I
December 3, 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
5-Regular Member
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.   

ChrisPLM12-AmethystAuthor
12-Amethyst
November 5, 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.