apache / apache/fineract-backoffice-ui

GLIM, GSIM and the centre collection sheet cannot be built — the backend refuses all three on PostgreSQL

Open
#376 1 comment 0 reactions 0 assignees View on GitHub
bug help wanted impact: branch-ops priority: medium
Dominant language
TypeScript
Stars
15
Forks
60
Avg merge
10h 15m
Merged PRs (30d)
108

Description

Three features cannot be built into this application because the platform refuses them on
PostgreSQL. Each was probed against `apache/fineract:latest` (`1.15.0-303-gf4f927e`, built
2026-08-15) with a fresh database, as the default superuser holding `ALL_FUNCTIONS`. No screens were
shipped for them, because a screen for any of these could only ever fail.

## 1. GLIM — group loan individual monitoring

`POST /v1/loans` with `loanType: "glim"` is accepted by validation and then fails in the database:

```
ERROR: null value in column "principal_amount" of relation "glim_accounts" violates not-null constraint
INSERT INTO "glim_accounts" ("account_number", "application_id", "child_accounts_count",
"accepting_child", "loan_status_id", "principal_amount", "group_id") VALUES (?, ?, ?, ?, ?, ?, ?)
```

The API answers `403 error.msg.unknown.data.integrity.issue`. The obvious alternative payload is
rejected outright — *"The parameter clientMembers is not supported"* — so there is no second shape
to try. `GET /v1/groups/{id}/glimaccounts` and `GET /v1/loans/glimAccount/{id}` both work; they just
have nothing to return, because nothing can be created.

## 2. GSIM — group savings individual monitoring

`POST /v1/savingsaccounts/gsim` answers **200** and reports `gsimId: 0`. Individual savings accounts
are created for the named clients, but no parent GSIM record is formed, and
`GET /v1/groups/{id}/gsimaccounts` stays empty afterwards. Adding `isGSIM: true` changes nothing on
that endpoint and is rejected as unsupported on `POST /v1/savingsaccounts`.

## 3. Centre collection sheet

`POST /v1/centers/{id}?command=generateCollectionSheet` answers **500**:

```
org.postgresql.util.PSQLException: ERROR: operator does not exist: boolean = integer
```

The query compares a boolean column to an integer — `ls.completed_derived = 0` — which MySQL
accepts and PostgreSQL does not. The comparison is unconditional, so this fails for every tenant on
PostgreSQL regardless of data. The command itself is recognised: a deliberately invalid command on
the same endpoint is refused with `error.msg.query.parameter.value.unsupported`, while this one gets
as far as looking the centre up.

The **individual** collection sheet this application already has is unaffected, and its `generate`
and `save` commands are the ones this backend accepts.

## Business Value

Group lending is the core of microfinance, and GLIM and GSIM are how a group loan or group savings
account is tracked per member — who owes what inside a joint liability group. Without them a branch
running group products has to track member-level balances outside the system, which is where
reconciliation errors and disputes come from.

The centre collection sheet is the daily working document of a field officer: one page listing every
member due at a centre meeting, filled in during the meeting and posted as one batch. Without it,
collections at group scale are entered account by account.

Because all three are refused by the backend, this issue is a tracking record rather than a UI task.
It becomes actionable here once the platform accepts the operations; the fixes belong upstream.
Anyone picking it up should raise the three defects on the Fineract JIRA project first and link the
tickets back here.

## What would close this

- The three platform defects fixed upstream and available in a released Fineract, then
- screens for GLIM accounts and GSIM accounts on the group record, and the centre collection sheet
beside the individual one — each built the way the rest of this application is: contract verified
against a running platform, unit tests, and a backend e2e test that seeds a real record.

Found while closing the functional gaps in #375.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the three failures at the listed Fineract API endpoints against PostgreSQL, then raise the corresponding defects in Fineract JIRA and link them back here. Once a released Fineract accepts the operations, inspect the existing individual collection-sheet flow and the group-record screens; done requires GLIM and GSIM group screens, a centre collection sheet, unit tests, and backend end-to-end tests with real seeded records.

Written by the indexing model from the issue text.

Assessment

Tech stack
angular, postgresql, typescript
Domain
api, backend, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.