CASE SUMMARY
A generic POS sees one customer and one payment. A florist must preserve three identities plus delivery, production and accounting relationships.
The client is a local Hong Kong florist. The payer, sender and recipient may all differ, while the order must retain delivery date and time, floral preferences, card message, contact instructions and production notes.
The project built a florist-specific web POS and controlled integration layer. Shop and phone staff follow the real working sequence, while Odoo 19 continues to manage contacts, sales orders, invoices, payments, credit notes and journals.
The payer, sender and recipient cannot be treated as one contact.
Historical data included duplicate customer IDs, inconsistent phone formats, old contacts and incomplete fields. Copying it into a new interface would reproduce the same problems. The new flow separates the three roles and supports search by name, customer ID or normalised phone.
After selecting a customer, staff can reuse purchase history, delivery addresses, recipients and long-term notes. Version checks prevent an older screen from overwriting a colleague's newer update.
Products, custom bouquets, delivery, price-change reasons and notes remain on one order.
Staff can search Odoo products and add custom items, delivery charges, rush fees and discounts. Every price change requires a reason while the Odoo list price remains intact. Delivery includes standard or exact times, address suggestions, district, recipient phone and failed-contact instructions.
Incomplete orders can be saved as drafts. The same action becomes final submission only when required fields are complete. The system then prints receipts, delivery notes and fulfilment documents, with payment details excluded from recipient-facing paperwork.
Payment, cancellation, credit notes and refunds remain distinct, traceable actions.
The POS supports unpaid, fully paid and deposit states. Payment methods are limited to approved Odoo settings. On receipt, the system creates the formal sales order, posted invoice and payment with operator, reference and timestamp.
Cancelling an unpaid order does not create a refund. A paid order creates a credit note, followed by customer credit, cash or bank refund as selected. Bank refunds remain pending until accounting completes reconciliation against a real bank transaction.
Odoo remains the owner of formal invoices, payments, credit notes, journal entries and reconciliation.
Fixed transaction IDs, duplicate protection, sandbox UAT and Odoo readback were verified together.
The frontend stores the pending order before submission, while the backend uses fixed checkout and payment IDs for idempotency. On timeout, refresh or repeated click, it retrieves the same result instead of creating another order.
The latest full regression included 634 frontend tests, 513 backend tests and 184 subtests. Browser checks covered customer search, history, drafts, payment, customer credit, refunds, printing and sync exceptions.
Core development and large-scale UAT are complete, while the 80% and 60-hour figures remain pre-launch estimates.
The client expects about an 80% efficiency gain across order taking, data lookup and daily close, releasing roughly 60 hours of repetitive work monthly. Functions and Odoo readback have been verified, but outcomes should be remeasured after four to eight weeks of production use.
Recommended measures include average order time for new and returning customers, repeated fields per order, daily close time, duplicate orders, missing addresses, wrong contacts and sync records requiring manual correction.
Frequently asked questions
Why not use the standard Odoo POS directly?
The client needs a specific sequence for payer, sender, recipient, long-term notes, delivery and floral requirements. The custom frontend improves daily work while formal sales and accounting records remain in Odoo.
Can a network timeout create a duplicate order?
Fixed transaction IDs and backend idempotency retrieve the original result. Duplicate orders and duplicate refunds also have dedicated safeguards and tests.
Has the 80% gain been proven in production?
Not yet. It is a post-UAT estimate comparing old and new workflows. The status is stated clearly and should be updated with production measures after four to eight weeks.
EXPERT AUTOMATION CONSULTATION
Does your team have a repetitive, error-prone workflow?
Tell us how the process works today, its monthly volume and the common exceptions. We will identify the part worth automating and define a testable first phase.