Choose a grocery store system by testing a weighed basket, a perishable lot and the resulting checkout records as connected business requirements. A scale connection alone does not answer how a shop handles containers, expiry information or transaction corrections. Use a small demonstration basket and require evidence for each handover between tasks.
Start with the products that expose the difficult cases: loose produce sold by weight, sealed goods sold by unit and perishables received in different lots. Write the intended unit beside each item. Then ask the demonstrator to show how a cashier and a stock controller work with those records, rather than accepting a general inventory presentation.
The examples here draw separately on Odoo 19’s scale documentation and Odoo 18’s expiration documentation. Keep those version labels in the comparison. They provide concrete questions for a shortlist; the final basket exercise asks what the proposed installation actually joins together.
What must a weighed-product demonstration show?
Odoo 19 requires an IoT system to connect a scale. Its scale guide describes associating the device with the relevant point of sale and choosing the electronic scale in the configuration. Ask the demonstrator to identify the proposed connection arrangement and the exact installed version before entering products into the test basket.
Odoo 19 requires the product to be enabled for Point of Sale before its weighing option can be enabled. Odoo 19 documents enabling To Weigh With Scale on the product. These settings belong in the evidence sheet because two similar-looking product records may be configured for different sales methods. Give loose produce and a prepacked item separate test cases.
Odoo 19 computes the price in the weighing popover after determining the weight. The documented sequence then adds the item to the cart through Order. Inspect the quantity, unit and product identity together. Ask the operator to explain what the displayed quantity means before comparing it with the physical test item.
Keep equipment suitability and any applicable certification in their own review. The scale guide contains European requirements; a business in Zambia should not convert those statements into a local certification conclusion. The useful software test here is narrower: does the proposed setup represent the intended weighed sale and handle its exceptions visibly?
How should container weight and repeated sales be checked?
Odoo 19 provides Tare to subtract the container weight. In Odoo 19, the Order button remains unavailable until the scale returns to zero. Both behaviours appear in the product-weighing instructions. Use them to design a demonstration that includes more than one sale, rather than weighing a single item and stopping.
Ask the cashier to show an empty container, the intended tare action and the filled container. Record the displayed net quantity and how the product is added to the basket. Remove it, then begin the next item. If the display does not return to its expected starting state, keep the exception visible and ask how the operator recognises and resolves it.
Also test an abandoned weighing action. The acceptance sheet should distinguish a measurement shown on screen, an item added to the basket and a transaction completed at checkout. Those are useful operational checkpoints to request, even when a particular platform uses different labels for them.
For a wider discussion of joining physical checkout and online stock, use WooCommerce POS and stock synchronisation. That integration decision is separate from establishing whether a specific weighed item has been represented correctly.
What does perishable stock need beyond a product name?
Odoo 18 assigns expiration information only to products tracked using lots or serial numbers. Its expiration guide describes enabling the tracking and expiration features, then configuring the product. Capture these prerequisites when comparing a demonstration with the business requirement; a visible date field without its tracking context tells only part of the story.
Odoo 18 distinguishes expiration, best-before, removal and alert timing fields. Have the stock owner write what each relevant date means in the shop’s process. Do not invent standard shelf-life values for the exercise. Use an approved product specification when preparing a real implementation and keep the decision about food handling with the responsible business owner.
Odoo 18 allows dates to be assigned manually when the product has no configured expiration timing values. This makes a useful exception test: receive a fictional batch whose date must be entered rather than calculated. Inspect the chosen date and lot together, and ask who reviews an incorrect entry before the goods become available for sale.
Odoo 18 documents selecting the next-soonest-expiring lot when one lot cannot cover the required quantity. The same guide places its perishable delivery example in a FEFO removal-strategy context. Demonstrate that inventory workflow separately from the scale workflow; ask for specific evidence before treating it as automatic expiry selection at the proposed checkout.
| Requirement | Documented example | Evidence to request for the proposed shop |
|---|---|---|
| Device connection | Odoo 19 scale connection through IoT | Installed version, device association and observed reading |
| Weighed product | Odoo 19 product weighing configuration | Correct product, unit and quantity in the basket |
| Container treatment | Odoo 19 Tare action | Before-and-after readings for the same container |
| Perishable identification | Odoo 18 lot or serial tracking | Receipt linked to its entered expiration information |
| Lot selection | Odoo 18 FEFO delivery example | Which lot supplies each part of the requested quantity |
| Checkout record | A requirement for the demonstration | Retained sale, correction and stock-reference evidence |
Original basket evidence sheet
Use this hypothetical exercise: a basket contains loose tomatoes in a reusable container, a sealed packet and a perishable product held in two fictional lots. The worksheet deliberately follows both the cashier’s view and the stock controller’s view. Its purpose is to discover where the proposed system connects them and where another step is required.
Basket identity. Give the exercise a reference and record the test environment, version and configuration. List each product with its intended unit and handling method. Leave monetary amounts out of the shared worksheet; the question is whether the system represents the agreed quantity and record relationships.
Weighing evidence. For the tomatoes, retain the container treatment, net reading and basket line. Ask the cashier to remove the item and repeat the action. Record how they distinguish a cancelled attempt from an accepted basket line. Keep the sealed packet as a unit-sale comparison so the exercise does not accidentally treat every product as weighed.
Perishable evidence. Enter two lots with different approved test dates and limited fictional quantities. Request a quantity that needs both lots. Follow the documented inventory process available in the proposed version and record the lot allocation. Ask where a supervisor sees an incorrect date and how the correction is reviewed.
Checkout evidence. Complete the basket in the test setup and request the transaction record. Compare item identities, units and quantities with the original sheet. Then request a separate correction demonstration and record its reference. The requirement is a traceable explanation of what changed, not a screen that merely returns to the expected total.
Handover evidence. Ask the stock controller to locate the movement associated with the basket and explain the treatment of the perishable lots. If that relationship is not available, describe the missing step precisely. A separate manual procedure may be a deliberate scope decision, but the decision should be visible before selection.
Use the completed sheet to compare options on demonstrated behaviour and remaining work. For checkout payment testing, see WooCommerce payment methods. For the broader systems brief, visit business systems or get started with the basket sheet and unresolved requirements.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.