Odoo Rebuild Closing 14 Gaps for an Adhesives Distributor, Extended With OpenClaw and Gemini AI Inside Warranty

Industry

Industrial Adhesives Distribution

Geography

US Gulf Coast + Mexico

Cooperation Period

Ongoing engagement

Intro Summary

An industrial adhesives and specialty coatings distributor approached Clixlogix after two prior engagements with certified Odoo implementation partners failed to produce a working system.

Odoo 19 was standing and broken. Operational modules ran. The QuickBooks accounting cutover was unfinished. Daily operations across inventory, pricing, and reporting were unstable. Ownership had set a firm end of year live date and questioned whether Odoo was still the right platform.

The client arrived with something the prior partners had never produced. A formal gap analysis against their own SOW listed 14 specific gaps and 4 missing swim lanes.

Clixlogix took the engagement on the condition that Odoo would be put into open competitive evaluation against Microsoft Dynamics 365 Business Central. Odoo won on documented reasoning. Clixlogix then built directly against the gap analysis, closed each documented gap, fixed an active inventory leak on incoming vendor cases, and delivered a conversational agent surface on WhatsApp and Slack.

The Challenge

Two prior Odoo certified partners had stood up the Odoo 19 environment and started the QuickBooks cutover without completing it. Both engagements produced planning artifacts. The delivered system remained unstable across purchasing, inventory, and reporting.

The operational scope was specific. A distribution business runs with manufacturing in Mexico and distribution from Texas. Mexico factory lead times run 20 to 60 days.

The customer base sits above 4,500 records across three geographic regions plus an “other” bucket. Sales flow through 8 distinct pricing tiers with cascading filters.

Products are received in one unit and sold in another. Adhesive base compounds arrive in kilograms and dispense into fluid ounce cartridges. Structural adhesive systems sell as 4 component kits that must auto deduct primer, adhesive, activator, and applicator SKUs at fulfillment. Payment terms vary per customer, with methods split across credit card, wire, ACH, check, and cash, each carrying its own fee treatment.

The prior specification covered the transaction spine from lead to quote to order to invoice to payment. Coverage thinned on the operational specifics that make a distribution business work at margin.

The single most costly gap was a live inventory leak. Product from Vendor A arrived in cases of 24 cans. The same product from Vendor B arrived in cases of 30 cans. The prior system posted the same count on receipt regardless of source. Every Vendor B case shelved 6 cans of unrecorded inventory. The client had flagged this as their highest priority fix. The prior contractor’s diagram did not model it.

Thirteen other gaps sat alongside the inventory leak.

Mexico in transit inventory was not deducted before the reorder engine fired, so the system could recommend double orders on shipments already on the water.
Fee treatment across credit card, wire, and shipping did not account for customer recovery, so net margin was calculated incorrectly on every invoice with a passed through fee.
Automated payment reminders were absent across the 5 trigger points ownership had specified.
Region tagging was missing from the contact record, breaking every regional pipeline report.
The 4,500 contact backlog waited on a bulk import flow that had not been scoped.
Four operational flows were missing entirely, including a cash impact simulator for Mexico deposit planning and a read only external access model for the CPA.

The commercial envelope was set by ownership as a hard constraint before the engagement began.

“3 percent of revenue. No exceptions.”
— Ownership

Fig 1 – The three pivots that reframed the engagement, from two failed partners to a scoped Odoo rebuild

The Solution

Clixlogix structured the engagement into two sequenced phases with the platform question resolved before any rebuild work began.

Business Process Discovery Anchored in the Client’s Gap Analysis

Discovery opened with a direct commercial objection from ownership before any technical work began.

“We have already paid two partners for planning documents. What makes yours different?”
— Ownership

The Clixlogix team took GitHub collaborator access to the Odoo.sh production, staging, and development branches, followed by administrator access to the Odoo database.

Initial access ran a day longer than expected. The prior contractor had set up Odoo.sh branches under a personal GitHub account. Ownership had to transfer to a company organization before Clixlogix engineers could see the code. The 28 hour discovery window absorbed the delay without slipping the SOW timeline.

Discovery collapsed to 28 hours because the client had already done the diagnostic work through their gap analysis. Clixlogix validated each documented gap against the live Odoo environment, confirmed the priority ordering, and used the gap analysis as the source of truth for customization scope.

Business requirements were documented across purchasing, inventory, sales, accounting, and pricing with priorities, assumptions, and scope boundaries stated in writing.

Consulting Insight

The client’s stated ask was fixing Odoo inventory. The actual ask was verifying whether Odoo was still the right platform after two failed attempts. Discovery scope had to match the underlying question. Anchoring to the presenting symptom would have delivered the third engagement in the same shape as the first two.

Fig 2 – The five discovery workstreams spanning Mexico factory operations through accounting reconciliation

Platform Evaluation with Odoo in Open Competitive Review

Clixlogix committed in writing that Odoo, Microsoft Dynamics 365 Business Central, and other viable options would be compared against the documented business requirements on merit. The evaluation covered out of box functional fit, customization requirement, TCO over three years against the 3 percent of revenue budget ceiling, and integration dependencies for the QuickBooks accounting archive and the third party quoting tool.

Odoo emerged as the recommended platform. Both platforms cover the functional territory natively. The decision was made on customization economics, existing infrastructure investment, and TCO at the client’s operational scale.

