For future & post date transactions you should be able to prevent transactions being entered into the past or future which are clearly not correct. This could be done by having a date range allowable for transactions, which could be changed each month or when required. This would help prevent a lot of errors when posting transactions with incorrect dates.
by: Simon P. | over a year ago | Other
Comments
no further comments
This is an excellent suggestion
This is an excellent idea. We create thousands of transactions in one month and a data entry error that puts a date out in the year 2044 or 1914 can become very cumbersome to correct. Please consider this enhancement for your next updates. Thank y ou
Necessary idea.
Absolutely and in all modules tied to the current periods open in GL!
EXCELLENT idea! I currently run multiple reports each month to "catch" these type of errors. Would be nice if they couldn't occur in the first place.
For historical dates, simply preventing all entries to closed periods should solve the issue - even unposted entries or edited transactions should be able to be posted to the current period.
Yes this needs to happen! Trying to fix something after is has been entered is a total pain. There needs to be hard warnings in place to prevent these kinds of errors. This would save everyone so much time not having to figure out what to do to fix a date error!
This is a huge problem for us. We need to be able to close the AR and AP subledgers monthly so that our users don't try to post to previous periods where the General Ledger is closed. All other accounting systems I have used handle it this way. Please make these changes on your next enhancement.
It needs to have some setting so that authorized users/one security level can work on posting closing entries to the prior month while everyone else (and all modules that everyone else works in cannot post to prior period and forces them to change the date when they try to post to a prior period). This needs to include all modules, including SM module.