Projects:POS Terminal Session Management/Functional Specification

Contents 1 POS Terminal Session Management 1.1 Functional Requirements: Terminals and Tills status Window 1.1.1 Description 1.1.2 Scope 1.2 Functional Requirements: Close Store 1.2.1 Description 1.2.2 Business process definition 1.2.3 Scope 1.3 Functional Requirements: Open Store 1.3.1 Description 1.3.2 Business process definition 1.3.3 Scope 1.4 Functional Requirements: Open Terminal at front office 1.4.1 Description 1.4.2 Business process definition 1.4.3 Scope 1.5 Functional Requirements: Open till/Initial count 1.5.1 Description 1.5.2 Business process definition 1.5.3 Scope 1.6 Functional Requirements: Till cash up 1.6.1 Description 1.6.2 Business process definition 1.6.3 Scope 1.7 Functional Requirements: Flash report 1.7.1 Description 1.7.2 Scope 1.8 Opening/Closing store processes

POS Terminal Session Management

this is an optional free commercial module that can be installed on top of Openbravo for Retail distribution starting from RR14Q2.

Functional Requirements: Terminals and Tills status Window

Description

In order to manage the status of the terminals and their sessions a new window will be built

Scope

• New window at backoffice where to manage the Terminals and Tills status.
• It will have three different levels:
  • Terminal status
  • Tills status
  • Tills details

In Terminals status tab we see the different terminals for that shop with the following information:

• Terminal Code
• Terminal Name
• Terminal Status:
  • Closed: If we have run a close store
  • Open: If the store has been open
• Business Date: In blank if Terminal Status = Closed
• Tills active: Will show if there is any open till for that terminal

The user will be able to close the tills of a terminal if he knows that it's been closed in the front-office --he has the Cash up report-- but still has not been updated in the backoffice.

In Tills status tab we see the different tills for a terminal in the current Business Date with the following information:

• Till status:
  • Open in Front-office
  • Closed in Front-office
  • Closed in Back-office
• Opened: Date and time when the till was opened
• Opened by: User who opened the till
• Closed: Date and time when the till was closed
• Closed by: User who closed the till
• Closed from: Terminal or Backoffice

In the Tills details tab we will see the totals of the closed tills by payment method:

• Opening Amount
• Expected Amount
• Counted Amount
• Difference

The user will be able to reprint the cash up report for that till.

Functional Requirements: Close Store

Description

The store closing for a day is done in the backoffice.

• When the supervisor arrives at the store, the first thing he does before opening the store for the new day is the store closing.
• The reason of doing it the following day is to let all the data be updated in the backoffice and, also to avoid human errors due to tiredness at the end of the day.
• The store supervisor logs in the backoffice and checks in the Tills Status window the current status of each of the terminals in that store.
• The Tills Status window will show a row for each of the sessions in the store filtering by Business Date.
• Clicking on a session should provide drill down of the details of that session.

Business process definition

• As the closing of each of the sessions should have been done the previous night, all the sessions should be in status "Closed in front-office". If any session is still opened we can have the following options:
  • The supervisor finds the printed cash up report for that session together with the rest of them. It means that the session was closed in the front-office but the status was not updated in the backoffice. It is most probably due to a connectivity issue between that terminal and the server. The supervisor may want to check it with the IT tech and can manually close the session from the backoffice. The status for that session will then be "Closed in back-office" and the whole store will then be closed for that business day meaning that no sales can be done in any terminal
  • The supervisor does not have the cash up report for that session together with the rest of them. It means that, for some reason, the session was not closed in the front-office. The supervisor will need to check the reason, do the cash-up and then close the session and store. The supervisor might open the session for their sales, but he might forget entering the sales and/or closing the session