Axis	Industrial and Operational Reality	Odoo	Business Central	Winner
Variant heavy distribution	6 pack formats per product, 4 component kit BoMs, 8 cascading pricing tiers	Product variants, Product Packagings, Kit BoM, and pricelist rules all native	Item variants, Assembly BoM, and sales price lists all native	Tie on native fit
TCO across 3 years	3 percent of revenue ceiling covering licensing, implementation, and customization	Custom plan licensing plus Odoo.sh hosting as a separate line item, leaving substantial headroom for implementation and customization	Premium licensing consuming a materially larger share of the ceiling before customization	Odoo
Customization economics	10 workstreams need custom development in initial rebuild	Python developer sourcing was deeper and lower rate for the scope in question	AL developer sourcing was narrower and premium rate for the scope in question	Odoo
Existing infrastructure	Odoo.sh production, staging, and dev branches on a live GitHub pipeline	Retained. Existing pipeline carried forward	Full replatforming, Odoo.sh environment discarded, pipeline rebuilt from scratch	Odoo

Business Central lost the evaluation on the three axes above. The client’s board could recommit to Odoo defensibly because Odoo had been tested against a real alternative and won on documented reasoning.

Consulting Insight

Putting the incumbent platform into open competitive review is what makes the platform recommendation trustworthy. The discipline matters most when the partner running the review has commercial interest in the outcome. A board can recommit to a previously failing platform only after that platform has been tested against a real alternative and won on documented reasoning.

The Odoo Rebuild Delivered

With the platform confirmed, Clixlogix scoped the initial rebuild across 10 named workstreams. Each workstream closes documented gaps from the client’s own review of the prior contractor’s specification. The sequence keeps daily operations running through the transition.

Consulting Insight

A client who has already paid two partners for planning work has done more diagnostic work than they realize. Asking for the client’s internal artifacts before running independent discovery compresses effort, honors the money already spent, and signals that the new partner respects the work that came before.

1. CRM Contact Model with Regional and Relationship Fields

The prior contact record was missing the fields that every downstream CRM report depended on. Region tagging across Gulf Coast, Southwest, Great Lakes, and Other was absent, which broke regional pipeline reporting outright. Personal Notes for the client’s relationship based sales approach, Next Follow Up dates with automated task creation, and Last Contact auto update logic were all missing. Forty five hundred historical contacts sat in a spreadsheet with no bulk import flow scoped.

Clixlogix rebuilt the Odoo contact model against the client’s SOW. Region is now a required field on every contact and drives regional pipeline reporting. Personal Notes and Sales Notes are captured against each record.

Setting a follow up date creates a scheduled CRM activity on the assigned salesperson’s activity queue with a due date matching the follow up. Every interaction recorded through call log, email log, WhatsApp conversation, or meeting note updates the Last Contact date automatically.

The 4,500 contact backlog was migrated through a structured bulk import with deduplication rules applied on email, phone, and business name.

Credit limit is stored on the customer record and evaluated at sales order confirmation. When an order would push receivables past the configured limit, the system displays a warning on the confirmation dialog with the current outstanding balance and available headroom, requiring the salesperson to acknowledge before proceeding or route the order to Ownership for approval.

Fig 3 – The enriched Odoo contact model with regional tagging, follow up activities, and credit limit gating

2. Sales Configuration with 8 Tier Pricing

“The pricing tool stays. Get Odoo talking to it. Y’all figure out the plumbing.”
— Sales Manager

The client operates 8 distinct pricing tiers spanning Master Distributor, Distributor, Contractor Preferred, Contractor, and others, with cascading filters that resolve the correct rate based on customer, product, and quantity. A third party quoting tool had been running as a spreadsheet workaround because the prior Odoo configuration could not resolve tier pricing at quote time.

Clixlogix wired the third party quoting tool into Odoo as the pricing engine for quotes and sales orders. Eight tier cascading pricelists resolve at the sales order line.

Credit card surcharge sits as a toggle on the quote. Shipping can be entered manually where a rate shop is not appropriate. PDF quotes generate with the client’s branding. Quotes convert to sales orders with priced attributes carrying forward.

Payment terms per customer auto populate on every invoice from the customer record. Discount approval is gated at the 10 percent threshold, routing any deeper discount to the Sales Manager for approval before the quote leaves the system.

Repeat order functionality allows a past order to be duplicated as a new quote. This is a daily workflow for the sales team.

Technical Analysis

Odoo pricelists resolve item pricing against a sequence of rules within each pricelist. When multiple rules match the same order line, the rule with the highest priority wins and the rest are ignored, which can produce surprising results when tier structure evolves over time. Explicit priority ordering plus a fallback rule for uncovered edge cases prevent silent pricing errors at the sales order line, especially at tier boundaries where a customer straddles two categories.

3. Inventory Variant Model, Product Packaging, Kit BoM, and Stock Classification

“Every scan finds a different SKU. It is easier to look at the label than trust the scanner.”
— Warehouse Lead

The prior configuration had modelled cartridges, cans, quarts, gallons, pails, and drums as flat SKUs, with every size and packaging combination as a separate product template. Structural adhesive systems, which the client sells as a kit of 4 component SKUs, were not modelled as kits at all. Stock velocity classifications across Fast, Steady, Slow, and Obsolete appeared in reports. No engine drove them from the inventory module.

When the variant model rebuild started, the catalogue carried duplicate product templates for what should have been variants of a single template. Product managers had been duplicating templates to work around the missing variant logic. The rebuild consolidated these duplicate templates back into a proper template plus variant structure, which reduced catalogue maintenance overhead without changing the count of genuinely distinct saleable SKUs.

