The cashier sells, the stock level drops immediately, cash is reconciled with the records when the shift closes, and the manager sees the day's results in the morning. The fiscal receipt, however, goes through a cash register solution from the state registry — we estimate that connection separately at the diagnostic.
The checkout is the fastest-moving place in a store. A mistake here costs the most, because it affects money, inventory and taxes at once.
The foundation is the Point of Sale app. The others connect it to inventory, purchasing and accounting. Which apps are needed is determined at the diagnostic.
Sales screen, shift, cash, card and customer account, refund, receipt, session report.
A sale at the checkout is deducted from stock; multiple warehouses, delivery and stocktaking.
Receiving and counting in the warehouse with a scanner. Part of Enterprise.
Cash journal, an accounting entry when the shift closes, invoice and credit note.
Settling a quotation or order at the checkout in full or with a down payment, then delivery.
A minimum stock rule for items running low and a request to the supplier.
Coupon, “buy X, get Y free”, loyalty card, gift card and discount by code.
Connecting a USB printer, scales, scanner and customer display. Part of Enterprise.
The cashier signs in with a PIN or a badge; the report shows who sold what.
At every stage the document stays inside Odoo. The cashier and the accountant look at the same figure.
The cashier clicks “Open Register”. The starting cash amount is checked and the session begins.
The product is selected by scanner or from the list, and the quantity and discount are changed on the numeric keypad. Attaching a customer is optional, but it is needed for loyalty and invoicing.
Cash, a card terminal, QR or a customer account is selected. Each register gets its own cash payment method and journal.
The Odoo receipt is an internal document. The fiscal receipt that is sent to the tax authority is issued by an online or virtual cash register from the registry.
Through “Refund” against an order, or without an order using a negative quantity. As a result, a credit note linked to the original receipt is created.
Cash movements unrelated to sales are recorded with “Cash In/Out”. The manager sees statistics by session and order.
The cashier counts the money and Odoo compares it with the expected amount. If the difference exceeds the allowed limit, a manager approves it. When “Close Register” is clicked, the accounting entries are posted.
The example is hypothetical: no figures, just to show the mechanism. A store runs three registers, each with its own cash payment method and journal. In the evening, the second register has less cash than the records show.
Not everything works out of the box. The fiscal receipt and local payments in particular are separate work. The list below is refined at the diagnostic against your process. The information follows the Odoo 20 documentation; if your version differs, we check it at the diagnostic.
| Goal | In standard Odoo | Extra work (BUline) |
|---|---|---|
| Sales, shift, cash control | Available: opening and closing the shift, difference limit, “Cash In/Out” | Roles, permissions, rule for approving a difference |
| Win-back | Available: against an order and without one, credit note | Approval procedure and refund reasons |
| Fiscal receipt (fiscal sign, QR code) | Not mentioned in the official documentation: a connection to an Uzbekistan fiscal module or a virtual cash register | Connecting to the API of a cash register solution from the registry. Estimated as a separate project |
| IKPU (MXIK) code in the product form | Not mentioned in the official documentation: the Odoo localization for Uzbekistan does not mention IKPU (MXIK) | A field in the product form, code validation on import, matching the 11-digit base code |
| Offline mode | Available: orders are stored in the browser and synchronized once the connection is restored. The card terminal does not work | Offline procedure, cache size, cashier instructions |
| Loyalty, coupon, gift card | Available: “Discount & Loyalty” programs | Adapting the rules to your sales policy |
| Weighed goods | Available: scales via USB or IoT, the “To Weigh” flag on the product | Testing the scale model and the barcode nomenclature |
| Receipt printer | A network ePOS printer (for example Epson TM-m30) connects directly; USB and ESC/POS printers connect via IoT | Choosing devices, connecting and testing them |
| Click, Payme, Uzcard, HUMO | The official documentation has no ready-made connector for the point of sale | Testing, a ready-made module or custom development — estimated at the diagnostic |
The terminal and QR lists in the Odoo documentation are organized by country. Uzbekistan is not listed, so each method is tested in a test database.
| Approach | In the Odoo POS | A note for Uzbekistan |
|---|---|---|
| Cash | Available. A separate cash payment method and journal for each register is recommended | The payment form is shown on the receipt |
| Bank card (terminal) | Providers in the documentation: Adyen, Stripe, Razorpay, Worldline and others | Uzcard and HUMO terminals are not named in the documentation. If communication with the terminal is lost, the operation is cancelled |
| QR code | Available: country-specific types and the general EMV format | Uzbekistan is not in the list of types; compatibility with banking apps is established during testing |
| Customer account (sale on credit) | Available. The credit limit only warns and does not stop the sale | To make the term and the limit mandatory, a rule outside the POS is needed |
| Click, Payme | Not in the official list of providers | According to their documentation, the connection is built on your server's side |
The items below have been checked against official sources. Those that apply to your line of business, we list in writing at the diagnostic.
Each connection is assessed and built separately. We do not promise that a “ready-made connector exists.”
Reports are not kept separately from the POS: they are generated from sales in the same database.
The stages follow the general BUline Method. The timeline is agreed in writing after the diagnostic. Implementation process →
We study the number of registers, shift procedure, product records, devices, the current cash register solution and payment methods. Result: a business requirements document (BRD).
We confirm the structure of registers, warehouses and journals, the roles, the way the fiscal receipt is connected and the hosting type.
First, testing with real sales in one store or at one register, then the remaining points.
The cashier, manager and storekeeper are trained by role: shift, refund, offline mode. Instructions and video lessons are provided.
After launch, 30 days of intensified support, then agreed ongoing support.
This list speeds up the diagnostic. We can start even if not everything is ready.
| Mistake | Consequence | How we prevent it |
|---|---|---|
| One cash journal for all registers | It is not visible which register the difference came from | A separate cash payment method and journal for each register |
| Counting on the card terminal to work without internet | The queue stops and the cashier does not know what to do | Offline procedure: the rules for cash and receipts are written down |
| Allowing returns without limits | Hidden shrinkage | Approver, reason and an allowed limit |
| Uploading products without an MXIK code | An error on the receipt and the invoice | Code validation on import |
| 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 |
No. The Odoo receipt is an internal document. The law requires an online or virtual cash register from the registry, while the Odoo documentation does not mention a connection to an Uzbekistan fiscal module. We review the way to connect at the diagnostic.
The Odoo POS works in the browser: in offline mode, products and customers are taken from the cache, and orders are saved and sent once the connection is restored. The card terminal does not work offline and a new customer cannot be registered. Fiscal receipt deadlines are separate: they are given above.
These services are not in the terminal and QR lists in the Odoo documentation. According to their documentation, the connection is built on your server's side. A ready-made module or custom development is estimated at the diagnostic.
Network ePOS printers, most often tested with the Epson TM-m30 series, connect without IoT. USB and ESC/POS printers require the IoT system. Bluetooth printers are not compatible with Odoo. For scales, the documentation recommends the Mettler Toledo Ariva S.
Odoo Online is not compatible with third-party and custom modules. If a module is needed for local payment or the fiscal receipt, Odoo.sh or your own server is chosen. We decide the hosting type at the start of the project. Hosting options →
Under Article 27¹ of the Law on Personal Data, biometric and genetic data and the data of telecom operators' users must be stored in Uzbekistan. Storing other data abroad is possible under certain conditions. Details
The Odoo license depends on the number of users and apps (terms at odoo.com). The scope of BUline's service depends on the number of registers and stores, 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.