View source | Discuss this page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Show collection (0 pages)
Collections help


Retail:Web POS User Guide

Back to main page



The Openbravo Web POS is one of the key components of the Openbravo omnichannel platform. It is used in stores to assist shop floor staff in client-side selling and enables the checkout process.

See Openbravo Web POS in action

Visit our Product Tour page to watch some videos and get a first impression of our solution, including an assisted sale scenario and a click&collect scenario.

Launching Web POS

Openbravo for Retail uses two GUIs: Web POS and the Openbravo back office. Both run in a web browser and both can be launched independently.

View larger

It is recommended to run Web POS in full screen mode, this way Web POS takes full control of the screen and all other distracting elements disappear from the screen making the cashier to focus only in sales operations.

Note - iPad users: During the Web POS login the browser will ask you: "Increase Database Size? Do you want to allow [application] to use up to 50 MB of storage on your device?". VERY IMPORTANT: You need to approve this to be able to use the off-line capabilities of Web POS.

Web POS GUI overview

Login Page

The login page shows the list of users which can access this particular Web POS terminal. Each user shows an icon, whose color describes if the user currently has a session open in this terminal:

View larger

Main layout

The Web POS uses an adaptible layout. The layout will adapt itself automatically depending on the resolution of the device it's being used in. This means that it will look slightly different in a desktop computer than in a smartphone, for example.

In the most common scenario, the Web POS will display a two column layout, which contains the main menu and the ticket area in the left side, and the tab area on the right side.

View larger

In smartphones and devices with small screens, the Web POS automatically switches to a one-column layout. A switching button which can be used to switch back and forth between the left and right columns is added to the button toolbar.

View larger
View larger

Users can also swipe the screen to switch between toolbars. Some actions will also automatically switch to the appropriate column when necessary.

Since RR17Q2 is it possible to disable not wanted toolbars by setting to "N" the following preferences:

Ticket area

One half of the screen is occupied by the ticket area. Here all products that are added to the active ticket are shown in a list view. It serves as a preview of the final ticket that the customer will receive after successful payment. Items in the list view can be selected and subsequently edited.

View larger

Message area

The message area on the other side of the screen shows the time and date and informs the user about actions and events.

Numerical pad

The on-screen keypad is used by touch screen users to enter product codes, quantities and other numerical data.

View larger

The discount key can be configured:


The tab buttons at the top of the screen give access to the four main POS activities: scan, browse, search and edit. The first three activities are used to find and add products to a ticket, the edit activity applies to the last or user-selected product.

The menu

The menu is the main way to open most of the advanced features of the Web POS. Apart from the functionalities which will be explained in detail in subsequent sections, the menu contains some basic features also present in other Openbravo mobile applications.

The main ones are:

Bulbgraph.png   Note: Approval can be configured for log out if there are open tickets. To do so there is a preference called Web POS Remove Receipts Approval

Please take into account that the menu is scrollable, and that you can easily scroll through the available options by dragging the menu options themselves.

Bulbgraph.png   This feature is available starting from 3.0RR19Q2.
View larger

The menu entry Online status (where the user could log out or lock the screen) and the User menu entry (where the user could change the role) are now combined into a single menu entry. This new menu entry will also have the image and the name of the registered user, to facilitate the identification of the user who has logged in.

When you click on this menu entry, a pop-up window with 3 options will appear:

View larger


Shortcuts to navigate back/forward in the browser have been blocked to avoid an involuntary navigation.

When using a keyboard you may use the following shortcuts:

Main Flows

Openbravo Web POS supports the following main flows:


In order to activate the new Terminal Authentication Security (Enhance Terminal Authentication) a preference should be enabled. Check this topic to activate the preference called <<Terminal Authentication enabled>>. By default, this preference has 'N' value, put 'Y' to enable Authentication security.

Bulbgraph.png   Note: Starting from 3.0RR16Q1 it will be enabled by default

In this case, we navigate directly to login page and we can enter our user and password.

We will navigate to Terminal selecting window (Only the first time we access to Web POS. After first access, selected terminal is saved and we will access directly to login page) in order to link this physical device to a POS Terminal Configuration.

Note: Cleaning device cache will delete this info and you need to link again the physical device to corresponding configuration.

linking the device


Above window should be filled in order to link the device with the POS terminal:

Terminal key identifier.jpg

Remember that a POS Terminal can be just linked to one physical device.

After link the device with the terminal, the login page will be open with the selected POS Terminal Configuration. As explained above, this login page will be automatically shown in the future unless the terminal is unliked or the browser cache of the device is removed.

In the login process and before sending data to backend, the system will check if the terminal is still authenticated. If someone (from ERP ) changes the value of Terminal Authentication enabled preference or if the POS terminal is unliked then a modal will be shown explaining the situation. The system will force to the user to link the terminal again.

Bulbgraph.png   Note: One device should be used with one unique terminal. If a device is used with more than one terminal, previously, the cache should be cleaned in the device, and important data could be lost

Setting a new password

If configuration in Client has been set (Client), Users will be forced to renew their passwords once they have reached their limit "Days To Password Expiration".

During login, the process will check if the user has reached the limit date for the password, in this case, the interface will force the user to renew the password, and the new limit date will be updated once the new password is saved.


The new password must be different from the previous password, otherwise a message is shown.


Also password could be renewed from the backend before expiration date has been reached, in User windows, using password field to change the password.

Bulbgraph.png   The field "Days To Password expiration" configurable in Client, and the related behaviour is available from 16Q2 version.


Using a barcode scanner, products can be added to the ticket by scanning their barcodes. The barcode scanner works as a human-input-device (HID) similar to a keyboard and generates a numerical string followed by a carriage return. The user will see the numerical string appear in the field that sits in the numerical pad. Barcode scans are registered when the Web POS is in Scan or Edit mode.

Bulbgraph.png   Note: If your keyboard mapping doesn't match with the mapping used internally by the barcode scanner, some characters could be changed by others when the barcode is read. Please try to avoid this kind of characters ('-','/') in the barcode.
View larger

You can test barcode scanning in the Web POS demo environment using the example barcode sheet displayed.

By default products are marked as grouped products, it means that when a product which is already in the ticket is scanned the quantity of this line will increase. Having a product marked as "Not grouped" a new line with quantity 1 will be created once a barcode is scanned.

Bulbgraph.png   Starting from 18Q3 when a grouped product which is already in the ticket is scanned then the scroll will be moved to show the affected line


Now a Web POS user can scan products through an RFID reader.

Add Product

With everything configured properly products can be added to the ticket using the reader. To do so, one just need to bring closer an RFID tag to the reader and it will beep.

Also while standing in Return this receipt products can be added. In this case they will be added with negative quantity as it proceeds.

Under some circumstances the reader can beep but the product will not be added. If that happens it means that the tag is either in Hardware Manager's buffer, or in the current ticket.

Also if the reader does not beep it means that the tag is already in the reader's buffer.

All buffers will be cleaned each time Web POS gets refreshed.

Remove Product

Each time a line which has been added to the ticket using an RFID reader is removed it will also be removed from the Hardware Manager's buffer and theoretically from the device's buffer (this has not been possible for EmbiPOS due to its API)

This affects to:

Disable/Enable RFID Reader

Any user of a terminal with Use RFID and Web POS action Disable / Enable RFID Reader can disable and enable the RFID reader through a new button placed in the main menu.

This will also be reflect in a new icon next to the SCAN label in the main toolbar. This icon has 3 states:


Manual entry

Sometimes barcodes are missing or cannot be read by the scanner and need to be entered manually. For this, you need to be in Scan or Edit mode. The UPC/EAN code is entered using the on-screen or physical keyboard and by tapping the Enter or UPC/EAN key the code is submitted to the system. It will then search for a product match and once the product is found, it is added to the ticket.


View larger

Products can be browsed by category. Selecting a category in the category list will refresh the product list view. Adding a product to a ticket is done by tapping the desired product. If the product is marked as Generic, Search tab is going to be opened filtering by tapped product children. The item that was last added to the ticket is selected by default.

By default products are marked as grouped products, it means that when a product which is already in the ticket is tapped the quantity of this line will increase. Having the product marked as "Not grouped" a new line with quantity 1 will be created.

Since RR15Q2: If product images are not being used, they can be hidden from search and browse tab using the preference "Hide Product Images in search and browse tabs". It will give more space to product description.

Since RR16Q3: Is possible to load product categories structured as a tree (hierarchical). See Product Category to configure a category tree

View larger

If the category has children, there is a expand [+] / collapse [-] icon button in the right.

Behavior of the tree


View larger
View larger
View larger

The search functionality is used to perform keyword searches. If necessary, the user can set a product category filter to reduce the amount of results or search by product characteristics.

The clear button (marked with an X symbol) is used to remove the current keyword filter and product characteristic filters too. In some browsers, such as Chrome, a microphone icon is shown inside the text field. Tapping it will let you enter the keyword by using human speech.

In the left side product characteristics are shown. Product Characteristics are values(Color:Red,Blue...; Size:40,42...) of a product to create(explode) different product from a Generic one.

Brand is going to be the first button always because it is a field of the Product and we can fill it whenever we want.

The remaining button will be characteristics owned by the product we have in our Assortment. Pressing in one of them, a modal will be shown with values linked to this characteristic.

The Characteristic modal show us all the values we are able to choose (values of the selected characteristic) and you can select more than one. Some of these values could have children. These children will be the same value as its parent but more detailded(Parent:Green, Child:Light Green). We can see a value's children tapping on the green triangle at the value line. If we are watching children we can go back to parent level tapping in the top left Back button. Selecting a value with children will filter by this value and all its descendants(all values in the tree below it).

When a value's tick icon is in light green means that some of its descendants is selected. Finally, when all values to filter are selected we must press Done button. Now, the characteristic buttons we used to filter are in yellow to know which are filtering and which not.

How to manage Product Characteristic is well explained in the following link:

By default products are marked as grouped products, it means that when a product which is already in the ticket is tapped the quantity of this line will increase. Having the product marked as "Not grouped" a new line with quantity 1 will be created.

Since RR15Q2: If product characteristics are not being used, Search by characteristics tools can be hidden using the preference "Hide Product Characteristics from search tab"

Since RR15Q2: If product images are not being used, they can be hidden from search and browse tab using the preference "Hide Product Images in search and browse tabs". It will give more space to product description.

Since RR15Q4: You can hide the filtering button of some product characteristics by unchecking Filter on WebPOS field on Product Characteristics window.

View larger

Since RR16Q3: Is possible to load product categories structured as a tree (hierarchical).

View larger

Push on categories combobox to open a modal dialog with category tree selector. If the category has children, there is a expand [+] / collapse [-] icon button in the right.

Behavior of the tree

Best Seller