Clixlogix rebuilt the catalogue around an Odoo variant tree with structured product packaging. Product family sits at the template level. Formula grade and container format sit as variant attributes underneath, with container values including Cartridge, Can, Pail, Drum, Quart, and Gallon.

Each container format is a distinct saleable product variant with its own SKU, stocked in Units. A quart can and a gallon can are separate discrete stock items. Unit of measure conversion between them at the sales order line does not apply.

Product Packagings on each variant define fixed procurement and sales quantities, so a case of 12 cartridges or a pallet of 4 pails posts the correct discrete unit count to stock.

Adhesive system kits are configured as Kit BoMs. Fulfillment of one kit auto deducts the primer, adhesive, activator, and applicator SKUs from stock.

A stock classification engine sets, updates, and clears Fast, Steady, Slow, and Obsolete flags against velocity thresholds calculated from units sold over a rolling 90 day sales window. The classification job runs nightly.

Fast. SKUs above the top decile of unit sales.
Steady. The next four deciles.
Slow. Below median velocity with any sales in window.
Obsolete. Zero sales across the full window.

The Texas warehouse ran scanners from two different vendors with different symbology support. Some scanners read EAN 13 labels reliably. The Code 128 labels used for warehouse generated receipt tags did not read reliably on the same scanners. Barcode configuration was built to handle both symbologies without forcing a hardware refresh, and a firmware compatibility matrix was documented for the ops team so future scanner purchases stay within the supported set.

Fig 4 – The three tier inventory model from product template through variant attributes to warehouse operations

4. Dual Vendor Case Reconciliation, The Inventory Leak Fix

This was the client’s own highest priority fix. Product from Vendor A arrived in cases of 24 cans. The same product from Vendor B arrived in cases of 30 cans. The prior system posted the same count at receipt regardless of source. Every Vendor B case was shelving 6 cans of unrecorded inventory.

Clixlogix configured Odoo’s vendor packaging capability on each product. The Vendor A case of 24 cans and the Vendor B case of 30 cans are registered as separate purchase packagings linked to their respective vendors.

The applicable packaging is selected on the purchase order line from the vendor record and carried onto the receipt, so the case count posts against the actual case quantity for that vendor. Where a vendor supplies multiple packaging formats, the buyer selects the packaging on the PO line before confirmation.

The vendor bill quantity and billing unit follow the same packaging structure through Odoo’s standard bill to receipt matching. Reconciliation between the vendor bill and the physical receipt now matches the actual can count moved into stock. The inventory leak is closed.

Fig 5 – Dual vendor case reconciliation closing the six can per case inventory leak on Vendor B receipts

Field Note

Vendor specific packaging rules are more common than they appear in distribution operations with multiple sourcing options. During discovery for any distribution client, ask about pack counts by vendor before scoping receiving flow. The two prior partners had missed this because they had never asked.

5. Bulk Adhesive to Filled Cartridge via Manufacturing BoM

Adhesive base compounds are received from the Mexico factory as bulk material in kilograms. The Texas warehouse fills discrete cartridges from bulk material before shipment to customers. The prior configuration treated bulk drums and filled cartridges as unrelated SKUs with manual stock adjustments each time cartridges were filled. Physical stock and system stock drifted apart on every base compound shipment because the fill event was not recorded as a system transaction.

The mass to volume transformation cannot be handled through Odoo’s native UoM conversion. Kilograms sit in the Weight category and fluid ounces sit in the Volume category. Odoo only converts automatically within a single UoM category. The transformation also involves discretization into a countable finished good, which requires a manufacturing step that native UoM conversion does not model.

Clixlogix modelled this as a light manufacturing flow using Odoo’s Manufacturing module. Bulk adhesive base is configured as a raw material product measured in kilograms in the Weight category. Filled cartridge is configured as a finished good product measured in Units.

A Manufacturing BoM defines the transformation. Each cartridge consumes a specific mass of bulk material calculated from the adhesive’s density and the cartridge fill volume.

When cartridges are filled at the Texas warehouse, a Manufacturing Order consumes bulk stock and produces cartridge stock in the correct proportion. System stock now tracks bulk drum inventory and filled cartridge inventory accurately, and the transformation is auditable through the Manufacturing Order record.

Fig 6 – The bulk adhesive to filled cartridge transformation modelled as a Manufacturing BoM

6. Purchasing Engine with In Transit Awareness and Mexico Factory Flow

The prior custom demand calculation used average daily sales multiplied by lead time plus safety stock. It did not include confirmed incoming quantities from active Mexico purchase orders. The system could recommend a fresh order on a SKU with 20 to 60 days of stock on the water.

The Proforma Invoice step, which the Mexico factory issues before production and which triggers a pre payment deposit obligation, did not appear anywhere in the flow. Multi product container consolidation, where a single truckload from Mexico carries multiple products from different POs with shared freight cost, was not modelled.

Clixlogix rebuilt the purchasing engine so confirmed in transit quantities from active purchase orders are deducted from the calculated need before a purchase suggestion fires, using Odoo’s native forecasted quantity as the underlying data source. Draft and cancelled purchase orders are excluded from incoming stock. Confirmed purchase orders count toward forecasted supply when their expected receipt dates fall within the planning horizon. Overdue receipts are flagged for review and excluded until purchasing reconfirms their expected dates.

The Proforma Invoice sits as its own custom step between purchase order creation and shipment milestone tracking, with the deposit obligation triggered on Proforma receipt.

Eight custom shipment milestones track each PO through the full lifecycle.

Order Confirmed
Production
Shipped
In Transit
Border Crossed
Arrived
Cleared
Delivered

