+ All Categories
Home > Software > Openbravo Retail Configuration Guide

Openbravo Retail Configuration Guide

Date post: 29-Jul-2015
Category:
Upload: mehmet-demirel
View: 205 times
Download: 1 times
Share this document with a friend
Popular Tags:
24
www.unibravo.com All Right reserved by Openbravo Openbravo Retail Configuration Guide
Transcript
Page 1: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

Openbravo Retail

Configuration Guide

Page 2: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

Openbravo Retail Introduction

This document describes how to configure the following specific settings of the Openbravo Commerce Platform:

Enterprise model Store pricing Assortment Cash Management Web POS

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

If you are trying out Openbravo Commerce 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 Retail system manages to hit a bug in the PostgreSQL database version as being currently shipped in the Openbravo rPath Appliance which can lead to bad performance of the application. To avoid this for the moment we recommend to use the On Demand or Ubuntu installation methods

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

Login as System Administrator Navigate to General Setup -> Application -> Module Management Click the Add Modules tab Find the Openbravo for Retail module within the list of available modules. Click on Install Now and follow the guided installation flow

Page 3: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

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:

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:

o Represents a physical retail store

o Only leaf organizations should be configured as store type

o The POS terminals set up in Openbravo shall be restricted to stores

o Must have an Anonymous Customer (Business Partner defined as Customer)

o Must have an Anonymous Customer Location

o Must have at least one on-hand warehouse defined in the "Warehouses" tab

o The currency defined is the currency that will be used in all terminals of this store. The currency used can be

edited to define retail configurations like the precision used in Web POS terminals.

Group:

o Represents a grouping of stores (or other groups)

Page 4: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

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:

Prices defined at store level will always overwrite the prices defined at parent level

If the store does not have any attached price list, the price will be inherited from the parent element (store group) in

the organizational structure

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.

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.

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:

Clone: New button is displayed in the toolbar. It will create a copy (clone) of the selected assortment. Newly created

assortment is opened in form view in order to let the user modify it if required

Include all products: The user will be able to include all products at once in the assortment by using this button.

Duplicated products in the same assortment are not allowed

Page 5: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

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.

Assortment management rules:

If a store has an attached assortment, it can only trade with products defined inside the assortment

Assortment defined at store level will always overwrite assortment defined at parent level

If the store does not have any attached assortment, the assortment will be inherited from the parent element (store

group) in the organizational structure

Notes:

Only products included in the assortment and have a price defined in the price list assigned to the store will be

available to sell.

Page 6: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

Products with attributes are only supported in Openbravo Retail if all the characteristics are not mandatory.

See this issue.

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.

For each event you need to define the following:

Name: Name of the event. In "in/out" event type, the name can be seen as the event reason shown in WebPOS to

allow the cashier give more detail of the operation (e.g it can be different reasons for withdrawing money from the

store, for instance the cash security level is reached in the store, or we need to transfer money from one store to

another)

Currency: Currency of the event

Payment Method: Payment method associated to this event. In case of cash up, it is necessary to create as

different close events as different payment methods are supported in the store

Event Type: In, out, close depending on the nature of the event

Financial Account: The account which will be the destination (or the origin) of the cash movement and it depends

again on the nature of the event. For in case, it is the financial account from where money is going to be extracted

(origin). For out case, it is the financial account from where money is injected (destination). Finally, for close it is the

financial account where money is also going to be injected (destination). Be careful, do not use the same

financial account in payment types (payments allowed for a POS Terminal) and for "close" Financial

Page 7: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

Accounts. Moreover, it is recommended to use a different financial account in payments allowed for a

POS Terminal and for the "cash management" events.

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.

Default invoice term for BPs

Default payment term for BPs

Default BP Category for BPs

Default country for BPs

Default organization term for BPs

Show Tax ID for BPs Edition: If checked, this option will show an extra field to insert the Tax ID.