Any product may be configured as a 'Best Seller' product. To configure them, go to "Master Data Management || Product Setup || Assorment" window. For each product list products can be configured setting its "BestSeller" property as selected.


All products with the "Best Seller" property selected are shown in Web POS as Best Seller products. These products are distinguished for having a highlight icon near to its name in BROWSER and SEARCH panels.

This image is located in array which allow to introduce different images, and its position is resized depending on the quantity.

Browser panel:


In browser panel is also a new category called 'Best Seller' with all best seller products included. Each of this products has the highlight icon, and they also have it in ther correspondign category.


Search panel:


PLM Status

Bulbgraph.png   This feature is available starting from 3.0RR18Q3.

Since the products have a life cycle in Openbravo, the process to sell them in a ticket has been altered. The different status can prevent some common flows in a sell flow. These are the two actions that can be restricted:

The next link shows how the status is configured in back-end:

Restrict Sale from POS

One of the attributes of the PLM Status if is possible to sell or not a product in the Web POS. If the selected status has the attribute checked, an user won't be able to sell that product in the Web POS. This means that the product is obsolete (or not even in the market).

Any product with this status is still loaded in the Web POS, and is possible to add it to do a return, or to use in any flow that doesn't mean a sell. When trying to add a obsolete product to a receipt, the next popup appears, no matter if the ticket is a layaway, a quotation or a receipt:

View larger

Restrict Sale Out-of-Stock

This attribute is, as its name indicates, to restrict to sale a product that is not in stock. This represents that the product is discontinued, and that will only be sold until there're existences in stock. The purpose of this is that the stock won't be replaced once finished. As in the previous sale restriction, it won't be possible to create a layaway nor a quotation, in addition to the receipt.

Each time a product is added to the ticket, the stock will be checked to, in case that there's not stock available, prevent to add the product to the ticket. The next popup is shown:

View larger

The popup tells how much stock is being required in the ticket and the existences. Also allows the user to continue with the action anyway, because there can be situations in which the stock is not correctly updated, and the client has the product in his hands. Moreover, if the product is added using the scanner the stock is not even checked (is absurd, because the product must be for scanning).

The stock is checked again when clicking in the total amount button, to navigate to the payments tab. The message shown will be exactly the same message shown when trying to add or modify a line without stock.

Offline Stock Validation

When trying to do the stock validation in offline mode a different popup appears telling that is not possible to check the stock:

View larger
Web POS Check Stock of Lines that are not Sold Without Stock

The Web POS Check Stock of Lines that are not Sold Without Stock preference activates or negates the stock validation when adding or modifying a line. The preference is set to 'Y' by default, so the lines modifications will be check by default. If the preference is set to 'N' the stock validation will only be done when clicking the total amount button.

Stock Validation in Pay Open Tickets

With the Pay Open Tickets menu entry, it is possible to synchronize a ticket without clicking on the total amount button, being possible to sell a product without checking its stock. To avoid it, a stock validation is also done when navigating to the Pay Open Tickets window. The discontinued products quantities are summed grouping them by product and warehouse, and the available stock is checked. If there's not enough stock, the same popup appears.

Using the scales

Products that are sold by unit of weight are placed on the scales before adding it to the ticket. When adding it to the ticket (either via scan, search, browse or UPC/EAN input), the total price is calculated as follows: weight x price per kilogram. For more information on how to configure products for weighing, see further down in this document.

Opening the drawer

View larger

The drawer is opened automatically when tickets are paid.

Since RMP29 we have also included a menu entry to do it. This menu entry can be hidden using a preference (OBPOS_retail.opendrawerfrommenu).

Bulbgraph.png   Note: Approval can be configured to open drawer. To do so there is a preference called Web POS Open drawer form menu

Also in RMP29 if the configuration is correct, the cash drawer is opened automatically in these cases:


View larger

The Edit mode is entered by tapping the Edit tab. By default the last product that was added is selected but tapping any other row in the ticket, selects it and brings up the edit mode for that item. The following can be edited:

The tap order to edit one of the above is as follows:

The quantity can also be changed using the + or - buttons.

Bulbgraph.png   Note: Approval can be configured for changing the price. To do so there is a preference called Web POS action Change price

Price Modification Reason

Bulbgraph.png   Note: This behavior can be enabled from RR19Q1

There is a new window called 'Price Modification Reason' that allows to configure some reasons for the price change. Once one or more reasons are configured the behavior will be enabled.

Once the price gets changed in WebPOS a popup will rise asking for the Price Modification Reason.

Viewing and printing paid tickets

Bulbgraph.png   Note: Starting from RR18Q1, a new modal selector has been added which replaces the old Receipts/Layaways/Quotations selectors. See here
View larger

This functionality lets the user find old (paid) tickets and print them. The flow of this functionality is simple. Paid tickets can be filtered by date and tapping one, shows the details in the ticket area.

Note: Receipts which contain products which are not included in the assortment anymore couldn't be loaded in old versions of the Web POS. This capability exists in RR16Q1 and subsequent versions. Similarly, it was not possible to load receipts for customers which are not loaded in the Web POS masterdata. This capability was added in RR16Q2.

Customer management and assigning to a ticket

New tickets by default have an anonymous customer assigned to them. This can be changed by tapping the customer name button at the top of the ticket which launches a customer picker dialogue where a known customer can be selected or, from the main menu, select the option "Customers". In both cases the customer selection window is shown.

Bulbgraph.png   Starting from RR17Q1 below functionality is available

Depending if you activate the preference "Enable Remote for Customer", the dialogue has one behavior or another.

Preference: Enable Remote for Customer (Enabled)

View larger

When the preference is enabled it shown a combo box and a text editor to filter by the customer or the address. The combo box have a list of filterable fields (customer or address).

Depending if field selected for the filter is from Customer or Address in result list are shown only the customer name or the customer name, the address and the filtered field.

Note: This behavior can be changed through the preference: WebPOS Filter Always BusinessPartner by Address.

Preference: Enable Remote for Customer (Disabled)

View larger

When the preference is disabled, it shows a text editor to filter by customer and address. If, after applying the filter, the returned customers have multiple addresses, then all addresses will be shown on a separate line. For each line the customer name, the address and icons to represent if the address are for shipping, invoicing or both are shown.

Advanced Filter

View larger

A new button is added to allow a more detailed search (Advanced Filter) . When click on this button will launch a more extensive search panel.

All available search-fields are shown and if entered a value, used as filter in the search. At the right of the text editor the following buttons are shown:

When click on button Apply Filters the dialogue is closed and the filters are applied.

Context menu

View larger
View larger
View larger

For each line in the filtered result it will have a context menu with following options:

Manage Address(es)
View larger
View larger
View larger

When select the context menu option Manage Address(es) will be shown a dialogue with all address for the selected customer.

For each address it will have a context menu with following options:

New Customer

View larger
View larger

When click on button New Customer the dialogue to create a new customer is opened. In addition to complete customer information also the address information can be completed. If you uncheck Use the same address for shipping and invoicing then you can enter differents shipping and invoicing addresses.

Don't forget to configure the defaults values for customer creation.

In case something is misconfigured, the customer will not be saved correctly. Try to find it in Business Partner window. If it has been an error go to Errors while importing POS data window.

Bulbgraph.png   Starting from RR15Q2 below functionality is available

Custormers defined On Hold on the backend are brought to WebPOS but they are not allow to be selected.

View larger
Bulbgraph.png   Starting from RR19Q1 below functionality is available

Customers can have secondary or alternative contact phone number. Therefore there is a new field “Mobile Phone” in the New or Edit Customer dialog to add it.

Allow Edit Anonymous Customer

Bulbgraph.png   This feature is available starting from 3.0RR13Q3.

From 3.0RR17Q3 is possible to allow or not to modify the anonymous customer or its address(es) depending on the Do not allow to edit anonymous customer preference. This property is not defined by default, so it will be possible to initially modify it.

Open multiple receipts

Bulbgraph.png   This feature is available starting from 3.0RR19Q2.
View larger

When you open the Customer Selector dialog box, a new contextual menu option will be available to allow you to open the Open Receipt Selector filtered with the selected Customer and allow a multiple selection of documents.

When you open the Customer Selector dialog box and click on the contextual menu, you will see the option: Related Documents

By clicking on the option: Related documents, the Open Receipts Selector will open, as shown in the following figure:

View larger

The selector is open with Advanced filter applied, setting the Customer field to selected customer line. You can change the Advanced filter to change the selection criteria.

You can select/deselect the documents you want to open. After completing the selection, press the Open Selected button to open all selected documents at the same time in the Web POS.

Customer View Improvements

Bulbgraph.png   This feature is available starting from 3.0RR19Q3.

The purpose of this customer view improvements is show additional customer information in the Customer Details , Edit Customer and New Customer forms, including transactional information such as customer receipt activity, as well as gift cards & vouchers information (in case gift cards module is installed).

View larger

View larger

It has been created a new preference for each new field as the way to allow that field is shown or not in WebPOS customer related forms.

View larger
View larger

Bulbgraph.png   This feature is available starting from 3.0RR20Q1.
View larger

As part of this new styling customer information is included in data Sections as the ones described below:

Customer Statistics

View larger
View larger

A new section has been added in the customer form called Statistics, it includes the most relevant customer statistics:

Statistics are only shown in customer form if have been previously configured in the backoffice.

Customer address management and assigning to a ticket

View larger
View larger

Once customer is selected, system will automatically fetch default address and assigning it to ticket. If customer has multiple address, this can be changed by tapping the customer address button at the top of the ticket (next to customer name) which launches a address picker dialogue where a required address can be selected.

The addresses will be for shipping and/or invoicing, and depending of address purpose and quantity of addresses, in receipt header are shown one or two buttons to address selection. Button with "icon truck" is for shipping address and buton with "note icon" is for invoicing address.

In this modal window, customer address are loaded automatically, which is read only at first. Tapping a address will get assigned to actual ticket. If customer have too many address, we can able to search customer address by name, filling the input text and pressing the magnifying glass button. Choosing New Address, new address can be added.

For each line in the filtered result it will have a context menu with following options:

See Manage Address(es) for menu items details.

Data Quality Management Integration in Customer and Customer Address

Bulbgraph.png   This feature is available starting from 3.0RR20.Q1

Infrastructure in Customer and Customer Address forms to support integrations to external providers of specialized solutions for optimizing data quality, data such as customer address, phone or email.

This infrastructure allow validations and suggestions, through webservice, a simple code function or a query to the database.

Suggestions and validations are shown on the customer and address forms if have been previously configured in the backoffice. How to create a Data Quality Management Provider

Cross store window for a product

OBPOS view cross store.png
OBPOS other store stock.png
OBPOS store stock detail.png

To enable this utility, the products must be properly configured.

After that configuration Cross Store window will be opened when a product is going to be added to the ticket for the first time.

