Every medicine is tracked by batch number and expiry date, branches supply each other with stock, and the POS warns about an expired medicine. Prescriptions, e-prescriptions and product marking lie outside the Odoo standard: we describe them openly, with sources.
A medicine is a product with an expiry date, a batch and its own rules. A mistake here costs more than money: it affects patient safety and inspections.
Odoo S.A. lists a “Pharmacy” industry package in the Apps Store (technical name pharmacy_retail; available in the 19.0 and 20.0 series). The page describes it as a retail pharmacy management system: purchasing and sales, batch-based inventory and tracking of batch expiry dates. The package relies on the Point of Sale, Inventory, Sales, Purchase, Invoicing, Studio, Knowledge, Calendar, Contacts and Discuss apps. It requires Odoo Enterprise and is available on Odoo Online, Odoo.sh and your own server. Odoo's Pharmacy industry page, for its part, lists Knowledge for the POS, inventory, sales, purchasing, accounting and staff training. Prescription processing is mentioned there in a single sentence, without detail.
The package is a pre-configured base, not a ready-made pharmacy program. The pages do not describe prescription checks, e-prescriptions, medicine marking, reference-price control or the Uzbekistan localization of Odoo. We assess these at the diagnostic as work added on top of the package.
A search for “pharmacy” in the Apps Store showed more than a hundred apps in the 19.0 series (25 October 2026). Most of them are third-party modules. They cannot be installed on Odoo Online; the quality of each and its fit with Uzbekistan's requirements are checked individually.
The core is the POS and inventory run by batch. Which apps are needed is determined at the diagnostic.
Sales, batch selection, a warning on an expired batch, customer account, returns, shifts.
Central warehouse and branch warehouses, internal transfers, goods in transit, stocktaking.
Four dates per batch (lot), a warning, and issuing the medicine closest to expiry first (FEFO).
Scanner for receiving and counting; the GS1 nomenclature reads the batch and expiry date. Included in Enterprise.
Minimum stock rule, supplier orders, reconciliation with the supplier's records.
A quality checkpoint at receiving, separation of a substandard batch. Included in Enterprise.
Loyalty card, coupon, gift card, a separate price list for B2B customers.
Journals by branch, supplier invoice, cash journal, bank reconciliation.
The prescription register form and additional fields without code. Included in Enterprise.
At every stage the document stays in Odoo, so head office sees branch stock and batches on its own screen.
The medicine arrives with a waybill and an invoice. The quantity is checked with a scanner, and the batch number and expiry date are entered. For marked medicines, code tracking is separate (below).
A checkpoint fires on receipt. A substandard or suspicious batch is set aside in a separate location.
Locations are created by storage condition: ordinary shelf, refrigerator, quarantine. Each medicine is counted only in its own place.
A transfer document is created from the central warehouse to the branch. Goods in transit sit in the “transit” location and remain the company’s property.
The cashier scans the medicine, and the batch is selected or imported. If the batch is expired, a warning appears. Even when the batch is missing or wrong, the POS does not stop the sale; it only requires the warning to be confirmed.
Checking the prescription and keeping its record are built as a rule outside the POS (section below).
When the alert date arrives, the medicine becomes visible. A substandard or expired medicine is withdrawn from circulation and written off by an act.
A manager sees sales, stock, batches nearing expiry and write-offs by branch and medicine group.
Odoo's documentation does not describe the prescription operation, prescription checks or a prescription register. For that reason this part counts as work added on top of Odoo.
The rules are official: the regulations on retail sales for pharmacies (Cabinet of Ministers Resolution No. 185 of 6 April 2017, Annex 2; latest edition in force since 3 July 2026). Under them, a prescription medicine is not placed where a customer can see it. A prescription is on paper or electronic. The medicine is dispensed under the international nonproprietary name (INN) given in the prescription. On a paper prescription the pharmacist writes the medicine name, the batch number and their own name, signs it, and the pharmacy stamp is applied. A fully dispensed prescription is stamped “Prescription is invalid”, and a prescription that does not comply with the rules is recorded in a separate register. The prescription registration journal is given in the regulation's annex: date, patient, institution and doctor, medicine name, quantity, dose, form, price, patient's address and phone, notes.
The route in Odoo: a prescription register form built in Studio (prescription number, doctor, institution, INN, quantity), its output as a report, and a mandatory-field rule at the POS for prescription medicines. The type of customization (Studio or process automation) is chosen at the diagnostic.
The example is hypothetical. A supplier reports that one medicine batch has been found substandard. The warehouse clerk needs to find the answer in a few minutes.
Batches, expiry dates and branches are in the standard apps. The prescription, e-prescription, marking and fiscal receipt are separate work. The information follows the Odoo 20 documentation; if your version differs, we check it at the diagnostic.
| Goal | In standard Odoo | Extra work (BUline) |
|---|---|---|
| Batch (lot) and shelf life | Available: four dates under batch tracking (expiration, best before, removal, alert) | Which medicine groups to enable it for, and how it is entered at receiving |
| Issuing the batch nearest expiry first (FEFO) | Available: the removal strategy. At the POS the cashier selects the batch, or it is imported | Testing automatic selection at the POS |
| Stopping the sale of an expired medicine | Partial: the Odoo 20 POS warns; blocking the sale is not described in the documentation | A mandatory-stop rule, plus a custom module if needed |
| Receiving by 2D code (Data Matrix) | Available: the GS1 nomenclature in the Inventory barcode settings, batch and expiry fields. Scanning at the POS is not described in the documentation | Testing the scanner model and the code structure |
| Connecting to Asl Belgisi (the national marking system): code check, sale reporting | Not available: not mentioned in Odoo's documentation | A separate project: the connection route is established in writing with the operator's documentation |
| Sale on prescription, prescription register | Not available: the documentation describes neither the prescription operation nor the register | Studio form, report and POS rule |
| E-prescription | Not available: not mentioned in the documentation | The terms for connecting to the digital health system are established in writing |
| Transfers between branches, central purchasing | Available: several warehouses, a transit location, minimum and maximum rules | Branch structure, locations, roles |
| Reference price and markup control | Price lists and discount rules exist; there is no check against the reference price | A reference price field and a report comparing it with the POS price |
| Sale by the piece (blister) | Can be set up with units of measure and packaging | The regulations allow sale by the piece (if the name, batch, expiry date and manufacturer are written on the pack), but prohibit dispensing a medicine whose primary packaging has been broken (Annex 2, para. 30) |
| Fiscal receipt (online or virtual cash register) | No: the Odoo documentation does not mention a connection to an Uzbekistan fiscal module | Connecting to a cash register device from the registry. POS page |
The following has been checked against official sources. Rules change often: we reopen the current edition on the day of the decision and confirm it in writing with the responsible pharmacist.
Each connection is assessed and built separately. We do not promise that a “ready-made connector exists.”
Reports are not copied into a separate spreadsheet: they are generated from the sales and inventory documents 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 central warehouse, one or two branches and the POS process, the prescription and marking procedure, and the current program and cash register tool. Written questions to the government systems are prepared. Result: a business requirements document (BRD).
We confirm the industry package or set of apps, the branch and warehouse structure, the prescription register form, the marking and POS route, and the hosting type.
First one branch works with real sales: receiving, POS, prescription register, expiry control. Then the other branches are connected in turn.
The pharmacist, cashier, warehouse clerk and branch manager are trained by role; practice runs on your own medicine list. Instructions and video lessons are provided.
After launch, 30 days of intensified support, then agreed ongoing assistance. When the rules change, the connection is re-checked.
This list speeds up the diagnostic. We can start even if not everything is ready.
| Mistake | Consequence | How we prevent it |
|---|---|---|
| The POS skips a batch error as a “warning” | A sale without a batch, and traceability breaks down | A cashier instruction and, if needed, a mandatory rule |
| Putting all medicines under the same tracking | Extra data entry grows at receiving and sale | Splitting product groups and choosing the tracking type |
| Postponing the setup of the prescription register | The paper register and the system drift apart | Approving the register form at the start of the project |
| Treating marking and the POS as two separate processes | The same medicine is recorded differently in two places | Confirming the connection route in writing at the architecture stage |
| Taking e-prescription deadlines from an outdated source | Wrong preparation | Establishing the current position in writing with the ministry |
Yes. Odoo S.A. lists a “Pharmacy” industry package in the Apps Store: POS, purchasing and batch-tracked inventory. It requires Enterprise and is also available on Odoo Online. Prescription checks, the e-prescription, marking and the Uzbekistan localization of Odoo are not described on the page: they are assessed as separate work.
The standard apps do not describe the prescription operation or a prescription register. We build this part with a Studio form, a report and a POS rule. The rules themselves are in Annex 2 of Resolution No. 185; we reopen the current edition at the diagnostic.
Odoo's documentation has no connection to the e-prescription module. Under Resolution No. 570, a pharmacy connects to the digital health platform: across the republic by the end of 2026 (para. 2), while a note to the annex gives 1 January 2027. We establish the connection method and the current date in writing with the ministry.
Medicines are in the mandatory digital marking group. Odoo's documentation does not mention a connection to “Asl Belgisi”, so the connection is assessed as a separate project. Scanning a 2D code at receiving and recording the batch and expiry date are available in the Inventory barcode settings.
The Odoo 20 POS warns when an expired batch is selected. The documentation does not describe forcibly stopping the sale, so control is built in two layers: expiry dates and FEFO on the warehouse side, and a cashier rule at the POS, plus a custom module if needed.
The head office and each branch are separate warehouses. A transfer travels with a document, goods in transit sit in a transit location and remain company property. If the branches are separate legal entities, Odoo 20 applies replenishment between companies.
The industry package is available on Odoo Online. Odoo Online is not compatible with third-party and custom modules: if you need a marking or e-prescription module, Odoo.sh or your own server is chosen. We decide the hosting type at the start of the project. Hosting types →
The Odoo license depends on the number of users and apps (terms on odoo.com). The scope of BUline's service depends on the number of branches and cash registers, apps, customization, 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.