[
https://issues.apache.org/jira/browse/FINERACT-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
김다연 updated FINERACT-3018:
--------------------------
Affects Version/s: 1.16.1
> 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, 1.16.1
> Reporter: 김다연
> Priority: Minor
>
> 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)