Bulbgraph.png   Starting from RR16Q2 it is possible to decide stock from which warehouses it is wanted to show in Other Stores Stock button. These warehouses are named as Cross Channel Warehouses. Check how to configure it here

When product is added to the ticket this window is closed and quantity of the product can be changed in a standard manner using product´s catalog or numeric pad. In case it is required to open the Cross Store window again - select corresponding line in the ticket and press on the Check Stock button.

Bulbgraph.png   Starting from RMP32 below functionality is available
Bulbgraph.png   This functionality is disabled by default. To enable it, the preference Allow to select a warehouse for a specific line order must be set to 'Y'

If Cross store is enabled it is possible to select from which warehouse the product will be shipped (only store warehouses can be selected). The store stock popup shows details about the units stored for that specific product in each warehouse. If there is not enough stock on the selected warehouse the remaining stock will be shipped from another warehouse taking into account the priority order.

OBPOS store stock clickable.png

Prior to adding the product to the ticket it is possible to change the warehouse. To do so click Store stock button again and select a new warehouse. For adding the product to the receipt click Add to receipt button. The line is now associated with the warehouse and that information can be checked in the details of the line.

OBPOS warehouse line.png

When the line is created it is not possible to modify the warehouse, for changing the warehouse the line needs to be deleted and recreated.


Bulbgraph.png   Note: Starting from 15Q4 below functionality is available

Reservations are taken into account on stock's popups. The Quantity shown will be the Stock - Reservations.

Creating a new ticket

New tickets can be started at any time, even when another ticket is still pending. A new ticket is created by tapping the * button in the top left of the main navigation. Once the ticket is created, you can add products by tapping on any product button in either the Browse or Search tabs.

If you selected a product which doesn't exist in the current ticket, a new line for this product will be created. If there is a line for this product already, a new unit will be added to this line instead, except if the product has been configured as "grouped" (in this case a new line will be added).

Bulbgraph.png   Note: Starting from RR16Q2 it is possible to have both positive and negative lines containing the same product.

Editing ticket properties

View larger
View larger
View larger

To change or review a receipt property (Description, if it needs to be printed, its sales representative) go to the main menu and select Receipt Properties. Other way to change or view the receipt property is clicking on the Document Number of the active ticket:

Here the value of properties such as Description or Sales Representative can be changed.

Description Description is used for notes, references or other user generated meta data to the sales order.

Print This checkbox conveys whether the receipt is going to be printed or not after ticket completion.

Sales Representative In order to show this field we must active the Preference Web POS Sales Representative in Receipt properties window. Done this sales representatives will be shown in a dropdown list. In case of having lots of Sales Representatives, there is another preference Web POS Use Modal instead of dropdown in Sales Reprentative that allows to show sales representative using a modal window with the corresponding benefits such as performance and usability. The user's role must be Manual if you want the Preferences to be taken into account.

Line Description

View larger
View larger

A Line Description is a part of Line Properties. It can be considered meta data and is used for notes, references or exceptions specific to the ticket line. To add, modify or view a line description, select a ticket line, tap the EDIT tab and tap the Description button.

Split a line

When selecting a line with more than one unit a new button (Split) will be available in Edit panel.

View larger


Split line dialog

Split line operation can not be undone once applied.

First line of the dialog adds some summary fields:

Splitline 2.png

The default proposal always split line into two lines. You can modify default proposal by changing Number of Lines field. Keyboard can as well be used to increase or decrease number of lines pressing "+" or "-".

To be able to apply a line split proposal user needs to make sure difference is set to zero, which means all available quantity has been allocated in the proposed lines.

For example: Having a line of 8 units: Suppose we want to split it into 4 lines with quantities: 2, 2, 1 and 4. The sum is greater than 8, so Difference set to -1. The button Apply is disabled and dialog displays a warning message. When last quantity changes from 4 to 3 units the Apply button is enabled again and changes can be done.

Splitline 3.png

Use the button "x" to remove a line. When a line is removed Number of Lines is adjusted automatically.

Split lines

Once changes are applied, split lines will be marked in order to work as "not grouped" products. If the product is added to the ticket again (through BROWSE or SEARCH) , it will be added as a new line, if you add the same product several times those will be grouped in the new line.


It would order:

Parking and selecting pending tickets

View larger

Multiple tickets can be kept at the same time and new tickets can be started while a current ticket was not closed yet. If this is the case, the ticket that was edited last, while move to the background and a number (or a+1 increment of the current number) while appear in the top right folded corner of the ticket. These parked tickets can be re-activated by tapping the number in the folder corner. The user can now pick a pending ticket from the modal dialogue that was invoked.

Bulbgraph.png   Note: In order to print automatically a parking/suspended ticket there is a preference called Web POS Print suspended order

Deleting a ticket

The current ticket can be deleted by tapping the bin button in the main navigation. This action cannot be undone.

Bulbgraph.png   Note: Approval can be configured for deleting a ticket line. To do so there is a preference called Web POS Delete Line Approval
Bulbgraph.png   Note: Approval can be configured for deleting a ticket. To do so there is a preference called Web POS Remove Receipts Approval

Starting from RR16Q2, if the Web POS Save Removed Tickets preference is configured, removed tickets ad ticket lines will be stored in backend.

This preference will consider the following scenarios

If this preference is granted, the application will create Orders following the Web POS sequence:

Printing a receipt

Tickets can be printed at any time using two menu options. As it happens with all menu entries these can be deactivated using a preference

Very interesting menu option Print last Receipt that allows to print the last receipt paid

It is possible to define whether a ticket should be printed twice automatically per payment method. In order to do so go to Pos Terminal Type > Payment Method. There is a flag named Print twice. Starting 16Q2 version, this can also be configured at Pos Terminal Type level.

Returning products

There are two ways of returning products:

Bulbgraph.png   Note: Approval can be configured for returns. To do so there is a preference called Web POS Returns Approval

From original receipt

View larger
View larger
View larger
Bulbgraph.png   Note: This is a module
Bulbgraph.png   Note: This menu option can be hidden using the preference Return receipt menu option
Bulbgraph.png   Starting from RR15Q2 We are able to do not allow returning more than sold. Two columns are shown:
  • Tot. Qty: Quantity of the original order line
  • Rem. Qty: Remaining quantity is the units we can return. Sold quantity - Returned quantity

In case we have sold all units of the line, we will continue showing the line but we won't be able to select it.

Bulbgraph.png   Starting from RR15Q2 Lines of the order to be returned can be splitted in shipment lines if the shipment of the original order has more than one shipment line. In order to enable this functionality we need to activate Split Lines in Shipments when Returning preference.
Bulbgraph.png   Note: Receipts which contain products which are no longer part of the assortment can only be returned in RR16Q1 and subsequent versions.
Bulbgraph.png   Starting from RR18Q4 , the Verified Returns selector has been significantly improved, and now works correctly with high volumes of data, and supports more powerful filtering and sorting
Bulbgraph.png   Starting from RR19Q1 , a new preference called 'WebPOS Allow Price Modification in Verified Returns' allows to change the price of a Verified Return line if the returning amount is less than the original

Blind Receipt: Return the whole receipt

View larger
Bulbgraph.png   Note: If there are already return lines in the receipt this action cannot be performed and the option in the menu will be hidden
Bulbgraph.png   Note: This menu option can be hidden using the preference Web POS action Return receipt
Bulbgraph.png   Note: Since 15Q4 It will NOT be possible to have positive lines in return tickets.

Blind Receipt: Return a line

View larger
Bulbgraph.png   Note: This button can be hidden using the preference Web POS Show Action Button Return

Ability to have sales lines and return lines in the same ticket

Can only get this scenario using:

Once return lines are entered or switched from positive to return the user can keep entering sales lines

Bulbgraph.png   Note: When a receipt has positive and negative lines then the document is created in the backend as a regular sales order
Bulbgraph.png   Note: There is a preference to prevent having sales and returns in the same receipt. The preference is Not Allow Sales With Return
Bulbgraph.png   Note: This kind of orders cannot work as layaway
Bulbgraph.png   Note: This kind of orders cannot be paid through "Pay Open Tickets"
Bulbgraph.png   Note: Starting from RR19Q1, a new preference named "Save as return sale with 1 or more negative lines" has been included. If this preference is set, orders having positive and negative lines will be saved as return from customer document, not regular sales ordes.
View larger

Creating an invoice

View larger

On customer´s request, an invoice can be produced for a ticket following this sequence:

Invoice Terms

Bulbgraph.png   This feature is available starting from 19Q1.

Since 19Q1 release, WebPOS supports two new types of Invoice terms: After Delivery and After Order Delivered.

These can be configured in two different ways, in the backend:

Invoice Reprinting

Bulbgraph.png   This feature is available starting from 19Q1.

This functionality allows to print every invoice related to a ticket directly from Web POS, using a new menu entry. This is needed as there is no longer a one to one relationship between orders and their invoices. This new menu entry will open a popup which will allow the user to select one or more invoices to print, or directly print the receipt. This menu entry will replace the current 'Print this Receipt' button for closed tickets.

Printing a closed receipt and its related invoices

After loading a previously paid receipt in web pos, the flow to print the receipt is the following:

This will open a new popup allowing the user to select several invoices (if there are invoices related to that order) and print them, or directly print the receipt.

The new Print Receipt popup showing one invoice.
The new Print Receipt popup showing no invoices related to the order.
The Print Invoices button will be enabled after an Invoice is selected.

Bulbgraph.png   Note: The Print this Receipt menu option will be visible only if the Web POS action Print receipt preference is enabled for the current logged user

The Print Invoices button on the new popup will only be enabled if at least one invoice is selected to be printed.


Layaway is an agreement in which the seller reserves an item for a consumer until the consumer completes all the payments necessary to pay for that item.

Bulbgraph.png   Note: Starting from RR15Q2, layaways can be managed at organization level

Creating a New Layaway

View larger

Bulbgraph.png   Note: Starting from RR18Q2, It is possible to create layaways with negative lines if the preference Allow layaways with negative lines is set as Y. This kind of layaways cannot be partially paid

Finding an Existing Layaway

View larger
Bulbgraph.png   Note: Starting from RR18Q1, a new modal selector has been added which replaces the old Receipts/Layaways/Quotations selectors. See here

Complete a Layaway

View larger

Voiding a Layaway

View larger

Starting from RR16Q4, it is possible to configure the store to allow/deny the layaways' cancellation process if these have some associated payments. Navigate to the Organization window and check Allow partially paid layaways to be voided.

Anonymous Layaways

View larger

Starting from '16Q2 it wll be possible to configure if it is allowed to create layaways for the Anonymous Customer as explained here.

When the store is configured to deny creating anonymous layaways, an error popup will be raised when the user tries to lay away the receipt.

Paying a ticket

View larger