Freight and duty are allocated to received inventory valuation after receipt validation using the configured allocation basis, which sits on quantity for freight and value for duty per the client’s cost accounting policy. That inventory valuation reaches COGS when the related inventory is sold. Multi product truckloads link multiple POs to a single custom container record, and the container’s freight cost is allocated across all products within it on the configured basis.

Fig 7 – The Mexico factory to Texas warehouse shipment lifecycle with in transit deduction before reorder

7. Shipping and Logistics with Carrier Integration

Small parcel and LTL shipping ran on different rails without integrated tracking. The prior flow assumed one order equals one label equals one shipment. Multi package splits, residential surcharge flags, and the PRO number capture step for LTL freight after pickup were all absent. Tracking numbers appeared on the customer email as a final step. Auto capture from the carrier API was never modelled.

Small parcel. Clixlogix integrated UPS and FedEx rate shopping into the Odoo shipping flow with tracking number auto capture from the carrier API on label generation. Multi package shipments now split into multiple labels against a single sales order. The residential versus commercial delivery flag comes from the carrier API’s own address classification at rate quote time. A manual override is available on the shipment record where the salesperson knows the destination better than the classifier.

LTL freight. LTL shipments through the client’s freight broker run through a custom REST API integration built against the broker’s published endpoints. Odoo generates the BOL from the shipment record and pushes it to the broker at pickup dispatch. The PRO number is returned by the broker’s API after pickup and captured automatically against the order record for customer service tracking. When the broker’s API is delayed on PRO issuance, the customer service team can enter the PRO manually with a flag distinguishing manual entry from API capture.

Cross border. Cross border shipments generate a commercial invoice, a packing list, and a country of origin declaration from the same flow. HTS codes carry from the product master into the customs data export.

8. Accounting with Recovered Versus Absorbed Fee Branching

“The close takes three days because we manually correct the ledger.”
— Finance Lead

The prior profitability calculation treated every credit card, wire, and shipping fee as a cost against margin, regardless of whether the customer had paid the fee on the invoice. This produced incorrect net margin figures across every customer who paid their own fees. Automated payment reminders were absent. A low margin invoice alert to ownership below a configurable threshold was specified in the SOW. Delivery had skipped it.

Clixlogix rebuilt the fee treatment logic in the accounting flow. Each fee category calculates net fee cost as the actual processor, bank, or shipping charge minus the amount recovered from the customer on the invoice.

Credit card, wire, and shipping fees carry their own accounting rules with separate revenue accounts, expense accounts, and recovery policies. Full recovery, partial recovery, and over recovery all resolve correctly through the same calculation. True net margin now reflects the real cost of each fee category per invoice.

Automated payment reminders trigger at 5 points.

5 days before due
On the due date
7 days overdue
21 days overdue
45 days overdue with escalation to ownership

A low margin invoice alert fires to ownership immediately on any posted invoice where net margin drops below the configured threshold. Bank reconciliation posts across the client’s 3 bank accounts with statement import and matching automation.

Fig 8 – Net fee recovery branching for credit card, wire, and shipping fees per invoice

9. Reporting with Cash Foresight Beyond the Standard Suite

Reporting needed to answer questions the prior configuration could not. Working capital metrics needed a single view. Mexico factory PO planning needed a cash impact simulator distinct from the 90 day forecast. Fee recovery rate by month needed to be measurable so pricing policy could be reviewed against actual recovery. Customer product cross sell opportunity needed a matrix to identify complementary purchases. Profitability by pricing tier needed to be visible so tier pricing could be validated against payment fee absorption.

Clixlogix built six reports and dashboards against these requirements.

Working Capital KPI Dashboard. Built in Odoo Spreadsheet linked to live database views. Covers Cash, Accounts Receivable, Accounts Payable, Inventory, DSO, Inventory Days, and Cash Conversion Cycle in a single view.
Cash Flow PO Impact Simulator. A custom Odoo model with a scenario form. Answers questions such as the projected cash position in a specific future week if a given PO is placed today with a stated deposit and shipment payment split.
PO Cash Commitment Report. Shows all open POs with committed cash, deposits paid, and remaining balance due.
Fee Recovery Rate Report. Tracks the net fee recovery ratio by fee category by month.
Customer Product Cross Sell Matrix. Identifies customers who bought from one product family during the last 12 months and did not buy from a defined complementary family in the same window.
Profitability by Pricing Tier Report. Shows average net margin per tier. Net margin is invoice revenue minus landed product cost, minus discounts and returns, plus net fee recovery, minus write offs.

The first iteration of the Cash Flow PO Impact Simulator missed a real world constraint. Freight cost is not known at the moment a purchase order is placed. It becomes visible 5 to 10 days later when the container is booked with the freight forwarder.

The simulator was rebuilt to project a freight cost range with a high and low bound calculated from the trailing 12 month broker rate history on the same origin to destination lane, then swap in the booked cost once actual booking numbers arrive. Ownership now sees both pessimistic and optimistic cash trajectory in the same view. Planning conversations shifted from single point estimates to range based decisions.

Fig 9 – The six report and dashboard suite built for cash foresight beyond the standard Odoo reports

10. Data Migration, User Onboarding, and CPA External Access

Four entire operational flows had been missing from the prior contractor’s specification. HR user onboarding, the Cash Flow PO Impact Simulation delivered under the reporting workstream, CPA read only external access, and the Data Migration and Reconciliation swim lane all needed to be built from scratch.

