[
https://issues.apache.org/jira/browse/FINERACT-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
elnafateh updated FINERACT-2740:
--------------------------------
Description:
Loan-loss provisioning entries can have their journal entries posted
immediately upon creation, via the createjournalentry command. There is no
review step: a provisioning entry that has just been generated can have its
reserves posted to the general ledger without anyone confirming the entry is
correct first.
This is a gap relative to how Fineract typically treats accounting-impacting
actions. Other financially significant workflows in the system, loan reschedule
requests for example, require an explicit review-and-decide step. The record is
created in a pending state, and a separate, deliberate action moves it forward,
before the action with real financial consequences is allowed to happen.
Provisioning has no equivalent. Creation and journal-posting are two separate
API calls today, but nothing stops the second from immediately following the
first.
h4. *Expected Behavior*
A provisioning entry should carry a review status, distinct from whether its
journal entries have been created: draft (generated but not yet reviewed),
approved (reviewed and accepted), or rejected (reviewed and declined).
h4. *Transitions*
A newly created provisioning entry starts in draft.
A draft entry can be moved to approved or rejected
An approved entry may be reverted back to draft ("undo"), but only if no
journal entries have been created for it yet.
A rejected entry has no further transitions available.
h4. *How this constrains existing behavior*
Journal entries may only be created for a provisioning entry that is currently
approved. Posting for a draft or rejected entry must fail, with nothing posted.
This includes the existing option to request immediate journal posting at
creation time; a newly created entry is always draft, so that request must fail
the same way.
Regenerating a provisioning entry's underlying rows (the existing "recreate"
action) must only be allowed while the entry is still in draft.
h4. These three new methods should live on
ProvisioningEntriesWritePlatformService
approveProvisioningEntry(Long provisioningEntryId, JsonCommand command)
rejectProvisioningEntry(Long provisioningEntryId, JsonCommand command)
undoProvisioningEntryApproval(Long provisioningEntryId, JsonCommand command)
was:
Loan-loss provisioning entries can have their journal entries posted
immediately upon creation, via the createjournalentry command. There is no
review step: a provisioning entry that has just been generated can have its
reserves posted to the general ledger without anyone confirming the entry is
correct first.
This is a gap relative to how Fineract typically treats accounting-impacting
actions. Other financially significant workflows in the system, loan reschedule
requests for example, require an explicit review-and-decide step. The record is
created in a pending state, and a separate, deliberate action moves it forward,
before the action with real financial consequences is allowed to happen.
Provisioning has no equivalent. Creation and journal-posting are two separate
API calls today, but nothing stops the second from immediately following the
first.\
h4. *Expected Behavior*
A provisioning entry should carry a review status, distinct from whether its
journal entries have been created: draft (generated but not yet reviewed),
approved (reviewed and accepted), or rejected (reviewed and declined).
h4. *Transitions*
A newly created provisioning entry starts in draft.
A draft entry can be moved to approved or rejected
An approved entry may be reverted back to draft ("undo"), but only if no
journal entries have been created for it yet.
A rejected entry has no further transitions available.
h4. *How this constrains existing behavior*
Journal entries may only be created for a provisioning entry that is currently
approved. Posting for a draft or rejected entry must fail, with nothing posted.
This includes the existing option to request immediate journal posting at
creation time; a newly created entry is always draft, so that request must fail
the same way.
Regenerating a provisioning entry's underlying rows (the existing "recreate"
action) must only be allowed while the entry is still in draft.
These three new methods should live on ProvisioningEntriesWritePlatformService:
approveProvisioningEntry(Long provisioningEntryId, JsonCommand command)
rejectProvisioningEntry(Long provisioningEntryId, JsonCommand command)
undoProvisioningEntryApproval(Long provisioningEntryId, JsonCommand command)
> Reviewed Loan-Loss Provisioning Entry Lifecycle
> -----------------------------------------------
>
> Key: FINERACT-2740
> URL: https://issues.apache.org/jira/browse/FINERACT-2740
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Loan
> Reporter: elnafateh
> Priority: Major
>
> Loan-loss provisioning entries can have their journal entries posted
> immediately upon creation, via the createjournalentry command. There is no
> review step: a provisioning entry that has just been generated can have its
> reserves posted to the general ledger without anyone confirming the entry is
> correct first.
> This is a gap relative to how Fineract typically treats accounting-impacting
> actions. Other financially significant workflows in the system, loan
> reschedule requests for example, require an explicit review-and-decide step.
> The record is created in a pending state, and a separate, deliberate action
> moves it forward, before the action with real financial consequences is
> allowed to happen. Provisioning has no equivalent. Creation and
> journal-posting are two separate API calls today, but nothing stops the
> second from immediately following the first.
> h4. *Expected Behavior*
> A provisioning entry should carry a review status, distinct from whether its
> journal entries have been created: draft (generated but not yet reviewed),
> approved (reviewed and accepted), or rejected (reviewed and declined).
> h4. *Transitions*
> A newly created provisioning entry starts in draft.
> A draft entry can be moved to approved or rejected
> An approved entry may be reverted back to draft ("undo"), but only if no
> journal entries have been created for it yet.
> A rejected entry has no further transitions available.
> h4. *How this constrains existing behavior*
> Journal entries may only be created for a provisioning entry that is
> currently approved. Posting for a draft or rejected entry must fail, with
> nothing posted. This includes the existing option to request immediate
> journal posting at creation time; a newly created entry is always draft, so
> that request must fail the same way.
> Regenerating a provisioning entry's underlying rows (the existing "recreate"
> action) must only be allowed while the entry is still in draft.
> h4. These three new methods should live on
> ProvisioningEntriesWritePlatformService
> approveProvisioningEntry(Long provisioningEntryId, JsonCommand command)
> rejectProvisioningEntry(Long provisioningEntryId, JsonCommand command)
> undoProvisioningEntryApproval(Long provisioningEntryId, JsonCommand command)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