The payment flow is initiated by tapping the total amount in the main navigation. This enables the payment panel on the right hand side where the expected (remaining) amount is shown. Multiple payments can be used at once, using the payment method buttons on the left hand side of the numerical pad. The sequence of taps is as follows. First, the payment method is selected, e.g. card, tapping the Card button. Second, the amount is entered, e.g. 100. Finally, the Enter button is tapped to confirm the amount. The paid amount is shown in the top panel and can be removed by tapping the clear (X) button. Once the expected amount is exceeded, a message indicating the change to be given to the customer appears.

If the option Open drawer before closing ticket is checked in the POS Terminal Type window in the backoffice, an Open button will be displayed as soon as the amount paid exceeds the amount expected. Tapping it opens the cash drawer and a Done button will appear next. Tapping the Done button confirms the sale and prints the receipt.

If the option Open drawer before closing ticket is not checked, the Done button will be displayed directly (and the Open button will not appear). Tapping it confirms the sale, prints the receipt and pops the cash drawer.

In case something is misconfigured, the order will not be saved correctly. Try to find it in Saler Order window. If it has been an error go to Errors while importing POS data window.

In the backend, the payment methods used to pay the ticket are stored in Sales Order > Payment plan > payment details

Pay using percentages

Percentages can be used to pay an order. To take advantage of this feature just select the payment method and then insert the quantity followed by percentage symbol. The percentage is calculated based on the pending quantity to pay.

In this video you can check how it works.

Multicurrency feature

View larger

Change in another currency will create a negative transaction in this payment method financial account. In case of the selected method is not a "cash" type (we cannot give change with no-cash payments), the change is going to give back in the POS terminal currency.

Please take attention to the configuration, remember that it is necessary to configure both directions of conversion rate. For example:

USD -> EUR: 0.680272

EUR -> USD: 1.47

Multicurrency Change & Rounding

View larger
View larger
Bulbgraph.png   This configuration will be available starting from RR19Q1

When paying a ticket there is the option of returning the change in different currencies with rounding applied if desired.

Just in the same way change is displayed, both currencies will be shown on WEBPOS. There is also the possibility of amending the change in the different currencies with a pop up.

For example, configuration is set to return less than 1 EUR in CNY with rounding. In this case, if the change of a ticket sale is 1.41 EUR, WEBPOS will show 1 EUR+ 1700 CNY (0.41 EUR converted in to CNY is 1640 but with rounding 1700 CNY).

The impact of the rounding is the following:

• The rounding of a sale will be reflected as a new line in the Payment In. It will be associated to the GL Item configured as rounding and it will be positive or negative depending on if the rounding has been up or down

• Cash up report information will reflect amount with the roundings applied

More information can be found in the project guide

Paying several tickets at once

It is the availability to pay more than one Order at the same time. This functionallity has a preference for security settings.

Selecting orders to pay

View larger

First, we have to tap in the 'Pay Open Tickets' menu option. A modal will be opened where we will be able to filter(by text and date) orders that are pending to be finished(Layaways) and orders opened in the terminal in that moment(Except Returns, Paid Receipts and Quotations). Choose order to load and press Done.

Bulbgraph.png   Starting from RR17Q4 There will be a preference OBPOS_SelectCurrentTicketsOnPaidOpen that allows the automatic selection in this window of the currently open tickets
Bulbgraph.png   Starting from RR19Q1 This selector has been refactored in order to obtain a better performance with high volumes of data

New "Multiorder" View

View larger

On the left side we will see orders with its total and pending to pay amounts. Each order has a Delete button (with a X), this button will delete the order from the list of order to be paid. In the toolbar there is another Delete button (with a X too) and it will close this "Multiorder" view and will navigate to the normal one order view.

Layaway a order

View larger

In case of want to layaway some of these orders, we need to click on the order and in the modal shown, enter the amount to be layaway. If we do not want to pay anything of this order, just write 0 and it will be layaway without payments. To remove the amount to be layaway, we could open again the modal clicking on the order and do not enter anything and press Done. The order will become a normal order and we will pay the total amount. The amount to pay will change.

Finally, we should enter payments and finish the process as same as with one order.

Payment methods

The following payment methods are supported by default:


Different cash currencies are considered different cash payment types. If multiple currencies are used, Web POS will use one currency as the terminal currency and the other currencies as payment currencies.

View larger

The conversion between different currencies is done automatically. In the Payment Panel, the amount is showed in one currency and the conversion is shown in the other currency in parentheses. Using the Exact Amount button, Web POS will calculate the amount in the first currency and will show the conversion in the second. Prices of products and total to paid will be always in terminal currency.

View larger

The same occurs in the Cash Management dialogue. The amounts are shown in the terminal currency and the conversion in the alternative currency is shown in parentheses.

View larger
View larger

Similar to the the previous display, in the Cash Up process, bills and coins in the alternative currency are counted and are entered in that currency. This amount is then converted and added to the terminal currency.

In the Post, Print and Close step and on the final ticket, amounts will be shown in both currencies.

Credit card

Depending on the integration with external payment providers, different credit card types can be used directly from Web POS.


Vouchers are defined in the back office by store and financial account.

Other payment methods

Other payment methods can be set for the terminal in the back office, that will use additional buttons in the payment panel. Additional payment methods can be also available by installing, additional modules like [1].

In case that more than the available buttons are needed, a "More..." button will appear. By clicking this button a new pop-up will appear with the rest of payment methods.

Payment method hierarchy

View larger
View larger
View larger

Starting from RR15Q2 there will be the option of grouping different payment methods in one category. To do so:


View larger

An overpayment is a situation where the amount paid by the customer exceeds the expected amount and the difference cannot be given back fully in cash to the customer. This situation typically occurs when payment methods other than cash are used such as vouchers or a combination of cash and voucher. An example:

When there is an overpayments situation, it will be shown in the message area. In the Cash Up process the report shows overpayments in case they are greater than zero. Cash, by definition, cannot have overpayments. In case more cash is available than was registered, there will be a cash difference situation, that is also registered in the Cash Up process. An overpayment in the back office shows a summed lines amount in the Payment In Plan than the total gross amount in the header.

A payment method can be configured to allow overpayments or not, therefore an overpayment limit can be defined. In case that overpayment limit is exceeded then "Overpayment exceeded limit" message will be shown.

Using the Cash Pad

View larger

To quickly enter bills and coins denominations the bills & coins pad can be used. It shows localized cuts that represent commonly used localized cuts. This can save the operator time by reducing the amount of tap / clicks and reduces human error. For a customer that hands over one 100 and one 50 bill, the shop assistant only needs to tap to buttons before change can be given and there is no need for mental arithmetic. You can switch between the regular numerical pad and the bills & coins tap by tapping the bottom left toggle button that shows currency symbols.

Tax calculation

View larger

Taxes in Web POS can be configured to calculate the tax information following a document based criteria. This means to calculate the rate of taxes based on the total nets of the document. Or can be configured to calculate taxes following a line based criteria. This means that it computes the taxes for each line, and then aggregates them to calculate the total tax amount.
For more information about how to configure Web POS taxes calculation see Tax Rate window.

Bulbgraph.png   Starting from RR16Q2 Taxes can be calculated following a document based criteria or line based criteria. Previous versions only allow line based criteria, and in order for the system to work correctly Document Tax Amount Calculation should be set to Line base amount by rate.

Credit Sales

This functionality allows to complete orders leaving an amount without paying, or what is the same, leave it as credit.

To enable it, the Pos Terminal Type must be configured.

Also, the Credit Line Limit of the Business Partner must be greater than zero or the customer balance of the Business Partner must be lower than zero.

View larger

If these two conditions are satisfied, a button with label Use Credit will appear in payments section.

View larger

Tap the button if the pending amount is wanted to leave as a credit. This process will check against the backend the available credit of the business partner. This quantity would be the difference between Credit Limit and Credit Used. If this amount is greater than the pending quantity of the sales order a confirmation popup will be shown. Pressing "Yes, use credit", the order will be processed. Pressing "Cancel", this action will be canceled.

View larger

On the other hand, if the outstanding amount exceeds the available credit, an information popup will be shown giving the information of available credit of the business partner, and it will not allow completing the order.

Bulbgraph.png   Note: When receipt is paid using credit, automatically a invoice will be created related to this receipt. So, it will not be included in the invoice generated by cashup

Cash Management

View larger

In the course of the day, the store´s cash register accumulates cash and vouchers in the cash drawer. At certain points in time, it is recommended to do a cash withdrawal where an amount of cash (or vouchers) is removed from the cash drawer and placed in the safe or sent to the bank for deposit. Typically cash withdrawals are made in case of:

Cash withdrawals and deposits require a reason. Reasons are associated with financial accounts.

Deposits are the opposite of withdrawals. A deposit moves money from an external account to the cash register´s cash drawer. This is typically done in the morning before the store opens to make sure there is enough change in cash to serve customers. It is also common to keep a certain amount in cash in the cash drawer after the Cash Up process at the end of the day so there is a decent amount of cash available for the next business day. For more detail, see the next section about Cash Up.

You can configure account names and reasons in Cash Management Events.

Since RMP29 the cash drawer will be opened if the active payment method is marked as cash or it is configured to open the cash drawer.

Usage in smartphones

In smartphones and other devices with small screens, the Web POS will automatically switch to a one column layout, exactly as it happens with the main window.

View larger
View larger

Users will be able to switch back and forth from one column to the other by using the switch button in the toolbar, or by swiping the screen.

Cash Up

The Cash Up process is used to review pending tickets, count cash and other monetary assets, register differences and print the Cash Up report. This process is usually executed at the end of the day or shift and is part of every store´s standard processes. It helps management get insight in daily sales, returns, cash movements and differences. The Cash Up process consists of four steps:

Review Pending tickets

View larger

In this step all pending tickets are shown. Here you can manually delete the pending tickets. In case a ticket still needs to be paid, e.g. via a quick cash method, you will need to cancel the cash up process, return to this ticket and close the payment against it.

Bulbgraph.png   Note: Approval can be configured for deleting pending tickets. To do so there is a preference called Web POS Remove Receipts Approval in Cash Up

Cash counting

The second step requires you to count the cash and possibly other monetary assets.

View larger

For cash payment methods, you have to enter the counted amount entering the number of bank notes and coins for each denominations. This method helps the user that counts the money to avoid any mistake. To enter the number of bank notes or coins counted for each denomination you have two methods:

You have also actions to reset all quantities counted and start again, and to open the cash drawer.

View larger

For other payment methods, if the amount counted is different than the expected amount, you need to enter this amount as follows:

You can tap the green exact amount button (marked with a check mark) for counted amounts that match the expected amounts.

Since RMP29 the cash drawer will be opened when this screen is shown if one of the payments methods is defined as cash or it is configured to open the cash drawer.

