End users have discovered that the “Track Up” feature, when using “Where Used” on a part, doesn’t work in Part Tracker but functions correctly in the Part screen.
Is it feasible to enable this feature in Part Tracker?
1 Like
That’s a good find. I’m seeing the same behavior on 2024.1.9. Seems that it’s set to read only because the Part Tracker application is Read Only and the Where Used is a slide out panel within that application. I briefly looked if maybe you could override that panel, but I’m not seeing anything. Maybe someone smarter here can devise a way to make it available in Part Tracker (in Classic that was the only place it resided), but ultimately that at least needs to be a case into Epicor to log it as a bug and/or another impacted customer.
1 Like
My first work around ended up working, but wasn’t ideal (I’ll explain below)… but I think my second attempt works. However… buyer beware. (Enter boiler-plate disclaimer here… use at your own risk).
The Where Used “page” is built in to the Part Entry/Tracker form.
There is a base (uneditable) row-rule that, disables all fields in the PartWhereUsed dataview except RowNav and EngWkb when in “tracker mode”.
All the Where Used buttons are bound to the PartWhereUsed dataview, and therefore also disabled.
One easy solution would be to reassign (or delete all together) the bindings of those buttons away from the PartWhereUsed dataview. Then that row-rule won’t affect them.
So, I tested by deleting the binding on the tool. Success. Now it wasn’t disabled.
HOWEVER!! There is also other functionality on the PartWhereUsed.TrackUp so if there are no parent assemblies, the button SHOULD be disabled. This is a good thing. Because although this modification worked, if I try to track up on a part that has no parent… I get an error.
And when I click “OK” to get out of the error, it takes me back to the Where Used Slide Out, but the form is cleared out:
So… not ideal. Since there are other reasons in keeping the tool bound to the PartWhereUsed dataview, you shouldn’t break that link.
Instead, you COULD just blatantly circumvent the row-rule.
Remember that the Condition where the rule takes effect is when TransView.SysReadOnly = true.
So… just set it to false!
First Event… We don’t want to change this value/setting unless someone navigates to the Where Used page. So, before the GetWhereUsed event (before the slider opens)… row update TransView.SysReadOnly to false.
This worked!
BUT… it set the entire Part Entry form to read only = false… so when you close the Where Used slideout, everything is now active (as if you were in Part Entry now and not Part Tracker). So, going this route also requires an event to change TransView.SysReadOnly back to “true” when you close the Where Used slideout:
Works… but keep in mind it not only turns the track up/down functionality on, it also opens up the Check Out button and potentially other things.
But here is a part without a Parent… notice the TrackUp is still disabled.
If I choose a part from the list the does have a Parent… Track Up is now available.
So, a couple quick/easy events can get around the row-rule… but, use at your own risk.
3 Likes
Sounds like this should be an idea so I added one.
Please vote
2 Likes