Title: Message Title
|
The transfer API's currently available on the develop branch have been built based on the assumption that activities occurring in one branch should under no condition trigger any accounting entries in another Branch.
As a pre requisite for transfers, the following changes were made * A new Asset account tentatively titled "Suspense Account for Transfer" is captured during loan product creation for all products having cash/accrual based accounting enabled * Each loan Transaction is now linked to a branch * New status are introduced for Clients, Groups (TRANSFER_IN_PROGRESS, TRANSFER_ON_HOLD) and Loans
For Transferring a client from one branch to another, the API's would be orchestrated as follows * /clients/{clientId}?command=proposeTransfer is called for a particular client passing the destination branch as a part of the POST body. This causes (in the case of cash based accounting) journal entries for crediting the "Loan Portfolio" account and Debiting the "Suspense Account for Transfer" with the total principal due. The client and all his active loans would now move into a "TRANSFER_IN_PROGRESS" state and the client is now linked to the destination branch.
* /clients/{clientId}?command=acceptTransfer is called by the user of the destination branch to confirm the transfer at the destination branch. This causes crediting the "Suspense Account for Transfer" and debiting the "Loan Portfolio" account in the context of the destination branch with the total principal due. The Client and transferred loans are now moved back to their original "Active" states
* /clients/{clientId}?command=rejectTransfer may be called by the destination branch to indicate that they do not wish to accept the transfer. No journal entries would be created (the client should only be updated to the office that proposed the transfer, currently not present in develop branch). The clients and transferred loans are moved into "TRANSFER_ON_HOLD" state
* /clients/{clientId}?command=withdrawTransfer may be called by the source branch (before acceptTransfer is called at the destination branch), this would reverse the journal entries created during proposeTransfer call and move client and all his loans back to active state
A intra-branch Group transfers (a bulk operation for moving clients from one group to another and synchronizing their loans to the meeting schedule of the new Group) is also present. The inter-branch Group group transfer is being updated to follow a similar process as the client transfer.
Next, we need to capture the history of branch transfers history (dates) and ensure that backdated operations may not occur on loans before the date of their transfer (Was earlier thinking of allowing the same and letting it affect the books of the branch to which the client belonged to at that point in time, but now think this would be wrong and we should not allow operations performed by one branches user to accidentally affect the accounting books of another branch etc)
Would expect the cleaned of functionality and UI to be a part of next Monday's release
|
|
|
|
|
|
|
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Mifos-issues mailing list
Mifos-issues@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mifos-issues