Retail:Web POS User Guide

Back to main page

Contents 1 Introduction 2 See Openbravo Web POS in action 3 Launching Web POS 4 Web POS GUI overview 4.1 Login Page 4.2 Main layout 4.3 Ticket area 4.4 Message area 4.5 Numerical pad 4.6 Tabs 4.7 The menu 4.8 Shortkeys 5 Main Flows 5.1 Login 5.1.1 linking the device 5.1.2 Setting a new password 5.2 Scanning 5.2.1 RFID 5.2.1.1 Add Product 5.2.1.2 Remove Product 5.2.1.3 Disable/Enable RFID Reader 5.3 Manual entry 5.4 Browsing 5.5 Searching 5.6 Best Seller 5.7 PLM Status 5.7.1 Restrict Sale from POS 5.7.2 Restrict Sale Out-of-Stock 5.7.2.1 Offline Stock Validation 5.7.2.2 Web POS Check Stock of Lines that are not Sold Without Stock 5.7.2.3 Stock Validation in Pay Open Tickets 5.8 Using the scales 5.9 Opening the drawer 5.10 Editing 5.10.1 Price Modification Reason 5.11 Viewing and printing paid tickets 5.12 Customer management and assigning to a ticket 5.12.1 Preference: Enable Remote for Customer (Enabled) 5.12.2 Preference: Enable Remote for Customer (Disabled) 5.12.3 Advanced Filter 5.12.4 Context menu 5.12.4.1 Manage Address(es) 5.12.5 New Customer 5.12.6 Allow Edit Anonymous Customer 5.12.7 Open multiple receipts 5.12.8 Customer View Improvements 5.12.9 Customer Statistics 5.13 Customer address management and assigning to a ticket 5.14 Data Quality Management Integration in Customer and Customer Address 5.15 Cross store window for a product 5.15.1 Reservations 5.16 Creating a new ticket 5.17 Editing ticket properties 5.18 Line Description 5.19 Split a line 5.19.1 Constraints 5.19.2 Split line dialog 5.19.3 Split lines 5.20 Parking and selecting pending tickets 5.21 Deleting a ticket 5.22 Printing a receipt 5.23 Returning products 5.23.1 From original receipt 5.23.2 Blind Receipt: Return the whole receipt 5.23.3 Blind Receipt: Return a line 5.23.4 Ability to have sales lines and return lines in the same ticket 5.24 Creating an invoice 5.25 Invoice Terms 5.26 Invoice Reprinting 5.26.1 Printing a closed receipt and its related invoices 5.27 Layaways 5.27.1 Creating a New Layaway 5.27.2 Finding an Existing Layaway 5.27.3 Complete a Layaway 5.27.4 Voiding a Layaway 5.27.5 Anonymous Layaways 5.28 Paying a ticket 5.28.1 Pay using percentages 5.28.2 Multicurrency feature 5.28.3 Multicurrency Change & Rounding 5.28.4 Payment Rounding 5.29 Paying several tickets at once 5.29.1 Selecting orders to pay 5.29.2 New "Multiorder" View 5.29.3 Layaway a order 5.30 Payment methods 5.30.1 Cash 5.30.2 Credit card 5.30.3 Vouchers 5.30.4 Other payment methods 5.30.5 Payment method hierarchy 5.31 Overpayment 5.32 Using the Cash Pad 5.33 Tax calculation 5.34 Credit Sales 5.35 Cash Management 5.35.1 Usage in smartphones 5.36 Cash Up 5.36.1 Review Pending tickets 5.36.2 Cash counting 5.36.3 Select cash to keep 5.36.4 Print, close, post 5.36.5 Agile Cash Up 5.36.6 Cash Up History 5.36.6.1 Cash Up Tax Info 5.36.6.2 Payment Method Status Cashup 5.36.7 Cashup History Window 5.36.8 Usage in smartphones 5.36.9 Shared Payment Devices 5.36.10 Limit for approvals for count differences in initial cash count and cash up 5.36.10.1 Initial Count 5.36.10.2 Cashup 5.36.11 Hide Cash Up Information to the Cashier 5.36.12 Kept Cash Report 5.37 Cash Up Partial 5.38 Quotations 5.38.1 Creating a Sales Quotation 5.38.1.1 Creating a quotation from an order 5.38.1.2 Create a quotation from a Layaway 5.38.1.3 Create a quotation for an anonymous customer 5.38.2 Loading previously created quotations 5.38.3 Creating a sales order form a quotation 5.38.4 Reactivating a quotation 5.38.5 Printing a Sales Quotation 5.38.6 Reject Quotation 5.39 Open Receipt Selector 5.39.1 Usage 5.39.2 Simple Search 5.39.3 Advanced Search 5.39.4 Keep filters in Open Receipt Selector 5.39.5 Keep filters in Business Partner selector 5.39.6 The results 5.39.7 Open Related Receipts 5.39.7.1 Back-end configuration 5.39.7.2 Usage 5.40 Multi Price List 5.41 Multiple Selection in Tickets 5.41.1 Select multiples lines 5.41.2 Delete multiples lines 5.41.3 Return multiples lines 5.41.4 Change quantity to multiples lines 5.41.5 Change price to multiples lines 5.41.6 Increment/Decrement quantity to multiples lines 5.41.7 Apply a discount to multiples lines 5.41.8 Keyboard special case: Ctrl + click 5.41.9 Keyboard special case: Shift + click 5.42 Product On The Fly 5.43 Product Services 5.44 Cancel and Replace / Cancel Layaway 5.44.1 Cancel and Replace 5.44.2 Cancel Layaway 5.44.2.1 Cancel Layaway and New 5.45 Reverse Payments 5.45.1 Introduction 5.45.2 Reverse Payment Cases 5.45.2.1 Paid tickets 5.45.2.2 Layaways 5.45.2.3 Returns 5.45.2.3.1 Not Anonymous Blind Returns 5.45.3 Invoices 5.45.4 'Cancel and Replace' and 'Cancel Layaway' 5.45.5 Paid on 'Credit' 5.45.6 Reversible payments and number of days to reverse a payment 5.46 Selecting printers 5.47 Support for attributes 5.47.1 Objective 5.47.2 Limitations 5.47.3 Configuration 5.47.4 Usage 5.47.5 Sales Flow 5.47.6 Stock Validation 5.47.7 Return Flow 5.47.8 Quotation 5.47.9 Attributes in Layaways 5.48 Cross Store Operations 5.49 Delivery Modes 5.50 Safe Boxes 6 Working with the back office 6.1 Sales orders 6.2 Backend Data Processing: Data Import Entries 6.2.1 Import Entry High Availability 6.2.2 Logging Import Entry Manager status 6.3 Errors while importing POS data 6.4 Sales Invoices 6.5 Payments 6.6 Goods shipments 6.7 Return from Customer 6.8 Financial accounts 6.9 Reporting 6.10 Characteristics 7 Offline Operations 7.1 How offline mode works 7.2 The local database: how the Web POS uses it and when it's safe to clear the browser cache 7.3 Login offline 7.4 Features supported in offline 7.5 Restrictions of functionality while offline 7.6 Hardware restrictions of offline mode 8 Web POS Updates 9 Questions? Contact us. We can help you!

