Hi guys, I’m trying to set my receiving date in the receipt entry menu to set by sysdate so that users are unable to do back date entry after 30 days.
Appreciate your help
You should be able to create a Post method directive to do this.
However, a word of caution: be careful when creating a BPM that does something ALWAYS. What happens if something is physically received late in the evening but no one is there to record it? They do the receipt entry the next day and now the record has the wrong date.
If people are back dating receipts when they should not, maybe create a BAQ report to capture where the receipt date does not equal the sysdate and have the manager work on correcting the behavior that is causing the problem.
Hi @jgreenaway , I have created a BAQ for the users to refer but still back dating receipts are still happening, that is why we gave them 30 days to key in the receipt entry, so after 30 days they are unable to key in or change date. Apologies if my question is too general
Are the dates that they are receiving still open fiscal periods? We can back date receipts but standard functionality prevents a receipt if Finance have closed the period. I know this isn’t what you are asking but thought it might help if you’re not already aware.
First method I’d look at is Erp.BO.Receipt.OnChangeReceiptDate, which should fire as soon as they change the dropdown (usually, Epicor is not 100% consistent with these things). If they pick a date before your desired window, have it throw up a warning message and reset it to today (or null it and force them to try again, either/or).
There’s also a OnChangeMiscApplyDate method. Not 100% sure what that does without going through a trace. You can also try UpdateMaster, which will fire upon saving, if you wanted to cover all cases, but I personally prefer instant feedback over waiting for saves.
I will say that I agree with the others here, that you should analyze why this is happening and try to correct behavior. However, I’ve also been around long enough to know that operations does not always care about these things and sometimes the most straightforward solution is to just stop them from doing things you don’t want them to do. This is a pretty straightforward BPM (can be done entirely with 2-3 widgets) so I’d just drop the hammer.
Good call Tracy - but I would also encourage using Earliest Apply Date.
From a financial standpoint you want receipts in the current period. If you use earliest apply date and try backdating a financial transaction you would need to get accounting involved.
Backdating transactions to prior periods causes them to post on the first day of the current fiscal period (that is as long as finance checks for outdated transactions when they capture WIP/COS).
Jenn