김다연 created FINERACT-3018:
-----------------------------
Summary: Fixed deposit accounts are numbered with the client
account number format instead of the savings one
Key: FINERACT-3018
URL: https://issues.apache.org/jira/browse/FINERACT-3018
Project: Apache Fineract
Issue Type: Bug
Components: Savings
Affects Versions: 1.15.0
Reporter: 김다연
When a fixed deposit application is submitted,
{{DepositApplicationProcessWritePlatformServiceJpaRepositoryImpl#submitFDApplication}}
looks up the account number format with {{EntityAccountType.CLIENT}}. Every
other deposit path uses {{EntityAccountType.SAVINGS}}: {{submitRDApplication}},
savings submission
({{SavingsApplicationProcessWritePlatformServiceJpaRepositoryImpl}}), and the
account created when an FD/RD is reinvested on maturity
({{DepositAccountDomainServiceJpa#autoGenerateAccountNumber}}). The number
itself is built by {{AccountNumberGenerator#generate(SavingsAccount, ...)}}, so
a client format is applied to a savings account.
*Steps to reproduce* (develop 70a374c255, PostgreSQL)
1. Create a client account number format with an office name prefix, and a
savings one with a savings product short name prefix:
{code}
POST /fineract-provider/api/v1/accountnumberformats
{ "accountType": 1, "prefixType": 1 }
POST /fineract-provider/api/v1/accountnumberformats
{ "accountType": 3, "prefixType": 301 }
{code}
2. For one client in Head Office, submit a savings account, a fixed deposit and
a recurring deposit application, then read their {{accountNo}}.
Actual result:
||Account||id||accountNo||Format used||
|client|1|Head Offic000000001|client|
|savings|1|J46X000000001|savings|
|fixed deposit|2|Head Offic000000002|*client*|
|recurring deposit|3|23EB000000003|savings|
Expected result: the fixed deposit is numbered with the savings format, like
the recurring deposit: its product short name followed by 000000002.
3. Change the client format to the client type prefix ({{PUT
/accountnumberformats/1}} with {{"prefixType": 101}}) and submit another fixed
deposit.
Actual result: {{000000004}}, with no prefix and no error.
{{generate(SavingsAccount, ...)}} does not put a client type into its property
map, so the prefix is dropped. A savings account submitted at the same time
gets {{J46X000000005}}.
*Impact*
* The savings format, which the account number preferences screen and the user
manual describe as the one for savings accounts, is ignored for fixed deposits
but applied to recurring deposits. A fixed deposit also changes format when it
is reinvested on maturity.
* With an office name or custom prefix on the client format, a fixed deposit
number looks like a client number. Clients and savings accounts have separate
id sequences, so fixed deposit id N gets the same string as client id N.
*History*
The lookup came in with MIFOSX-1511 (commit 637f062ce3, 2014). Before it, fixed
and recurring deposits both used the savings account number generator; that
commit moved recurring deposits to {{SAVINGS}} and fixed deposits to
{{CLIENT}}. It was reported as MIFOSX-2410, which was moved to
[openMF/community-app#1721|https://github.com/openMF/community-app/issues/1721]
(still open), and in MIFOSX-2650, but the backend was never changed.
*Suggested fix*
Use {{EntityAccountType.SAVINGS}} in {{submitFDApplication}}, and add fixed and
recurring deposit cases to {{AccountNumberPreferencesTest}}, which today covers
clients, loans, savings, groups and centers. Existing account numbers are not
changed; fixed deposits submitted after the fix follow the savings format,
which is worth a line in the release notes. Numbers stay unique: they are built
from the savings account id, and the random account number conflict check
already looks at the savings table.
One side effect: an installation that relies on fixed deposits picking up the
client format (for example a client format with a prefix and no savings format)
will see new fixed deposits numbered like other savings accounts, and it can no
longer give fixed deposits a prefix different from regular savings. A separate
account type for deposits, as asked in MIFOSX-2650, would cover that, but it is
a new feature and not part of this fix.
I'd like to work on this and will open a PR.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
