Hi guys,
This is an interesting topic. I have been wondering why, in general, we
seem to be deprecating more and more system functions. The individual
collection sheet has served us well over the years and still does, If
anything we could improve on its functionality by maybe adding a bulk
collection sheet template with little detail compared to a full loan
repayment bulk import template.
Fineract is used by tens of thousands of organisations throughout the
world and most of them are not on this listing and may not have a voice to
air their concerns. Maybe we can find a way of exposing this thread to
include more voters.
Regards,
*From:* James Dailey [mailto:jdai...@apache.org]
*Sent:* Saturday, 16 August 2025 02:53
*To:* dev@fineract.apache.org
*Subject:* Re: Collection Sheet Deprecation was [Re: Questions and
Observations on FINERACT-2290 (Collection Sheet API Refactor)]
Ed
I agree this needs to be discussed but it is important to acknowledge
that THIS Fineract listserv is the only official (and required) discussion
space. It is not the intention to bury anything in “an email thread”.
When I started up Mifos we spent a lot of time looking at Collection
Sheets and designing process flows around them. I fully know that this
design direction was important back then in 2002-2006.
However if there is no one here asking for them to be retained besides
you, then that is a sign that they have perhaps reached an end of their
utility. Or, that the users are not actually here, which is a different
problem.
So,… If there is a group using collection sheets in production AND they
are not on some permanent forked (old) version, then now is the time to
speak up. Here.
Generally, I’m fairly certain we can refactor this with an eye toward
extracting it from the core. Repeating the logic in two places makes no
sense either. Collection sheets are kind of assembled from
constituent loans and savings. The balances and due payments should be
calculated in the underlying components.
As the system gets restructured we need to decide to keep this at all, to
keep it in a new place, or as some external concept/plug in. Why wouldn’t
we want a separate component?
Cheers
On Thu, Aug 14, 2025 at 4:16 PM Ed Cable <edca...@mifos.org> wrote:
I'll leave the other thread for discussion of the API versioning and
refactoring related to Collection Sheet API but wanted to create a separate
thread regarding the deprecation of the Collection Sheet.
In general, for this and removal of any functionality, it's something
that needs to be discussed openly with the community and with a vote and
not a decision buried in a mailing list thread.
For the collection sheet specifically, more thought has to be given to
its deprecation as the centrality and highly coupled nature of the
collection sheet is being understated as it isn't merely a report that's to
be printed or a form filled out via a mobile application. It's a
significant portion of the user interface and highly coupled to many of the
microfinance features around groups/centers/meeting scheduling, staff
assignment, etc.
I do agree that from a UI perspective, the collection sheet and other
microfinance-centric functionalities and flows should be viewable based on
a configurable setting. As it doesn't lend itself to the optimal user
experience for a large portion of current Fineract user base.
I also am supportive of a strategy of slimming Fineract to its core
services and functionality above core Fineract services and APIs can be
extracted out.
So I do think we should give thoughtful consideration to what abstracting
out the collection sheet and corresponding microfinance functionality would
look like and what that effort would entail to abstract it out without
adversely impacting the original user base of the software but it's not as
simple as deprecating these API.
I welcome others' thoughts and inputs as I know even with microfinance
itself, the methodology has evolved and group lending and the concept of a
collection sheet isn't as central as it once was
Thanks,
Ed
On Wed, Aug 13, 2025 at 6:36 PM Kapil Panchal <
kapil.panchal.developm...@gmail.com> wrote:
Hi James,
I can proceed by marking this feature as @Deprecated and/or performing a
safe refactor to remove the API.
For API versioning I agree to Aleksandar Vidakovic's proposal on adapting
to the SpringBoot v7/Spring Framework v4. If I may, Aleksandar
Vidakovic takes the lead on this project and I can help to support the
conversion?
Thanks,
Kapil
On Thu, Aug 14, 2025 at 5:07 AM James Dailey <jdai...@apache.org> wrote:
Hi Kapil
I might suggest looking at this as an opportunity to remove the
collection sheet entirely from the Fineract namespace. It’s a legacy
concept I and others designed a long time ago, originally in 2002 based on
collection sheets we gathered from a dozen countries. It is strongly tied
to concepts in microfinance field operations, and especially when there was
no data connectivity.
It belongs perhaps as a sort of external microservice - data loading via
a bulk import could still be enabled.
The API versioning is a good idea but needs to be more holistic across
the platform I think.
On Mon, Aug 11, 2025 at 4:43 AM Ádám Sághy <adamsa...@gmail.com> wrote:
Hi Kapil,
Thank you for raising the concerns below. I’ll need some additional
details to fully understand your points:
1. *Collection Sheet API* – You mentioned it appears non-functional
and contains several logical errors.
o If it’s indeed not working, that’s a separate, high-priority
discussion.
o Could you clarify which logical errors you were referring to, and
what specifically makes you think it’s non-functional?
2. *Service annotations* – You noted that service methods are not
annotated with @Service and that beans are defined manually.
o Are you referring to the
CollectionSheetWritePlatformServiceJpaRepositoryImpl bean being defined
via configuration?
3. *Repository wrappers annotated with **@Service* – You mentioned
that this mandates full unit test coverage but that they should ideally be
annotated with @Component.
o Could you point out the exact classes you had in mind?
As for the other points, I agree we can refactor and remove redundant
logic—please feel free to suggest specific improvements or start work on
them immediately!
However, be careful by moving anything into the fineract-core… We are
aiming to keep it as small as possible as everything is built on top of
this module! If collection sheet are used for loans and savings - for
example - than the recommended move is NOT to move this logic into core!
Either:
- we split the logic into fineract-loan and fineract-savings
- Move the logic into a new module
- Leave it in fineract-provider for now
Shall you have any questions, please let us know!
Regards,
Adam
On 2025. Aug 11., at 12:09, Kapil Panchal <
kapil.panchal.developm...@gmail.com> wrote:
Hi Adam,
I’m currently working on *FINERACT-2290* and have a few questions before
I submit a pull request.
The *Collection Sheet API* in its current state appears non-functional
and contains several logical errors. It seems there was an earlier attempt
to convert from a JSON string request parameter to a class-based request
object, but:
Certain fields are missing.
The serializer is not correctly populating the objects, which causes the
conditional checks to be bypassed and results in incorrect (false)
responses.
This change set is *high risk* because it touches most of the loan and
savings product logic. I’ve had to refactor almost all major methods.
Extensive integration and end-to-end testing will be required to ensure
there are no regressions, especially in edge cases. At present, there are
no unit or integration tests for this functionality, and test creation is
outside the current ticket scope. I’ve been iterating on this for a while,
and only today have I reached a stable state after several experimental and
build-breaking attempts.
*Key Observations:*
Service methods are not annotated with @Service; instead, beans are
defined manually.
Repository wrappers are annotated with @Service. This mandates full unit
test coverage for these methods, but they should ideally be annotated with
@Component.
I agree with prior discussions on separating bean validation — having a
dedicated @Component validation class allows the request object to handle
checks independent of database queries.
Validation components can also perform database-related validations;
these can be injected into service classes for cleaner architecture.
Such validation components should be placed in *Fineract-Core* so they
are reusable across modules, reducing future refactoring needs.
The current design of having commands in *Fineract-Core* and
handlers/services/repositories in respective modules is good — it cleanly
decouples command definition from execution.
There is extensive use of this. in singleton contexts (API, Service,
Repository). While not harmful, it’s unnecessary boilerplate.
Multiple redundant intermediate DTOs exist where the request DTO itself
could be reused for data transfer.
I found redundant logic — e.g., a for loop with a break statement that
effectively executes only once; this can be simplified.
Some JDBC template queries use reserved SQL keywords, causing exceptions.
Refactoring these queries resolves the issue and returns proper response
objects.
*Suggestions:*
*Where appropriate, large tickets should be broken into subtasks to
manage complexity and reviewability.*
It may help to have a dedicated *developer-only Slack channel *for
technical discussions. This could complement other community spaces if
there’s a need to keep certain conversations more focused.
What are your thoughts on the above?
Thanks,
Kapil
--
*Ed Cable*
President/CEO, Mifos Initiative
edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
<http://facebook.com/mifos> <http://www.twitter.com/mifos>