• If by drilling down to the details of a session we notice that any of the cash ups done were wrong (let's say we incorrectly entered the differences for a given tender type) we will not be able to reopen and edit that session cash up but we will open a new session and record the necessary transactions to adjust the errors

Scope

• We will create a new process that will be launched from the menu
• This process will have the following input parameters:
  • Store
  • Business date
• This process will:
  • Validate if there are terminals from this store with open tills. In this case it will raise an error saying: Cannot close the store "XXXXXXX" because there are open tills and will open the window Till status so the user can check those sessions and close them.
  • If there are not, it will change the status of all terminals to Closed and leave the Business Date in blank.

Functional Requirements: Open Store

Description

In order to open a store for a given business day, it must have been previously closed for the previous business day as explained in previous section. Once it's been done, the supervisor will be able to open the store by selecting a business day

Business process definition

• The supervisor checks the store is closed. Open the store with a new process:
  • Set the new business day for all the sales that will be done until the next closing/opening of the store
  • Automatically open all the terminals. This will be reflected by changing the status to "Opened in back-office" in the Sessions Status windows for all of them
• If the user tries to open the store without having closed it previously, but there are not open tills, the system will automatically close it for the previous business date ad open it for the new one

Scope

• We will create a new process that will be launched from the menu.
• This process will have the following input parameters:
  • Store
  • Business Date
• This process will:
  • Validate if there are terminals from this store with open tills for another business date (it has not been previously closed. In this case it will raise an error saying: Cannot open the store "XXXXXXX" because there are open tills for another Business Date and will open the window Till status so the user can check those sessions and close them.
  • If there are not, it will change the status of all terminals to Open and will inform the new Business Date in blank

Functional Requirements: Open Terminal at front office

Description

If the massive terminal opening performed in the backoffice when opening the store has not reached any of the terminals --because they were offline-- we still want to use that terminal so the system must allow to do a manual terminal opening. For this purpose, the supervisor will need to go to each POS terminal one by one

Business process definition

• Log into the terminal and check if it's opened and with the current business date. Possible choices are:
  • The terminal is opened and the business date is the current date --meaning that the opening performed in the backoffice has been successfully pushed to that terminal
  • The terminal is closed. It means that the terminal was closed but the opening performed in the backoffice has not been pushed to the terminal. In that case, if it has not been identified and fixed when opening the store in the backoffice, the supervisor will be able to open the terminal directly in the POS terminal by setting the new business date. This will be pushed to the backoffice as status "Opened in the front-office".
  • The terminal is opened but the business date is different to the current actual date. It might be because the session was closed and opened from the back-office but none of both actions were pushed to the front-office. In this case the system will prompt a warning pop-up and will ask the Supervisor to check the Business Date. As in the previous user case, the supervisor will be able to open the terminal offline by setting the proper business date and it will later push to the server the closing of the previous session and the opening of the new one

Scope

When the Cashier logs we need to check if there is connectivity with the backoffice

• If there is connectivity, the system will check if the Business Date in the backoffice (BOBD) is the same one as in the POS (POSBD):
  • If BOBD = POSBD it means that everything is correct. Then the system will check if the till is open:
    • If Till is open, the cashier will be able to go on with his sales
    • If Till is not open, the cashier will need to do a Initial Count.
  • If BOBD > POSBD it means that the store has been opened in the backoffice but has not been updated n the POS. Then the system will update POSBD with the correct Business Date (POSBD) and the user will need to do an Initial Count.
  • If BOBD < POSBD it means that the terminal has been opened locally but not in the backoffice. Probably because when the supervisor wanted to open the office in the backoffice he could not connect to the central server. Then the system will update the status and the Business Date for that terminal and will create a new record at Till Status tab with the status Opened in Terminal.

• If there is no connectivity, the system will check if the POSBD is the same as the real date:
  • If POSBD = Real date it means that everything is correct. Then the system will check if the till is open:
    • If Till is open, the cashier will be able to go on with his sales
    • If Till is not open, the cashier will need to do an Initial Count.
  • If POSBD <> Real date it could mean that the terminal is still opened with the previous Business Date so an error message will be raised saying: Please, check if the Business Date is correct.

In this case the Supervisor will be able to edit the Business Date. If there were transactions pending to be included in a cash up, the system will prompt the cashier to do the cash up first

Functional Requirements: Open till/Initial count

Description

Once the terminal has been opened, when the Cashier arrives to the store he will go to his terminal and will need to count the initial float. Until the initial float is counted he will not be able to start selling

Business process definition

• The drawer opens automatically --or by the supervisor using the Open drawer button.
• The Cashier will count the cash using denomination (number of each coin and banknote). For this purpose, we will have a screen showing the Expected Initial Float and the Real Initial Float at the header and a line for each of the coins and banknotes (denomination):
  • The Expected Amount will be the "Amount to keep" selected during the last cash-up. In any case, it will be a fixed amount forced in the backoffice. This can be configured and/or changed in the backoffice at any time.
  • The Real Amount will be updated every time the Cashier enters a quantity for a given coin or banknote
  • The denomination will be set up for each store and currency
• Once the Expected Initial Float equals the Real Initial Float, the Cashier will be able to confirm the Initial Float and start

Scope

This window will only be available when the Till is closed (after a Cash up). When selecting this window the drawer will open

This window will list the different coins and notes defined for the corresponding currency. The user will be able to input the number of each coin or note by either:

• clicking on the coin or note which will increase the quantity in one
• clicking on the edit icon next to it which will allow to enter the quantity using the numeric pad

The window will list the Expected Amount as well as the Counted Amount which will be updated every time the user enters a coin or note. Once Counted Amount is equal to Expected Amount the user will be able to finish the counting. If there are differences, the system will ask for supervisors validation. The system will locally store the Real Initial Amounts in case we later need to do the cash up in offline mode

Functional Requirements: Till cash up

Description

It is performed at the end of each session. There can be several sessions during the same day. Typically, a session could be closed just after each peak of sales

Business process definition

• The Cashier counts the cash by denomination. For this purpose, there should be a screen with the Expected Amount and Real Amount at the header and each of the denominations in the same way as in the Initial Float Confirmation process. The Real Amount will be updated every time a denomination is entered. After the counting:
  • If there are no differences between the Expected Amount and the Real Amount the cashier should be able to count and confirm the rest of payment forms.
  • In case of differences, the supervisor will need to approve them in order to be able to go on and count the rest of payment forms
• The rest of payment forms are balanced by confirming/adjusting the totals. No transaction drill-down is required for any of them. Currently the credit card amounts are detailed by transaction and in case of differences the amounts must be adjusted by changing one (or several) of the transactions --not necessarily the ones that were incorrect. Any difference in the totals for any payment form must be approved by the supervisor
• Once the balancing has been done, the system leaves the quantities of the initial float for the following session. As it will always be a fixed amount for cash and 0 for the rest of payment forms, the system should not need to ask for any confirmation.
• The status of the session will be pushed to the backoffice as "Closed in front-office"

Scope

Following changes need to be done to the Cash up process:

• During the first step Review pending receipts, in case there is any pending receipt, the option of deleting it should be approved by the Supervisor:

• During the second step Count Cash, the amount in cash cannot be directly validated nor entered using the numeric pad but using denomination (as in Initial count):

• When trying to go to the next step, if any of the Payment methods have any difference, the supervisor must approve it:

• When selecting for each tender the amount to leave as initial float for the next till, for those tenders which allow just one choice, the system will not ask for confirmation
• Once the process has been completed, the status of the till will be updated in the backoffice as Closed in the frontoffice
• The Amounts to keep must be stored locally in order to be able to perform an Initial Count later if being offline.

Functional Requirements: Flash report

Description

The flash report will be produced in the POS terminal and printed in the thermal printer

Scope

• It does not require any input parameter by the user.
• It shows the sales per product for the current business date done in that POS terminal.
• Information to be showed is:
  • SKU number
  • Product name
  • Total sales for that product
• It will also show Total Sales and details of the date, time, store, POS terminal and user.
• It will only be available when being online.
• It will be launched only by the supervisors.

Opening/Closing store processes