A pharmacy POS and inventory system needs to distinguish batches, expiry information, stock locations and authorised actions, not merely scan products and print receipts. Evaluate these behaviours with a realistic demonstration before choosing software. General inventory features do not establish that a product meets pharmacy-specific legal, dispensing or patient-data requirements in Zambia.
This guide uses Odoo’s official lot and expiry documentation to explain demonstrable stock controls. It does not recommend Odoo as a complete pharmacy system or claim a regulator has approved it. A specialist pharmacy product and a configurable inventory platform should be assessed against the same operational cases, with regulatory suitability established separately. Lot tracking, expiry tracking.
What should you compare before buying pharmacy software?
Separate the sales workflow, the stock workflow and any dispensing or clinical workflow. A till transaction can reduce a product quantity without recording which batch left the premises. A general customer record is not evidence of suitable patient-record handling. Write these differences into the evaluation brief so a polished checkout demonstration does not obscure them.
Ask each candidate to show incoming stock from different batches of the same product, differing expiry dates, a returned item and a quarantined batch. Require evidence of who can change those records. The comparison should be based on observed behaviour and the product’s applicable documentation, not a vendor’s use of the word pharmacy.
Do not enter real patient information during an exploratory demonstration. Use invented test identities and non-clinical sample products. Keep the exercise focused on whether the system can represent the required controls without exposing confidential information or making a real dispensing decision.
How do product, batch and expiry records differ?
Odoo describes a lot as a batch of products. That differs from the product identifier: the same product can have several lots with different histories. Its documentation also notes that creating a lot reserves a record for a product but does not assign stock to that lot.
That distinction matters during migration. A database containing batch names is not proof that opening quantities are linked to the correct batches. Demonstrate the quantity in each location and inspect the source stock movement. Where tracking is enabled after stock already exists, Odoo points to an inventory adjustment to assign lot information.
Expiry tracking has another dependency. Odoo permits expiration information only for products tracked by lots or serial numbers. Do not assume that entering an expiry value in a spreadsheet makes the configured selling workflow enforce it. Trace the value into receipt, storage and outgoing selection. Official lot and expiry requirements.
What should the batch-control demonstration prove?
| Demonstration case | Evidence to request | Unsafe shortcut to reject |
|---|---|---|
| Receive a tracked product | Batch assignment linked to receipt quantity | Batch text recorded only in a note |
| Receive another batch | Distinct batch identity and expiry | One expiry value for the whole product |
| Select stock for sale | Actual outgoing batch and location | Total product quantity only |
| Quarantine a batch | Restricted destination and sale behaviour | A warning label with no demonstrated control |
| Investigate a recall | Traceable source and affected movements | Search by product name alone |
| Correct a date | Authorised change and retained explanation | Unexplained overwrite |
These are editorial acceptance requirements. The table does not assert that every listed control exists in an unconfigured product. A candidate that cannot demonstrate one should be recorded as incomplete for that requirement rather than awarded assumed compliance.
Why are expiry alerts insufficient on their own?
Odoo distinguishes expiration, best-before, removal and alert intervals. These are different meanings, not interchangeable date labels. Its documentation allows manually assigned dates and later changes, so the software value should be checked against the authoritative product information.
For pharmacy stock, do not derive an expiry date from a generic receipt interval when the actual batch carries its own expiry. The demonstration should show how staff capture the correct information and how corrections are controlled. This is a proposed operating safeguard, not a statutory formula or a claim about a particular installed pharmacy system.
Test what happens after an alert appears. Can a cashier still select the batch? Does a manager receive a task? Is the item moved to a restricted location? Record the actual result. A coloured warning is not evidence that stock cannot be sold, and a removal strategy alone does not prove an expired item is blocked.
An original batch exception register
Create a record with these fields for each unresolved case:
Product identity: catalogue identifier and sales unit.
Batch identity: batch reference as received and the source receipt.
Date evidence: labelled expiry and the system’s stored value.
Location and disposition: saleable, awaiting investigation, quarantined or returned, using the business’s approved categories.
Exception: missing batch, unclear date, unexpected sale permission or quantity mismatch.
Authority: role permitted to investigate and approve a correction.
Resolution: evidence inspected, change made and stock movement affected.
Recheck: repeat the original case to establish whether the defect remains.
The register should explain the discrepancy without copying unnecessary patient or prescription data. It is an original evaluation artefact, not a validated quality-management system or a replacement for the pharmacy’s regulated procedures.
Which access controls need a real test?
Prepare separate demonstration accounts for cashier, stock receiver and administrator roles as applicable. Attempt the same sensitive action with each account: editing a batch date, changing a quantity, returning stock to saleable inventory and changing permissions. Record what each account can actually do.
This article does not claim that the cited inventory pages establish a complete role-permission scheme. Their scope is lot and expiry handling. Access requirements therefore remain explicit acceptance tests, with further product documentation and pharmacy-specific requirements needed before selection.
Keep the clinical and regulatory suitability decision separate from the technical stock demonstration. Do not describe a generic inventory configuration as approved pharmacy software, nor infer authorisation from the presence of barcode, batch or expiry fields.
Spout’s web development service can be a starting point for discussing an integration brief. Send an enquiry with the batch test cases and the requirements that remain unverified.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.