Log in / create account
Openbravo.com
Issues
Forge
University
View source | Discuss this page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Show collection (0 pages)
Collections help

Search

Retail:Configuration Guide

Back to main page

Contents

Introduction

This document describes how to configure the following specific settings of the Openbravo omnichannel platform:

For generic documentation about Openbravo configuration please follow the Quick Guide.

If you are trying out Openbravo omnichannel platform for the first time, you MUST first execute all of the Business Setup configuration instructions in the Quick Guide before executing the configuration instructions below.

Installing the Openbravo for Retail module

The Openbravo for Retail module is the main module of the Openbravo Commerce Cloud. To install the module (an Openbravo Subscription to either Enterprise or Professional Edition is required since it is a commercial module, read more about Retail License):

Add Retail Stores to the Organization Model

In Openbravo an organization is a business unit within an entity (company). Each entity can have more than one business unit to cover different zones, areas, region, stores... Openbravo allows the definition of a hierarchical structure of organizations where a parent-child relationship between them can be determined. The result is a n-level organization tree, as follows:

OrgTree.png

This structure is flexible enough to support any further organizational change and may have unlimited levels, branches and nodes at each level as the situation may demand.

In Organization window there is new group of fields called Retail Configuration. There you can find Retail Organization Type field where you define whether an organization is a store or a group of stores:

Store:

Group:

RetOrgTypeAss.png
Bulbgraph.png   This configuration will be available starting from RR19Q2.

Document Types

OrganizationRetailConfig.png

Store Pricing Configuration

Item pricing can be managed by store or store group. This allows the retailer to manage multiple pricing for a single item.

In Organization window there is a 'Price List' field inside Retail Configuration group. Any node of the enterprise model (either group or store) can have a sales price list assigned.

Pricing management rules:

In the following example all stores located on Zone 1 will use the prices defined at Zone 1 level, except the Store 11, that is going to have its own price list.

PriceListTree.png

Before RMP19, only price lists which included the tax were supported. Starting RMP19, pricelists without including taxes are also supported in Retail.

In case a pricelist without taxes is used, the prices shown in the receipt lines will be net prices, and an additional line which includes the total tax will be shown. The total amount of the receipt will still be the gross amount.

Numerical Precision Configuration

The Web POS only supports one single precision, and by default uses the Price Precision of the currency it is working on both for its pricing precision, and for the general precision for all internal calculations. Sometimes, it's necessary when operating the backoffice to define a different Price Precision than the Standard precision, and sometimes this price precision would be wrong in the Web POS. For these cases, the POS Precision column in the currency window exists.

This POS precision prevails against every other precision, so if it is defined, then it is used both for price precision and other calculations. If it's not defined, then the Price Precision is used instead.

Bulbgraph.png   This configuration will be available starting from RR23Q2.

Starting 23Q2 release, the POS supports a different price precision compared to the main precision. If it is configured, all prices will be shown and calculated with this precision.

Assortment Configuration

Assortment management allows the retailer to determine the product range that will be made available for sale at various stores.

A new window Assortment is created to provide a new grouping for products.

The window has two processes (buttons) for common operations dealing with assortment:

ProductList.png

Organization window has a new optional field Assortment inside Retail Configuration section. Any node of the enterprise model (either group or store) can have an assortment assigned.

ProdListTreeAss.png

Assortment management rules:

Notes:

Assortment At POS Terminal Type Level Configuration

Bulbgraph.png   Starting from 3.0RR18Q4 this functionality is available

On 3.0RR18Q3 and previous releases, the only option to set the assortment of products for WebPOS was to define it at Store level (Organization window in the ERP). With this new development, the assortment of products for WebPOS could be defined also at POS Terminal Type level (POS Terminal Type window in the ERP).

WebPOS always needs an assortment of products to be loaded. To get the assorment, WebPOS terminal will look first if there is an assorment at POS Terminal Type level, and, in case it's not defined or set, it will look for the assortment set at Organization level.

Category Tree Configuration

Select menu option: Application / Master Data Management / Product setup / Product Category. Push button to show Tree Grid Visibilty.

CategoryTreeConfigErp.png

Remember: For a category can have children check Summary Level

Cash Management Events

A cash management event is either a cash deposit or withdrawal in the store, but also the process of cashing up. A store can have several cash management events and they are configured differently depending on the nature of the event (in, out, close).

These events are managed in WebPOS and need to be defined in tab Cash Management Event in Organization window.

CashManagementEvent.png

For each event you need to define the following:

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

Approval system enhancement for cash up and initial count processes, adding the possibility of specifying differences limits for each payment method before asking for an approval.

Global Count Difference Limit

Navigate to Organization window and select a organization to configure. On section Retail Configuration set Count Difference Limit, as shown on following figure:

CountDifferenceLimit Org.png

Count Difference Limit for the payment methods

Navigate to POS Terminal Type window and select a item to configure, in tab Payment Method select a item to configure. On section Cash Up set Count Difference Limit and on section Cash Management set Initial Count Difference Limit, as shown on following figure:

CountDifferenceLimit POSTermType.png

Note: Before to 3.0RR16Q2, null value in this field is the same as the value 0: the approval always is required when there is a difference amount. From 3.0RR16Q2 the behavior has changed: if the field is null, then never the approval is required, if the value is 0 and there is a difference amount, the approval is required.

Approval Reason

Navigate to POS Approval Reason window and edit/add the reasons, as shown on following figure:

CountDifferenceLimit ApprovalReason.png

Customers default configuration

The are some fields we must fill if we want to create new customers in Web POS. These fields will be the default value for customers created in our terminal.

