Jeff,
If the Change Log is an in-trans data directive, it’d run after the Pre and before the Std, unless I’m missing something…
Bah. You’re right – the Change Log is an In-Transaction directive. Is it okay to have another one bound to the Standard directive on the same table? Any issues with that?
I guess I’m unclear if / how the directive would know there was a change in the Standard directive route so that I could see that indeed the field was changed / toggled back to false.
I went to create an additional one using the Standard directive but noticed there’s no Change Log option in BPM Workflow Designer .
However, I did notice in the BPM for the In-Trans one that there’s a “Enable Standard Directive” item in the the Workflow Designer. Does someone know what that is and/or if it’s something that’s applicable to us? Any OB1s in here? LOL
Can you move your reversing BPM logic to In-Trans, and sequence it before the change log BPM? Or better yet, move it to a Pre? Or does it have to live after the database write?
Standard Data Directives do not trigger In-Tran directives even if they change DB directly or via service method calls. This limitation is by design. It is just impossible to handle such cases with the existing product architecture.
2 Likes
I’m not sure. The Epicor development group wrote the BPMs and explained that it had to at the very last stage before it restored the checkbox. Full disclosure: we have this BPM to allow us to enter OrderDtl lines during order entry for parts that are marked InActive (our business model requires this). So, the first Pre-Proc Directive checks to see if the part is InActive and if so, set’s it to false so that order entry can continue without interruption. Then afterwards, the the Standard Data Directive flips it back to its original state.
The code works fine and as expected. We’re just trying to figure out how to add the flipping back portion that occurs in the Standard Directive to the change log so we can track it.
Ah, and you’re saying that In-Trans directives are the only types that can record in the Change Log I assume? Is that what you’re saying?
You should be try first using Method Directive MasterUpdate or Update PRE and POST and not Data Directives (In-Tran / Standard).
Also why do you need to make Parts Active/Inactive? sounds terrible, like your business process should change. shrugs 
As part of your Epicor Implementation, do not default to customizations, instead first take a good look at business processes and make modifications. Any good Epicor implementation also modifies Business Processes. It’s not just about shoving the software in, bending it with customizations and off you go to the next plant. If you must customize then customize for the process and not the user. Work with regional executives on first changing the processes before you try to change the software, not doing so has been the cause for numerous failed Epicor Case Studies.
Does that need to be logged, if the initial flip from Inactive=True to False is recorded in the change log? Another option would be to append comments somewhere to record the flip from F to T and back to F - “Inactive part XYZ added to order”? Or are you troubleshooting issues where the flip doesn’t happen as expected, and need each stage recorded?
Yes, that 
…because a human manually making a part Inactive gets logged and looks exactly the same as the BPM changing the value. So where we see both, we would know its BPM related.
Interesting thought about commenting – is there a way to throw comments in the Change Log?
Yeah, this was a carry-over from before my time when the company uplifted from v8.03.
But it is nonetheless a really good question. I asked the team – and … they couldn’t give me a good answer. So we are going to re-visit the reasoning for this inactive toggle next week.
That said though, we’re doing the exact same flow process for parts marked on hold. We place parts on hold for older customer parts. Sometimes the customer will order that part again (which is fine), so the BPM takes it OffHold to allow for order entry, and then puts it back OnHold after.
(we then address the part onhold as a separate business process to ask if this is a one-off order or needs to come back of hold)
1 Like
Not that I know of, but you could have the BPM append comments into OrderHed.OrderComment, on the Part (Part.MfgComment or PurComment), or your own UD field or table. Or go completely lazy and have it send an email, and then you review the folder when there are issues (assuming it’s not dozens a day).
Do you have separate sales people vs part people? The change log would show a non-sales person setting it, which would tell you it wasn’t from the BPM.
Another thing that sometimes gets us is that converting a quote to order doesn’t trigger the same BPM’s that creating a sales order from scratch will.
I have not had a reason to test this yet, but what about the data directive calling a function instead of doing the update itself? I assume that using a BO to do the updating would hit the change log where the DD does not. (You’d be starting over near the top of @askulte 's chart.)
It’s also a lot safer to use the BOs to do the updating since they know what cascading effects to trigger, whereas the DD is basically a glorified SQL update.
I know sometimes people just want the answer to their question. But I think we as the community try to help each other go the “right route” as well, with questions such as why. I know sometimes it may sound stupid someone asking Why in the world are you doing this, are you craaaazy! but its with good intentions
Makes sense. Carry over.
1 Like
Just leaving this here for reference. If anyone is curious about the flow and Epicor’s recommendations. Adding some notes to @askulte screenshot above.
Method Directives:
- Pre, Post and Base processing logic
- Access to BOs
- Ideal place for Validations / Exceptions / Data Changes
In-Tran:
- Executes after standard Entity Framework data triggers
- Executes within a transaction, as a part of the trigger pipeline
- Immediately processes affected row
- Processes one row at a time (two rows for update operation (RowMod = “” is old row)
- Can change data on save
- — The In-Tran should never if it can throw an exception, it is very very expensive rollback.
- You shouldnt access BOs in here!
Standard:
- Executes when service method call has completed
- Executes only if service method completes without exception
- Processes batch of affected rows at once
- Does not affect data save
- Ideal place for integration operations (Audits, Email, Logging, Notifications, API)
1 Like
One reason to favor data directives is to avoid the need to maintain identical business rules on Update and MasterUpdate. Update is being phased out in favor of MasterUpdate, but the transition is gradual and undocumented. When Update is fully deprecated and processes like like MRP and DMT are documented to always use MasterUpdate, this reason for preferring data directives will go away.
I’ll bite. Why not?
I’m not arguing; I am curious. Performance hit, I presume?
Not exactly. Definitely, the Change Log widget can be used only in In-Tran DD.
But I pointed a different aspect. Any changes in Db occurring in Standard DD (directly via Db context or with Invoke BO Method widget) do not raise In-Tran directives. So, if you change a table with associated Change Log action in Standard DD, such changes will not be tracked.
Any ERP 10+ versions behave this way.
2 Likes
Yeah, ok. That’s what I understood. Makes sense.
I know we had a lot of convo going on in here by everyone – that’s great!
I just wanted to bump on a question that I asked too (perhaps even unrelated) that I didn’t see anyone answer regarding the “Enable Standard Directive” item in WFD.
Change Log not seeing Standard Data Directive change - #4 by Jeff_Owens
Does anyone know?