This is more of a “How could this have happened” kind of question. My finance team just made a discovery today that we’re trying to understand the cause of. The noticed that there were numerous (roughly 100) journal entries that were made on 8/28/23 but somehow ended up being posted to 1/1/2024. These included inventory journals, payment journals, and general journals. Does anyone have any insight into how something like this could have happened?
I would suspect that the earliest apply date got accidentally set to 1/1/24. You would need a backup from that day to restore to a test or pilot slot to check.
In addition to Greg’s advice, you may also look at the Book | Postings | Validations tab to see what the behavior for closed periods is. I have seen items moved to another period (although not the next fiscal year) if one of these rules is set to Autocorrect with Warning vs. Error.
After looking through some of the transactions that were posted to the wrong date it looks like they were through the Capture COS and WIP Process. I tried recreating the issue in our Test environment by changing the Earliest Apply Date to 1/1/2024 and running the process there but it wouldn’t even run. Error was Start Date is before Earliest Apply Date.
Sorry, this could be a needle you won’t be able to find. I searched EpicCare and only found an odd leap day KB.
We had that exact thing happen to us - someone got a little overzealous at closing periods and went through the correct month, but wrong fiscal year.
Definitely make sure your posting validations are error instead of warning, since the COS/WIP capture doesn’t show you the warning and ask if you’re sure you want to proceed. It does in the log I believe, but too late by then.
If you keep your future periods closed until you are ready to transact in them and use the error in validations, that prevents future dated transactions (new and much appreciated behavior from those of us that used to have to write BPMs to prevent this in the past).
Jenn