Show BP Category selector for BPs edition: If checked, this option will show an extra field to select the BP

category.

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.

Since RMP32 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 (Not allowed before).

Page 8: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

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

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

Page 9: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

Product Images

By default, the product images are automatically loaded into the browser local database, so they can be used offline in a

convenient way. However, the browser local database has a maximum size limitation in all environments, and in some of

them this maximum size can be quite restrictive (specifically, in iOS, the maximum size is restricted to 50 MB).

If this maximum size is not enough for your needs, you can configure the Web POS so that it doesn't save the images into

the local database, and instead requests them directly to the server.

The slight downside to using this method is that in when the POS goes offline, images for previously used products will be

available, but the images for products not yet used will not (the generic 'box' image will be shown instead). If this downside

is not relevant for you, then you can definitely use this method to make it possible to use big amounts of products with

images in devices such as the iPad

Page 10: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

How to configure the alternate way to load images

The first step to configure this alternate way to load images is to create a preference in the system, with property Web POS

Product Images from server instead of cache, and with value Y.

This preference will tell the Web POS that it needs to load images from the server directly, instead of loading them from the

local database.

To improve the performance of this functionality, and ensure that the server is not overloaded with the image requests, the

images are read directly from files in the server, instead of the database. This means that image files need to be generated

from the product images in the database. To do this, a process called Generate Product Images needs to be run.

Page 11: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

This process receives an assortment as a parameter, and will generate files for all products in the assortment which contain

an image. After this process has been run, the Web POS terminals should be able to load all product images without trouble.

Web POS module

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

Most of the configuration take place in two windows:

POS Terminal Type

POS Terminal

The POS Terminal Type window contains what can be described as a "POS Terminal Configuration". This is a configuration

designed to model a type of POS terminal. Each POS Terminal can only have one POS Terminal configuration.

Page 12: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

It allows a very flexible configuration and an example would be a multi-store company. Each store could be managed

differently (e.g have different cash up processes). In this case, different Pos Terminal Types could be defined for each store.

And terminals within same store could share the same Pos Terminal Type.

This two tables are designed to simplify the configuration process for the user: if the user needs to configure 100 terminals,

but all of them are basically identical, then the amount of data he will need to insert is quite small, because all POS terminals

will point to the same POS Terminal configuration.

In this section, we will first describe how POS Terminal Types are configured, and then we will describe the POS

Terminal window.

POS Terminal Type window

In this window, you basically design a POS Terminal configuration, which will be used by one or many POS terminals. Here

you configure relevant information at POS level, but also at payment method level.

In the header, you configure the following fields:

Name: The name of the POS terminal type

Document type: The document type used for sales orders, note see the performance section for its influence on

cashup and ticket creation performance in the backend.

Document type for returns: The document type for returned receipts

Document type for reconciliations: The document type used for the reconciliations done when executing the

"Cash up" process in the POS

Document type for quotations: The document type for quotations

Group orders in one invoice: If checked, then all orders processed in Web POS without an invoice are grouped by

Business Partner and an invoice for each group of orders is created in the Cash Up process. If unchecked, one

invoice per order will be created. Note see the performance section for its influence on cashup and ticket creation

performance in the backend.

Allow pay on credit: If checked, all POS terminals of this POS terminal type will be able to pay sales orders as a

credit.

Default Payment Method: Selects the payment method that will be used by default when closing a receipt.

Use external input: (Previously Use barcode scanner) If checked, the Web POS will take into account that an

external input (keyboard or barcode scanner) is going to be used in this POS terminal type. Checking this option and

then not connecting an external barcode will cause the virtual keyboard to be shown continuously in some devices

(specifically, in iOS devices (iPads, iPhones)).

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

Time to fully refresh masterdata (in minutes): A full refresh is the process of reloading the whole masterdata

set (including products, business partners, prices, taxes, ...). This operation is very expensive and time consuming,

so it should be done only when really needed (typically, every day). If done with too much frequency, this may tax