Introduction

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.

• The Openbravo back office GUI is simply launched by entering the standard application URL in the web browser´s address bar: http://<IP_address>/openbravo.
• Openbravo Web POS is also launched by entering a URL in the web browser. This URL is constructed the following way
  • If Terminal Authentication is enabled-->http://<IP_address>/openbravo/web/org.openbravo.retail.posterminal/
  • If Terminal Authentication is not enabled-->http://<IP_address>/openbravo/web/org.openbravo.retail.posterminal/?terminal=<POS Terminal ID (Search Key)>.

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.

• To activate full-screen mode in Android and iOS devices, open the browser (Chrome or Safari and navigate to the Web POS login page. Open the menu and select Add to homescreen. A new icon will be created in the homescreen for the Web POS. Tap on this icon and Web POS will be executed in full-screen mode.
• For the Chrome web browser press F11 to activate the full-screen mode.
• For Safari in OSX desktop machines press ⌘^F to activate the full-screen mode.

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:

• Orange: The user had an open session, and then selected the "Lock screen" option from the menu.
• White: The user doesn't have a session active in this terminal.

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.

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.

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 "Y" the following preferences:

• WebPOS Disable Browse Tab
• WebPOS Disable Search Tab
• WebPOS Disable Edit Tab

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.

• Tax Breakdown: The list of taxes applied in the order is shown here.

• Payment Breakdown: The list of payments of the order is shown here only when the order is a Paid Receipt or a Layaway.

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.

The discount key can be configured:

• to use discretionary discounts (by default)
• to apply a discount directly to the line selected (a new preference with the property 'WEB POS Open Discounts From Keyboard' with value 'N' should be created)

Tabs

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:

• Online status: conveys the connectivity status of the system. A green dot indicates that the system is online, a white circle indicates that the system is offline. This option also allows the user to lock the screen, or log out of the application.

• User option: this shows a popup with the currently logged user information. In this popup, you can also see the complete "profile" information, which shows the current role and language, and allows the user to change them and even set them as the default value for that user.

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.

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:

• Profile (to see and change the role)
• Lock screen
• End Session

Shortkeys

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:

• 0 - 9: Adds that number to the text area
• A - Z: Adds that letter to the text area
• Backspace: Removes a character off the text area
• Enter: Executes the entry in the text area
• +: Adds one unit of the selected product
• -: Substract one unit of the selected product. If the units of the product reach 0, the product is deleted off the receipt
• Del: Deletes the selected product off the receipt
• 0 followed by enter: Lock the screen

Main Flows

Openbravo Web POS supports the following main flows:

• Login
• Scanning
• Manual entry
• Browsing
• Searching
• PLM Status
• Using the scales
• Editing
• Back office
• Assigning a customer to a ticket
• Creating a new ticket
• Editing ticket properties
• Parking a ticket
• Deleting a ticket
• Printing a ticket
• Returning a ticket
• Invoicing a ticket
• Paying a ticket
• Tax calculation
• Cash management
• Cash up

Login

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.

• If security is not enabled we need to put the terminal searchKey in the URL.
  • Access URL --> <IP_address>/openbravo/web/org.openbravo.retail.posterminal/?terminal=<POS Terminal ID (Search Key)>

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

• If security is enabled, every device will use the same URL. In the first time that this URL is accessed from a terminal, the system will require to link the device to the POS terminal. Once the link is ready, this URL will provide to the user a direct access to the linked terminal. This behavior will remain until the terminal is unlinked or the cache is cleared.
  • Access URL --> <IP_address>/openbravo/web/org.openbravo.retail.posterminal/

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: This value is defined in the ERP (POS terminal window). Every terminal shoul have the field <<Terminal key identifier>> filled. If this field is not filled this terminal will can't be linked.

• User/password: These fields just are required to ensure that the person who is linking the device is a valid user. This user will not be used to log in the Web POS. The credentials provided should correspond to a user who has access to the selected terminal.

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.

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.

Scanning

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.

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.

RFID

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:

• Undo add line
• Delete line
• Undo delete line (This will add the EPC again to Hardware Manager's buffer)
• Remove ticket
• End session

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:

• Green:The RFID reader is connected and enabled.
• Red:The RFID reader is connected but disabled.
• Grey: The connection with the RFID reader was lost.

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.

Browsing

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

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

Behavior of the tree

• A click in the text-side selects the clicked Category.
• A click in the [+] icon expands the node and changes the icon to [-].
• A click in the [-] icon collapse the node and changes the icon to [+].
• Only there could be one node expanded at the same level (accordion behavior), so, when a node is expanded, if there is already any sibling expanded, it should be collapsed.
• When a node is collapsed and (later) reopened again, the previous (the last) children, grandchildren,… status (expanded or collapsed) should be preserved.
• Once any item is selected, the products of this category are loaded in the left column. Only the direct child products should be shown. Grandchildren and deeper levels of the selected category should not be shown.

Searching

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: http://wiki.openbravo.com/wiki/Product_Characteristic

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.

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

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

• A click in the text-side selects the clicked Category.
• A click in the [+] icon expands the node and changes the icon to [-].
• A click in the [-] icon collapse the node and changes the icon to [+].
• Only there could be one node expanded at the same level (accordion behavior), so, when a node is expanded, if there is already any sibling expanded, it should be collapsed.
• When a node is collapsed and (later) reopened again, the previous (the last) children, grandchildren,… status (expanded or collapsed) should be preserved.
• Once any item is selected, the popup closes itself automatically and the selected category is displayed in the combo.
• When the popup is shown, the selected category (of the combo) should be shown as selected in the tree. If this category is not an empty node, it should be shown as expanded (show its children) once the popup is opened. This is because if a user is in the SEARCH window filtering by the “category level N”, and opens the combo again, probably wants to fine-tune more the search by selecting an item of “category level N+1”
• In case of clicking outside the popup (in the dark-gray transparency), the popup would be closed and no changes will be made in the selection.
• The search should return products (that match the search pattern) of the selected category and all its children, grandchildren, ...

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

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:

• Sell a product (the product is obsolete)
• Sell a product without stock (the product is discontinued)

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

http://wiki.openbravo.com/wiki/Retail:Configuration_Guide#PLM_Status

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:

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:

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:

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

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).

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

• Cash up in cash counting step.
• Cash management

Editing

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:

• Quantity
• Price (only authorized users)
• Discount (only authorized users)

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

• Button - Amount - Enter. For example: QUANTITY, 5, Enter
• Amount-Button. For example: 5, QUANTITY

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

Price Modification Reason

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

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.

• Select Receipts in the menu.
• Search dialogue will appear. Filter and tap the magnifying glass button.
• A list of tickets will be shown, choose one.
• Details are shown. At the bottom of the ticket, a Paid label is shown.
• Select Print this Receipt from the menu and printer will print a Paid ticket.
• Press the X button to close the view.

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.

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

Preference: Enable Remote for Customer (Enabled)

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)

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

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:

• (x): When you fill the input field, the button (x) is shown to allow clear the input field
• Sorting: Allows to sort by a field in ascending or descending order. When a sort criteria is selected for a field then all others sort criteria are removed.

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

Context menu

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

• View details: Shown the customer details dialogue. With the following buttons: Edit, Assign Customer and Manage Address(es)
• Edit: Edit the customer information
• Manage Address(es): Show a dialogue to manage the customer addresses

Manage Address(es)

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:

• View Details: Show the address information. If address can be assigned for shipping and invoicing, it show a button with context menu to select the wanted action, but if only one action can be applied then is shown the correspond button.
• Edit: Edit the address information
• Assign to receipt: Assign addresses to shipping and invoicing addresses of receipt. This option is visible when selected address can be used for shipping and invoicing.
• Assign to receipt (Shipping): Assign address to shipping address of receipt. This option is visible when selected address can be used for shipping.
• Assign to receipt (Invoicing): Assign address to invoicing address of receipt. This option is visible when selected address can be used for invoicing.

New Customer

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.

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

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

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

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:

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

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).

• Greetings: This new field will allow to define how the seller needs to address the customer depending on whether the customer is a woman or a man, or it is a company or not.
• Birthdate: Customer Birthdate or Anniversary day
• Language: Customer default language
• Available Credit: The information to show in this field for a customer is the positive difference between these two customer figure/fields [“Customer Credit Line Limit” - “Current Balance”]
• Comments: Free text field for the seller to enter whatever customer information he/she might consider relevant.
• Commercial Auth.: This new field will show whether customer wants or does not want to receive commercial information from the organization.
• Contact preferences: This new field will reflect the way customer would like to receive company information, whenever above field (Commercial Auth.) is set as Yes. There will be two options provided by default email and sms.

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.

