We currently enter dates for check and approval manually on a drawing, estimating when the approvers will get a chance to look at them. Generally, I allow up to a one week tolerance on a date being accurate. Obviously, this is poor practice as the drawing won't necessarily match the electronic data stored. I currently have a publish process to update the viewables and drawings upon PR approval to update a status note to "RELEASED". I have so far been unable to find the parameter that links to the approval date: can anybody help, please?
One place that I worked for had a policy for their drawings to show only the last 4 revisions. the reason will become self evident.
When it exceeded the space, it would roll the information over - within the drawing parameters.
To overcome the problem with dates and such, they created locked positions and parameters on the format ie date1, date2, date3, rev1, rev2 and so on.
a program would "shuffle" the information when a PR was finalized, picking up the date information from the PR when the promoter "signed" and populating the parameter. Limiting it to 4 lines kept just enough info to please the history buffs and making the programming simple.
The viewer would see the latest information and history on the drawing. Should one need more history, this can be retrieved from the database.
Hopefully, this gives you some insight (but don't ask me how they did it!)
Thanks Ron, that sounds perfect. How did they do this?
On a serious note, I have toyed with the idea of doing this as our revision information is all manual, individually added tables, which I abhor. Our service provider has a tool do this, but (surprisingly) it comes at a cost. Quite a large one.
Are you able to offer any insight into whether they stored their historic information as parameters or as a separate database? One problem I repeatedly encounter is that information in the Windchill database is unobtainable by external sources / code.
After I asked you not to ask how they did this, that was the first question you asked!
So here is what I know.
the drawings contained the parameter data which was pushed by the promotion request action.
The program just managed/populated the parameter data for each promotion within the drawing file.
The cost may actually be justifiable if you look at what the productivity gains and accuracy (do overs) would save.
but to make sure it wasn't a slip...
Push data from the Promotion request action to the drawing, not vice versa.
Chains work better when you pull them (so I'm told)