too much the server, greatly slowing down the operation of POS terminals.

Page 13: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

Time to incrementally refresh masterdata (in minutes): This process is much lighter than a full refresh,

because it only loads records which were changed from the last time a refresh was done. This is much less expensive

than a full refresh, but has the disadvantage that if a record was deleted, it will not detect it.

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 both on login, and periodically every number of

minutes as specified in the field.

If both fields are specified, then both incremental and full reloads will be done each number of minutes as indicated on each

field.

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

Search key: An identifier string for the payment method.

Name: The name of the payment method

Payment method: The Openbravo payment method associated with this POS payment method

Currency: The currency associated to this payment method in POS

G/L Item for Writeoff: In case the amount received when paying a ticket differs from what is expected, this G/L

Item reflects this difference. We strongly recommend using the name of the POS terminal and the Payment

method for naming the G/Item in order to avoid problems with matching transactions and bank

statements. Example: VBS Cash overpayments

Payment Provider: Dialog that will be used to confirm the payment of a receipt using this payment method,

usually the dialogs listed in this field are included by payment gateway modules.

Refund Provider: Dialog that will be used to confirm the refund of a return order using this payment method,

usually the dialogs listed in this field are included by payment gateway modules.

Allow Open Drawer: If checked, to paid, the cash drawer will be opened

Open drawer before closing ticket: If checked, when paying a ticket, new step will appear to open drawer before

finish paying the ticket.

Cash: When checked indicates this payment method is a cash method and will show a coins and bank notes panel

when selected. To configure a new coins and bank notes panel go the document How to create a new coins and bank

notes selector. It also indicates that overpayments made with a cash method will be returned to the customer and

the change to return to the customer will be calculated and displayed in the payment panel.

Default Cash Payment Method: only shown for a cash payment method, when there are multiple cash payment

methods one of them can be flagged as the default cash payment method, is used for example when displaying the

initial count view in the retail sessions module.

Page 14: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

Show coin keypad: If the payment method is cash you can configure if you want to see the coin keypad checking

this field to yes. If unchecked, the basic numeric pad will appear.

Starting from RR15Q1 there is a new field Max. Limit Amount: This amount limits the quantity of money you can

use to pay a ticket for that payment method. For example if the tickets is 505€ and the limit for the cash payment

method is 500 the system will show a message "The maximum limit (500 €) for this payment method has been

exceeded. Payment not allowed"

Starting from RR15Q2 there is a new field Payment method Category: This combo allows to group different

payment methods in one category. This categorization means that when being in the payment panel instead of

seeing all the payment methods the user will see just one. When clicking the button it will show the payment

methods that belong to it

Starting from RR15Q2 there is a new field Image: This field makes sense when the payment methods is

categorized, that is, when it belongs to a Payment Method Category. When the popup gets opened it will show not

only the name of the payment method but an image. Taping the image will select the payment

Cash Up

Automate movement to Other: If this field is selected, there will be an additional step during the cash up process

for this payment method, which will allow the user to specify how much money should be kept in the main account,

and how much will be moved to a secondary account (configured in the Cash Management Events tab

of Organization window). Hence, if you select this, following checks need to be considered, which are the different

options given to the user while cashing up for this payment method:

Keep Fixed amount: A fixed amount will be kept in the financial account of the terminal

Amount:: The amount for the previous option

Allow variable amount: If checked, the user will be able to input an amount to keep in the financial account of the

terminal

Allow not to move: If checked, the user will be able to keep everything in the financial account of the terminal, so

not "moving" money

Allow move everything: If checked, the user will be able to move all money to the destination financial account

configured in the Cash Management Event

Cash differences: This G/L Item is used if there are cash differences during cash up (theoretical amount different

than the counted one). The created transaction will be associated with it.We strongly recommend using the

name of the POS terminal and the Payment method for naming the G/Item in order to avoid problems

with matching transactions and bank statements. Example: VBS Cash differences