QuickBooks cutover. Clixlogix executed the accounting cutover from QuickBooks to Odoo. The migration scope covered the chart of accounts, cutover date opening balances, open receivables, and open payables. Full transactional history for the pre cutover period stayed in QuickBooks as a read only archive. Odoo became the single system of record from the cutover date forward.

User onboarding and CPA access. A user onboarding flow was built for internal staff with role based access provisioning. The external CPA has a read only access model into the accounting modules with the specific reports they need for tax filing, including a general ledger export.

Cutover reconciliation. Reconciliation was documented as its own workstream with reports comparing opening balances by ledger account and open items by individual document. The finance team could verify each position before final cutover.

Delivery Note

Finance closes each month on business day 3. During the parallel run period ahead of final cutover, the QuickBooks to Odoo balance comparison ran automatically overnight after each test migration cycle. The Finance Lead received the reconciliation report by 7 AM the following day, which kept the parallel run from slipping the actual month end close. Post cutover, this pipeline was retired and normal Odoo close ran without any QuickBooks dependency.

Delivery Cadence and Testing Discipline

The rebuild ran on a 2 week sprint cadence with continuous client feedback. Sprint planning opened each cycle with acceptance criteria written by the Business Analyst in Gherkin format, stored in the same GitHub repository as the code. The client’s Sales Manager and Warehouse Lead attended the sprint demo to sign off on deliverables before they promoted from staging to production. Retrospectives closed each sprint.

Continuous integration ran through Odoo.sh staging branches with a GitHub Actions workflow layered on top. The workflow deployed each merged pull request into a designated staging branch, ran a custom database anonymization script against sensitive customer fields before test execution, and reported results back to the pull request. Regression tests covered quote to invoice, receipt to stock, and Cash Flow PO Impact Simulator flows. A GitHub branch protection rule required a passing regression run before merge to production.

Fig 10 – The delivery pipeline from developer commit through branch protection to feature flag rollout

Higher risk changes shipped behind feature flags implemented as Odoo system parameters keyed to specific customization modules. Dual vendor case reconciliation and net fee recovery both rolled out to a pilot cohort first, with the flag flipped to full rollout only after 2 weeks of clean operation. Data migration had its own gate. The cutover balance import could not promote to production unless the reconciliation reports matched within tolerance.

Daily bug triage sorted incoming defects into three lanes.

Production breakers. Same day fixes.
Normal defects. Cleared at sprint end.
Cosmetic items. Backlog reviewed at the sprint retrospective.

This discipline prevented the tail of unresolved defects that had left the prior partners’ work unshippable.

Implementation Roadmap and Commercial Envelope

The rebuild ran across phases with a fixed cost per phase and a timeline landing the full system by the end of year deadline. Each phase carried stated acceptance criteria and test scenarios.

The engagement ran on a fixed cost model. A Business Analyst led functional workstreams. A Delivery Manager acted as technical architect for Odoo configuration and customization. A Senior Digital Consultant owned the client relationship. CEO oversight covered commercial and scope decision points.

Estimation was shared as a line item sheet showing person, role, hour count, and deliverable, keeping the commercial envelope transparent through three scope revisions.

Warranty Period and Post-Launch Feedback

The engagement carried a 90 day warranty after production cutover during which Clixlogix absorbed fixes for any defect traceable to the rebuild scope. The SOW defined a same day acknowledgment SLA and a 3 business day fix delivery target.

Feedback ran through email between the client’s operating team and the Business Analyst and Delivery Manager mailboxes. Formal ticketing was skipped. Fixes shipped through the same Odoo.sh staging branch and CI pipeline that had governed the rebuild.

Total issues surfaced during warranty landed in the low double digits. Most were edge cases in pricing tier resolution for customers who straddled category boundaries and reconciliation quirks involving a handful of opening balance journal lines and open receivable or payable allocations. All were resolved inside the warranty window. Ownership signed off on warranty close at day 90.

Client-Initiated AI Extension

Approximately 60 days into the warranty period, the client’s owner sent a short email to the Senior Digital Consultant.

“Read your AI posts before hiring you. Ready to add that. Set up a call.”
— Ownership

The blog posts covered conversational agent surfaces, AI assisted document processing, and the operational economics of running agents on top of ERP systems. The owner had read them during initial vendor vetting and held the idea until the core rebuild proved itself in production. The scoping call happened the following week.

The extension shipped as a distinct engagement with its own SOW, fixed cost envelope, and acceptance criteria. It reused the existing Odoo codebase and delivery team.

The agent Gateway, messaging channels, model API accounts, monitoring, identity mapping, audit logs, document intake pipeline, and review queues required a separate runtime and security configuration on new infrastructure.

Scoping ran across roughly 12 working hours split between a 4 hour operational workshop, 6 hours of technical assessment against the stable Odoo instance, and 2 hours of SOW preparation. Two workstreams emerged. A conversational agent surface on Odoo for the sales team through WhatsApp and Slack, and an automated vendor document extraction workflow for the Mexico factory Proforma invoices, BOLs, and container manifests the purchasing team had been transcribing by hand.

Conversational Agent on Odoo via Gemini and OpenClaw

The AI extension’s first workstream built a conversational agent surface so the sales team could run daily Odoo workflows from WhatsApp and Slack. Primary customer contact already ran through WhatsApp, with every interaction feeding the Last Contact date on the CRM record. Earlier AI helper scripts had accumulated around the prior Odoo instance for pricing lookup, inventory visibility, and operational handling. The channel needed better tooling. The scripts needed consolidation into a maintainable form.

