I have a data directive on the QuoteHed table that is supposed to insert a value into a UD field I’ve created when a given row’s Expired field is set to true. When I update a single row through the Quote Entry screen it works fine, but when I use Process Quote Expiration with multiple rows that have an expiration date older than the current date my bpm only changes the value in the UD field for one of the rows.
I think I likely have a misconception about how in transaction data directives work, I had thought my data directive would be triggered once for each row being changed by Process Quote Expiration, but that doesn’t seem to be the case.
What do the condition blocks look like? DD’s are usually bulletproof. My first suspicion is that you’ve got something going on that is causing your action to not trigger.
Remove the condition blocks from the execution chain (remove the arrow linking them to the Start widget) and link your set field directly to the Start. Reset your quotes to unexpired. Then re-run process quote expiration. It should trigger a field update on all expired items. If it does, you know something’s up with your conditions and you should start looking at what the data actually looks like (that is, the fields aren’t set to what you think they are, so events aren’t happening as expected either).
If it doesn’t (unlikely, but I want to cover all bases), then for some reason the system isn’t allowing updates, which should lead your investigation in that direction.
Because you’re right, DD’s are looking at everything row-by-row. There are no datasets, BO’s, and minimal to no business logic to worry about. If it’s firing on one row, and not the others, then there’s something in the data that’s different too.
Just tried without the conditions and I’m still getting only one row changed. I also set up a directive to log changes to the QuoteHed table and it only recorded one of the three rows being changed, and it wasn’t the one that had it’s UD field set properly. I’m thinking the answer may lie in something with the way Process Quote Expiration works.
A client trace won’t trace anything process related, you can maybe get it with server tracing from the appconfig, but I’m not 100%.
Some things that can occur here that cause the tom-effery.
Deferred updates. Happens with materials transactions where you make a change at the directive level, but the update doesn’t happen till later through deferred update and what you did gets washed away.
Buffer Copy required. Sometimes Epicor will use buffer copy for updated rows and your data can get passed through and completely ignored. Saw this with WIP transactions. I would pass data in, Epicor would buffer copy the original row over my changes, and my data directive would be ignored.
They are doing a direct SQL update in the process and ignoring the BOs.
I think I may be running into this with the Price List Import process. Trying to capture certain qty break changes and deletions. Works perfectly when data changes via UI or DMT, but not with the process. Anyone have any useful insight on Price List Import?
For anyone stumbling upon this… It seems the Price List Import process first deletes every qty break row (PLPartBrk records) then adds them back. So I don’t see any original or updated rows, just adds and deletes. I was able to trigger my Standard Data Directive appropriately with code that looks like this:
