Aman-Mittal opened a new issue, #288:
URL: https://github.com/apache/fineract-backoffice-ui/issues/288
## Business value
Every product form in the app hardcodes `accountingRule: 1` — the platform's
value for **NONE**. Nine sites, all five product families:
```
products/loan-product-form.component.ts:1350
products/savings-product-form.component.ts:263, 291
products/fixed-deposits/fixed-deposit-product-form.component.ts:254, 285
products/recurring-deposits/recurring-deposit-product-form.component.ts:245,
277
products/shares/share-product-form.component.ts:282, 309
```
And there is not one GL-mapping field anywhere in the application:
```
grep -rn
"fundSourceAccountId\|loanPortfolioAccountId\|interestOnLoanAccountId\|savingsReferenceAccountId"
\
src/app/features --include=*.ts
# no results
```
So no product created here ever posts a journal entry. A loan is disbursed
and the general ledger does not move. Interest accrues and nothing reaches an
income account. A fee is collected and it lands nowhere.
**This is what makes the rest of the accounting module inert.** The chart of
accounts, accounting rules, financial activity mappings, accounting closures
and provisioning screens are all built and all working — and they have nothing
to attach to, because no product references a GL account. An institution cannot
produce a trial balance, cannot close a period, and cannot reconcile. For a
regulated lender that is not a missing feature, it is a reason not to deploy.
It is also the cheapest large win available: the platform accepts the
mappings on the same `POST`/`PUT` the forms already send. Nothing new needs
designing on the backend.
## What the platform expects
`accountingRule` takes four values: `1` NONE, `2` CASH, `3`
ACCRUAL_PERIODIC, `4` ACCRUAL_UPFRONT. Everything else follows from which is
chosen — a cash-based product needs a small set of mappings, an accrual product
needs receivable accounts as well.
Each product family has its own mapping set, and the product template
endpoint returns the GL accounts eligible for each slot. The forms already call
those template endpoints for other option lists, so the data is in reach.
## Sub-tasks
Each sub-issue is independently shippable and independently useful — a loan
product with correct accounting is worth having before savings is done. Take
them in roughly this order; the first establishes the shared pieces every later
one reuses.
Sequencing note: sub-task 1 builds the shared accounting section and the
accounting-rule selector. **Do not start 2–5 until it has merged**, or five PRs
will each invent their own version of the same component.
## Scope
In scope: the accounting rule selector, the GL mapping fields per product
family, advanced mappings, and reading existing mappings back when editing a
product.
Out of scope: the chart of accounts, accounting rules, and financial
activity mapping screens — all already exist and work. Nothing about journal
entry viewing or reversal (tracked separately). No change to the generated API
client.
## Getting started
- Product forms: `src/app/features/products/`
- Template endpoints already called by those forms for currency and charge
options
- The accounting screens this unblocks: `src/app/features/accounting/`
- `npm test`, `npm run lint:prune`, `npm run i18n:check` and `npm run build`
must pass on every PR.
## Verification
Configure a loan product with cash accounting, disburse a loan against it,
then open the journal entries screen and confirm the disbursement produced a
balanced entry against the mapped fund source and portfolio accounts. That
end-to-end check is the definition of done for this epic — not the forms
rendering.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