Architecture

Clixlogix deployed OpenClaw as the sustainable agent surface on top of the stable Odoo build. OpenClaw runs as a Gateway process on the client’s own infrastructure, receives messages from WhatsApp using the Baileys channel and from Slack using Socket Mode over WebSocket, and routes them into a session powered by Gemini 2.5 Flash-Lite for Tier 1 read only queries and Gemini 3 Flash Preview for Tier 2 approval drafting.

The agent executes actions against Odoo through the Odoo External API. The initial deployment used XML-RPC with the integration isolated behind a Python adapter so the client can migrate to Odoo 19’s JSON 2 API before XML-RPC removal in Odoo 22. Each Odoo module in scope exposes a specific set of operations through a Python skill package with structured input schemas, retry logic, and clear error responses.

Authentication runs through role based Odoo internal user accounts, one for each of Sales, Purchasing, Ownership, Finance, and Warehouse. API keys sit in environment variables and rotate on schedule. No superuser access. Odoo’s own access control system enforces which operations each role can invoke.

Fig 11 – The OpenClaw agent architecture from messaging channels through Gemini to the Odoo External API

Technical Analysis

Gemini was chosen for three reasons. Cost per token at the Flash-Lite tier sits at the low end of major provider offerings, which matters for the 3 percent of revenue technology budget ceiling. The 1 million token context window handles multi turn conversation state and larger tool result payloads without truncation. Live product catalogue, customer records, and PO status are retrieved per request through Odoo tool calls without preloading into session context, keeping data current and limiting customer data exposure. Native multimodal handling in the same model family covers vendor document extraction as a second use case without switching providers.

Technical Analysis

Gemini 2.5 Flash-Lite serves Tier 1 read only queries at $0.10 input and $0.40 output per 1M tokens, the selected low cost tier at deployment. Tier 1 queries are structured lookups where throughput and price matter more than reasoning depth. Gemini 3 Flash Preview serves Tier 2 mutating operations requiring multi step approval drafting, at Google’s fast Flash tier for the Gemini 3 generation with the reasoning depth needed for approval message construction, at a price point well below Gemini 3.1 Pro. The split kept monthly LLM spend inside the operating budget and preserved reasoning depth where the approval flow needs it.

Action Surface

The action surface splits into two tiers. OpenClaw’s tool policy configuration provides the coarse boundary by controlling which tools each agent role can invoke at all.

Tier 1 reads. Read only tools that execute automatically. Sales staff query stock by variant attribute before quoting. Purchasing queries in transit inventory and open PO cash commitment. Ownership queries the working capital dashboard and asks scenario questions of the Cash Flow PO Impact Simulator directly through chat.

Tier 2 writes. Tools that pause for explicit human approval routed through the same channel that made the request. Draft quotes generated through conversation resolve the 8 tier pricing engine and produce a PDF for review, sent back through chat for approval before the quote leaves the system. Discount requests above the 10 percent threshold pause and route to the Sales Manager with customer, product, and margin impact stated in the approval message. Low margin invoice alerts and credit limit warnings surface to ownership through chat with the underlying figures inline.

Daily automation. Workflows the agent runs without operator initiation. CRM activity logging on incoming WhatsApp customer messages runs automatically and updates the Last Contact date. The daily purchase suggestion, previously an email report, arrives each morning as a WhatsApp message to the purchasing lead with SKUs, calculated need, and in transit deduction shown.

Deployment and Reliability

Every tool call is logged with tool name, arguments, session context, and decision outcome for audit review. Sensitive fields including customer names, prices, and invoice amounts are redacted at write time.

The deployment sits behind Caddy on Ubuntu with the Gateway bound to loopback for private channels. Slack uses Socket Mode with an app level token, which keeps the Gateway off the public internet. The WhatsApp channel runs on a dedicated business number distinct from any personal WhatsApp account, with session credentials held on encrypted disk.

Skill tier assignments and policy changes hot apply through OpenClaw’s default gateway.reload.mode: hybrid setting in openclaw.json without Gateway restart. Adding a new plugin skill may require a channel or Gateway restart depending on the plugin, and this is handled through the standard sprint cadence.

The WhatsApp channel runs on the Baileys implementation, which is unofficial and can break when the underlying WhatsApp web protocol changes. Two mitigations were built in from day one. An email fallback routes urgent approval requests to the appropriate role by email if WhatsApp goes down. Credit limit warnings and low margin alerts never sit in a dead channel. The email fallback carries the same signed approval ID, expiry window, and single use enforcement as the chat path. A channel health monitor pings the Gateway every 5 minutes and alerts ownership if the WhatsApp connection has been unhealthy for more than 15 minutes.

Delivery Note

Tier 1 agent queries target a 3 second budget end to end. On a validation sample of 200 stock lookup queries measured during warranty against the production Odoo instance in the same US region as the Gateway, median latency landed at 2.1 seconds with a 95th percentile at 3.4 seconds, measured Gateway ingress to Gateway egress. WhatsApp delivery latency to the phone sits outside this budget. Stock lookups run against live Odoo state without caching, since stock levels change during quoting and a cached availability answer could lead to overselling.

Sender Identity and Access Control

Security starts before any Odoo permission check. OpenClaw’s native sender admission and channel allowlist rejects messages from unmapped WhatsApp numbers and Slack user IDs before they reach the LLM session. On top of that, Clixlogix built a custom identity mapping component that resolves each admitted sender to a specific internal employee and each employee to one of the five role based Odoo internal user accounts covering Sales, Purchasing, Ownership, Finance, and Warehouse.