Bulbgraph.png   Note: Approval can be configured to open drawer. To do so there is a preference called Web POS Open Drawer approval Cash Up
Bulbgraph.png   Note: Approval can be configured for continuing with the process if there are differences between the expected amount and counted amount. To do so there is a preference called Web POS Cash Up Differences Approval

Select cash to keep

View larger

The third step will ask you to decide on the amount of cash you want to keep in the cash drawer. This is a common practice for most stores to keep a certain amount to use as change the next day. You can configure this automatic deposit in the back office, see Cash Management Events.

In the case the payment method is configured to have only one option and the user does not have the possibility to decide the amount to keep the step will be ignored and it will be used automatically the only option available.

Print, close, post

View larger

In the final step a preview of the cash up report is shown for you to review before tapping the Post, Print & Close button that will withdraw, deposit and clear all payments, print the report and close the cash up process. A success message will pop up directly afterwards.

Agile Cash Up

Bulbgraph.png   This configuration will be available starting from RR19Q2

When a organization have a lot of payment methods will be possible to group for only used payment methods in Cash Up process.

View larger

Prior to being able to use the Agile Cash Up for Web POS, some configuration related to them needs to be done in back-office.

You will need to define the following preferences:

When using Agile Cash Up, the payment methods used are shown at the beginning. Once the payments are counted, let us continue without counting the unused payments.

View larger

When the preference CashUp - Remove unused payments from CashUp Report is defined, all unused payments methods are hidden from Post, Print & Close step of Cash Up process.

Cash Up History

View larger

In Openbravo ERP, Channel - Touchpoint window has a tab "Cash up History". Here we can see all the cash ups done and in progress by the selected terminal (User, date ... ). Selecting a cash up, we will be able to see two Buttons:

It has two subtabs "Cashup Tax Info" and "Payment Method Status Cashup".

When cashup information changes (a sale, a return, etc) and there is connectivity with the server, this information is synchronized automatically and creates/updates the records in this window.

Cash Up Tax Info
View larger

I shows the amount for each tax registered in the cashup process.

Payment Method Status Cashup
View larger

It shows the cashup information for each of the payment methods of the cashup. Here we can find fields like Starting cash for a given payment method, Total Sales Amounts, Total Returns, Total Deposits or Total drops.

Cashup History Window

Bulbgraph.png   Starting from RR19Q1 below functionality is available
View larger

In Openbravo ERP, Cashup Window we can see all the cashups displayed as well as related store and touchpoint information. This eases the process of checking cashup amounts for a whole store without the need of browsing each store touchpoint to gather each touchpoint cashup inofrmation.

This windows displays the same tab information than the cashup tab located in Channel - Touchpoint window, and incorpores filterable and sortable store and touchpoint information.

Usage in smartphones

As it happens in the main window and in the Cash Management window, the layout of this window changes in smartphones and other devices with small screens. In this case, the window changes to a one column layout, and the user can switch back and forth between the columns using the switch button in the toolbar, or by swiping the screen.

Bulbgraph.png   Starting from RR15Q3 below functionality is available

The cash up steps only appears if you have to do something on them. e.g.- If there are no Receipts pending to be closed that step will not appear.

Shared Payment Devices

If a Terminal Hierarchy has been created and there are some Payment Devices shared you will notice that the Cash Up process does not show any data from the shared Payment Device for the Slave Cash Up and it shows the total of the amount on the Cash Up of the Master Terminal.

A hierarchy of POS terminals can only do the cash up while being online. The reason for this is that information needs to be synchronized between the terminals in order to do the cash up for shared payment devices.

View larger

In general, it is needed to do Slave Cash Up first in order to do the Master Cash Up. However, starting 16Q2, it's not mandatory to do the cashup in the slave terminals if there wasn't any payment activity in them.

View larger

The Cash Up Process will not create the Invoices and the Reconciliations until the Master Cash Up is done.

Limit for approvals for count differences in initial cash count and cash up

Initial Count

When are doing the initial count before opening the store if difference exceed initial count difference limit for Cash payment method, you are asked for approval as shown the following figure:

View larger

Select a user to approve cash difference. Next you are asked for approval reason as shown in following figure:

View larger

In main menu select option Cash Up to open Cash Up window. Complete a count process and if a difference exceed Count Difference Limit you are asked for the approval reason. As shown in following figure:

View larger

Hide Cash Up Information to the Cashier

The preference that allows to hide some critical information of the cash up to the user is OBPOS_HideCashUpInfoToCashier. By default, this preference is set to ‘N’, in this state, the WebPOS works as usual.

Once the preference is activated (Value to ‘Y’), some fields from the cash up are hidden to the user. The information is shown as indicated:

View larger
View larger
View larger

Even if the preference is active, all the information is visible in the physically printed cash up.

To configure the preference, follow this link

Cash Up Partial

The Cash Up Partial process is very similar to the Cash Up process but it just prints the Cash Up report, it does not executes the Cash Up process in the server side. The report printed is the same as the Cash Up report but with a message to diferenciate when the backend Cash Up process is executed.


The Openbravo Web POS allows the user to create Sales Quotations, to view previously created quotations, and to create Sales Orders from quotations. These options are all available in the main menu of the application, if the quotations document type and the quotation prefix have been configured correctly in the POS Terminal Type, and the POS Terminal windows (more information can be found here).

Creating a Sales Quotation

View larger

To create a sales quotation, the user needs to select the option "Create Quotation" from the main menu. This will create a Sales Quotation. After this, the user needs to indicate which lines should the quotation contain, exactly like how he does it in receipts: he can use the product browser to pick products, or the scan tab to scan products to add lines. Like in receipts, the price or the quantity can be changed in every line.

Once the quotation is complete, the user must tap on the "Total amount" button to save the quotation. Obviously, the quotation doesn't need to be paid: a sales order will probably be generated from it at some point, and that document is the one which is paid instead.

Creating a quotation from an order
Bulbgraph.png   This feature is available starting from 3.0RR19Q1.

To create a sales quotation from an order, the user needs to select the option "Create Quotation from Order" from the main menu. This will create a sales quotation based on the order.

Create a quotation from a Layaway
Bulbgraph.png   This feature is available starting from 3.0RR19Q1.

To create a sales quotation from a Layaway, the user needs to select the option "Create Quotation from Layaway" from the main menu. This will create a sales quotation based on the layaway.

Create a quotation for an anonymous customer
Bulbgraph.png   This feature is available starting from 3.0RR19Q1.

There is a flag called 'Allow anonymous customer quotation' at the organization level in the back-end to allow create a sales quotation for anonymous customers.

Loading previously created quotations

View larger
Bulbgraph.png   Note: Starting from RR18Q1, a new modal selector has been added which replaces the old Receipts/Layaways/Quotations selectors. See here

A user can load any previously created quotation by selecting the option "Quotations" from the main menu. This option will show a window which can be used to search for quotations. The quotations can be filtered by document number or business partner, and also by creation date.

Once the quotations are shown, the user can tap on the quotation he wants to load.

Creating a sales order form a quotation

View larger

Once a quotation is loaded, the user can create a sales order from it by selecting the "Create sales order from quotation" option from the main menu. This option will display a popup, with a single checkbox: "Firm quotation". If a sales order is created from a firm quotation, the prices of the products will not be updated to the newest values valid today. However, if the quotation is not firm, the order will be updated with the current prices of the products, and the final total price of the sales order may be different from the original quotation.

Once the sales order is created, it works like any receipt in the POS: lines can be created, edited or deleted, and the receipt itself should be paid.

Reactivating a quotation

A quotation which is still in status "Under evaluation" can be reactivated. This process allows the user to modify a previously created quotation as long as it has yet to be used to create a sales order. This option is available in the main menu, under the name "Reactivate Quotation".

Once a quotation has been reactivated, the user can edit it normally, and can re-save it by clicking on the "Total amount" button.

Bulbgraph.png   Starting from RR15Q4 when a quotation is reactivated, a new one will be created with a new documentNo. The original quotation is marked as rejected

Printing a Sales Quotation

From the 2015Q1 release onwards it is possible to print a quotation from the menu. Select the 'Print this Receipt' with an opened quotation.

View larger

Reject Quotation

From the 2015Q4 release onwards it is possible to reject a quotation from the menu. Select the 'Reject Quotation' with an opened quotation. The application will ask for a reason that it is defined in the ERP in window 'Reject Reason'

View larger
View larger
View larger

Open Receipt Selector

From the RR18Q1 release a new selector has been added which can be used to load from backend different kind of documents (receipts, layaways, quotations). This new selector effectively replaces the old selectors.


The Open Receipt selector can be opened through the new menu entry Open Receipt. Clicking on the menu entry will open the selector on its simple search view. Clicking on the Advanced Filter button of the selector will open the advanced search view.

Simple Search

Open Receipt Simple Search

While on the simple search, the user will be able to filter by one criteria at a time. By default the Document Number filter is applied, and the user can change the filter using the available drop down. Using the simple search option will always sort by Order Date and Document Number (both descending) to show most recent documents first. The available possibilities to filter are:

Advanced Search

Open Receipt Simple Search

While on the advanced search, the user will be able to combine all previous filters in a single search.

Keep filters in Open Receipt Selector

Bulbgraph.png   This feature is available starting from 3.0RR19Q2.

After closing the open receipt selector and open it again, the previous applied filters will remain.

Keep filters in Business Partner selector

Bulbgraph.png   This feature is available starting from 3.0RR19Q2.

When you open the customer selector and apply a filter, it is maintained for the next search. After closing the customer selector and reopening it, the previous applied filter will be maintained.

The results

Open Receipt Simple Search

Once the required filtering criteria is applied, the system returns the list of receipts that match that criteria. The information shown for each document is the following:

Open Related Receipts

Bulbgraph.png   This feature is available starting from 3.0RR18Q2.

Open Related Receipts is a functionality that allows to open the not paid nor already opened orders (or layaways) of the business partner assigned to an order that is being opened, unless if the assigned business partner is the anonymous business partner.

Back-end configuration

There's a new flag in the Pos Terminal Type window called Open related receipts that enables this functionality.

Open Related Receipts Configuration

The Open Related Receipts functionality is called when opening an order from the order selector. When the user clicks on a ticket in the selector, the Web POS checks if the selected order is already opened, and if not it searches for the not paid and not opened tickets that belongs to the business partner assigned to the opening order. If there's any related order a popup appears with the list of those related orders, and allows the user to select the orders that wants also to open. By default, all orders are selected to be opened, and the user can unselect anyone before continuing. If the users clicks on the Cancel button or closes the popup, only the initial order will be opened.

Open Related Receipts Popup

In the popup, for each related order, the shown information is:

Multi Price List

From the RR15Q4 release it is possible to use multi price in Web POS.

View larger
View larger
View larger
View larger

