We have a issue where we cannot find a way of controlling PO receipts in future accounting periods.
We use the “earliest Apply Date” to control prior dates.
But users can post months in advance and the system does not catch the error.
I have just done a test and received a a service in June 2024!
For Example, we will be going through the month end process for March. We will be catching up on receipts on 01/04. The system defaults the receipt date to the calendar date and therefore it is very easy for colleagues to post the receipt into the wrong period.
I know this is a user error, but I cannot find a option where the system rejects the receipt because the period is not open.
I just want to get the system to help pick up on user error using system controls.
I have previously used MS Dynamics where there was an option to change the system dates to the month end date which would help control posting before closing the accounts on the 1st or 2nd of the month. I cant see that its a option in Epicor either.
There must be a simple option to control this… I just cannot find it.
10 years ago, when I first used Epicor 10.0, I also raised the same question as you, but unfortunately, until today, Epicor has not had a feature that can meet this requirement except for the “Earliest Apply Date” function that you already know
Thanks for the replies.
This is my first message on this forum and really appreciate the help. @gpayne Our system setup uses the calendar date as a default receipt date. (there maybe other options that in unaware of)
The user has to manually change it to the correct receipt date.
So, if we physically receive goods in on 31/03/2024 and the delivery note gets processed on 01/04/2024:
The user has to manually change the date to 31/03/2024.
If they use the default date of 01/04/2024, then the cost will go into April.
I cannot find a way to control future receipt dates in Epicor.
I tested a receipt entry, and the system allowed me to receipt goods on 26/06/2024!!
Even if I close the accounting periods, it still allows receipts to be posted in the future!
Therefore, the system is not working as a safety net if a user makes a mistake, there are no warning boxes, no way to close receipt periods in the future.
So in your processing you physically have goods arriving, but are not doing anything with them in the system that day? From a system standpoint I can’t see anything to stop it. What drives it needing to be received in Epicor the previous day?
Hi, thanks for your reply.
The driving factor of having the receipt on the correct date is the accounting period.
The cost has to hit the GL in the correct period for the monthly P&L and Balance Sheet to be correct.
I have not used a system with such limited accounting controls before.
Unless you have something set up in Company Configuration, this sounds like a user issue. If I receive something today, it selects today’s date. Are users changing the date?
It would only be the balance sheet since it is just going to be an asset on day 1. Epicor is my fourth ERP I have developed in and none of them have anyway to know what has happened outside of their system.
What happens or is produced at the initial receipt? Epicor has an arrived status, but it is basically the same as receiving.
@jkane, yes, I agree, it is a user error.
But this is the first system I have used that does not have controls to stop the user posting into a future period.
I’m not sure why a system would allow me to post a receipt of goods or services in error in say Dec24?
@Gpayne, I agree it is a balance sheet transaction, but if the goods are not receipted in the correct period and the stock is counted at month end then the difference ends up either in the P&L or you waste time looking through transactions to find the problem.
If the system had a fundamental control on dates then it would not happen.
I’m not sure why someone would write in a option of “earliest apply date” and not have a “latest apply date” as well?
Its like someone has done 1/2 job on this.
I would create a BPM that checks that the receipt date is not greater than today and if it is, change the date to today.
One thing that I love and hate about Epicor is that it is so loose on these types of things. I love it because it allows you to build the system to how your business processes work. I hate it because it allows companies to use the system “incorrectly”. It is a double-edged sword for sure.
I second the suggestion from @jkane to create a BPM. I’ve done this on several client systems, and usually try to build in something to help reinforce proper user actions. For example, make it so only a supervisor can enter a date other than today. Supervisors then have an incentive to coach correct user behavior.
Epicor works best when we follow the first rule of ERP systems - “tell the system what you are really doing, at the time you actually do it”. 95% of problems I run across are a violation of (1) telling the system something other than what you are doing (gaming the system) or (2) telling the system at a time other than when the action occurred (usually after the fact). Always ends up with the system not having accurate information and people start not trusting what they see.
Thanks for your help on this all.
Your suggestions are work rounds and don’t really address the fundamental controls missing in Epicor.
@jkane we have a BAQ report, but the system should be controlling the dates, we shouldn’t have to run a manual process to catch errors.
@jgreenaway, I have not come across a system that struggles with date control like Epicor does. Its not very practical if colleagues are off sick or on annual leave to then need to post transactions into the system, for the date to cause a problem!
@AndyB , how can the system control the dates when it does not know when something actually arrived? You are asking the system to do something that it has no knowledge of, it is the responsibility of the user to follow the company procedure. The system does not know when the goods physically came to the building you work at. If the system did know that information, then you would not need to have humans working at your company.
If you truly want to stop people from posting into a future period, do not open up the next fiscal period. But I do not know how you balance that if the person who does the receiving is out for the first week of the month as you cannot do any other transactions for that week since there is no fiscal period.