Because role accounts are shared across employees within each role, the Gateway audit log preserves the specific sender identity and writes a correlation ID into the Odoo record chatter, so the audit trail can reconstruct which employee triggered which Odoo write. The allowlist and identity mapping are controlled configuration requiring manager approval for changes. Access removal on employment change happens same day.

Approval Controls and Idempotency

Tier 2 write operations run through custom validation logic Clixlogix registered on OpenClaw’s before_tool_call hook. The tool policy above already restricts which mutating tools each role can invoke. On top of that, the custom hook performs payload validation against the schema, HMAC approval verification, replay check against a persisted store, and audit enrichment before execution.

Each pending Tier 2 action carries a canonical payload including record ID, action type, and the exact values shown to the approver, signed with HMAC using a Gateway held secret. Approval IDs expire after 15 minutes and are single use. If any signed value has changed at commit time compared to the approval message, the approval is invalidated and a fresh request is generated with current values. The HMAC secret rotates quarterly and on any suspected compromise.

Quote, invoice, and CRM activity creation carries a stable request ID generated once at operator commit and persisted across retries. Odoo rejects any write attempt with a request ID that has already succeeded, so network drops and reconnects do not create duplicates. Request IDs are retained for 30 days.

Customer Channel Isolation and Prompt Injection Handling

Customer facing WhatsApp traffic is isolated from the agent command channel. Inbound customer messages arrive on a separate business number and route through a matching component that resolves sender phone to customer record on the CRM. Matched messages log as CRM activity updates with deduplication on WhatsApp message ID so a redelivered message does not create a duplicate log entry.

Attachments such as photos of damaged shipments and PDF returns forms attach to the CRM activity and inherit the same access controls as any Odoo attachment. Consent language covering communication and logging is captured on customer onboarding, with a stop communication opt out honored by the matching component before any log write. Unmatched sender numbers route to a manual triage queue for the sales team.

Prompt injection is addressed through architecture. OpenClaw’s own security guidance is clear that detection based defenses on adversarial content have been defeated under adaptive attack. External messages and vendor documents are handled as untrusted input by restricted components that carry no Odoo write tools. Customer WhatsApp messages route into the CRM activity logging path only. Vendor documents route into a Gemini extraction component that emits structured JSON against a defined schema. Both untrusted paths cross into the write path only as validated structured data, and all financial writes require explicit human confirmation through the Tier 2 approval flow.

Technical Analysis

OpenClaw’s threat model treats authenticated Gateway callers as trusted operators within the gateway instance, a documented architectural position. The mitigation is minimal tools per agent role, restricted allowlists, sandboxing, and human confirmation for sensitive actions. The controls Clixlogix built on top are HMAC signed value bound approvals, stable request ID idempotency, sender identity mapping with same day revocation, customer versus internal channel separation, and untrusted input isolation. These are guardrails against common failure modes. Strong multi tenant isolation would require additional infrastructure. The deployment sits on the client’s own infrastructure with a small operating team, a single workspace, and a controlled sender allowlist. That deployment shape fits the guardrail model.

Vendor Document Processing via Gemini Multimodal

Document Mix and Native Odoo Testing

The AI extension’s second workstream automated data extraction from vendor documents the purchasing team had been transcribing manually.

Mexico factory Proforma invoices carry handwritten annotations against quantities and delivery dates where the factory foreman notes production constraints. Freight forwarder Bills of Lading arrive with stamps, shipper handwritten notes, and container manifests spanning three or four pages per shipment. Customs paperwork carries HTS codes, country of origin certifications, and duty calculations across multiple sheets.

Manual transcription ran 20 to 40 times per month. Transcription errors corrupted downstream reporting including working capital projections and the Cash Flow PO Impact Simulator.

Odoo 19 supports document digitisation using OCR and AI as a native feature. During testing against the client’s actual document mix, native digitisation did not reliably capture handwritten amendments on printed line items, totals dispersed across multi page container manifests, or operational stamps and shipper notes on BOL scans. The client’s documents pushed the extraction requirement beyond the native feature’s reliability envelope.

Gemini Extraction Workflow

Clixlogix built a document extraction workflow using Gemini 3 Flash Preview’s multimodal capability. Documents dropped into a monitored folder are converted, validated, and processed by Gemini, which reads mixed content of printed text, handwritten annotations, tables, and stamps and emits structured JSON matching the Odoo purchase order and vendor bill schemas.

The extraction output carries per field source page references. Confidence scoring flags low confidence fields for buyer attention. Duplicate document detection runs on document hash and reference number. Schema validation failures route to an exception queue with the specific error surfaced.

The output flows into a review queue in Odoo where the assigned buyer confirms or adjusts extracted values before posting. Human confirmation on financial commitments and shipment dates keeps ownership control on the numbers that flow to the ledger. Document files are retained for 90 days then archived off, and the Gemini API is configured for zero data retention on the extraction path.

Fig 12 – The vendor document extraction workflow from received documents through Gemini to the Odoo review queue

Technical Analysis

The extraction component operates as an untrusted input processor with no Odoo write tools. It reads printed text, handwritten annotations, tables, and stamps in each processing run and returns structured output matching a specified schema. The human review step in Odoo means Gemini does not need to be perfect on ambiguous handwriting. Validation happened on a sample of 100 recent Proforma invoices and 50 BOLs collected during discovery, with field level matching against manually verified ground truth. On line item text, quantities, and unit prices, the extraction target of 95 percent field match before buyer correction was met on the validation set. Handwritten shipment date annotations trailed at a lower match rate. The buyer’s confirmation step covers remaining edge cases.

