[
https://issues.apache.org/jira/browse/FINERACT-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095263#comment-18095263
]
Abhishek Chaudhary commented on FINERACT-1950:
----------------------------------------------
Following the discussion on the dev list ([thread|[[DISCUSS] Reviving
FINERACT-1950 — Disallow backdated transactions (global configuration)-Apache
Mail
Archives|https://lists.apache.org/thread/6pbh34o0c7g960sod5fnbhk510gtf7mp]),
I'd like to revive this ticket and take up the implementation. Could someone
assign it to me? [~ikimbrah] [~adamsaghy]
Summary of the design agreed on the list:
h3. Configuration
* New global configuration {{{}disallow-backdated-transactions{}}}, disabled
by default, following the existing GlobalConfigurationProperty pattern
(Liquibase-seeded, per-tenant).
* Validation is anchored on the {*}current business date{*}, not the system
date.
* Tolerance is a *calendar-month boundary* rather than a rolling N-day window,
aligning with monthly reconciliation cycles: transactions may be dated within
the current and previous calendar month; anything before the first day of the
previous month is rejected. The boundary moves forward on the 1st of each
month. (If current-month-only is preferred, this is a one-line change —
defaulting to current-plus-previous unless there are objections.)
h3. Scope
* Applies to client-facing portfolio transactions (savings
deposits/withdrawals, loan repayments) {*}and manual journal entries{*}, per
the dev-list feedback — one uniform ruleset.
* This complements accounting closures (GLClosure): closures remain the
permanent hard lock on closed periods; this configuration is the day-to-day
guard on the still-open window — matching the original goal of this ticket:
control without requiring a formal period closure.
h3. Override
* A dedicated permission allowing authorised users (e.g. accountants) to post
backdated transactions even when the configuration is enabled — carrying over
the permission-based override from the original 2023 design by Ibrahim and
Francis.
h3. Out of scope (for now)
* Reconciliation-status awareness: Fineract has no reconciled flag on
transactions today. The calendar-month boundary acts as a practical proxy; if a
reconciliation concept lands later, this configuration is the natural hook
point.
* Per-transaction-type granularity — can be added later if a real need emerges.
h3. Implementation plan
# Configuration constant + ConfigurationDomainService accessor + Liquibase
changeset seeding the config and the override permission.
# A shared validation component computing the cutoff date from the business
date.
# Wiring into the three transaction paths (savings, loan repayment, journal
entry).
# Integration tests: enabled/disabled, boundary edges (last day of previous
month vs. the day before), month rollover, and the permission override.
I'll submit this as a single PR unless reviewers prefer it split.
> Disallow backdated transactions - A Global Configuration
> ---------------------------------------------------------
>
> Key: FINERACT-1950
> URL: https://issues.apache.org/jira/browse/FINERACT-1950
> Project: Apache Fineract
> Issue Type: Improvement
> Reporter: ibrahim kimbugwe
> Priority: Major
>
> We need to have a global configuration to disallow backdated transactions for
> a given period without necessarily closing an accounting period in the
> closing entries.
> A use case of a teller not being allowed to post a backdated transaction on a
> customer after the till was balanced or after COB. The accountant can however
> have the right to post GL transactions on a back date.
>
> This should however be set as a global configuration that can be turned on
> and off.
>
> [~francisguchie] and [~bgowda] and [~eroemma] what do you think of this
> improvement?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
