We’re looking to add an approval layer for the journal entry process. One option might be to check the “Manually Review All Transactions” box in GL Transaction Type Maintenance, which would send the journal entry to the review journal for approval by someone in the finance manager security group.
I see SingleGLJrn and MultiGLJrn in TransType maintenance, but Epicor doesn’t have any details on what those types are. I checked Field Help, Application Help, Edu course on the posting engine, as well as the posting engine technical reference… Does someone know?
Another option could be to restrict JE’s Actions>Post to a manager security group via BPM or Process Security, while allowing JE entries by anyone that has access to Journal Entry. Post could be based on dollar amount if nec.
Your last approach is the most common, and I consider this the best for accounting transaction controls:
“Another option could be to restrict JE’s Actions>Post to a manager security group via BPM or Process Security, while allowing JE entries by anyone that has access to Journal Entry. Post could be based on dollar amount if nec.”
If you are looking to do this by total value, then I generally suggest do this through a bpm. If it is all GJE, then you could do this through the process security maintenance.
We have also implemented like-procedures for AP and AR.
The Single vs Multi is related to multi-book. You would use this if you are posting to multiple GL books, but this will not help you with your current situation.
this is a common request for american owned companies, so we developed an approval dashboard and prevented anyone from being able to approve journals that they created.
Can you segregate duties with different access on Journal Entry vs Journal Posting Process? If you add users A to the menu security for Journal Entry but remove user A from Journal Posting Process they would be able to create an entry but not post correct?
Ah…so any given individual with access to the “Journal Entry” menu can both Create and Post as long as the current user logged in is not equal to the EnterdBy UserID on the JournalHed when posting?
By default, in vanilla Epicor, the same person who entered can post a JE. You would have to add a Method Directive to the post method can prevent that from happening.
How can you block the posting person from editing a line before posting?
I’ve written a method directive to disallow other users from making edits.
But when you post, it runs the same BO.GLJournalEntrySvc/update, throwing the blocking error message. The way the event is written it still posts but the message is concerning.
I’m not. Our control was the LAST person who edited the entry cannot post it. It would require collusion between two people. If the poster updated it, they are the last updater and then would no longer be able to post it. The pre-directive is only on the POST method. I had nothing on update.
How do you track the last person? When I checked a posting person can edit a line, but the line still shows that the entry person is still the original person.
As a fix, I’ve adjusted the application studio rules to disable the views when the creator is not the current userid.
This allows them to post but does not allow any changes.
And then a method directive to block the creator from posting there own group.
I just did a quick test (1 journal post), but if you turn on “Manually review all transactions” for the GL Transaction Types of MultiGLJrn and SingleGLJrn, that will push every journal entry to the Review Journal.
We handle this is by having the Manually Review All Transactions box checked in GL Transactions Types and security groups. We block access to the review journal from the users who have access to Journal entry and vice versa for the approvers. It works for us to meet our audit purposes. One thing we did find recently is that if they do use Automatic Transaction Reversal Module it will bypass and not run these thru the review journal.
The one item we wish it would do is have the ability for a change log of the transaction as it goes thru the review journal. Example if rejected and reposted we would see the back and forth of transaction. We may end up building a BPM to push this to UD table to accomplish it.