Before it, it was not possible to have several price lists in Web POS. There was only one price list that was defined at a store level (Standard price list). The aim of this feature is to retrieve not only that price list but the ones explicitly defined for each business partner. If a business partner has no price list defined, the system will get the standard one.

There are three preferences related to this functionality:

Bulbgraph.png   This feature is available starting from 3.0RR18Q4.

A client can be related to a price list different to the default one.

When these preferences are active select a customer who has a different Price list defined in the backend: the Price List changes and products appear with prices from it.

Bulbgraph.png   This feature is available starting from 3.0RR18Q4.


Multiple Selection in Tickets

From the RR16Q2 release it is possible to use multi selection in tickets in Web POS.

Select multiples lines

To select multiple lines of the ticket, select a line normally or press the EDIT button. A "pin" button is displayed in the upper right part of the ticket (marked with a red circle in the figure below).

View larger

Click on "pin" button, to toggle selection mode to "multiple selection", a "pin" button turn to orange and show "Select All" button. See figure below.

View larger

From now:

Delete multiples lines

To delete multiples lines:

1. Select a line and press the EDIT button

2. Press "pin" button

3. Select other lines to delete

4. In EDIT window press "Delete" button

Most of the operations performed on the ticket can be undone, when working with multiple selected lines work as usual, in the SCAN window operations performed are displayed and has the "Undo" button to undo the changes. See figure below.

View larger

Return multiples lines

To return multiples lines:

1. Select a line and press the EDIT button

2. Press "pin" button

3. Select other lines to delete

4. In EDIT window press "Return Line" button

Change quantity to multiples lines

To change quantity to multiples lines:

1. Select a line and press the EDIT button

2. Press "pin" button

3. Select other lines

4. In EDIT window (Keypad) enter the new quatity do you want and press the button QUANTITY.

Change price to multiples lines

To change price to multiples lines:

1. Select a line and press the EDIT button

2. Press "pin" button

3. Select other lines

4. In EDIT window (Keypad) enter the new price do you want and press the button PRICE.

Increment/Decrement quantity to multiples lines

To Increment/Decrement quantity to multiples lines:

1. Select a line and press the EDIT button

2. Press "pin" button

3. Select other lines

4. In EDIT window (Keypad) press the button "+" or "-".

Note that the keypad "+" and "-" buttons should be enabled ONLY in the case the quantity be the same for all selected lines.

Apply a discount to multiples lines

To apply a discount to multiples lines:

1. Select a line and press the EDIT button

2. Press "pin" button

3. Select other lines

4. In EDIT window (Keypad) enter the discount do you want and press the button DISCOUNT.

Note: The preference "WEB POS Open Discounts From Keyboard" will be disabled

Keyboard special case: Ctrl + click

The equivalent (and intuitive) action for multiple lines selection using the keyboard is keep pressed Ctrl key while clicking the desired lines. If press Ctrl key and clicks (while pressing it) a non-selected line, this line should be automatically added to the selection. If press Ctrl key and cliks a selected line, this line shuold be automatically removed from selection.

Note that the "pin" button visualization (status) has not been affected at any time due to the Ctrl key press, so it should not be affected neither when the user does Ctrl key-up.

Keyboard special case: Shift + click

The equivalent (and intuitive) action for multiple lines range selection using the keyboard is keep pressed Shift key while clicking the desired lines that limit the range.

Note that the "pin" button visualization (status) has not been affected at any time due to the Shift key press, so it should not be affected neither when the user does Shift key-up.

Product On The Fly

From the RR17Q3 release it will have the possibility of creating new products “on the fly” through the Web POS. These new products will be used for an specific sales order and never will be re-used again. The products can be created into different ways:

All the related information can be found on the Product On The Fly

Product Services

From the RR16Q2 release it will be possible to configure and sell in Web POS services (products with certain product type defined) related to products and product categories.

All the related information can be found on the Product Services project

Cancel and Replace / Cancel Layaway

Bulbgraph.png   Starting from RR16Q4 below functionality is available

From the RR16Q4 release it is possible to do a Cancel and Replace of a ticket or Layaway and Cancel of a Layaway.

Cancel and Replace

The principal goal of this development is to allow users to modify already paid or reserved tickets. Instead of directly modifying the completed tickets what this process does is to cancel the original order and create a new one with all the goods present in the original order in draft status ready to be modified. This process at the same time creates a cancellation order copy of the original order but with negative quantities.

Check Openbravo ERP Cancel and Replace User Guide for more information related to data generated in backend for Cancel and Replace process

This process has the restriction that delivered products cannot be removed from the ticket, so in paid orders the ticket can only be modified to add new products, instead in reservations the user can add or remove (non delivered) products.

There is a button on the menu named “Cancel and Replace” visible for layaways and paid orders:

View larger

If the ticket has been already cancelled/replaced a popup is shown telling that a cancelled order cannot be cancelled/replaced.

View larger

If the ticket was not cancelled a new ticket is created copying the order and referencing it. As soon as the new order remains loaded at the terminal (not necessarily being the active one) the original order will not be able to be loaded to avoid situations in which the user adds payments which won’t be added to the new order too.

View larger

If new lines are added to the new ticket, or quantities are increased, the total amount of the ticket will be increased, and as for normal tickets. it will be necessary to pay completely the ticket, if it is not a layaway. This process takes into account what it was previously paid in Original ticket.

Cancel and Replace preferences:

Cancel Layaway

The main difference between "Cancel & Replace" and "Cancel Layaway" is that the cancel layaway process only cancels the ticket, so no new ticket is generated to replace the original. This implies that only a new inverse order is generated to cancel it.

Other important difference is in the inverse order. In cancel and replace process the inverse order was an exact clone of the original, and then the customer selects the payment method used to pay/return the difference generated by modifying the new order. In cancel layaway instead, the customer selects which will be the payment method used to negate the original order, if it previously had any payment. As happens with returns, an overpayment situation can be generated. The system controls that situations generating G/L item payments for those payments.

View larger

If the layaway was not already cancelled the Web POS treats the cancellation as a return, and the user must add payments until the partially paid amount is returned. The quantity amount to return may be returned in a different payment method than was paid before. The ticket shows also a label which indicates that is a layaway cancellation.

View larger

Cancel Layaway preferences:

Bulbgraph.png   Note: Starting from RR18Q2, It is not possible to cancel a layaway with negative lines. The reason behind this is that since it is not possible to have layaways with negative lines partially paid the correct way to proceed is by doing Void Layaway.
Bulbgraph.png   Note: Starting from RR19Q1, It is possible to define an specific template for this kind of document (Cancelled Layaway) in the Organization window under the field "Cancelled Layaway Template"
Cancel Layaway and New
Bulbgraph.png   This feature is available starting from 3.0RR18Q3.

Cancel Layawyay and New is a functionality to be able to create a ticket with the lines that have been canceled after doing a Cancel Layaway.

The preference Web POS Cancel Layaway and New controls if this functionality is active or not, being disabled by default.

The work flow is really simple. After canceling a ticket, if the functionality is enabled, a popup appears asking if the user wants to create a new ticket with the canceled lines/units (see the image at right):

View larger

This new ticket doesn't have any relation with the canceled one. The relations between products and services will be maintained, and if there was a deferred service, the new one will also be linked to the product that the old service was.

Reverse Payments

Bulbgraph.png   This feature is available starting from 3.0RR17Q1.


Reverse Payment (RP from now) is a new and very important functionality introduced in Web POS. This functionality was previously available for Openbravo ERP, so is important to include in Web POS too. To know more about the ERP functionality visit the next link.

With RP, a customer is allowed to return (or as the name explains, reverse) a payment of a ticket and change it to another payment type.

For example, a customer have bought a TV paying it by card, but accidentally the Web POS user has introduced and synchronized a cash payment. Before RP, to solve this situation was necessary to create a return ticket and create again a new one with the correct payment method. Now is possible to load the required ticket and directly reverse it.

Any payment that has been synchronized is ready to be reversed.

A reverse payment may be done even if the ticket has a related invoice or the cashup has been done. The new payments (payments generated to revert the original payments or the payments to introduce the new correct quantity) are introduced in the same invoice that the original payments are.

A preference has been implemented in order to enable or not the RV functionality: OBPOS_EnableReversePayment. It is configured by default as ‘Y’.

Reverse Payment Cases

RV is implemented for different situations:

RP for an already paid ticket. Before this implementation, a closed ticket couldn’t be modified in Web POS. Now all payments can be reversed but the final total pay amount must pay the ticket completely after closing it again.

The next example explains all clearly:

Open a paid ticket. After this development, the total amount button was disabled. Now the button is enabled, but with the difference that is light grey color (instead of green) which explains that this button doesn’t continue the default flow of the operation (as would be pay a newly created ticket).


Clicking in the total amount button the list of payments done for this receipt are displayed.


The ‘Done’ button is shown disabled, because if the ticket hasn’t got any modification it won’t be possible to synchronize the order.

Each loaded payment has a new button located at the right:


This button reverts the selected payment. This will create a new negative payment with the same amount than the first one. The original payment will be renamed to "* + original name" and the new payment will be named "original name + <*R>". For example, if the payment was "Cash", after reverting will be renamed to "*Cash" and the new negative payment will be named "Cash<R*>".

When trying to revert a payment, confirmation is required for:


And when confirmed the reversal payment is created:


The original payment has no more the reverse button because a reverted payment can’t be reverted again, and in the other hand the newly created payment now has a new button located at right:


This button cancels the payments revert and returns it to the previous status.

After reverting a payment the done button doesn’t appear because, as the image shows, there is a quantity remaining to pay, 150.50€ at this case. As previously explained, this quantity must be paid in order to complete the ticket again. This quantity can be generated by any number of payments, but the final quantity must be 150.50. If the final pay amount is over those 150.50€ because, for example, the customer only has a 200€ in cash or his/her card only can buy over 200, the rebased quantity will be shown in Web POS as change to give to the customer, or overpayment in case of card.

Reopening the ticket again will be the possibility to reverse the last payment, because the payment cancellation button is only shown before paying the ticket.

If the ticket is again opened all reverted and reversal payments will appear again, but they won’t be editable, what means in this case, it won’t be possible to revert or cancel them.

Changes in backend

When synchronizing the ticket after doing the RP, the new generated payments must be created in backend. Those payments are added to order where the RP has been done. So, before reverting the payment, if there was only one payment:


After doing it, there will be also the new generated ones:


The received and outstanding amount will never change during a RP.

The relation between the reversed and the reversal payments is maintained as occurs in the backend process (link added before).

No cash

There are situations in which there is no cash in the drawer during the reverse action. In this case, when reversing any type of cash payment a, red color label will be displayed telling that there’s not enough cash to revert the payment and the button to add payments will be disabled:


In case of selecting the ‘Cash’ payment method:


The ‘check’ button (the button to create a payment that pays the remaining amount with the selected payment method) is enabled because the Web POS allows to introduce a cash payment with quantity amount to the quantity reversed (even if has no sense to revert a payment and introduce again the same payment method) and the message that tells that there is no cash enough disappears.


First of all is important to know what a layaway is and how it works in Openbravo. The next link explains all information related to Layaways:

The workflow with layaways is very similar to full paid tickets with the difference that the final paid quantity can be lower, equal or higher than the previously paid.

All reverse buttons and methods works exactly as paid receipts, with the difference, as explained just before, that the ‘Layaway’ button is enabled all time to save the current layaway not being necessary to pay all ticket or leaving the remaining to pay at same quantity was before.


Payments in return tickets can be reversed as well. The workflow is exactly the same to paid receipts.

The only difference with common receipts is that as the return tickets have negative payments, so those negative payments will be shown as negative (unlike to occurs normally when introducing negative payments when doing a return) and the reversal payments (positive payments, because are the quantities that the customer pays to the Web POS user to revert a negative payment) are shown in positive

The following image shows the reversed payment of a returned ticket:

Not Anonymous Blind Returns
Bulbgraph.png   This feature is available starting from 18Q4.

From 18Q4 is possible to configure the application to not allow blind returns. There will be a new configuration option at Organization level that allows or disallows blind returns.

If deactivated this option, when creating a new blind return with an anonymous customer and tapping on “Done” a warning will appear saying blind returns is not allowed for anonymous customers and the operation will be cancelled.

Bulbgraph.png   The organization must be properly configured.

Login into Openbravo backend. Go to “Organization” window and select desired record. Uncheck field “Allow anonymous blind returns” Now the receipts attempts to be processed by anonymous customers will not be completed. However, if checked, the tickets creation process will be normally executed.


RP process can be done no matter if there’s or not an invoice created to this ticket. But, if exists, is important to carry the changes done during the RP to the invoice. The new generated payments must also appear in the invoice.

If the invoice was initially:


After doing the RP, the new payments are also created in the invoice:


As occurs with the order, the received and outstanding quantities don’t change.

'Cancel and Replace' and 'Cancel Layaway'

To know more about C&R and CL processes go to the next link:

During the C&R process is not possible to reverse payments.


The previous image shows that during a C&R process, the payments created in the order that is being canceled don’t have the button to reverse the payment. Once the process is finished, the payments will be available to reverse in the order that have been created.

Is also important to know that the netting payments created during the C&R and CL processes are not reversible. To revert those payments the user will have to go to the order in that those payments have been replaced and reverse the original ones.

Example 1: Cancel and Replace

There is a ticket with an ‘Avalanche transceiver’ product paid. The user wants to add a new ‘Insect repellent’ product to the ticket, so a C&R process is done:


During the C&R process, as commented before, is not possible to do the reverse payment of the payment that was originally generated.

This new order is fully paid and synchronized, having a payment of 150.50 and a payment of 14.50 of cash.

Loading the new ticket again:


There are two payments, one generated in this payment when synchronizing the new order during the C&R process, and the netting payment generated to refer to the original payment (generated in the original receipt before doing the C&R).

This second payment is not reversible for this ticket. To revert it the user will have to go to the original receipt:


And here the payment is reversible.

The inverse order always contains only the netting payment, so won’t never be reversible:


Example 2: Cancel Layaway

Partially paid layaway. Ticket with an ‘Avalanche transceiver’ unit with a cash payment of amount 50. This layaway has been canceled, and the remaining have been returned also in cash.

Loading the original receipt (after CL this ticket is a receipt):


There are two payments, the original one and the netting payment. As in C&R, the netting payment is shown with ‘Canceled’ label and is not reversible. The original payment is treated normally.

Loading the inverse order:


There are also two payments, the netting payment and the payment generated to return the money to the customer when the layaway had been canceled.

The netting payment is not reversible but the other payment can be normally revert, following the rules explained in a return receipt, as the inverse order is a negative order.

Web POS has the possibility to complete receipts without paying them, using the functionality to pay as credit. See more information in the current link:

This functionality also affects to RP.

Any quantity paid on credit doesn’t generate an associated payment, so there’s no possibility to reverse that quantity.

If a ticket is fully paid on credit, as there’s no payment related to the order, the total amount button will be disabled:


In the other hand, if a ticket is partially paid on credit:


The ticket is shown as partially paid on credit, and the quantity paid on credit is shown. The total amount button is also enabled (is in light grey color) and the payment list is also available to reverse. If those payments are reversed, the remaining quantity will be, as usual, the exact quantity of the payment (the amount paid on credit is not taken into account).

Any payment reversed will be added also to the generated invoice.

Reverse with Credit

There is also the possibility to revert a payment paying that part on credit. As the credit generated before, this new quantity paid on credit won’t be available to be reversed in the future. As each ticket paid on credit must have a related invoice, if a payment is reversed with credit, the reversal payment will be added to the invoice if exists, or will create a new one with them, and the received and outstanding quantities will be modified or created.

Not enough cash when reverting with credit

Previously there’s an explanation about how Web POS works when there’s no cash in the drawer and an user is trying to revert a cash payment. The ‘Use Credit’ button is also adapted to work with this logic:


In this image is visible that a cash payment is being reverted and the selected payment method is cash again. The ‘check’ button is enabled (as explained before), but the ‘Use Credit’ button is disabled. This is because there is a generated negative cash payment which cannot be returned (no cash to return), so there can’t be any possibility synchronize the ticket.

If the selected payment method is distinct to cash:


As the other buttons, the ‘Use Credit’ button must be disabled.

Reversible payments and number of days to reverse a payment

A payment method can be configured to be reversible or not. This configuration is done in ‘Point of Sale || POS Terminal Type’ window, in ‘Payment Method’ tab:


The ‘Reversable’ field tells if the payment method is or not reversible. A payment method with that field unchecked cannot be reverted. By default, a payment method is reversible.

The field ‘Available delay’, that is only shown when the ‘Reversable’ field is checked, stores the number of days that a reverse payment can be done since the payment was created. By default, the ‘Available delay’ is null for each payment.

If the ‘Available delay’ field is null, the payments of this configured payment method will be always reversible.

If the field is set to 0, it means that only can be reversed in the day that was paid, no matter the time in which has been paid.

If the field is set to any other number, the payment will be reversible during that number of days, until the last day has been finished. As in the previous case, doesn’t matter the time in which the payments had been done.

When an user tries to revert a non reversible payment the next popup appears:


And the process stops.

In the other hand, if the payment method is reversible but the number of days to revert have expired, an approval will be asked to continue with the process.

Selecting printers

Bulbgraph.png   Starting from RR17Q1 below functionality is available

In the Web POS by default the printer used to print receipts and PDF documents is the Main Terminal Printer defined by the Hardware URL in the POS Terminal window. If there are printers configured in the POS Terminal Type to print receipts or PDF documents, a different printer can be selected. In this case two new menu options appear: Select Printer to select a new printer to print receipts and Select PDF Printer to select a new printer to print PDF documents.

View larger

Also, when printing a receipt, if the printer fails, the dialog that informs about the situation and allow the cashier to try again, allows to select a different printer before retrying.

View larger

Note: The cashier must have configured properly the permissions preference WEB POS Select Printer to have access to the dialog that allows to select a different printer. This permission is granted by default.

Bulbgraph.png   Starting from 19Q2 below functionality is available

As well, there is a configuration at Touchpoint Type level that will allow selecting a different printer every time a document is going to be printed instead of selecting a different printer throw the main menu.

Support for attributes

This section holds the configuration required for performing a Sales or Return transaction using an instantiable attribute of the product in Openbravo WebPOS.

Bulbgraph.png   This feature is available starting from RR17Q3


Some products are identified in stock by instantiable attributes like serial number, lot number, expiration date and others. Any material movement of those products require the attribute information to be provided, so the stock is always informed about the specific attributes available. It allows better traceability and control.

Openbravo supports products identified by attributes. But current Openbravo Web POS does not allow to read attribute information when selling or returning, so the system decides (as per FIFO or other rules) which specific items (with specific attribute values) are shipped for any sale from Web POS.

The objective of this new feature is to allow reading attribute information from products sold and returned in Web POS, so this info is used for actual shipping based on the attribute values read from the items sold.


This functionality is just supported for instantiable attributes defined as mandatory.

Also there is a limitation if you are using a specific control for serial number or lot number.


1. Enable Preference: To be able to use this functionality a preference should be enabled. Go to Preference and search the Property = "Web POS Enable support for product attributes" and change the Value = Y.

View larger

2. Re-Login into Openbravo WebPOS to load new preference changes.


Sales Flow

When a product is selected (scanned or browsed) having an instantiable attribute, a popup will appear to input the attribute set value.

View larger

The value of an attribute should be syntactically correct. For example, if the attribute is defined as follows:

Example 1:
Attribute Name: Purchase Lot
Lot: Y
Serial No. : Y
Expiration Date: Y
Then a valid attribute set value can be: LSEP06_#6969_15-10-2018

Example 2:
Attribute Name: Purchase Serial No
Serial No. : Y
Expiration Date: Y
Then a valid attribute set value can be: #6969_15-10-2018

Once the attribute set value is scanned, the entered attribute set value is displayed in the ticket lines. While synchronizing the order if the attribute set value entered by the user is not available in the back office, the attribute set is created and associated with Sales Order and Goods Shipment.

Stock Validation

If the Enable Stock Validation preference is enabled, the validation of the stock will be done using the attribute set value entered by the user.

View larger

Return Flow

When a Verified Return transaction is created, the attribute set value is loaded from the Sales Order if it was used while creating an order. A popup is raised for the user to scan the attribute set value which will be validated against the Sales Order.

View larger

Once the attribute set value is entered a visual feedback is provided to the user by changing the background color of the text field. Green or Red signifying if the value entered matches with the Sales Order or not. Until all the values entered are correct the user cannot proceed with the flow.

View larger

When a blind return is performed, the attribute set value entered by the user is created in the back office while synchronization of the blind return order.


When converting a Quotation to Sales Order, the user should provide the attribute set value for the product.

To use this feature you need to enable a preference named Web POS Ask for attributes when Quotation to the Sales Order.

Once the preference is enabled, you will be asked to enter the attribute value for the product while converting the Quotation to the Sales Order.

View larger

Attributes in Layaways

Bulbgraph.png   This feature is available starting from RR18Q1

Starting from RR18Q1, it is possible to:

View larger

View larger

Cross Store Operations

Bulbgraph.png   This feature is available starting from 19Q2.

Enabling Cross Store operations, it will be possible to pay and return in one store a product purchased in a different store.

It will be also possible to sale in one store a product not present in this store but in a different store.

Delivery Modes

Bulbgraph.png   This feature is available starting from 19Q3.

Delivery Modes is now available in Web POS through a new preference called "Web POS Enable Delivery Modes".

