The store checkout, the website and the marketplace rely on one stock level and one order history. The three main lines of business are covered on separate pages; clothing, home goods and beauty stores are covered on this one.
Industry-specific processes and Uzbekistan requirements for these lines are covered in detail on separate pages. Below are three store types: clothing, home goods and beauty.
Shifts and cash control, returns, loyalty, offline mode and fiscal receipt requirements. Point of sale page →
Real stock levels, delivery, local payment methods and marketplace connection, the e-commerce law. Online store page →
Multiple branches, central purchasing, expiry dates, loyalty and product marking. Retail chain page →
Which apps you need is determined during the diagnostic, depending on the store type. Barcode, Planning and devices (IoT) belong to the Enterprise edition.
Sales screen, shifts, returns, loyalty, offline mode.
Catalog, cart, delivery; picking up an order at the store (click & collect).
Stock by variant, several warehouses, inventory counts.
Receiving, transfers and counting with a scanner. Part of Enterprise.
Minimum stock rule, supplier terms, repeat order.
Code, automatic discount, “Buy X, get Y”, loyalty card, gift card, eWallet.
Cash journal, invoice, credit note, bank reconciliation.
Salesperson shifts, delivery and installation visits. Part of Enterprise.
USB printer, scale, scanner. Part of Enterprise.
In a clothing store, one model splits into dozens of variants by size and color. In Odoo, the model is one product, and size and color are attributes. Each combination becomes a variant with its own stock level and sales. Many variants can be entered on an order in one window through a grid (Variant Grid Entry); this feature is switched on in the Sales settings. At the checkout, the cashier selects the variant at the time of sale. On its own page for a clothing store, Odoo shows barcode, point of sale, an online catalog and in-store order pickup.
End-of-season discounts and loyalty rules are managed at the checkout as programs: code, automatic discount, “Buy X, get Y”, loyalty card, gift card. For returns and exchanges, Uzbekistan has a rule: a good-quality non-food item can be exchanged within 10 days of purchase if it has not been used and its packaging and consumer properties are intact.
In a home goods store, the customer chooses from a catalog, the item comes from stock or on order, and sometimes delivery and installation are sold as well. In Odoo, a set (for example, kitchen equipment) is a bill of materials of the “Kit” type: one line on the sales order, while at delivery each component is shown separately. According to the documentation (for a set without tracking), if any component runs out, the set is not sold or delivery is delayed. On its own page for a furniture store, Odoo shows a “pay now, deliver later” flow at the checkout: if a delivery date is selected, the stock document is created automatically.
In Odoo 20, the delivery and installation service is handled through field service inside Planning: a visit is created as a shift from the sales order, a worksheet is filled in, and the customer signs the report. If the “Under warranty” flag is set, the amount for materials and services added from the shift drops to zero.
In a beauty store, product lots and expiry dates matter, and customers are regulars. In Odoo, lots and expiration dates are enabled only for tracked products: four dates are entered (expiration, best before, removal, alert), and the FEFO strategy issues the lot closest to expiry first. Odoo 20 warns the user if an expired product is selected at the checkout. A gift set is a “Kit”.
The loyalty program, gift card and eWallet work with regular customers; with a loyalty card, the customer is selected first, and points are calculated afterward. Perfumery and cosmetics fall under the declaration section of Appendix 4 to Resolution No. 43. No separate regulation for cosmetics was found in the list of technical regulations (gov.uz, 25 October 2026).
Most retail processes are available in the ready-made apps. The fiscal receipt, local payments and marketplaces are separate work. The data follows the Odoo 20 documentation; if your version differs, we check it during the diagnostic.
| Goal | In standard Odoo | Extra work (BUline) |
|---|---|---|
| Variants (size, color) and grid entry | Included: attributes, variants, Variant Grid Entry | Designing the attribute structure and loading the catalog |
| Point of sale: shifts, returns, loyalty | Included. Point of sale page | Roles, return procedure, loyalty rules |
| Fiscal receipt (online or virtual cash register) | The Odoo documentation does not mention a connection to the Uzbekistan fiscal module | Connection to a cash register device from the state registry; estimated as a separate project |
| Set (Kit) | Included: one line at sale, components at delivery | Set composition and sales procedure |
| Delivery and installation service | Included: field service inside Planning (Odoo 20, Enterprise) | Worksheet templates, connection to a local courier |
| Expiration date and lot | Included: lots, four dates, FEFO, alert at the checkout (Odoo 20) | Defining the product groups with expiry dates |
| Automatic discount based on remaining shelf life | Not confirmed in the documentation | Discount rule and label process; a custom module if needed |
| Online store and marketplaces | Included: eCommerce. Marketplace connection is estimated separately | The estimate described on the online store page |
The items below have been checked against official sources. Those that apply to your type of store are recorded in a written list during the diagnostic.
Reports are not copied into a separate table: they are built from the register transactions, online orders and stock moves in the same database.
| Mistake | Consequence | How we prevent it |
|---|---|---|
| Entering every size and color as a separate product | Stock and reports are scattered, and the catalog is hard to maintain | One model is one product; size and color are attributes |
| Enabling expiry tracking for all goods | Extra data entry grows at receiving and sale | Enable it only for groups with expiry dates |
| Allowing returns without limits | Hidden shrinkage | Approver, reason and an allowed limit |
| Treating the Odoo checkout and the fiscal cash register device as one thing | One sale is recorded differently in two places | Settle the connection at the start of the project, with written confirmation |
| Enabling loyalty rules without testing them at the checkout | Discounts conflict with one another | Test the rules in a test database and at one register |
This list speeds up the diagnostic. We can start even if not everything is ready.
The model is one product, and size and color are attributes. Each combination becomes a variant and keeps its own stock level. On an order, many variants can be entered in a grid, and at the checkout the cashier selects the variant. So that the number of variants doesn’t grow out of control, we design the attribute structure from the start.
At the checkout, a return is linked to the original receipt and creates a credit note. The time limit and conditions are configured to Uzbekistan’s requirements: for a good-quality non-food item, the law sets 10 days. We read the list of non-exchangeable goods from the government rules and record it during the diagnostic.
The store checkout and the website work from one warehouse stock level in a single Odoo database. Sending stock to a marketplace depends on a third-party module and its middleware, so it is estimated separately. Online store page →
Odoo manages expiry only for goods tracked by lot or serial number. Tracking adds work for every product, so we enable it only for groups with expiry dates. If an expired product is selected at the checkout, Odoo 20 shows a warning.
The documentation does not mention that Odoo’s own receipt serves as a fiscal receipt. The law requires an online or virtual cash register from the registry, and the Odoo documentation does not mention a connection to the Uzbekistan fiscal module. We review the connection method during the diagnostic. Point of sale page →
The Odoo license depends on the number of users and apps (terms are on odoo.com). The scope of BUline’s service depends on the number of stores and registers, catalog size, apps, integrations, data volume and training. The exact cost and timeline are given in a written proposal after the free diagnostic.
During the diagnostic, we review your processes and tell you where standard Odoo is enough and where configuration is needed — with an app list, edition and phases.