I am working in Part Entry. I have a UD field in the Part Plant table that I am attempting to add to the Part Cost grid. I am using the first example here How To: Adding Columns to Existing Kinetic Grid - Experts’ Corner - Epicor User Help Forum (epiusers.help) as a guide. I have been able to get the field to show up though it took some digging since the Part Cost grid expand event reloaded the part cost data for some reason overwriting my added column. Once I removed that the field showed up as expected. The issue now is that it seems to only be retrieving the data from the UD field in Part Plant for the current plant and populating that value to every row in my part cost grid.
I think it would be helpful to see your dataview-condition configuration - and your iterative event - so we can see what might not be getting updated.
I struggled a lot with this, as well, on a grid that updated frequently - it just keep up.
So, I would actually recommend trying a BPM that pulls all the data whenever the grid data is loaded…
Absolutely.
Pass down the data you need, not try to piece it together in the UI.
2 Likes
Your Expression in the dataview-condition is the problem.
This takes each row of PartCost and is testing its PartNum value against the PartNum of the currently-selected row of PartPlant (so you always get the same Plant)
Let me see if I can find a better expression…
I tried adding a AND PartCost.PrimaryPlant CONTAINS(Because of the damn ~) PartPlant.Plant. This only populates the one row that is the current plant and leaves the others blank.
As far as the BPM suggestion goes, I wouldn’t mind going that route but the field that is being filled in on the PartCost is just a field that has been added in the dataview and not actually added to the table. I’m not sure how I would go about populating it through the BPM.
I reviewed the walkthrough you are following and see that the expression should be fine - it’s on the dataview-filter-set of the iterative event where the selection is applied
What does yours look like?
Here’s what we found out after lots of help - the less-visible, but simpler, more-efficient, and more-stable option:
3 Likes
I’m going to give this a shot and then try to physically figure out a way to light a Kinetic Layer on fire. Thanks for the time.
2 Likes
Maybe we could set up an infinite recursion loop to drive it to its knees, at least
1 Like
Just curious if creating a custom grid powered by a BAQ might not be simpler? No risk of recursion, or recursion, or recursion…
It’s certainly a great option to consider!
But sometimes, the events involved make it impractical to change too much…
Then again, sometimes even that is worth the extra effort
1 Like
Absolutely!