• Preferences list:
  • Web POS Show Customer Greetings
  • Web POS Show Customer Birthdate
  • Web POS Show Customer Language
  • Web POS Show Customer Available Credit
  • Web POS Show Customer Comments
  • Web POS Show Customer Commercial Authorization
  • Web POS Show Customer Contact Preferences

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

• Section named Personal Information, fields to be included:
  • Greetings
  • Name
  • Last Name
  • Tax ID
  • Birthdate
  • Birthplace
  • Language
• Section named Contact Information, fields to be included:
  • Phone
  • Alternative Phone
  • Email
  • Comercial Auth.
  • Contact Preferences (email, SMS)
• Section named Others, fields to be included:
  • Business Partner Category
  • Available Credit
  • Customer Consent
  • Comments
• Section named Address only in New Customer form when Use the same address for shipping and invoicing is checked.
  • Country
  • Address
  • Postal Code
  • City

Customer Statistics

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

• Recency: how recently did the customer purchase in number of days. In other words, what is the number of days that have passed since the customer last purchase in a given store.
• Frequency: how often does the customer purchases within a period of time that should be defined in the backoffice, as required by the organization. In other words, the number of customer purchases in a given period of time.
• Monetary value: that is customer’s total purchase amount within a period of time that should be defined in the backoffice, as required by the organization.
• Average basket: as [Total Sales Amount / Total Number of Sales], within a period of time that should be defined in the backoffice, as required by the organization.

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

Customer address management and assigning to a ticket

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:

• View Details: Show the address information. If address can be assigned for shipping and invoicing, it show a button with context menu to select the wanted action, but if only one action can be applied then is shown the correspond button.
• Edit: Edit the address information
• Assign to receipt: Assign addresses to shipping and invoicing addresses of receipt. This option is visible when selected address can be used for shipping and invoicing.
• Assign to receipt (Shipping): Assign address to shipping address of receipt. This option is visible when selected address can be used for shipping.
• Assign to receipt (Invoicing): Assign address to invoicing address of receipt. This option is visible when selected address can be used for invoicing.

See Manage Address(es) for menu items details.

Data Quality Management Integration in Customer and Customer Address

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

Suggestions and validations are only shown in Customer and Customer Address forms if have been previously configured in the backoffice in Organization/Data Quality Management tab.

Cross store window for a product

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.

