In the OHADA standard, transfers between cash/bank accounts are a two-step process. The balance is moved first out of the sending account into a "transfer account" and then later transferred from the "transfer account" to the receiving account. The given reason for this that these transfers can take place at two different time points.
For example, you might send money to the bank, but the bank will only post the transaction receiving the money the next business day. Conceptually, you would move the money to a transfer account from your cashbox today (to reflect that the cash count is correct today), and then move it into your bank when it gets posted (to reflect the balance of the bank changing to following day).
The OHADA specification requires this functionality, even if you don't need the time delay. Therefore, to be OHADA compliant, we need to support it. Similarly, all hospitals must use the transfer account even if they won't ever have a time delay in their transfers to be OHADA compliant, as mandated by the DRC government.
Our client hospitals consider having to create two transactions (cash account A -> transfer account and transfer account -> cash account B) to be annoying and have asked us to implement the ability to shortcut this by automatically running through the transfer account when transferring money.
I propose we create a new database table called cashbox_transfer_matrix that looks something like this:
to_cashbox_id
from_cashbox_id
transfer_account_id
1
2
3415
2
1
3416
When a transfer is specified on the client, the user will pick another cash account to send the money to. On the server, we will check if:
Transfer accounts are enabled in the enterprise settings (enable_cashbox_transfer_accounts).
A transfer account exists in the cashbox_transfer_matrix for the cashbox pair.
If:
enable_cashbox_transfer_accounts is false, we will create a single transaction, moving money directly from the cashbox A to cashbox B.
enable_cashbox_transfer_accounts is true, but we are missing a transfer account for those two cashboxes, we will throw an error. This ensure that hospitals do not make a mistake by forgetting to create a transfer account for new cashboxes.
If enable_transfer_accounts is true and a record exists in the cashbox_transfer_matrix for the two cashboxes, we will need to generate two transactions:
a. Cashbox A -> transfer account
b. transfer account -> Cashbox B.
The interface for assigning transfer accounts will be in the cashboxes module. We will probably have to create new page with a matrix containing each cashbox and their transfer accounts.
Motivation
In the OHADA standard, transfers between cash/bank accounts are a two-step process. The balance is moved first out of the sending account into a "transfer account" and then later transferred from the "transfer account" to the receiving account. The given reason for this that these transfers can take place at two different time points.
For example, you might send money to the bank, but the bank will only post the transaction receiving the money the next business day. Conceptually, you would move the money to a transfer account from your cashbox today (to reflect that the cash count is correct today), and then move it into your bank when it gets posted (to reflect the balance of the bank changing to following day).
The OHADA specification requires this functionality, even if you don't need the time delay. Therefore, to be OHADA compliant, we need to support it. Similarly, all hospitals must use the transfer account even if they won't ever have a time delay in their transfers to be OHADA compliant, as mandated by the DRC government.
Our client hospitals consider having to create two transactions (cash account A -> transfer account and transfer account -> cash account B) to be annoying and have asked us to implement the ability to shortcut this by automatically running through the transfer account when transferring money.
To satisfy all parties, I propose that we adopt a design that optionally uses transfer accounts if they exist when transferring between cashboxes. We have previous implemented this incorrectly (see https://github.com/IMA-WorldHealth/bhima-2.X/pull/2956, https://github.com/IMA-WorldHealth/bhima-2.X/issues/2741).
I propose we create a new database table called
cashbox_transfer_matrix
that looks something like this:to_cashbox_id
from_cashbox_id
transfer_account_id
When a transfer is specified on the client, the user will pick another cash account to send the money to. On the server, we will check if:
enable_cashbox_transfer_accounts
).cashbox_transfer_matrix
for the cashbox pair.If:
enable_cashbox_transfer_accounts
isfalse
, we will create a single transaction, moving money directly from the cashbox A to cashbox B.enable_cashbox_transfer_accounts
istrue
, but we are missing a transfer account for those two cashboxes, we will throw an error. This ensure that hospitals do not make a mistake by forgetting to create a transfer account for new cashboxes.enable_transfer_accounts
istrue
and a record exists in thecashbox_transfer_matrix
for the two cashboxes, we will need to generate two transactions: a. Cashbox A -> transfer account b. transfer account -> Cashbox B.The interface for assigning transfer accounts will be in the cashboxes module. We will probably have to create new page with a matrix containing each cashbox and their transfer accounts.
This design supercedes https://github.com/IMA-WorldHealth/bhima-2.X/issues/2741.