Cash deposit/withdrawal: This G/L Item is the one associated in the transaction added in the financial account in

both terminal and backoffice after cash up processed is processed. So it is important a G/L Item is configured

here. We strongly recommend using the name of the POS terminal and the Payment method for naming

the G/Item in order to avoid problems with matching transactions and bank statements. Example: VBS

Cash G/L Item for Cash up

Count Cash: For payment methods marked as Cash indicates whether to show or not a cash count step in the cash

up process to count the cash amount in the drawer with the help of currency denominations. To activate this option

you must configure first Coins and Bank notes in the Currency window for the payment method currency.

Cash management

Allow withdrawals: If checked, withdrawals can be created associated with this payment method

GLItem for withdrawals: The G/L Item associated with the transactions created for withdrawals. We strongly

recommend using the name of the POS terminal and the Payment method for naming the G/Item in

order to avoid problems with matching transactions and bank statements. Example: VBS Cash

withdrawal

Allow deposits: If checked, deposits can be created associated with this payment method

GLItem for deposits: The G/L Item associated with the transactions created for deposits. We strongly

recommend using the name of the POS terminal and the Payment method for naming the G/Item in

order to avoid problems with matching transactions and bank statements. Example: VBS Cash

differences

Starting from RR15Q2 below functionality is available

Page 15: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

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.

POS Terminal window

In this window specific POS terminals can be added. Every POS terminal needs to be added here.

In the header, the following fields are configured:

Search key: An identifier for this terminal, it must be unique and it is the one that is going to be used in the URL to

access the terminal

Name: The name of the terminal

Hardware URL: The URL of the receipt printer, it will be given by the hardware manager, followed by /printer

Scale URL: The URL of the scale

Order Document No PREFIX: This prefix is used for the POS order documents generated in Sales Order window in

the backoffice for each ticket of the POS terminal

Order Quotation No Prefix: This prefix is used for the document number of POS quotations generated in this POS

terminal.

POS Terminal type: The Terminal Type which describes the configuration used by this POS terminal

Default Tab for Web POS: Ability to define whether the tab for selecting products is Scan (when scanning products

is the main action) or the browse

Page 16: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

Default customer: The customer can be configured at store level or at terminal level. In this case it is more

restrictive so if it is filled then the system will use this customer instead

Terminal Key Identifier: When Terminal Authentication enabled preference is 'Y', this is the code for this POS

Terminal configuration. Using for first time a physical device connecting to Web POS we will be able to link the device

to this configuration using this code.

Is linked to a physical device: This field is checked when a physical device is linked to this POS Terminal

configuration using Terminal Authentication security.

Unlink device: This process button allow us to unlink the actual physical device from this configuration. We could

lose data not synchronized in the ERP (terminal is offline and exists data to send to the ERP), we need to be sure of

this action.

In the payment type, the following information is configured:

Search key: It is an identifier string for the payment method.

Name: The name of the payment method

Payment method: The payment method type defined in the POS Terminal Type, which contains the configuration

information for this payment method

Financial account: The financial account associated with this payment Very important: The financial account

must be associated only with this payment. The Organization of the Financial Account, must be in the

Org Access list of the User Role (Only in the Cash Up process) . POS processes will not work correctly

otherwise

Cash management close event: The cash management close event which should be used when executing the

cash up process

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. 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 orpayment.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 posterminal has an open cashup. This window is to define configuration before start

working in Web POS, if you change the configuration while the terminal is operating you could have errors in the terminal or

data inconsistency.

Page 17: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

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

Organization: It is store of the POS Terminal.

User/Contact: The name of the user who did the cash up.

Cashupdate: The date when the cash up was done.

Cash Up Report: This process button, create a pdf report with all the information about the cash up.

In the reconciliation subtab, the following information is configured:

Payment type: It is payment type which is related to the financial account of the reconciliation.

Reconciliation: The reconciliation itself.