• Add to Ticket button adds product to the ticket
• Store Stock indicates the total stock of the product in the warehouses assigned to the store and when pressing on it shows details about the distribution of the stock across bins and warehouses.
• Similar to above Other Stores Stock button indicates the total stock of the product but in the rest of the stores of the organization and its distribution across warehouses.

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.

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.

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.

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.

Reservations

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).

Editing ticket properties

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

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.

Constraints

• Can not split a line with one unit
• Can not split lines in multi selection mode
• If the line is associated services do not split
• If the line has associated complementary products do not split
• In modal split dialog Number of Lines have a minimum value of 2 and every Line Quantity have a minimum value of 1
• To split a line Original Quantity be equal to Split Quantity, that is to say Difference is zero.

Split line dialog

Split line operation can not be undone once applied.

First line of the dialog adds some summary fields:

• Original Quantity: Show original line quantity
• Split Quantity: Quantity assigned to split lines
• Difference: Difference between Original Quantity and Split Quantity
• Number of Lines: Editable value to set a number of split lines

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.

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.

Example:

• Multi -tool with 8 units
• It is divided into 2 lines of 4 units
• It adds new Multi -tool

It would order:

• Multi -tool with 4 units
• Multi -tool with 4 units
• Multi -tool with 1 units

Parking and selecting pending tickets

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.

Deleting a ticket

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

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

• Pressing “Delete/Trash” button in Web POS interface when one ticket is being edited
• Going to Cash up window and clicking on “Delete” button
• Going to Cash up window and clicking on “Delete All” button
• Logging out with some ticket in new status.

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

• It will not be possible to have duplicated Document No.’s.
• Order will be synchronized in “Closed” status
• Ordered Quantity will be equal to zero, however the lines and header will have checkbox Deleted checked and the lines will have column Quantity Deleted to know what was the original value.

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

• Print a concrete receipt
  • Tickets can be printed at any time by selecting the more button (arrow down)in the main navigation and selecting the Print this Receipt item in the menu.
  • One way to do it is first select a specific receipt using the menu option Receipts and then click Print this Receipt
  • Or while creating a receipt click the click Print this Receipt
• Print the last receipt

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

• Print a ticket twice

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:

• From original receipt
• Blind receipt, that is, without having the original receipt

From original receipt

• Create a new receipt
• In the main navigation select the more button (arrow down) to open the menu and select Verified Return
• It opens a search selector to find the corresponding original receipt
• Select the receipt and choose the corresponding lines changing the quantities if needed
• The lines added will be negative. The quantity, price or discounts cannot be updated
• Execute the payment flow as if it were a regular sale. The difference is that the payment now goes out towards the customer.
• A Return From Customer document is created in the back-office

Blind Receipt: Return the whole receipt

• Create a new receipt
• Add product to the ticket (for example via scanning, browsing or searching)
• In the main navigation select the more button (arrow down) to open the menu and select Return this receipt
• The ticket is now turned into a return ticket with negative quantities
• Execute the payment flow as if it were a regular sale. The difference is that the payment now goes out towards the customer.
• A Return From Customer document is created in the back-office

Blind Receipt: Return a line

• Create a new receipt
• Add product to the ticket (for example via scanning, browsing or searching)
• Select the line and the right panel shows the Return button
• The button turns out the line into a return line
• Execute the payment flow as if it were a regular sale. The difference is that the payment now goes out towards the customer.
• A Return From Customer document is created in the back-office

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

Can only get this scenario using:

• Return from original receipt
• Blind Receipt: Return a line

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

Creating an invoice

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

• In the main navigation select the more button (arrow down) to open the menu and select Invoice this Receipt.
• The ticket is now flagged for invoicing. The bottom of the ticket shows its new status.
• Execute the payment flow and an invoice is created.
• A sales invoice document is created in the back office.
• Launch the back office via Back Office in the more menu
• Find the sales invoice that was generated and print it for the customer

Invoice Sequence project implements a clear way to distinguish "full", "simplified" and "aggregated" invoices created in any touchpoint, in terms of document type, numbering and printing.

Invoice Terms

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

• After Delivery: products of the sales order are invoiced as soon as they are shipped, for example, if there is partial shipment of the order it is invoiced. In this case several sales invoices might be created for one sales order corresponding to all goods shipped before each invoicing run.

• After Order Delivered: the invoice will be generated after all products on the sales order have been shipped, so one order - one invoice.

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

• In the Organization window, by completing the field "Default invoice term for BPs".
• Configuring it directly on the Business Partner window by selecting an "Invoice Term" in the customer tab.

Invoice Reprinting

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:

• Click on the Menu
• Click on Print this Receipt

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 Print Invoices button on the new popup will only be enabled if at least one invoice is selected to be printed.