Results

The engagement is active. Discovery, platform decision, and customization scope lock outcomes are complete. Phase acceptance outcomes are being added as phases complete.

14 Documented Gaps Closed in the Rebuild

Every gap the client had diagnosed in the prior contractor's specification was addressed across the 10 workstreams of the initial rebuild.

Active Inventory Leak Fixed at Receiving

Vendor specific pack counts now post correctly at the carton posting step, ending the inventory drift on incoming Vendor B cases that the client had flagged as their highest priority fix.

8 Pricing Tiers Resolved at Quote Time

Cascading pricelists replaced the spreadsheet workaround, with the 10 percent discount approval gate wired in for margin protection.

4,500 Contacts Migrated with Deduplication

The historical customer base consolidated into Odoo with Region tagging live for regional pipeline reporting and Personal Notes preserved for the relationship based sales approach.

Mexico to Texas Visible Through a Consolidated Milestone View

Eight shipment milestones track each container across 20 to 60 day Mexico lead times through a consolidated view, with in transit inventory deducted from the calculated need before the reorder engine fires.

5 Trigger Automated Payment Reminder Sequence Live

Reminders fire from 5 days before due through 45 days overdue with escalation to ownership on the final trigger, closing the accounts receivable follow up gap.

Selected Odoo Workflows Accessible Through WhatsApp and Slack

OpenClaw with Gemini 2.5 Flash-Lite and Gemini 3 Flash Preview exposes read only queries and pauses mutating operations for human approval through chat, replacing earlier AI helper scripts that required manual maintenance whenever Odoo's data model shifted.

Manual Vendor Document Entry Reduced

Proforma invoices, BOLs, and container manifests are extracted by Gemini 3 Flash Preview multimodal into an Odoo review queue where the buyer confirms before posting, replacing 20 to 40 manual transcriptions per month with pre populated draft records.

Odoo Validated Over Business Central on Documented Reasoning

The platform decision was published with cost, fit, customization economics, and integration dependency reasoning stated in writing, giving the client's board a defensible answer after two failed certified partner attempts.

21 Day Close From First Discovery Call to Signed Statement of Work

Discovery effort was compressed to 28 hours because the client's own gap analysis had already done the diagnostic work, and the commercial envelope held constant across three scope revisions.

Technology Stack

Category	Tools and Platforms
Platform Core	Odoo 19 (ERP on Odoo.sh with GitHub based deployment pipeline); Microsoft Dynamics 365 Business Central (evaluated as primary alternative, not selected)
Odoo Modules in Scope	Inventory (variant tree, Product Packagings, Kit BoM, vendor specific pack rules, stock classification engine); Manufacturing (BoM and Manufacturing Orders for bulk to cartridge); Sales (quote to order with pricelist resolution and discount gate); Purchase (demand calc with incoming quantities, Proforma workflow, 8 shipment milestones); Accounting (net fee recovery, cutover reconciliation, CPA reports); CRM (regional tagging, personal notes, follow up activities, last contact updates)
Pricing and Quoting	Third party quoting tool integrated as the pricing engine for 8 tier cascading pricelists at quote time
Data and Migration	QuickBooks (read only archive for pre cutover history); structured import pipeline (opening balances, open receivables, open payables, chart of accounts)
Shipping and Logistics	UPS and FedEx (small parcel rate shop with tracking capture and address type flag); LTL freight broker (custom API for BOL generation and PRO number capture); custom customs documentation module (commercial invoice, packing list, country of origin export)
Conversational Agent	OpenClaw Gateway (self hosted on Ubuntu with Caddy, Slack via Socket Mode); Gemini 2.5 Flash-Lite (Tier 1 read only queries); Gemini 3 Flash Preview (Tier 2 approval drafting); WhatsApp (Baileys, dedicated business number); Python skill packages calling the Odoo External API (`XML-RPC` now, `JSON 2` planned before Odoo 22)
Document Extraction	Gemini 3 Flash Preview multimodal (structured JSON matching Odoo schemas, zero data retention); monitored folder pipeline (schema validation, duplicate detection); Odoo document review queue (buyer confirms before posting)
Security and Access	Sender identity mapping with same day revocation; employee to Odoo role mapping across 5 role based accounts; OpenClaw native sender allowlist; API keys in environment variables rotated on schedule; HMAC signed approval payloads (15 minute expiry, single use); stable request ID idempotency; customer versus internal channel separation; untrusted input isolation; audit logging with field level redaction

Services Delivered

Enterprise Software, ERP Services, AI Software & Application Development, Digital Engineering, Consulting Service, Project Rescue

Team Composition

Senior Digital Consultant, Delivery Manager and Technical Architect, Business Analyst, Odoo Functional Consultant, Python Developer, DevOps Engineer, QA Engineer, CEO Oversight

Have a question for our team or need help with your project?

Our team can share client references, scope your project, and answer any question about your delivery.

Related Case Studies

More engagements where our delivery teams shipped similar outcomes for clients across industries. Read on for context on the patterns we reused, the trade offs we navigated, and the metrics that landed in production.

Alcohol SEO and Content Marketing for a Premium US Spirits Brand

SEO Digital Marketing Ecommerce SEO

Abu Dhabi real estate paid media audit and lead quality case study featured image

Paid Media Audit and Lead Quality Rebuild for an Abu Dhabi Real Estate Agency

Digital Marketing PPC Real Estate

View All Case Studies