Projects:Web POS/Cash Close
Contents |
Functional specifications
Partial & daily close
This is the flow performed at the end of the day to close the cash. It consists on the following steps.
Review pending tickets
All unpaid tickets are listed. This is, the ones that have been created but not processed yet. They are locally stored in POS, so this list is locally retrieved. For each of them one of these 2 options must be taken.
- Void: Ticket is voided, removing it from POS
- Quick cash: Ticket is processed as paid with cash and sent to backend
It is required to perform these actions on all pending tickets before being able to continue to next step. In case there are no pending tickets, a message will be displayed within this step.
Count cash
For each payment method expected amount is listed. User can confirm for each of them or enter the actual value. It also displays expected total and actual difference.
Only once all of them have been confirmed it is allowed to move forward.
Post, print, close
A summary report is displayed.
When clicking in post button:
- Report is printed
- Cash close process is executed
- For all orders that have not been already invoiced, a consolidated invoice is created.
- In case of differences with expected amount, a payment is added
- Each of the associated financial accounts is reconciled
Register change included in the cash drawer
This flow is started from menu and opens a different window.
It allows to create:
- Deposit (in)
- Drop (out)
When dropping out, a predetermined destination must be chosen.
Technical specifications
DB
Table OBPOS_APP_PAYMENT needs to be extended with three new fields:
- G/L Item for cash differences. Used to create transactions for cash closing in case of difference with expected amount.
- G/L Item for deposits and drops. Used to create transactions for cash management.
- G/L Item for cash close. (mandatory) When closing cash, a transaction with the total amount is created in payment type's fin acct to drop out all money.
- Financial account for cash close. (mandatory) When closing cash, money is moved from payment type's fin acct to this one.
It shouldn't be allowed to use same financial account in different Payment types, not even for different POS Terminals. This can be enforced in DB with a unique constraint in OBPOS_APP_PAYMENT.FIN_Financial_Account_ID
Partial & daily close
Review pending tickets
- Pending tickets are stored locally in POS, list should be retrieved from local.
- VOID and QUICK CASH actions cannot be undone, a message should be displayed to ask confirmation.
- Void: Removes ticket from POS.
- Quick Cash: Executes local pay process, this should also send the ticket as paid to backend.
Count cash
Before reaching this point it must be ensured local POS buffer is empty and every ticked is already loaded in backend. This process can be only executed online.
A service in backend should return a list of all Payment types. Expected amount for each of them is the Current balance of each financial account.
Only those payment types having value in G/L Item for cash differences field should be allowed to be counted. The rest of them are shown just for informational purpose, they cannot be edited.
Post, print, close
Report is served from backend. Format TBD
Close process
Invoice Orders
Those orders that have not been already invoiced by Loading Order Process, should be grouped in a consolidated invoice.
This can be done following different rules depending on localization, therefore, even a default rule can be implemented, it must support an easy way to overwrite it.
Reconciliation
For each of the cash differences, a new transaction is added to the correspondent financial account, this will have the G/L item defined for cash differences.
For each financial account associated to payment type, a new GL item is created to drop out the total amount and a inverse one is created in the destination financial account (using same G/L) to represent transfer to that acct.
For each financial account, all pending transactions are cleared and included within a reconciliation that is processed.
For each destination financial account a reconciliation is done including created G/L items.
Register change included in the cash drawer
List of "destinations" is hardcoded in a js file that can be overwritten by modules. Both drop and deposit can have a list associated, in case it is empty, it is not shown and a generic one is used. Finally, this is used just to create a comment in the transaction.
Back end
Both drop and deposit actions create a transaction with the G/L item defined for this purpose in the correct financial account.
Known issues & limitations
- First version does not support multicurrency in same terminal. This is, financaial accounts associated to different payment types in same terminal are assumed to be in same currency.