Layaways

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.

Creating a New Layaway

• In the main navigation select the more button (arrow down) to open the menu and select Layaway this Receipt.
• The ticket is now flagged as Layaway. The text "To be laid away" is shown.
• Add (or not) payments. You can create a Layaway doing a prepayment or without payments.
• Press Layaway button (In the right part of the screen) to process this order.
• A sales order is created in the back office.
• If a newly created layaway needs to be changed back into a Sales Order, this is possible from 16Q2 onwards, using the menu item "Receipt this Layaway"

Finding an Existing Layaway

• In the main navigation select the more button (arrow down) to open the menu and select Layaways.
• In the modal, add parameters in order to filter layaways and click on the chosen layaway to open.
• The layaway is shown as a order. "Layaway" text is shown and some buttons are disabled.

Complete a Layaway

• Find an existing layaway.
• "Pending to pay amount" shown takes into account the previous done payments.
• Pay layaway:
  • Lay away again this order: Add a payment (partial payment) and press Layaway button.
  • Full pay the total gross amount of the order and this layaway is going to be completed. Shipment will be created and an Invoice if it is required (Do not forget to choose "Invoice this receipt" option in the menu if you want to create an invoice).
• A sales order is created in the back office.

Voiding a Layaway

• Find an existing layaway.
• In the main navigation select the more button (arrow down) to open the menu and select Void this Layaway.
• The text "Void this Layaway" is shown.
• Pending to return amount will show the total amount of the prepayments done by the customer because this is the amount we have to return.
• Add payment types and amounts to give back the money.
• Press Done button to void this layaway.
• In the back office, this sales order is going to be closed and negative payments will be created representing the refunded money.

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

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

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

• Remaining to pay and change will be shown in the selected payment, i.e.: If you check another payment button(different currency), Remaining to pay or change will be update to the selected currency.

• In order to give back the change, we can select which payment method (Currency) to use. i.e.: We have "change" to give and we want to give it in other currency, we have to check the payment method wanted, the change will be updated and finally we have to push Done button.

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

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

Payment Rounding

Enabling Payment Rounding, it will be possible to round payment amount in sales and returns created in Web POS.

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

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.

New "Multiorder" View

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

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:

Cash

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.

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.

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.

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

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

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

• There is a new window Payment Method Category to define the categories, for example Credit Cards, Vouchers, etc. So first the user needs to enter the categories to be used
• In POS Terminal Type window the user can assign these categories to any of the payments. Apart from this it is possible to add an image to the payment method
• For example if Credit Card category is created and assigned to VISA and AMEX payment methods instead of having two buttons (VISA, AMEX) there will be just one (Credit Card)
• Click the button Credit Card and a popup will be opened. Select the payment method
• A message warns the user which payment method is selected

Overpayment

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:

• Expected amount is 12.50
• Customer uses 3 vouchers of 4.50 each = 13.50
• Overpayment is 1.00 because no change can be given back

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

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

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.

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.

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

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.

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.

Cash Management

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:

• The amount in cash exceeds a certain limit. For safety reasons, a cash withdrawal needs to be done.
• Shift change: Cash is taken out when changing shifts.
• Scheduled cash withdrawals: Many stores have their cash withdrawals scheduled. Typically a courier comes to pick up the cash.

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.

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

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.

Cash counting

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

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:

• Tap the edit button with the pen symbol. Enter the number of denominations and finally tap on the return button.
• Tap on the denomination button to increase by one the number of denominations

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

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

• Tap the edit button with the pen symbol for
• Enter the counted amount on the numerical pad and tap Enter
• Do the same for all available payment methods

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.

Select cash to keep

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

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

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

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:

• CashUp - Group payments by expected amount (OBPOS_retail.cashupGroupExpectedPayment): Allow to group the used payment methods and allow us to continue without counting not used payments
• CashUp - Remove unused payments from CashUp Report (OBPOS_retail.cashupRemoveUnusedPayment): Show only the used payment methods on Cash Up Report (Both: Web POS - Post, Print & Close and ERP - Cash Up Report)

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.

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

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:

• Cash up Report (PDF). Pressing this button, a pdf report will be created with the cash up information
• Cash up Report (XLS). Pressing this button, an excel report will be created with the cash up information. This button is available in 17Q1

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

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

Payment Method Status Cashup

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

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.

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.

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.

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:

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

Cashup

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:

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:

• Part 1: Review pending receipts
  • This window has no change and all the information is shown.

• Part 2: Count Cash
  • The Total and Expected label and quantities are not shown. The Counted label and quantity is still visible to the user.