The functionality described below is available starting from 15RRQ2

Override POS Terminal Type Configuration: this flag allows to override the configuration of the cash up defined

in the POS terminal type – Payment Method.

o Automate movement to Other: If this field is selected, there will be an additional step during the cash up

process for this payment type, which will allow the user to specify how much money should be kept in the

main account, and how much will be moved to a secondary account (configured in the Cash Management

Events tab of Organization window). Hence, if you select this, following checks need to be considered, which

are the different options given to the user while cashing up for this payment method:

o Keep Fixed amount: A fixed amount will be kept in the financial account of the terminal

o Amount: The amount for the previous option

o Allow variable amount: If checked, the user will be able to input an amount to keep in the financial

account of the terminal

o Allow not to move: If checked, the user will be able to keep everything in the financial account of the

terminal, so not "moving" money

o Allow move everything: If checked, the user will be able to move all money to the destination financial

account configured in the Cash Management Event

Page 18: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

o Cash differences: This G/L Item is used if there are cash differences during cash up (theoretical amount

different than the counted one). The created transaction will be associated with it. We strongly

recommend using the name of the POS terminal and the Payment method for naming the G/Item

in order to avoid problems with matching transactions and bank statements. Example: VBS Cash

differences

o Cash deposit/withdrawal: This G/L Item is the one associated in the transaction added in the financial

account in both terminal and backoffice after cash up processed is processed. So it is important a G/L Item

is configured here. We strongly recommend using the name of the POS terminal and the Payment

method for naming the G/Item in order to avoid problems with matching transactions and bank

statements. Example: VBS Cash G/L Item for Cash up

o Count Cash: For payment type marked as Cash indicates whether to show or not a cash count step in the

cash up process to count the cash amount in the drawer with the help of currency denominations. To

activate this option you must configure first Coins and Bank notes in the Currency window for the payment

type currency.

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.

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.

Page 19: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

When creating new orders, shipments and invoices 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 POS

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.

Therefore the advice is to let different POS Terminals use different document sequences, especially in high

volume environments. This means that different POS terminals will have to make use of different POS Terminal Types.

Security Settings

View large

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:

Go to the Role window in the back office (General Setup > Security > Role)

Select the role you want to grant access to Web POS to

Go to the child tab called Form Access

If it does not exist yet, create a new record and set the Special Form field to Web POS.

Save and reload the Web POS for the changes to take effect

Setting access to specific functionality:

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

Go to the Preference window in the back office (General Setup > Application > Preference)

Create a new record and select the functionality in the Property field. For example order.discount or Web POS

window Cash Up.

Set the value to Y in the value field to enable access.

Set the desired visibility in the Visibility section below.

Save and reload the Web POS for the changes to take effect

The following functionalities are relevant for Web POS users:

Changing price (Web POS action Change price, by default revoked)

Giving discount (Web POS action Apply discount, by default revoked)

Page 20: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

Invoice receipt (Web POS action Invoice receipt, by default granted)

Return receipt (Web POS action Return receipt, by default granted)

Print report in Cash Up (Web POS action Print cash up, by default granted)

Print report in Cash Management (Web POS action Print cash management, by default granted)

Print receipt menu action (Web POS action Print receipt, by default revoked)

Using payment type card (Web POS payment Card, by default granted)

Using payment type cash (Web POS payment Cash, by default granted)

Using payment type voucher (Web POS payment Voucher, by default granted)

Accessing Cash Management (Web POS window Cash management, by default revoked)

Accessing Cash Up (Web POS window Cash Up, by default revoked)

Accessing Point of Sale (Web POS window Point of Sale, by default granted)

Accessing Back Office (Web POS Back Office, by default granted)

Creating Discretionary Discounts (Web POS action Advanced Discounts, by default granted; together with Web POS

action Apply discount)

Editing Firm Quotation check when creating order from Quotation (Web POS Quotation: Editable Firm Check, default

granted, available from RMP27)

