View source | View content page | Page history | Printable version   

Projects:Web POS/Cash Close


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.

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:

Register change included in the cash drawer

This flow is started from menu and opens a different window.

It allows to create:

When dropping out, a predetermined destination must be chosen.

Technical specifications


Table OBPOS_APP_PAYMENT needs to be extended with three new fields:

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

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.


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

Retrieved from ""

This page has been accessed 3,416 times. This page was last modified on 14 June 2012, at 15:09. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.