Hi all, I'd like to help move FINERACT-1950 ( https://issues.apache.org/jira/browse/FINERACT-1950), "Disallow backdated transactions - A Global Configuration", forward again, if the community is still interested.
The ticket was filed by Ibrahim Kimbugwe in 2023 and received good support from the community. Bharath Gowda mentioned that it solves a practical operational issue, especially around month-end and year-end processing. Ibrahim and Francis Guchie had also built and tested an implementation using a global configuration along with a permission-based override, allowing authorised users to post backdated transactions when required. I think that's a good approach since it fits the common teller and accountant workflow. It looks like the implementation was never merged upstream, and the ticket is currently unassigned. Ibrahim, Francis, if you still have the implementation and are willing to share it, I'd be happy to help get it upstream. If the code is no longer available, I'd like to pick up the ticket and continue with the same approach. One thing that has changed since then is that the Business Date and COB functionality has matured quite a bit. Because of that, I think it would make sense to base the validation on the current business date rather than the system date. My initial idea is something along these lines: - Introduce a new global configuration, for example disallow-backdated-transactions, disabled by default and following the existing GlobalConfigurationProperty pattern. - Allow the configuration value to optionally specify a tolerance of *N* days, similar to the existing *-for-days* style configurations. - When enabled, reject client-facing portfolio transactions such as savings deposits, withdrawals and loan repayments if they are dated before the current business date. - Keep a permission-based override so authorised users can still perform backdated transactions when necessary. - Leave manual journal entries unaffected, as discussed in the original ticket. - Add integration tests covering the enabled and disabled cases, the tolerance window and the permission override. For context, I noticed that allow-backdated-transaction-before-interest-posting and backdate-penalties-enabled already exist, but both address more specific cases rather than backdated transactions in general. I'd appreciate some thoughts on a few points before I start working on it. 1. Should manual journal entries remain outside the scope of this configuration, or should accounting transactions also be configurable? 2. Would a single global configuration with an optional tolerance window be enough, or would separate controls for different transaction types be more useful? 3. For the override, would a dedicated permission be the preferred approach, or should it integrate with the existing maker-checker flow? If this direction sounds reasonable, I'll post a short design note on the JIRA ticket and follow up with a PR. Regards, *Abhishek Chaudhary*