Change profile settings (Mobile Change Profile, by default granted, available from RMP30). Allows to change profile

settings (role and language)

Sales with Returns (Do not allow Sales with return, by default revoked)

Switch from positive to return line (Enable switch from positive line to return line, by default granted)

Multi Order (Web POS Enable Multi Order menu entry, by default granted)

Receipt Discounts from Keyboard (Web POS Open Discounts From Keyboard, by default granted, available from

RMP28)

Open Drawer button (Web POS Open drawer from menu, by default granted, available from RMP29)

Select a specific warehouse to consume the goods for a specific order line (Allow to select a warehouse for a specific

line order), by default revoked.

Enable the functionality to split in shipment lines, lines from orders to be returned. (Split Lines in Shipments when

Returning, by default disabled, available from RR15Q2)

The following functionalities are related to Quotations:

Create Quotation (Web POS action create new quotation, by default revoked)

Sales Order from Quotation (Web POS action create sales order from quotation, by default revoked)

Reactivate Quotation (Web POS action reactivate quotation, by default revoked)

Show Quotation (Web POS action show quotations, by default revoked)

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:

Page 21: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

If a user doesn't have entries in the POS Terminal Access tab, then it can log in all the available POS Terminals

(provided that it has access to a role with access to the Web POS form).

If a user has entries in the POS Terminal Access tab, then it can only access the terminals specified there.

Approvals

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:

"Approvable Action" Preference with value N at client level. In order to show Approval Modal.

"Approvable Action" Preference with value Y at user's or role level. In order to give access to this action.

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:

When pressin Total toolbar button, approve Discretionary Discounts. Property Web POS Discretionary Discount

Approval (OBPOS_approval.discounts). More information about this action can be found here.

Open Cash Management window. Property Web POS Cash Management window

approval (OBPOS_approval.cashmgmt).

Open Cash Up window. Property Web POS Cash Up window approval (OBPOS_approval.cashup).

Open Cash Drawer in Cash Up window. Property Web POS Open Drawer approval Cas

Up (OBPOS_approval.opendrawer.cashup).

Open Cash Drawer in Point of Sale window. Property Web POS Open Drawer approval

Menu (OBPOS_approval.opendrawer.menu).

Remove suspended orders in Cash Up(Step 1) window. Property Web POS Remove Receipts Approval in Cash

Up (OBPOS_approval.cashupremovereceipts).

Remove receipts with Delete button or Login out. Property Web POS Remove Receipts

Approval (OBPOS_approval.removereceipts).

Remove an order line. Property Web POS Delete Line Approval (OBPOS_approval.deleteLine).

When pressing Total toolbar button, approve return lines. Property Web POS Returns

Approval (OBPOS_approval.returns).

Set price of a product in a line. Property Web POS set Price approval (OBPOS_approval.setPrice).

Approve difference between Expected and Counted cash. Property Web POS Cash Up Differences

Approval (OBPOS_approval.cashupdifferences).

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.

Offline

Page 22: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

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

In order to enable the new Terminal Authentication Security (Enhance Terminal Authentication) we must create a Preference

called Terminal Authentication enabled with value 'Y', client 'System' and organization '*'.

If security is enable we share the same URL in all terminals. If security is not enabled we need to put the terminal searchKey

in the URL.

Terminal Authentication enabled is 'N': Access url -->

openbravo/web/org.openbravo.retail.posterminal/?terminal=VBS-1

Terminal Authentication enabled is 'Y': Access url --> openbravo/web/org.openbravo.retail.posterminal/

Other Settings

The following preferences can be also set.

Quotations are not Firm by default. When creating an order from a quotation, by default Firm is checked unless this

preference is set to Y.

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.

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

Page 23: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

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.

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:

Page 24: Openbravo Retail Configuration Guide

www.unibravo.com All Right reserved by Openbravo

Print Templates

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

external modules.

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.


Recommended