I have a Data directive BPM that updates the ship by date backwards a number of days depending on the ship to location, this is working fine on the update or creation of order lines. However I’m trying to figure out how to make this retroactive across all of our current open lines in our database, only need to do this once.
I’ve tried setting it up as a Method on the UpdateMaster directive in SalesOrder, but that didn’t seem to work when i tried updating an order line to trigger the directive. Is there anything i’m missing here?
Trying to do it 1 time? Don’t trigger off that BPM. You’ll want to trigger it off of some very custom table, i.e. use an Update condition on a UD table where something equals true, as an example. Then you invoke your code from that.
Hmm. I am not sure if I know what’s more efficient. DMT is probably a safer bet vs. doing it all code though, just for transparency into what is begin acted upon.
Can you expand on what you mean by “update condition” ? I’m trying to update what looks to be 5,000 lines. Previously the BPM we used before changed the Ship By Dates by the same number of days across all customers.
Management now wants each customer to have their own “shipping window” if that makes sense, I have it set up in my custom code and it works great, just need to get it to work retroactively just once.
I was thinking on creating a UD field and putting the calculated date there, exporting that data then DMT, but then again i would need to trigger so that it updates across all lines.
It sounds like you are making this more complicated than you need it to.
Can just simply make a BAQ that does the calculations in a calculated field? Then you should just be able to take those results and DMT the changes in, no BPM needed.
If you can’t do it in and BAQ/SQl you can always to an advanced BPM only BAQ that loops through your results set and use the same code update a blank the field in your BAQ. Then like before, send the results to excel, and DMT in the changes.
BPM’s only work with the data set that is loaded on that specific transaction. And the BPM is only triggered when there is a change. (for an update BPM anyways) So to get that to work, you would have to figure out how to load all of those transaction, and fake out the system to think that there is a change so it actually processes. That’s not easy to do.
Now, if you make a BAQ that get’s the info you want, you can make a BPM that acts on the BAQ information, and you can probably copy most of the code that you have in that into that BAQs BPM and utillize the code. That’s not too hard. You would just loop through the results.
Do you understand what I am saying when I say make a BPM only updateable BAQ?
I like the approach here. I would HIGHLY advise against making something that goes back and updates ALL previous data (depending on the volume I guess of your operations). EX, we had a BPM that would go back to EVERY SINGLE ORDER LINE for a particular customer number and set a new credit hold date on the sales order line, whenever someone marked credit hold on the customer master. This made setting credit hold on a customer that has lots of order lines take upwards of 60 min. Once I disabled this bpm, the customer was able to be put on credit hold in a min or two (whatever the Epicor OOB is). Instead, lets just look at the last credit hold date on the customer record (1 record), not every single order line.