Working with the back office

Openbravo for Retail uses one single database that can be accessed via both front (e.g. Web POS) and back end (e.g. Openbravo 3) user interfaces. In this section you will be shown how users can take advantage of this architecture. First of all, all information in the back office is accurate in real-time as transactions are processed as they occur (an exception to this is when a connectivity outage occurs, which can cause delay). Secondly, the back office is web based (as is the front office) which allows remote and mobile users view store performance from anywhere. Here is an overview of the most important back office views and how to use them:

Sales orders

View larger

This window gives a real-time view into the sales transactions in the stores. By default sales orders for all organizations (stores) are shown in the grid so the first thing you want to do is to filter the organization column for one or maybe a few specific stores. See the Column Filters section in the User Interface Introduction for Openbravo 3 for more detail on filtering. If you plan to use a certain view more often, you may want to save it. See the Saving Views documentation for more detail.

In the Lines child tab you can find the order lines and in the Payment Plan and payment details (child of payment plan) tabs you can view which payment method(s) were used to pay this ticket.

Note that you need to refresh the grid using the Refresh button in the toolbar to see the incoming orders appear.

Bulbgraph.png   Starting from RR15Q2 below functionality is available

If oBPOSNotInvoiceOnCashUp flag is set to Y the sales order won't be invoiced during Cash Up Process.

Backend Data Processing: Data Import Entries

Bulbgraph.png   Starting from RR15Q3 below functionality is available

View larger

All the transactions created in Web POS are send to the backend server for processing. These includes:

The transactions from Web POS go through a three step process:

This multi-step process ensures that the communication from WebPOS to the backend is fast and robust. Transactions are quickly stored in a fast table and processed in parallel based on server capacity. For a developer how-to see this page.

Data is mainly processed in parallel by type of data and organization, so different types of data of different organizations is processed in parallel. Each separate process is called a task. So orders of organization A and organization B are done in parallel, but also business partners of organization A and orders of organization A are done in parallel. There are internal checks done to ensure that data is processed in the correct order.

You can find the currently being processed data in the Data Import Entry table. Data which has been processed can be found in the Data Import Entry Archive table.

View larger

When you open the Data Import Entry tab then initially only Initial and Error records are shown (see the filter symbol on the far right).

The following fields are shown:

Bulbgraph.png   When an entry is in Error state you can let the system process it again by manually setting it back to Initial. Periodically the system will pick up Initial records and try to process them again. You can force the system to start processing right away by going to the 'Direct Process Import Entries' function in the menu and pressing the Done button. This function will also show the number of active and queued tasks.

View larger
Bulbgraph.png   When an error occurs in the detailed processing of a record then this error record can be found in the POS Import Error table. See the next section.

Import Entry High Availability

Bulbgraph.png   This feature is available starting from 3.0PR18Q2.

When working in a clustered environment, it is possible to configure the import entry processing as a high available service.

Errors while importing POS data

View larger

This window gives a real-time view into the errors importing data from Web POS. In case of something is wrongly configured, you can get an error loading data in Openbravo ERP. In this window, you can find information about these errors.

Bulbgraph.png   Note: Starting from RR15Q3, there is available a new process background Sync All Errors While Importing. It can be scheduled to try to sync periodically all records not synchronized of this window

Sales Invoices

In a similar fashion as for the sales order window, you can view sales invoices in the back office that were generated via the Web POS. Note that there will be much less invoices than orders because by default an individual POS sale does not generate an individual invoice, but instead after the Cash Up process, one grouped invoice for all sales orders will be created. On customer request though, an individual sales invoice can be created in the Web POS GUI by marking the ticket as such. This is done by selecting Invoice this Receipt in the more menu in the navigation. The sales invoice will appear in the sales order window in the back office.


View larger

Each completed POS sales order creates one or more Payment In documents, depending on the number of payment methods used. If a ticket is paid using two different payment methods, then it will also create two different payments. The Payment In window in the back office provides insight in the different payment types used during a period of time, store or amount. Trying different columns filters and saving them as different views is an easy way to perform some basic sales analytics.

Goods shipments

Each completed POS sales order generates a Goods Shipment document for the products that were sold.

Return from Customer

View larger

Returns are common and are supported in Openbravo for Retail. Using the Web POS GUI the flow for customer returns is as follows:

After having done the above, the back office now has generated the following documents:

Financial accounts

View larger

Financial accounts are defined by store and payment method. Then, there will be also one cash book for the store and one for the back office and the same for credit card and possibly other payment methods. All payments, deposits and withdrawals are registered here and the current balance for each account is shown in the header. Here, good practice is also to set column filters for the different stores, payment and periods and save the views.


Openbravo´s standard reports can be used for retail:


Added a new flag "Use on WebPOS" in the Characteristic definition to disable it in the WebPOS. If the flag is deactivated the characteristic and any of its values are not uploaded to the POS.

Some warning messages are shown, if the flag is unchecked and a discount or promotion is applied to the characteristic of a product, warning will say that discount will not apply to the products.

Offline Operations

Bulbgraph.png   Note: When one or more modules in your instance are set to be in-development then Openbravo disables offline mode. This to support developers working with Openbravo.

How offline mode works

View larger

The Web POS supports offline functionality. This means that if you lose connection to the server, you can still execute several common tasks, such as creating new receipts, doing cash management movements, or executing the cash up process. You can even log in the application using the normal login page.

Once the connection to the server is restored, all the created documents (receipts, cash management movements, cash ups) will be automatically synced with the backend if your session is still active, and if not, you will be prompted to log in again in the application so that everything can be synchronized.

This feature of the Web POS relies on several HTML5 technologies such as the application cache and the WebSQL local database. The Web POS uses these to store internally both the information that needs to run, and the information the user generates while being offline. Therefore, it's very dangerous to delete the browser cache, because some browsers and devices delete the local database when you do it, and in this case some of your data (tickets, cash ups, ...) may be lost. We will now explain a bit how the Web POS uses the local database, and how to avoid mistakes.

Bulbgraph.png   Starting from RR18Q1 offline mode has been improved
View larger

In newer versions of the WebPOS, offline mode has been improved to work better in unstable networks and in the event of failure in the central server. From 18Q1 onwards, the WebPOS controls the transition back to online and executes it only when it is sure that it can be completed. The main purpose of this change is to ensure a better and more consistent user experience in the case the connection to the backend is not reliable.

The state of the transition to online can be monitored by a new menu item and it can also be forced in the case of some emergency that would require to execute some functionality that requires online operation immediately. More information about these changes can be found here

You can also define a default timeout setting the Preference: Default Request timeout.

Bulbgraph.png   Starting from RR18Q4 offline mode has been improved

Two new configurations has been added for offline operations

1.- Limit the time WebPOS could be in offline

A new preference has been included to activate this functionality called "Web POS Maximum time which the terminal can be offline".

This preference sets the maximum time (in minutes) in which the terminal can be offline. If this time is reached, the application is locked until the connection comes back.

By default, there is no preference set and should be configured at System level in each instance.

2.- Define the time WebPOS sessions is valid in offline.

A new preference has been included to activate this functionality called "Web POS Offline session time expiration".

This preference sets the time (in minutes) in which the terminal current session is valid in offline. If this time is reached, if the application is reloaded, the webPOS navigates to login page. If this time is not reached and the application is reloaded, the application navigates directly to default webPOS tab.

By default, the preference is set to 60 minutes.

The local database: how the Web POS uses it and when it's safe to clear the browser cache

The Web POS uses the local database to store all the information the user generates. Specifically, it stores receipts, new customers, cash management and cash up information. The Web POS begins storing information here as soon as the user logs in the application, because it creates a new "till" every time the user logs in after the last cash up has been done.

The local database is part of the cache of the browser. You clear/delete the local database when you clear the browser cache. In combination with offline working: the browser cache should not be cleared in case the cash up has not yet been completed, even if all the tickets have been synchronized with the backend. If you clear the browser cache, deleting the local database then the cash up (and other not-yet-synchronized) information is lost.

This guideline is very important, because it means that payments will not be reconciled, even though they were saved correctly in the backend, if the local database is wiped out before the cash up is done.

Just after doing a cash up, it is safe to delete the local database, before any other document is done (so, until a new receipt, customer, or cash management movement are created).

Note when the Web POS is updated it is most of the time not needed to clean the cache.

Login offline

In addition to the main basic features of the Web POS, the login itself can also be done offline. However, it's important to understand that the Web POS will only allow users which have already logged in online mode to log in offline mode. Therefore, if you need to provide offline log in mode for a given user, you need to ensure that this user logs in every terminal he will need to log in while this terminal is online.

Features supported in offline

View larger
View larger
View larger

The following list of features are supported in offline mode:

All the data generated by the user (receipts, customers, cash ups, ...) will be automatically synchronized with the backend when the connection comes back. Most of the times the user doesn't need to execute any additional action for this to happen. In some cases, the session which the user had may have expired in the backend when the connection comes back. In this rare cases, the user will be prompted to log in the application again to ensure that the session is valid, so that the data can be automatically synchronized.

Since RR15Q2: If there are transactions pending to be synchronized a red sign is shown in the top-left corner. While this symbol is present, a new menu entry is available to see pending to synchronize documents. When Web POS is synchronizing data, the sign is blue and rotates and it is still possible to see what is pending to synchronize with this information updated in real time.

Restrictions of functionality while offline

Most of the basic functionality in the Web POS is supported while being offline. However, some actions (particularly those which need data which is not stored in the terminal) cannot be executed when the connection is down. A non-complete list of actions which do not work while being offline is:

Hardware restrictions of offline mode

The amount of data that can be processed while offline depends on the hardware and browser. The worst case is Safari on an iPad which has a physical database size limit of 50MB. At the rate of 4 orders with 10 lines per minute, it will take you three days to fill it. On the higher end of the spectrum, it will take more than two years to fill 10GB on a Samsung Galaxy Tab or more than four years to fill 25GB on a Asus Eee Slate EP121. Read more about offline operations in this blog post.

Web POS Updates

Available in the 2015Q1 release and later: When the Web POS system is updated on the server side the client side will automatically detect this when data is synchronized or when the user logs in. The user is presented with a dialog below.

View larger

The application will automatically refresh after the user clicks 'OK'.

Available in the 2015Q2 release and later: Warning users when Web POS system is in development mode. This means that some functionalities, such as offline operation, are currently disabled. This mode is not intended to be used in production instances. The user is presented with a dialog below, pressing the red button in the right side.

View larger

Questions? Contact us. We can help you!

If you have further doubts, we are happy to answer all your questions and get you set up. Simply fill out the form here, or for immediate assistance, call us on the phone numbers there.

Retrieved from ""

This page has been accessed 187,332 times. This page was last modified on 8 November 2019, at 13:53. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.