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

PDF Books
Add page
Show collection (0 pages)
Collections help

Search

Cấu Hình MobiSales

Back to main page

Contents

Introduction

This document describes how to configure CloudERP for Retail explaining solution specific settings in

For generic documentation about CloudERP configuration please follow the Quick Guide. If you are trying out CloudERP for Retail 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 CloudERP for Retail

Bulbgraph.png   The Retail system manages to hit a bug in the PostgreSQL database version as being currently shipped in the CloudERP 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

To install the module (an CloudERP Professional instance is needed because it is a commercial module):

Add Retail Stores to the Organization Model

In CloudERP 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... CloudERP 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

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.

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:

Note: Only products included in the assortment and have a price defined in the price list assigned to the store will be available to sell.

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:

Customers default configuration

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

CustomersConfiguration rmp19.png

Grouped products

By default all of the products are grouped in MobiSales. 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).

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

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

OBPOS view cross store.png

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 MobiSales 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

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 MobiSales Product Images from server instead of cache, and with value Y.


OBPOS image preference.png

This preference will tell the MobiSales 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.

OBPOS generateimageprocess.png

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 MobiSales terminals should be able to load all product images without trouble.

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

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.

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.

Masterdata.png

In the header, you configure the following fields:

step will appear to open drawer before finish paying the ticket.

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 both on login, and periodically every number of minutes as specified in the field.

If only the second field is filled the system will fully load the data the first time the user logs in the POS, and afterwards only incremental loads will be done (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.

PaymentM.png

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

Cash Up

Cash management

POS Terminal window

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

PosTerminal.png

In the header, the following fields are configured:


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. 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 MobiSales, 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 MobiSales, if you change the configuration while the terminal is operating you could have errors in the terminal or data inconsistency.

CashUpHistory.png

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

In the reconciliation subtab, the following information is configured:

Security Settings

View larger

Not every user is supposed to have access to MobiSales and not every MobiSales 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 MobiSales:

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 MobiSales 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 CloudERP 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:

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.

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

In order to enable the new Terminal Authentication Security (Enhance Terminal Authentication) exists a Preference: Terminal Authentication enabled. By default, this preference has 'N' value, put 'Y' to enable Authentication security.

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

Other Settings

The following preferences can be also set.

MobiSales Locale Settings

Language

UI language in MobiSales 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 MobiSales at role level, this default language will be set to user when the role is set as default for MobiSales. 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 MobiSales 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

Print Templates

Print templates are used to print different reports from MobiSales. 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 MobiSales Formats field section. Precedence of these settings works in the same way as described in previous section.

Retrieved from "http://wiki.openbravo.com/wiki/C%E1%BA%A5u_H%C3%ACnh_MobiSales"

This page has been accessed 453 times. This page was last modified on 15 July 2014, at 09:46. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.