Aman-Mittal opened a new issue, #294: URL: https://github.com/apache/fineract-backoffice-ui/issues/294
Part of #288. Depends on #290 and #291 — the base mappings must exist before they can be overridden. ## Business value The base mappings from the earlier sub-tasks send every fee to one income account and every payment to one fund source. Real institutions need finer granularity: - **Payment channel to fund source.** Cash collected at the counter belongs in the till account; a mobile-money collection belongs in the wallet settlement account; a bank transfer belongs in the bank account. Without this mapping all three land in the same place, and nobody can reconcile the till at close of day or the mobile-money float against the provider's statement. - **Fee to specific income account.** Processing fee, insurance fee and late fee are different revenue lines to a finance team, and are often taxed differently. One combined "income from fees" figure cannot be broken down after the fact. - **Penalty to specific income account.** Same argument, and penalties are frequently reported separately to regulators. These are the mappings that turn "the ledger balances" into "the ledger is useful". ## What to build Three repeatable mapping tables, each a list of rows the user can add to and remove from: | Mapping | Row shape | |---|---| | Payment channel to fund source | payment type → GL account | | Fee to income account | charge → GL account | | Penalty to income account | penalty charge → GL account | The payment types come from the payment-type endpoint the app already consumes; the charges come from the product template response, which already carries the charge options the form uses elsewhere. A small repeatable-row component shared across all three is worth building — the shape is identical and `loan-product-form.component.ts` is long enough already. Add these to the loan and savings product forms. Deposit and share products may accept a subset; check the template response for each rather than assuming. ## Two things to get right 1. **Omit the arrays entirely when empty.** Sending `[]` and sending nothing are not always the same to the platform. Verify on a live instance (`npm run e2e:stack`) which it wants, and match it. 2. **Only charges attached to the product should be offered.** Offering every charge in the tenant produces mappings the platform will reject, and the error will not make it obvious why. ## Testing - **Unit spec:** rows can be added and removed; the submitted body carries the arrays in the platform's expected shape; empty tables produce no key. - **Unit spec:** loading a product with existing advanced mappings repopulates all three tables. - **Mocked e2e:** intercept the `POST`, assert the nested arrays. - A **backend e2e** collecting a repayment through two different payment types and asserting the journal entries hit two different fund sources would be the real proof. Welcome, not required. ## Scope In scope: the three advanced mapping tables on loan and savings products. Out of scope: financial activity mappings, which are institution-level and already have their own screen. ## Getting started - `src/app/features/products/loan-product-form.component.ts`, `savings-product-form.component.ts` - Shared components from #289 - `npm test`, `npm run lint:prune`, `npm run i18n:check`, `npm run build` -- 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]