CustomersConfiguration rmp19.png

Preferences

The following preferences have been created:

Grouped products

By default, all of the products are grouped in Web POS. It means that when a line representing a product is already in the ticket and more units are added, the line will change the quantity without creating new lines.

If you want to create a new line for each product, "Grouped product" field should be disabled.

This field is located in the header of the product window.

Not grouped products will generate new lines when they are added to the ticket through "Browse", "Search", "Scan". When they are added to the ticket we will be able to change the quantity of each line.

Non Returnable Products

Bulbgraph.png   Starting from RR17Q2 below functionality is available

By default all of the products are returnables in Web POS. It means that it will always be possible to return them. However, in some cases this should not be the rule and in this field you can deactivate this functionality. It is also possible to fill the value of Overdue Return Days in order to set a maximum period of time to return an item.

This field is located in the header of the product window.

The following pop-up will rise when trying to return a non returnable product as a return line:

NormalNonReturnable.png


The following pop-up will rise when trying to return a non returnable product using verifying returns:

VerifiedNonReturnable.png

PLM Status

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

From 18Q3 is possible to configure the PLM (Product Lifecycle Management) Status of the products. This status affects to critical flows in which the products are used. Up to now, in the Web POS the only affected flow is the process of selling them. In the next link is possible to find more information and the different status of the PLM Status:

http://wiki.openbravo.com/wiki/Projects:PLM_Status

Configure the PLM Status

The products status is configured directly in the Product window. There, there's a selector to set the current status to it:

Plmproduct.png

It is also possible to open the status list in a selector, to see which is the impact of each one:

Plmselectorproduct.png

Here the user can see how a status affect to the different flows. The selector is not modifiable, is read only.

PLM Status in the Assortment

The PLM Status can also be configured in the Assortment window, in the Product tab of the window. Any configuration done here overrides the configuration set in the Product window, affecting only in the organization for which the assortment is configured. This allows to have a different status for a product in each store. The products that are not configured in the assortment will use the status of the product.

Plmassortment.png

The PLM Status can also be shown with the selector popup, as in the Product window.

Enable cross store for a product

Cross store is an utility which allow us to see the detailed stock by bin in our store and also the stock of the product in other warehouses of the organization.

To see the stock detail view the field Show stock screen shuold be checked in the product window.

In this example we will activate the stock screen for the product Base camp duffel 70L

OBPOS enable show stock.png
Bulbgraph.png   Starting from RR16Q2 below functionality is available

It exists the possibility to define which warehouses are going to be part of “Cross Channel Warehouse”.

Definition is done in window “Organization” using “Cross Channel Warehouse” tab and adding the warehouses using button “CC Warehouse”. This warehouses are warehouses not defined as Warehouses on Hand of the Store, and defining them in this tab it will be possible to check the Stock of products in those warehouses from Web POS for the configured Stores.


CCWarehouse button.jpg

Apart from that using the field “Included Warehouses” in the organization it is possible to define different logics:

-All excluding defined: Web POS will propose all the warehouses defined in the system except which ones defined as On Hand

-Only those defined: Web POS will propose you only the stock of defined warehouses

Included CCWarehouses.jpg

After this configuration, Web POS will open the stock window when a product is clicked in order to be added to the ticket.

OBPOS view cross store.png


Product Media

Bulbgraph.png   Starting from RR23Q1 below functionality is available

Product Media data can be used on WebPOS by configuring it. To enable the behaviour it will be needed to configure the record on Product Media Tab in Product Window and enable "Web POS Show Product Images from External System" Preference.

The POS will show the image using the URL described in the "Product Media" tab for the particular product selected in the application. The right image size will be chosen if multiple images with different sizes are available, depending on the functional flow that is being used (for example, Thumbnail size images will be used in Search, while bigger images will be shown in the stock screen).

Anonymous Layaways

Bulbgraph.png   This configuration will be available starting from RR16Q2

This new functionality provides the functionality to allow or deny the creation of layaways for the anonymous customer of the store/terminal (the anonymous customer is defined either on the POS Terminal window or on the Organization window; the value on POS Terminal window, if it exists, will override the value on Organization window).

Navigate to the Organization window and check Allow anonymous customer layaway if you want to allow the creation of layaways for the anonymous customer.

AnonymousLayawaysConfig.png

Allow to void Layaways partially paid

Bulbgraph.png   This configuration will be available starting from RR16Q4

This new feature provides the ability to configure the store to allow/deny the layaway voiding process if these have some associated payment.

Navigate to the Organization window and check Allow partially paid layaways to be voided if you want to allow the voiding of layaways when there are related payments.

VoidLayawaysConfig.png

Currency Exchange Rate at Store Level

Bulbgraph.png   This configuration will be available starting from RR18Q3

This new feature provides the ability to configure currency exchange rates at Store level. Currently Openbravo only allows to define currency exchange rates at * level. With this feature, if any exchange rate is defined for an store, the one defined at * level will be overwritten.

Navigate to the Organization window and open Conversion Rates tab. Notice that the tab only will be displayed if the selected organization type is Retail Store.In this window it will be possible to define information:

ExchangeRateAtStoreLevel.png

Currency Rounding at Store Level

Bulbgraph.png   This configuration will be available starting from RR19Q1

This new development allows to select rounding for different currencies.

Navigate to the Organization window and open Currency Rounding tab. It will be possible to configure:

In this example, if change is between 100 and 25, it will be rounded up to 100. However if it is less than 25, it will be rounded down to 0.


Backroun.png

Maximum Allowed Quantity or Price Configuration

Bulbgraph.png   This configuration will be available starting from RR18Q3

Introduction

This configuration allows to show a popup if the quantity or price exceeds a value set in two new properties defined:

Retail wk config price.png
Retail wk config qty.png

These preference works as other preferences from Web POS, in terms of configuration, with a small difference: the value set indicates Web POS the value to be exceeded to show a confirmation popup. Once set one or both of these preferences, the functionality starts to be check in Web POS.

How it works

Once configured, there are two possible scenarios to take into account:

Retail wk func price after.png
Retail wk func price before exce.png

Retail wk func price after exce.png

Retail wk func price after exce cancel.png

Retail wk func price after exce ok.png

The quantity is set to the lines selected without any UX difference.

Retail wk func qty before.png
Retail wk func qty after.png

The quantity is not set directly and a confirmation popup is shown:

Retail wk func qty before exce.png
Retail wk func qty after exce.png
Retail wk func qty after exce cancel.png
Retail wk func qty after exce ok.png

Web POS module

Channel

A Channel is any interface used by the organization to interact with clients in an omnichannel retail context. Typical channels are the webstore, kiosks, POS terminals in a physical store, Self-Checkout terminals in a physical store, a Call centre or Back office sales.

A Channel - Touchpoint Type is a grouping of touchpoints with a identical -technical- configuration but different identification. This is a configuration designed to model a type of Touchpoint. Each touchpoint belongs to a single Touchpoint Type. Each touchpoint type refers to one single channel, but a channel can hold multiple Channel Touchpoint types.

Taking as an example physical stores, each POS Terminal is an example of a Channel Touchpoint, and all POS Terminals of a specific model belong to the same Channel Touchpoint Type. POS Terminals represent the different terminals on each store and need to be configured properly in order to ensure operations are well supported in the backofice (e.g stock is updated in the backoffice when a sale is registered, invoice is created if customer requires it, etc.).

The Channel configuration takes place in two windows:

This structure allows a very simple but flexible configuration. An example would be a multi-store company in multi-channel environment. Each store could be managed differently (e.g have different cash up processes) and could need separate configuration even for each channel. In this case, different POS Terminal types could be defined for each store as different Touchpoint Types. And terminals within same store could share the same Touchpoint Type. In case of eCommerce channel for example, each eCommerce platform can could be defined as separate Touchpoint Type but belong to the same Channel.

These two windows are designed to simplify the configuration process for the user: if the user needs to configure 100 touchpoints, but all of them are basically identical, then the amount of data he will need to insert is quite small, because all Touchpoints will refer to the same Touchpoint Type.

In this section, we will first describe how Channel - Touchpoint Type are configured, and then we will describe the Channel - Touchpoint window.

Channel - Touchpoint Type window

In this window, you basically design a Touchpoint Type, which will be used by one or many Touchpoints. Here you configure relevant information at Touchpoint level, but also some configuration for payment methods in a subtab.

Masterdata.png

In the header, you configure the following fields:

Bulbgraph.png   Starting from RR19Q2 below fields have been moved to Organization window.

There are as well some other fields related to Openbravo POS touchpoint types. Those are only visble when Openbravo POS application is selected:


Masterdata loading

In addition to these, there are two more fields which define how the masterdata reloading is done:


If neither of the fields is defined, then the system will fully refresh all data when the user logs in (and data will not be automatically refreshed until the next log in).

If only the first field is filled, then the system will fully refresh all data in the next login done after of minutes specified in the field.

If both fields are specified, then both incremental will be done each number of minutes as indicated in the field. The full refresh will be done in the next login done after of minutes specified in the field.

Bulbgraph.png   Starting from RR19Q4 The incremental refresh of masterdata will be done in background

When the time Time to incrementally refresh masterdata (in minutes) expires, the web pos will start loading in background all the models.

And when the next ticket is finished, or the Time to Show Incremental Refresh Popup (in minutes) expires, it will save the model changes in db, and when doing this it will show a loading screen. As the loading already took place, the amount of time the user is blocked has been significantly reduced.

If there is no changes in any of the models, nothing will be shown to the user.

If an incremental refresh with a large volume of data happens, the UI will then be blocked as this data needs to be loaded in chunks. The background masterdata maximum size can be configured by the preference "Background Masterdata Maximum Size". If set to -1 it will disable the background masterdata refresh, and the previous way of loading the data blocking the UI will be used.

Also in 19Q4 version, the incremental refresh will not be triggered by default when logging in the application or refreshing it. Only if it is really time to refresh the data (taking into account the Time to incrementally refresh masterdata (in minutes) preference), the incremental data loading will be triggered when logging in the application.

Payment Method
PosTerminalTypePaymentMethod.png

In the Payment Method tab, you configure the following fields:

Cash Up
Cash management
Change Logic
Bulbgraph.png   This configuration will be available starting from RR19Q1

This section applies if Multi Change is enabled

Bulbgraph.png   Starting from RR15Q2 below functionality is available

If Leave as Credit field is set to 'Y' that payment method wont take part on the CashUp process since it is not going to get paid. It won't also have a Financial Account associated.

LeaveAsCredit.png
Hardware URL
Bulbgraph.png   Starting from RR17Q1 below functionality is available

In the tab Hardware URL you can configure a list of Hardware Manager (only for printer devices) to allow the cashier to select a different printer to use in the case he wants to or the current selected printer is not working for any reason. This list of Hardware URL addresses is shared by all the touchpoints with the same Touchpoint Type and it must be configured using the Hardware Manager window.

Posterminaltypeprinters.png
Terminal for Seller
Bulbgraph.png   This feature is available starting from 3.0RR17Q3.

From RR17Q3, a new concept of terminal have been included. These terminals are Terminals for Sellers.

Terminals for Sellers are terminals distributed in different sections of a store. These terminals are only used to create layaways, so are never used to directly buy or return products. An example may be a customer who is in a supermarket, in the fruits section. This customer chooses four apples and asks to a seller to create a layaway with those four apples, which will be paid to a vendor in a normal terminal.

To consider a touchpoint to be a Terminal for Seller, the touchpoint needs to belong to a Touchpoint Type with an specific configuration:

As commented before, a Terminal for Seller should never be used to pay tickets or return products. These terminals don't contain a drawer, so any operation related to a cash movement is not allowed. Due to this reason, Terminals for Sellers are not allowed to do Cash Ups or any operation available in the Cash Management window. The following functionalities are disabled here:

As the Cash Up, Cash Up Partial and Cash Management menu entries are disabled, if an user tries to navigate directly to any one of those pages directly by URL, a popup will appear telling that a Terminal for Seller cannot navigate to that URL.

Payment methods not counted in the Cash Up process:

Even if this type of touchpoint is not considered to work with payments, there are some flows that may need to get money back. Those flows are:

These three situations will be always managed using payment methods that are not counted in the cash up, so which won't need to have a drawer in the terminal.

If the Sessions module is used, Terminals for Sellers are also considered and their behavior particularly when the Store is closed changes a bit. You can find a bit more information here

Allow to configure the UI
Bulbgraph.png   This feature is available starting from 3.0RR19Q3.

A new field called "Touchpoint UI configuration" has been created in touchpoint type window. This field allows to select a certain UI configuration which is configured in a separate window called "Touchpoint UI Configuration". There, several actions (buttons) can be placed in differents areas of the screen according to the user needs.

Touchpoint types which are already configured will mantain the prior behavior (field will be blank). For new ones, a preconfigured Touchpoint UI Configuration (Default POS UI Configuration) will be used. This value can be set as blank (to use prior behavior) or changed for a Touchpoint UI Configuration specifically created.

UIConfiguration field in touchpointtype.jpg


Here you can find more information about that feature

Channel - Touchpoint window

In this window the individual Touchpoints must be created.

PosTerminal.png

In the header, the following fields are configured:

Bulbgraph.png   Starting from RR16Q3 below functionality is available
Bulbgraph.png   Starting from RR19Q1 below functionality is available
Bulbgraph.png   Starting from RR20Q3 below functionality is available


PaymentCash.png

In the payment type, the following information is configured:

Very important. Payment methods are secured by Search key value in Role preferences. There are three predefined values: OBPOS_payment.cash for cash payments. OBPOS_payment.cash payment method is also used to calculate cash change in the payment panel. OBPOS_payment.card for card payments and OBPOS_payment.voucher for voucher payments. If you need to add new payments with different Search key values you need to secure them in order to allow users to use the new payments you create. To do this, as System Administrator you need to go to the window References, in this window search the record with name Property Configuration and in the tab List Reference add a new record with the same Search key as the new payment you need to add. This new record should belong to your own module which should be dependent from the Web POS module. Once it is created you will be able to assign permissions to this new payment in the Preferences window.

Note. The search key field in the tab List Reference must start with the DB prefix of the module you are creating this value, but the search key of the payment method does not need to start with any prefix, so for example if the search key in List Reference is OBPOS_payment.mypayment the search key in the payment method to secure can be OBPOS_payment.mypayment or payment.mypayment.

Note. When a ticket is created within Web POS, the information related to the payments of this order is stored in Sales Order > Payment plan > payment details

Note. Do not add payment types if this touchpoint has an open cashup. This window is to define configurations before start working in Web POS, if you change the configuration while the touchpoint is operating you could have errors in the touchpoint or data inconsistency.

CashUpHistory.png

In the cash up history, the following information is configured:

In the reconciliation subtab, the following information is configured:


Bulbgraph.png   The functionality described below is available starting from 15RRQ2
OverridePOSTerminalConfiguration.png
Bulbgraph.png   Starting from RR15Q4 below functionality is available

In Channel - Touchpoint window you can define a hierarchy of touchpoints in order to allow to share any payment method you have accross touchpoints of the same organization. e.g.- There are 4 terminals in an store but you have only one pinpad.

TerminalHierarchyMaster.png

More than two levels of hierarchy are not supported. This means that a “master” touchpoint cannot be slave of any touchpoint.

TerminalHierarchySlave.png

A touchpoint can use both standard payment methods and shared payment methods at the same time.

When a touchpoint is defined in the backoffice, another touchpoint can be specified as its “master”. When this is done, two important changes happen in the POS operation:

PaymentMethodShared.png


Bulbgraph.png   The functionality described below is available starting from RR17Q2
Terminal status
Bulbgraph.png   Starting from RR18Q2 below functionality is available

Through the touchpoint window, it is also possible to monitor some key metrics and facts of each terminal in the system.

The information is shown in touchpoint window header and it is grouped in Terminal Status section.

The user could monitor the following information in Terminal Status section

Terminal status.png
Terminal status extension
Bulbgraph.png   Starting from RR18Q4 below functionality is available

As an extension of previous terminal status values user can monitor, now it is possible to monitor more in detail the current status of a terminal from Touchpoint Window

The information, as before, is shown in Touchpoint window header and it is grouped in Terminal Status section.

The user could monitor the following new information in Terminal Status section

Terminal status ext.png
Bulbgraph.png   Starting from RR19Q1 below functionality is available
=Terminal status history=
Bulbgraph.png   Starting from RR18Q4 below functionality is available

In addition, a new sub tab has been created in Channel - Touchpoint window called "Terminal Status History".

Terminal Status History records are created once the cash up is synchronized with the ERP and are updated until the current cash up is processed in WebPOS.

The information the user could monitor is

Terminal status ext history.png
Bulbgraph.png   Starting from RR19Q1 below functionality is available

Configuring for performance

Several settings have consequences for the performance of Web POS in the backend operations: creating orders, invoices and doing cashups. This section gives an overview of some settings.

Group orders in one invoice - Cashup Performance

In the POS Terminal Type you can check the group orders in one invoice. If this flag is not checked then each ticket in Web POS will result in a separate invoice in the backend. These invoices are created when doing the cashup.

If shops close at the same time and several shops do the cashup at the same time this can result in the cashups of different shops waiting for each other as they might share the same document sequences for invoices. See the next subsection on document sequences for more information.

In general it is fine/best to check the group orders in one invoice flag. This results in better cashup performance, smaller database sizes and most of the time no separate invoice is needed as there is already a printed ticket for the customer.

Generate invoice for orders

Another setting in the POS Terminal Type specifies if a separate invoice should be generated for each order/ticket when the ticket is created. This results in a slighly slower ticket creation in the backend. The Web POS user does not notice this as the backend ticket creation does not block the Web POS user interface. But having a separate invoice for each ticket will result in much more data in the database and more load on the server.

So the advice is to only check this option if it is really needed and in all other cases keep it unchecked.

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

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.

Querying performance

Bulbgraph.png   Starting from RR16Q1 below functionality is available

Sometimes we could suffer performance problems when we are searching something in Web POS and it takes time to render all the items or when we have an environment with high volumes. Because of that, we can set this three preference (Searching in WebPOS limit value for Products, Searching in WebPOS limit value for Customers and Searching in WebPOS limit value for Orders). We have to put the number of items we would like to show in a search. By default this value is 300, in case you want to show less items, set preferences with your selected value. This feature is available searching Products, Customers and also Orders(Paid orders, layaways, quotations...).

Document Type and Sequence Numbers - (Cashup) Performance Consequences

The document type defines the document sequence which is being used for orders and also defines the document types for invoices and other business documents.

When creating some documents such as shipments, payments or reconciliations, the system uses the document sequence to generate a new document number for the business document (order/invoice/shipment). Document numbers need to be unique and also need to be incremented correctly. To ensure this the system will lock the database while creating business documents.

If different terminals share the same document sequence for a business document then POS actions of these terminals will sometimes wait on eachother (at database level) when new document sequence numbers are created. Especially with large cashups this can result in longer processing times.

In 19Q1 and earlier releases, the document types were configured at Touchpoint Type level, so each store had to configure its own terminal type with specific document types in order to have good performance. In 19Q2 and newer releases, the document types are configured at Organisation level, but it is still very important to configure specific document types for each store. This is the best way to ensure that the server can process documents from different organisations in parallel and that contention is kept to low levels.

Synchronized order

Enabling Synchronized Request Order we will enable this functionality. From 16Q2.

This functionality makes the transaction be processed on the server completely synchronously. So the WebPOS user interface wait for the confirmation that the record has been successfully processed on one of the servers before it can proceed. If an error occurs the ticket is not saved on the server and a message is sent to the WebPOS client to show the error.


Hardware Manager window

Bulbgraph.png   Starting from RR17Q1 below functionality is available

This window defines the list of Hardware Manager URLs with configured printers that are available for assigning to POS Terminal Types.

See Hardware URL for configuring Hardware Managers for each Terminal Type.

For each Hardware Manager record you have to configure the following fields:

Hardwaremanagerwindow.png
Bulbgraph.png   Starting from 19Q2 below functionality is available

A process called, Delete Auto Registered Hardware URL, allows to delete the automatically registered hardware manager urls. This process shows a pick and execute window that will let the user select the hardware managers that wants deleted.

Once the records to delete has been selected and the process is executed they will be removed with its dependencies in Touchpoint Type window.

Offline Mode

The WebPOS supports offline operation. One of the most important parts of the support for offline operation is being able to save the application sources in a persisted state, so that if the connection is not available, the application can nonetheless be started correctly.

In previous versions of the application, we used the Application Cache technology to persist the application sources. This is still supported in current versions, and we expect to keep it for some time. However, starting from RR18Q3 we now also support the persisting of application sources using Service Workers. Service Workers are the preferred way to persist the sources nowadays, because they are more flexible and they give greater control to the developer of which resources he wants to cache, and how to manage this cache. However, they are not yet fully available in all browsers, which is the main reason why we are keeping the support for Application Cache as of now.

In RR18Q3, Service Workers was enabled by default for Google Chrome users. In RR20Q3, it was also enabled by default for Safari users.

However, as previously explained, it is possible to switch between Service Workers and Application Cache using the preference "Web POS Use Service Workers for Offline Support". This is a system-admin preference which must be defined using System Administrator role, and only once per system. If it's set to 'Y' (or if it doesn't exist) then Service Workers are enabled, otherwise Application Cache will be used instead.


Bulbgraph.png   Starting from 18Q4 It is possible to restrict the amount of time the terminal can remain in offline mode

This can be configured with the "Web POS Maximum time which the terminal can be offline" preference.


Bulbgraph.png   Starting from 18Q4 Offline mode has changed slightly, and now it doesn't necessarily require authentication

You can use the "Web POS Offline session time expiration" preference to specify how much time will the WebPOS consider a session still valid while being offline. This will slightly change the way the POS behaves is the user refreshes the application while being offline: before, it would always ask for the user to enter credentials to continue, and now it will only ask him to do so if the session is no longer considered valid.

Customizing UI through Touchpoint UI Configuration

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

A new window has been created to configure which actions will be shown in Web POS and where to place them. Below you can find the list of actions buttons areas which are available to be customized using this feature.

How to create a custom Touchpoint configuration

Step 1 (header): Create a new UI Configuration
Step 1 - Create the Touchpoint UI configuration
Step 2 (2nd level tab): Define which action button areas are going to be customized
Step 3 (3th level tab): Add and select the place for desired actions
Step 2 & Step 3 - Configure the action button area and its actions
This is the aspect of Web POS after apply above configuration

Other configurations

example 1
Example using col span and row span
This is the aspect of Web POS after apply above configuration
example 2
Example configuring receipt top area
This is the aspect of Web POS after apply above configuration

Action button areas available in "Main Web POS" window

Receipt Top Area [3.0RR19Q3]

This action button area is located at the top of the ticket. This area allows to customize 6 actions distributed in one row (from 0 to 5). This Action button area does not provide any layout variant. The configuration provided by default by Web POS does not add any button in this action button area. If you want to add new buttons here a new Touchpoint configuration must be used.

Aspect of the edit keyboard using default configuration
Edit - Bottom Right Button Area [3.0RR19Q3]

This action button area is located next to the keyboard which is shown when a line is being edited. It consist of a layout with 2 columns (0 to 1) and 6 rows (0 to 5). This action button area provides a layout variant which allow to place the action button area at the right or at the left of the keyboard (By default will be placed at the left of the keyboard).

Aspect of the edit keyboard using custom configuration with right as a value for layout varyant
Scan - Bottom Right Button Area [3.0RR19Q3]

This action button area is located next to the keyboard which is shown when SCAN is selected (no line selected). It consist of a layout with 2 columns (0 to 1) and 6 rows (0 to 5). This action button area provides a layout variant which allow to place the action button area at the right or at the left of the keyboard (By default will be placed at the left of the keyboard).

Aspect of the scan keyboard using default configuration

Security Settings

View larger

Not every user is supposed to have access to Web POS and not every Web POS user is supposed to have access to Cash Up and Cash Management. You can set access to these windows in the back office as follows.

Enabling a role to access Web POS:

Setting access to specific functionality:

Note roles defined as Automatic (Manual field is unchecked) have access to all functionality regardless preferences.

The following functionalities are relevant for Web POS users:

The following functionalities are related to Quotations:



Note that access to Cash Up and Cash Management will be disabled by default for new roles.

When the user has no access to specific menu entries these ones will be hidden in the menu


Enabling specific terminals for users:

Starting Openbravo for Retail RMP20, specific users can be given access to specific POS terminals. This is done through the POS Terminal Access tab in the User window.

View larger


The following rules are followed to decide whether a user has access to a terminal or not:


Bulbgraph.png   Starting from RR17Q4 below functionality is available

Several preferences have been created to be able to show or hide the action buttons related to the products in the order. The default value is to show them. Some examples of the preferences:

Approvals

Bulbgraph.png   This feature is available starting from RMP26

Some actions require of supervisor's approval in order to be accomplished.

When an action requiring of approval is performed a pop up requesting supervisor's credentials is shown and it is not possible to continue till these credentials are provided or the approval is cancelled aborting the action in this way.

In case the user launching the action is a supervisor, no approval is requested to complete it.

Supervisor

Each action requiring approval can have its own supervisors, thus it is possible for a user to be supervisor of action A but not action's B supervisor.

Each Approvable Action require of a different preference to be set:

Note that, as opposite as the other security preferences, supervisor preferences require of explicit setting, this means automatic roles are not considered as supervisor unless there is a preference defining it.

Approvable Actions

Here is the list of actions that can require approval:

Audit Information

Whenever an action is approved by a supervisor, the Sales Order created in the back office keeps track of the supervisor's user as well as the action she approved.

This information can be seen in the Approvals read only sub tab in Sales Order window.

This sub tab contains the following 2 columns:

Offline

Approvals can be granted in offline mode. In order to approve an action being in this mode, it is required that the user that has granted to that action has logged in at least one time being online in the terminal

Terminal Authentication Security

A fundamental WebPOS mandatory rule is not to access the same POS Terminal from two or more devices / web browser instances. For the same reason, it is not allowed to access from the same web browser instance to two or more terminals. To help avoid this, Openbravo have created the Enhanced Security Authentication.

Starting from RR16Q1 this functionality will be enabled by default thanks to the preference Terminal Authentication enabled.

If someone wants to overwrite the value of the main preference, a new preference for the same property should be created. The value of that new preference will override the value of the original one.

Take into account that this preference (to override the default one) should be created leaving the client field empty and it should be visible for Organization "*"

Term authentication preference.jpg


Remember that if terminal authentication is enabled, every terminals will share the same URL and then a specific terminal will be linked.

If security is not enabled we need to put the terminal searchKey in the URL.

Bulbgraph.png   When a new device is used in a terminal, it is very important to clean the browser cache in the new device, to prevent corruption data.

Other Settings

The following preferences can be also set.

Web POS Locale Settings

Language

UI language in Web POS works in a similar way as in ERP: it is defined per session and can be changed, while being online, from User > Profile dialog.

Bulbgraph.png   Topics covered in this section below this line are available starting from RMP31

It is possible to define a default language for Web POS at role level, this default language will be set to user when the role is set as default for Web POS. Additionally it a user can be restricted not to change her defaults by using the Change Profile Settings preference.

Business Objects such as Product, Product Categories, Taxes, Promotions and Discounts, etc. Are also translated to the same language the UI is set to.

Formats

Date and Numeric

Numeric and date formats in Web POS are defaulted to the same that in backoffice.

Bulbgraph.png   Topics covered in this section below this line are available starting from RMP31

Starting from RMP31 these formats can be set different to the default ones at Store, Group of Stores or Group of Organization levels. It will be used the most specific one, for example having this Organization tree: 

 Formats in Format.xml:
     date: dd/MM/yyyy
     numeric: "." decimal, "," for thousand grouping

 Organizations/Stores definition:
  * 
  |- Group 1 (defined date format: MM-dd-yyyy)
  |   |- Store 1.1 
  |   |- Store 1.2 (defined numeric format: "," decimal, "." for thousand grouping)
  |- Group 2 (defined numeric format: "," decimal, "." for thousand grouping)
      |- Store 2.1
      |- Store 2.2 (defined numeric format: "." decimal, "," for thousand grouping)

The format that would be used in each of the stores would be:

Store Date Format Numeric format (decimal/thousands separator)
Store 1.1 MM-dd-yyyy (taken from Group 1) ./, (taken from Format.xml)
Store 1.2 MM-dd-yyyy (taken from Group 1) ,/. (taken from Store 1.2)
Store 2.1 dd/MM/yyyy (taken Format.xml) ,/. (taken from Group 2)
Store 2.2 dd/MM/yyyy (taken Format.xml) ./, (taken from Store 2.2)

These settings can be configured in Organization window:

WebPOSFormat.png


Currency Format in Web POS is the same that in backoffice. It will be used to change the decimals of currency , by default it will be #,##0.00 , the same that priceInform in Format.xml.

Bulbgraph.png   Topics covered in this section below this line are available starting from 3.0RR17Q2

Starting from 3.0RR17Q2 this format can be set different to the default one at #,##0.0 and #,##0.

The value of this field is defined in priceInform in Format.xml.

Formats in Format.xml: 

  <Number name="priceInform"
      decimal="." grouping="," formatOutput="#,##0.00" formatInternal="#0.00"/>

Organizations/Stores definition: 

  * 
  |- Group 1 (defined currency format: #,##0)
     |- Store 1.1 
  |- Group 2 (defined currency format: #,##0.0)
     |- Store 2.1 
  |- Group 3 (defined currency format: #,##0.00)
     |- Store 3.1

The format that would be used in each of the stores would be:

Store Currency Format
Store 1.1 #,##0
Store 2.1 #,##0.0
Store 3.1 #,##0.00

These settings can be configured in Organization window


Print Templates

Print templates are used to print different reports from Web POS. Default ones can be overwritten by others provided by external modules.

Bulbgraph.png   Topics covered in this section below this line are available starting from RMP31

In the same way it is possible to change date and numeric formats at Store/Organization level, templates can be defined at those levels. They are set in Organization window in Web POS Formats field section. Precedence of these settings works in the same way as described in previous section.

Do not clean the browser cache - Updating the Client Web POS

In normal operations the client side application is automatically updated when updating Web POS modules on the server. However in some cases it makes sense to refresh the client side application explicitly.

One way of refreshing the Openbravo Web POS client is to clean the cache. Then when refreshing the page the Web POS is reloaded from the server. But as is noted here one should be really careful with cleaning the cache during business operations.

Therefore this section describes a method which allows you to update the client side application without cleaning the cache.

  1. In the browser with Web POS go to the following URL: chrome://appcache-internals/
  2. Find the manifest with the url of the Web POS (most likely there is the only one manifest, see below)
  3. Press on Remove option for this manifest.
  4. Close the page, close the browser.
  5. Start the browser, start the Web POS by going to the original WebPOS URL.


WebPOSCleanAppcache.png

Hide Cash Up Information to the Cashier

Bulbgraph.png   Starting from RR16Q4 below functionality is available

Since 3.0RR16Q4, it has been implemented a new property configurable from the Preference window named OBPOS_HideCashUpInfoToCashier. This preference allow to hide some critical information to the user in the cash up part.

Follow this link to learn more about this new functionality.

Configuring Web POS Import Transaction Process

Bulbgraph.png   Starting from RR15Q3 below functionality is available

From the 2015Q3 version of Openbravo Retail transactions which are sent through the server are imported by a separate process using parallel processing. The benefit of this approach is that it makes the Openbravo Retail solution much more stable in very high volume environments (1000 tickets/minute).

The import process will try to process transactions in parallel:

So if there 10 stores, and in each store there are POS systems submitting tickets/cashups and business partners, there will be a total of 30 processes started. They are executed in parallel if there are CPU-processors available.

The parallel processing and even the disabling of this new import process can be controlled through several configuration parameters which can be defined in Openbravo.properties:

Import Entry JMX Extension

The Import Entry has a JMX extension that exposes the following operations: 

2022-08-02 11:30:56,652 [RMI TCP Connection(2)-127.0.0.1] INFO  org.openbravo.service.importprocess.ImportEntryManager - Import Entry Manager
* Active threads: 1/11
* Processor queue size: 0/1000
* Current cycle: 9
* Blocked type keys in this cycle (0): []
* Processors:
 
* Shut Down: false
Cluster Service - IMPORT_ENTRY
* cluster: false
* node enabled: true
* handling in this node: true

Import Entry High Availability

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

Before 3.0PR18Q2 release when working in a clustered environment, it was only supported to run the import process in the same (one) node of the cluster. This was done by setting the import.disable.process property as true for that node.

Starting from 3.0PR18Q2 it is possible to configure the import entry processing as a high available service for the cluster. This means, that in case the node in charge of handling the service fails, eventually another available node of the cluster will take care of processing the import entries, replacing the node that failed.

To enable this feature two properties have to be configured in the Openbravo.properties file of each cluster node:

Import Entry Cluster Service Settings

Once this feature is enabled, by default, each node in the cluster will check (ping) every 10 seconds if the node in charge of executing the import process is still "alive" or, on the other hand, if it should be replaced with another node of the cluster.

It is possible to change this default time to use a custom value by using the Cluster Service Settings window.


ClusterServiceSettings.png


In this window a new record should be created with the following values:

Bulbgraph.png   After establishing the new configuration in this window, it will be required to restart every cluster node.

Cluster Service Management Extension (JMX)

This feature also provides a management extension available through JMX. This extension provides the following operations:

Supporting High Volume Master Data: Remote Master Data Handling

Bulbgraph.png   Starting from RR15Q4 below functionality is available

To support high volumes of products, customers Openbravo allows you to work remotely with master data from the WebPOS client. The high-volume master data is then not loaded into the WebPOS client database but is accessed when needed on a cloud server.

The following data can be handled remotely from WebPOS clients:

By enabling remote data handling the WebPOS clients are capable of working with millions of products, prices, and customers.

By default remote data handling is disabled. The enabling of the remote data functionality is controlled by several preferences which are discussed in the next section.

Note that enabling remote data has the consequence that it is not possible to operate the WebPOS client in complete offline mode.

Remote Data Preferences

Several preferences are used to control which data is handled remotely. These are illustrated in the screenshot below. The screenshot below shows that by default the remote-data preferences are set to N. To enable remote data handling you have to define the related preferences and set the value Y. In addition, 'Selected' check-box has to be set as Y too. In the screenshot below this is illustrated.

Note: it is important to define the preferences on at least one of client/org/user/role level to ensure that the system will prefer it over the default preferences which are set to N.


PreferencesRemote-OK.png

Use Contains Remote Data Preferences

There are also two preference more for remote searching: Use contains in Remote Customer search and Use contains in Remote Product search. By default, remote queries are done using starts With to filter in order to improve performance of those queries. In case of you need to filter using contains, you can create these preference setting them to 'Y' to have this ability in Web POS for remote models. Non remote models already use contains to filter.

Remote Data: Product Categories

In case of a high volume of product master data, so when products are accessed remotely then the way product categories are loaded by the WebPOS clients is also changed. The system needs to run an update process in a daily (for example) batch to determine which product categories should be loaded by which WebPOS.


Remote-Data-PC-Process.png


After running the process the product categories which are loaded in the client are displayed in the assortment. Note, the subtab is only visible if there are product categories linked to an assortment.


Remote-Data-PC-AssortmentSubtab.png


Remote Master Data Limitations - Future enhancements

In the 15Q4 release, the remote data capability also has some limitations, these will be addressed in future releases:

So in high volume environments it is better to limit the number of discount definitions by defining them on product/BP category level or only for specific business partner.

Default Web POS layout in case of remote product data (no browse/catalog option):


Remote-Data-WebPOS-UI.png

Retail Extension Modules enabled for Remote Data

In the subsequent releases many extension modules have been checked for their support of remote product/business partner data. Also automated tests have been added to ensure continuous correct operation with remote data.

This is the current (16Q2 release) list of modules which have been tested with remote data, most are also tested automatically:

Discount Modules (see limitations section, the remark for discount setup there still applies):


As a next step parallel to the 16Q2/Q3 releases we are adding automated tests on high volume datasets for many of these modules. This section will be updated when the automated tests on high volume data are enabled (probably around 16Q3 timeframe).

Terminal information and logging

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

Since 19Q1 release, the WebPOS is able to log any user action and system process execution which took place during the usage of the application. This information is then sent to the server, and stored in Openbravo.

A system administrator can then review this log to debug the system and better understand the causes of errors.

What can currently be logged

Currently three main items can be logged:

How the log is generated

Both user actions and processes are logged automatically, the developer or admin doesn't need to do anything about it. Technical log messages are logged if they have been added in the code.

The log is collected in the frontend, and then is synchronised to the backend in an efficient way

Log configuration

There are several preferences which allow system administrators to configure how much log they want the system to generate:

Mobile Log Client Save Level (Trace/Debug/Info/Warn/Error/Critical): Level of logs saved in backend (by default Warn) Mobile Log Client Console Level (Trace/Debug/Info/Warn/Error/Critical): Level of logs displayed in console (by default Info)

Reviewing the log

Once generated, the log can be reviewed in the Terminal Log window. On this window, you can filter by device id (terminal), date, log level (so you can show each of the log categories independently, or combined), and context.

The context is a descriptor of the state of the system the moment a particular log even was generated. In the case of the WebPOS, it can contain either the name of the window (and modal popup if there is one open), and specifically in the main WebPOS window, it will contain the document number of the ticket which was open in the screen. This can be very useful to get all the log events which happened in the context of one particular ticket.


TerminalLog.png

Retrieved from "http://wiki.openbravo.com/wiki/Retail:Configuration_Guide"

This page has been accessed 147,639 times. This page was last modified on 2 March 2023, at 06:36. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.