This document explains the configuration required to use and sell Product Services both in backend and in Web POS, and the main flows that are available for the user
Back End Configuration
Allow Anonymous Sale
A new field has been added in Product window within POS Properties section.
This field is a checkbox, flagged by default, named 'Allow Anonymous Sales'.
When this checkbox is unflagged for a service, this service can not be sold in a ticket whose owner is the Anonymous Customer.
Anonymous Customer: the one defined in the store in a field named Anonymous Customer.
Store: can be found in the Organization window.
As explained on the Backend Configuration section, the Proposal Type indicates how the service will be proposed to the user during Web POS operations.
The values shown for the Proposal Type of the service depend on the Linked to Product flag. Services linked to product might have a Mandatory Proposal defined or an Optional Proposal defined.
Services not linked to products, on the other hand, might be defined with a Final Mandatory Proposal.
- Services Configured as Mandatory Proposal
In this case the product is defined as a “Service” in the Openbravo ERP, with checkbox “Linked To Product” checked and proposal type “Mandatory Proposal” is selected.
The expected behaviour is that this service is proposed in Web POS when the user adds a product that it is linked to the service. In this case when the user adds "Crampons 10 points" the service “Adjust Crampons” must be proposed before allowing the user to continue adding ticket lines.
- Services Configured as Optional Proposal
In this case the product is defined as a “Service” in the Openbravo ERP, with checkbox “Linked To Product” checked and proposal type “Optional Proposal” is selected.
The expected behaviour is that this service is going to be selectable in Web POS when the user adds a product that it is linked to the service. In this case when the user adds “Baby Carrier” the service “Fit in the car” can be selected.
When the product is added to the ticket, the icon is displayed in the line. If the user press that icon, the search tab is opened with all optional and mandatory services. The user is able to select one or more services.
- Services Non-linked to products: Final Mandatory Proposal
In this case the product is defined as a “Service” in the Openbravo ERP, with checkbox “Linked To Product” unchecked and proposal type “Final Mandatory Proposal” is selected. At the time of paying a ticket in Web POS, when the user taps the Total Amount button, the services search is automatically opened to show this kind of services.
When the user clicks on the CONTINUE button then the payment process continues and the payment tab is shown.
- Services Non-linked to products: Informative Proposal
In this case the product is defined as a “Service” in the Openbravo ERP but the checkbox “Linked To Product” is not checked and the Proposal Type field is empty.
The expected behavior is that the service is going to be able to use as normal product but the stock level is not going to be checked as it is a service.
In the Web POS, it will be possible to find the Service using the search tab and add the product to the ticket as a line. The difference with a product line is that service icon is displayed in the screen.
Special Case: Services Multiselection
The multiselection of lines in Web POS allows the user to perform several actions for a set of lines, instead of performing the action one by one for each line. This way it is possible to manage the POS much faster.
The Services Multiselection allows the user to quickly search services associated to several products at the same time, and to add these services to a ticket, related automatically to all the selected products.
There are several important fields in the definition of a service in the backend, which will affect how the multiselection behaves.
The first and most important field is the checkbox “Available in multiline selection”. In order for a service to be selectable when the user is using line multiselection, this checkbox must be enabled on the service configuration. If it is not selected, the service will still be available through single line service search.
The second most important field which affects the services multiselection behaviour is the “Grouped Product” check. When the service is marked as a grouped product, a single line of the service will be added to the ticket, related to all the selected products. If the service is not a grouped product, a service line will be added for each selected product (this behaviour mirrors the behaviour of adding services one by one).
When searching for related services for several products, only the services that are related for all of these products, and that are not yet present in the ticket related to the selected lines, will be shown (see the screenshots for a clear example).
Special Case: Associate Service With Multiple Products
It will be possible to associate service with multiple products to group them, i.e. transport vehicle service. In the EDIT section of any service, there are two buttons to manage the service associations:
- Add associations
This button will open a window to select the lines that we want to associate with the service. The window only will display relatable lines.
- Remove associations
This button will open a window to remove the associated lines with the service.
Service Quantity Rules
It will be possible to define a Quantity Rule for each service defined in Openbravo ERP. The definition of a service will contain the following options:
- Independent services
If a service is not linked to products (independent services), it will be possible to add it to the ticket on its own and modify the quantity of the line. Quantity rules are not applied to independent services.
User case: The user goes to the store and buys two massage tickets. The massage service is not linked to any product so it will be possible to add it using the search tab and also modify the quantity in case that the user wants to buy more than one unit.
- Unique quantity
If the service is defined as linked to product and the quantity rule is Unique quantity, in this case the service must be added in relation with an existing product in the ticket and the quantity can not be edited.
The rule to set the service quantity is defined through the quantity rule. In this case, Unique quantity, defines that the service can be related with one or more lines but it is not possible to change the quantity to anything different than one (or minus one in case of returns).
User case: The user goes to the store and buys some products (e.g. a TV, a bed and a sofa). Then the user decides to buy the delivery service. In this case delivery service has fixed price and quantity rule set to “Unique quantity”. The salesman will select 3 lines and the delivery service related to all of them. In this case only one line will be inserted with quantity one and it will not be possible to modify it.
- As per product
If the service is defined as linked to product and the quantity rule is As per product, in this case the product must be added in relation with an existing product in the ticket and the quantity can not be edited.
The rule to set the service quantity is defined through the quantity rule. In this case, As per product, defines that the service can be related with one or more lines but it is not possible to change the quantity and it is going to be the same quantity as the related lines. When the service line is related with more than one line, the quantity will be the sum of all the related line quantities.
User case: The user goes to the store and buys 3 pairs of trousers. The user decides that the trousers’ length is too long and he decides to hire the service that the store has to adapt the trousers’ length to the client’s legs. In that case, the ticket will have two lines with 3 units each (a line with 3 trousers and a line with 3 services). Since the service is configured with it’s quantity rule As per product, the service line in the ticket has the same quantity of the related line.
- Special Case: Mixing positive and negative lines
It is possible to associate the same service to both positive and negative product lines on the same ticket. In this case, there will be positive and negative service lines too. The quantity of these lines will be set according to the quantity rule defined for the service, as seen on the previous points.
If the service is configured as Unique Quantity and it is related to both positive and negative product lines, there will be a line of the service with quantity -1, and another line of the same service with quantity 1.
If the service is configured with its quantity as per product, however, the positive and negative quantities of the service will depend on the quantities of the associated products.
Service Price Rules
The price of the services related to products can be calculated in several ways. From one side, it is possible to have a fixed price, defined on the price list used in the store. On the other hand, it is possible to define the price of a service according to a price rule.
When the service price is defined with a price rule, the final price is calculated based on two components. The first component is a fixed price defined on the store’s price list, and the second component is the price obtained from the price rule.
The following paragraphs will explain the different configurations for the price rules.
The Price Rules are defined on the Price Rule window in the backend. The following fields are available:
- Rule type
- Percentage (only available when the rule type is set as percentage)
- After discounts
When the rule type is set as Ranges, a new subtab (Ranges) is displayed. The fields available on this subtab are the following:
- Amount Up To
- Rule Type
- Percentage (only available when the rule type is set as percentage)
- After discounts (only available when the rule type is set as percentage)
- Price List (only available when the rule type is set as fixed price)
Below is a screenshot picturing the different Price Rule and Range configurations
These Price Rules are associated to services on the Product window, under the Price Rule Version tab. In order to do this, the service must be checked as Is Price Rule based.
Imagine we have a service configured as follows:
- Percentage, Before Discounts
This rule type is used to calculate the amount of a service based on its fixed price, plus an amount calculated using the total amount of the related lines (not taking discounts into account).
In the above screenshot showing Price Rules, this configuration is named 20%
Provided that we have a ticket with 2 trousers (amount: 2x75€ = 150€) and 2 units of “Adapt Trousers”, the price of adapt trousers will be the following. (Qty * base price) + (related amount * 20%) = (2 * 15) + (150 * 20%) = 60€ for two units, which will be 30€ for a single unit.
The following screenshot shows the calculation in the POS:
- Percentage, After Discounts
This rule type is used to calculate the amount of a service based on its fixed price, plus an amount calculated using the total amount of the related lines (taking discounts into account).
In the above screenshot showing Price Rules, this configuration is named 25% After Discounts.
Provided that we have a ticket with 2 discounted trousers (amount: 2x55€ = 110€; original amount 2x75=150€) and 2 units of “Adapt Trousers”, the price of adapt trousers will be the following.
(Qty * base price) + (related amount after discounts* 25%) = (2 * 15) + (110 * 25%) = 57.5€ for two units, which will be 28.75€ for a single unit. The following screenshot shows the calculation in the POS:
This rule type is used to calculate the amount of a service based on its fixed price, plus an amount calculated depending on the amount of the related lines. Each range may define a percentage (following the rules already explained) or a fixed price coming from a price list.
In the above screenshot showing Price Rules, this configuration is named Ranges.
With the same configuration, we will see the price calculation for different ranges.
a) Given the following ticket:
- Trousers: 2 Units. Total amount 150€
- Adapt Trousers: 2 Units.
The matching range is the first one (up to 250€, with a 15% percentage), and the calculated amount (following the calculation seen before) will be 52.5 for the service line.
b) Given the following ticket:
- Trousers: 7 Units with a 5% discount. Total amount 498.75€ (525€ before discounts)
- Adapt Trousers: 7 Units.
The matching range is the second one (up to 500€ after discounts, with a 12% percentage), and the calculated amount (following the calculation seen before) will be 164.85€ for the service line (7*15 + 498.75*12%).
c) Given the following ticket:
- Trousers: 8 Units. Total amount 600€
- Adapt Trousers: 8 Units.
The matching range is the third one (more than 500€ after discounts, defined with a fixed price coming from the Services price list), and the calculated amount will be the base amount, plus the amount obtained from the price list. In this case the Adapt Trousers service has a defined price of 2 on the Service Price list. Therefore, the total amount of the service line will be 15*8 + 2*8 = 136€
Service Price Rule Improvements
Before 19Q3 it was only possible to use a single Price Rule to calculate the price of a service related to several products.
Now, when defining the relationship between a service and products or categories, it is possible to define Service Price Rule Versions specific for each relationship.
Based on this change, when a price rule based service is related to a product, its price rule is evaluated first looking at the product, then looking at the category of the product, and finally looking at the generic price rule configuration of the service.
Moreover, on order to manage correctly this new configuration, the price of a service is now calculated line by line based on its relationships (instead of doing a single calculation with the summed amounts)
As soon as new “Service” product type has been added to Openbravo functionality, new return rules are implemented in the Openbravo ERP functionality and Openbravo Web POS functionality. This document explains how do returns work in Web POS for the “Service” type products. Before reading this document is highly recommended to read the documentation of the ERP functionality, where is explained how does ‘Services’ works.
There are two different type of return in Openbravo:
- Blind returns: Return of products without a previous ticket
- Verified returns: Returns generated from an existing ticket
Depending on the return type that is going to be applied, the workflow will be different. Let’s explain the differences between this two methods.
The most important thing to know about this type of returns, as explained before, is that the products to return are not taken from a previously paid ticket. This means that if a service has normally a limited period of days to return (called “Overdue Days to Return” in Openbravo, ODR at this article hereinafter), as is impossible to compare if this period has expired, an approval will be always required from Web POS to be able to return “Service” type products. This approval will be allowed only for users that has “OBPOS_approval.returnService” property activated.
Of course, a not returnable service will never be allowed to be returned.
These are the different ways to make a blind return:
- Return Line Button
To return a ticket using this button a product with it’s related service must be added to the ticket, or a non “Related to Product” (RtP hereinafter) service alone. To return a RtP service the product to be related to must be included to the ticket and be also returned.
Then select the product and optionally the service to return (if the service is not selected it will be returned equally, because there is no possibility to have a positive product with negative services related, or negative services added to positive products) and click on “Return Line” button.
If the service related to the product to return is not returnable, a popup will appear telling that the related service to this product is not returnable and the operation will be cancelled.
If the service line was also selected to return and is not returnable, a similar popup appears telling that the product selected is not returnable.
If the service to return is not RtP and is not returnable the same popup will be shown telling that this service is not returnable.
When trying to return a returnable service, as explained before, there is no possibility to know the date when that product was bought, so an approval popup will always appear asking for an authorized approval.
Introducing correct user and password the product and service will be correctly returned.
In the other hand, if the approval user or password is not correctly introduced or if the popup is closed or cancelled, it means that the return of the service has not been approved, so the return process will be fully aborted and neither product nor services will be returned.
If this service line had two services, one of them related to the product to be returned and the other related to a product which is not going to be returned, if approval is correctly introduced the service line will be divided in two different lines with the same service, one with negative value (returned) with one service and the other a line with a positive service related to the product which has not been returned.
- "-" Button
The second way to make a blind return is using the “-” button located in the right panel shown when clicking on any line of the ticket.
With this button the quantity of a product may be changed to a negative amount, which is exactly the same done when returning a product with the “Return Line” button.
To reproduce, after clicking on the product to return is necessary to introduce the quantity to subtract and click on “-” button. The quantity introduced will be subtracted to the line quantity amount.
Take into account that all RtP services needs to have a quantity rule defined (“As per product” or “Unique quantity”), so it means that the quantity of a service line cannot be modified in Web POS. To return a RtP service line using this method, as explained before for the previous method, will be necessary to select and modify the quantity of its related product. Then follow the same steps described for “Return Line” button method and the result will be exactly the same.
Example: There is an “Avalanche Transceiver” product with a “Delivery” service related. The quantity of the product is 1 and the defined quantity rule is “As per product”. Clicking on the product, selecting 2 and clicking on “-” button will subtract 2 product to its quantity, so the quantity will be -1 (which is the same as returning a product with quantity 1 using the “Return Line” button). As in the other case, if the related service is returnable approval will be asked and the service will be returned in case of correct approval and will be deleted in other case. If the service is not returnable a popup will be shown telling that service is not returnable and the product won’t be returned too.
- "Return this Receipt" menu button
The third way to make a blind return is using the “Return this Receipt” button located in the menu:
This process returns the whole ticket. If there is any not returnable service the popup which says that the service is not returnable appears and if there is any service, but all services are returnables, approval will be asked. If approved, the ticket will be returned and will become a return ticket. Else, if approval is cancelled or closed all the process will be stopped and neither product nor service will be returned.
Example of a returned ticket:
- Other ways
There are other situations that are not considered to be a standard flow to make a return, but that can generate the return of a service.
These are divided in two cases:
- Adding a service in a ticket to be returned
- Adding a service to a product to be returned
The first case includes any type of service, so is not necessary to be a RtP service. When a service is added to a negative ticket is added as negative service too, so as in the other cases approval will be required if is returnable, and the error popup will be shown if not.
The second case only includes RtP services which are related to a negative product. As in the previous case, if is returnable, approval will be asked for and if not popup will be shown.
This is the second type of return. The products and services returned by this method are always added to the receipt from a previously paid ticket. This allows to know the purchase date of the product is going to return, so new return rules are introduced. This should be the most used return method.
To use this return type there is a “Verified Returns” button on the menu panel:
The next popup is shown to select the desired ticket to return:
And a second popup is opened to select the orderlines to return:
In this popup an user can select which lines wants to return and the amount quantity of each line, except the quantity of the service products. A service line must be selected with full quantity or don’t select it.
This can generate a problem because a customer, for example, has bought two TVs with a guarantee service for each one. Later, the customer wants to return a TV and it’s guarantee. With this popup a service cannot be selected to return alone so the solution is to return one TV and the two guarantee services, and then add a new guarantee service to buy.
Not returnable service can’t be selected to return on the popup.
If a service is returnable and is selected to return the Web POS will check if the product is in time to be returned. To check this is necessary to compare the product’s ordered date with the new return date subtracting the ODR of the service. If the new date minus ODR is lower or equal to the ordered date, the service will be returned, otherwise approval will be needed. As in previous cases, if approved the return will continue and if not all process will be stopped.
When ODR is null means that the product won’t never need for approval .If ODR is 0 means that the service is will only be returnable without approval the same day that is bought. Finally if is negative means that the product will always ask for approval.
Example: A customer buys a TV with it’s guarantee service. The ODR is 15. 5 days after the customer wants to return the TV and the guarantee. The system checks if the return date minus ODR is lower or equal than the ordered date (no problem in this case) and the ticket is returned not asking for approval.
Example 2: A customer buys the same TV and guarantee. 15 days after tries to return both. The system checks dates and determines that the operation gets the same date to when was bought (return date - ODR = ordered date) so the products are returned without requiring approval.
Example 3: The same TV and guarantee.The customer tries to return 30 days after. Is out of date, so the system will asked for approval. If approved the products will be returned, otherwise won’t be able to return the service.
Services Related to Closed Tickets
Configure deferred sell in ERP
Select menu option: Application / Master Data Management / Product and search a product to configure.
Go to section Service Product and check Allow Deferred Sell, and optionally set Deferred Sell Max Days.
Deferred Sell Max Days field defines in the case of services that does allow deferred sell the maximum days after the original product was sold, this service can be linked with it. If NULL, there are no date restrictions about when this service can be linked to a product. And for example 0 means the service can be linked only in the same day. 1 only one day after, ...
Select a non-active ticket
Select menu option Receipts and search and open a non-active ticket
Select a line to add a service
Select a product line to add a service and press button services in ticket line or in EDIT window (marked with a red circle in the figure below).
Search services avaliable for selected product line and select it. Only services configured for diferred sell can be added to product.
Add a service to open receipt or create new one
After select a deferred sell service a dialog open for select a open receipt or create new one.
Dialog show a message to explain it not posible add a product to not editable receipt and show a list of open receipt and give the option of create a new one.
Select create a new receipt or select a open receipt and press button Apply.
When Open then target receipt after apply is checked the receipt is open in Web POS.
If it allows deferred sales but it is overdue (there are more days since the product sell than the Deferred Sell Max Days), then a warning appears but there is an authorization key that allows a manager to link a service to a product even if the Deferred Sell Max Days has been surpassed.
Associate a service with more than one product
The Openbravo Web Pos printable service is a new feature that allows users to print or not services associated with a product that the client requested into the ticket.
By default, all services will be printed when paying a ticket. The services configured in backend and which have a price of zero won't appear in the printed ticket. On the other hand, although a ticket is configured to not appear, but its price is not zero, it will appear as well.
Automatic Service Price Calculation
As explained in the Service Price Rules section, some services have its price calculated based on the products to which the service is related.
Normally these services show their base list price in the Search Tab, and the real price can only be seen once the service has been added to the ticket.
When the Automatic Service Prices module is installed, however, the total price of the service can be previewed on the Search Tab
For services configured to modify taxes of products linked, sales taxes are applied automatically during the operation, so after adding the service to a product, the new taxes configuration will be applied if the product fits with the configuration defined.
Before adding the service that modify the taxes.
After adding the service that modify the taxes. Note the taxes for Expedition tent 4 season 2 person has changed and in consequence the price has been reduced according to the reduction of taxes.
The aim of this development is to improve the calculation of the cost of delivery services by allowing to define if it will be paid either as part of the ticket or in the delivery itself.
It will also improve the overall management of delivery services, by handling automatically the proposition/removal of services when the special "Home Delivery" delivery mode is used.
A new checkbox field has been added at Product level, Delivery Service, to indicate if a service will be used as a delivery service. This checkbox is only visible when the product's type equals Service, the service has been configured as 'Linked to Product' and Delivery Modes have been enabled (using the Web POS Enable Delivery Modes preference).
When this checkbox is enabled, the service will no longer be available as a regular service in WebPOS, and instead it will be used especifically when the Home Delivery delivery mode is used. The relationship of products/categories and the service, and the price calculation (if applicable) are not changed, and the delivery service will behave just like a regular service. There are no limits on how many delivery services are configured in an instance.
Another combo box has been added to the Organization window, Delivery Payment Mode. This combo box will allow to choose if Delivery Services will be paid as part of the ticket (combo value: Pay in the Ticket) or if they will be paid during the delivery (combo value: Pay in the Delivery). This combo will only be visible if the Delivery Modes preference has been enabled. Pay in the Ticket is the standard mode, in which delivery services have their own price and are paid as part of the receipt. If Pay in the Delivery is configured, however, Delivery Services will have a price 0 in WebPOS, and their delivery cost will be stored in a new field in the Order Line: Amount to pay in delivery. This new field is located in the Delivery Fields group, and it is only visible if the Delivery Modes preference is enabled and the line has a delivery cost defined.
Searching Delivery Services
As with the configuration fields, in order to use Delivery Services in WebPOS it is required to configure the Web POS Enable Delivery Modes preference. The Delivery Services functionality is triggered when the Delivery Mode of a product is changed to Home Delivery. When that happens, an automatic search for related delivery services is triggered.
- If the search doesn't return any result (the product doesn't have any related delivery services) then no action is performed.
- If the query returns a single result, then the delivery service is added automatically to the ticket.
- If the query returns more than one result, then the Search tab is shown, with all the available delivery services listed.
In any case, if the product has related delivery services, a new icon is added to the order line, allowing to search again for the delivery services of the line.
Adding Delivery Services
When a Delivery Service is added to the ticket (either automatically or manually after searching), the service will show a small gray van icon (opposed to the wrench/hammer icon shown in regular services). If the store has been configured to pay delivery services as part of the ticket, then the delivery service behaves as a normal service (its price affects the ticket's total amount).
If the store has been configured to pay delivery services during the delivery, however, the delivery service will have always its price set to 0, and its calculated value will be shown as a new property on the line. This new property can be clicked to open a popup allowing to change the price of the delivery service (controlled by the preference WebPOS Approval to Change the Delivery Payment).
It is important to note that Delivery Services are only valid as long as the related product's delivery mode is set to Home Delivery. If this delivery mode is changed back to a different delivery mode, then Delivery Services are automatically removed from the ticket.