• Part 3: Count Cash (other payments with Count Cash unchecked).
  • All expected quantities per payment method are hidden. All payment methods defined in the back-end as ‘Count Cash’ are not displayed too. Finally, the information of the total expected and the total difference are not visible.

• Part 4: Quantities to keep
  • These windows have no change and all the information is shown.

• Part 5: Post, print and close
  • Several fields are not visible in this window:
    • Net and Gross Sales
    • Net and Gross Returns
    • Total Retail transactions
    • Cash Management Withdrawals (total and specific per payment method).
    • Cash Management Deposits (total and specific per payment method).
    • Difference amounts (total and specific per payment method).
  • Some other fields are still visible:
    • Starting amounts (total and specific per payment method).
    • Counted amounts (total and specific per payment method).
    • Kept amounts (total and specific per payment method).
    • Deposited amounts (total and specific per payment method).

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

To configure the preference, follow this link

Kept Cash Report

Optionally, an additional report can be configured to print a ticket along with the Cash Up Report that shows the amount of cash kept in the terminal or Safe Box after the Cash Up process.

To enable this report, first define which payment methods will be shown in this ticket. This is done by enabling the flag Print cashup kept amount in the Tab Channel - Touchpoint type -> Payment Method. Only payment methods of type Cash with the flag Count payment in Cash Up flag enabled will be eligible to show this flag.

Then, in Channel - Touchpoint type the number of copies of this ticket to be printed can be specified in the field Kept Cash Tickets to be printed on Cashup. By setting this value to 0, no ticket will be printed, even if there are payment methods marked for this report.

When the selected payment method is in a Safe Box, the search key of the Safe Box will appear in this ticket as well.

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.

Quotations

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

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

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

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

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

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

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.

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.

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'

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.

Usage

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

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:

• Document number
• Customer
• Date From
• Date To
• Amount From
• Amount To
• Order Type (Receipt, Return, Layaway, Quotation)

Advanced 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

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

Keep filters in Business Partner selector

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

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:

• Date and Time of the document
• Document Number
• Customer
• Amount
• Document Type

Open Related Receipts

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.

Usage

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.

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

• Document No
• Order Date
• Amount
• Pending

Multi Price List

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

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:

• Web POS Enable Multi Price List: It enables Multi-Price List functionality.
• Web POS Show Standard Price on Search and Browse: It shows the standard price on Search panel and Browse too.

• Web POS Allow products not to have a price in main pricelist: It allows to define products without a price in the main price list of the store.

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.

• The price list selected appears near to the document number of the ticket.
• When the price list selected is not the default one and the preference Web POS Show Standard Price on Search and Browse is enabled, standard price appears in grey on Search and Browse panel.

• When Web POS Allow products not to have a price in main price list is enable, the user can define a product without price in the store's main price list but with price in another customer price list. If the price list selected is not the default one the product will be shown to be added to the ticket. Once is added, if the user selects another price list where this product doesn't have price defined, the product is automatically removed from the ticket and a warning message is shown to the user to indicate the product doesn't have price in the current price list.

Notes:

• Products that do not belong to the Price List selected disappear from Search and Browse.
• It's not possible to select a product through EAN Code that does not belong to the Price List. The application shows a message.
• It's not possible to select a Price List directly.

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).

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.

From now:

• Single clicks/taps on a non-selected line, selects it (the previous one(s) remain(s) selected).
• Single clicks/taps on a selected line, unselects it (the previous one(s) remain(s) selected). If there is only one line selected in the whole ticket, it cannot be unselected.

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.

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.

• If the user press Shift key and clicks in a line, and all the other selected lines are above it, the selection should go from the first selected line to the clicked one.
• If the user press Shift key and clicks in a line, and all the other selected lines are below it, the selection should go from the last selected line to the clicked one.
• If the user press Shift key and clicks in a line, and there is selected lines above and below it, the selection should go from the first selected line to the clicked one and the selection of the lines below the range, should be removed.

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:

• Copying an existing product
• Creating the product from scratch

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

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:

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

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.

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:

• Web POS action Cancel and Replace: "Y" value by default. If this preference is set to "N" "Cancel and Replace" menu entry will not be available.
• Cancel and Replace orders totally paid and delivered: "Y" value by default. If this preference is set to "N" "Cancel and Replace" menu entry will not be available for tickets fully delivered.
• Cancel and Replace orders with deliveries: "Y" value by default. If this preference is set to "N" "Cancel and Replace" menu entry will not be available for tickets fully or partially delivered.
• Cancel and Replace Layaways without Payments and Deliveries: "Y" value by default. If this preference is set to "N" "Cancel and Replace" menu entry will not be available for layaways without payments neither deliveries.

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.

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.

Cancel Layaway preferences:

• Web POS action Cancel Layaway: "Y" by default. If this preference value is set to "N" "Cancel Layaway" menu entry will not be available.
• Cancel layaway action only if payments: Not available by default. If this preference value is set to "Y" "Cancel Layaway" menu entry will only be available if the layaway has payments.

Cancel Layaway and New

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):

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

Introduction

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.

http://wiki.openbravo.com/wiki/Projects:Reversepayment/User_Manual

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:

• Paid tickets
• Layaways
• Returns

Paid tickets

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.

Layaways

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:

http://wiki.openbravo.com/wiki/MobiSales_User_Guide#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.

Returns

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

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.

Invoices

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:

http://wiki.openbravo.com/wiki/Retail:Web_POS_User_Guide#Cancel_and_Replace_.2F_Cancel_Layaway

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.

Paid on 'Credit'

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:

http://wiki.openbravo.com/wiki/Retail:Web_POS_User_Guide#Credit_Sales

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

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.

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.

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.

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.

Objective

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.

Limitations

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.

Configuration

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.

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

Usage

Sales Flow

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

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.

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.

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.

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.

Quotation

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.

Attributes in Layaways

Starting from RR18Q1, it is possible to:

• Add products without attribute value into a Layaway
• Edit attributes information in Receipts, Quotations and Layaways

• When the layaway is finally going to be completed, and shipped, it is mandatory that all attributes have correct value:

Cross Store Operations

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

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

Safe Boxes

Safe Boxes is now available in Web POS. Refer to Safes Boxes link to configure and use it.

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

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.

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

Backend Data Processing: Data Import Entries

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

• new or changed tickets
• layaways and returns
• quotations
• new or changed business partners and addresses
• cash management actions
• cash ups

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

• when received from Web POS they are first stored in a data import entry table
• a parallel and asynchronous process will read all the new records from this table and process them
• processed record are archived on an hourly basis and stored in the import archive table

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.

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:

• Type of Data: the type of the received data, business partner, order etc.
• POS Terminal: Which terminal set the JSON object.
• Import Status: can have one of three values:
  • Initial: received from Web POS but not yet processed
  • Processed: correctly processed by the system, these records are due to be archived
  • Error: these records encountered an error in initial processing, the Error Info field contains details of the error.
• Data: the json content of the message
• Error Info: The Java Exception giving details on the error, if the entry is in Error status.

Import Entry High Availability

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

Logging Import Entry Manager status

It is possible to log a snapshot of the Import Entry Manager's current status including information about the entries that are queued and the ones that are currently being processed. This log can be useful for debugging purposes. This log can be triggered from the ImportEnrtyManager JMX MBean executing the logImportEntryManager method.

Errors while importing POS data

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.

• Status: Describes the main reason of the error.
• JSON order data: It is the JSON object sent from Web POS.
• Error: The Java Exception which caused the error.
• Data type: The object of the JSON data (Order or Business Partner).
• POS Terminal: Which terminal set the JSON object.
• Save again: After checking your configuration error and solving it, you can resend the data.

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.

Payments

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

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

• Create a new ticket
• Mark the ticket as To be Returned via the more menu in the navigation.
• At the bottom of the ticket the new status will be indicated in orange text.
• Scan (or manually add) the product that is to be returned as if it were a regular sales ticket
• Adjust quantities if necessary
• Start the payment flow
• Tap the Exact Amount button (the green button with the check mark) if the returned amount is of payment type cash
• Tap the Done button
• Return the amount to the customer

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

• A Negative Payment In document
• A Return from Customer document
• A Financial Account transaction (withdrawal) document

Financial accounts

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.

Reporting

Openbravo´s standard reports can be used for retail:

• Cash reports by POS terminal and by dates
• Average cart by store and by dates
• Sales reports by POS terminal
• Sales reports by agent
• Inventory reports

Characteristics

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

How offline mode works

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.

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.

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

The following list of features are supported in offline mode:

• Login: as mentioned, login works in offline mode but only for the users which have already logged in online mode.
• Creating new tickets
• Creating new customers
• Cash management (available since version 3.0RR14Q2)
• Cash up (available since version 3.0RR14Q2)

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:

• Paid receipts
• Quotations (you can still create new ones, but you will not be able to load previously created quotations).
• Layaways (you can still create new ones, but you will not be able to pay previously laid away receipts).
• Verified returns (you can return tickets directly, but you cannot load previously created tickets to return them)
• Change user profile options: the user profile settings will be the ones which were used the last time an online login was done. This means that the language cannot be changed while being offline.

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.

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.

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.

Category: Retail