Code and SoulC// S
    AboutDiagnosticCasesInsights
    Where to startEngineering diagnostic
    Build and operateCritical PlatformsSoftware engineeringAWS OperationsSoul Stack
    Modernise what existsDrupalAcquia Site StudioAcquiaOdoo
    Operational intelligenceApplied AITraceable revenueBars and restaurants
    Engineering capacityEngineering Residency
    OdooImplementation, integration and evolution

    Anyone can install Odoo. Implementing it is another story.

    Code and Soul designs, integrates and evolves Odoo for real operations, from the cash desk at a bar to the shop floor, and through Brazilian tax.

    And we know the other side of the counter: our bar, our gym and our agency run on Odoo.

    Fiscal › Matriz fiscal
    Fiscal matrix in Odoo, with each operation, its internal, interstate and export CFOP codes, CST codes and base reduction
    Fiscal › De-para de fornecedores
    Supplier mapping in Odoo: each supplier's code and description point to the internal product, using fictitious companies

    An ERP rarely fails at installation. It fails at the first thing your process does that the system's standard does not foresee.

    That is when having been through it counts. Plenty of people can configure. Knowing what will go wrong at the March close, before March, comes from having closed one.

    What we learned by doing it.

    Nine situations that define an Odoo project, and what we do in each one.

    • Odoo Point of Sale

      The sale deducts stock, but the balance does not add up.

      A recipe becomes a bill of materials and deducts each ingredient at the sale. But outflow without inflow means negative balances. So checked receiving goes into the project together with the point of sale, not as a month-end correction.

    • Odoo Accounting

      Post each sale, or close by cash session?

      Sale-by-sale entries clutter the books. By session, the entry follows the cash close, and the month reconciles. This is a choice to make before the first day of the point of sale, not after.

    • Odoo Purchase

      The supplier bill arrives with no line items. What about cost of goods?

      You can have cost of goods by category from the bill, separating cost from expense and reconciling with the bank. By product, only with itemized receipts and stock valuation. We tell you which of the two your operation can sustain.

    • Odoo Employees

      Several companies in one database.

      Multi-company is where most mistakes happen. Chart of accounts, tax rules, stock, signature and each lead's destination must know whose they are. Our own database holds five companies, and each one sees what is its own.

    • Odoo Studio

      The Studio automation worked, until someone touched it.

      A rule the operation depends on becomes versioned, tested code. Studio stays for what can break without stopping anything. That is what we did at Ōkami.

    • Odoo WhatsApp

      The customer does not use e-mail.

      Official WhatsApp goes into the Odoo flow, not beside it. At Ōkami, the signed contract reaches people with no e-mail through WhatsApp.

    • AI needs to talk to the ERP. Through what?

      Through dedicated routes, with calls signed in both directions, and sensitive data kept out of what is sent, enforced by an automated test. An assistant with loose access to the database is the risk we do not accept.

    • Odoo Manufacturing

      The finished lot has to say where it came from.

      Bills of materials, operation routing, a tablet on the shop floor and tracing from the finished lot to the component lot. With imports, freight, insurance and customs fees go into average cost, and drawback has a balance and a deadline.

    • Configure or code?

      Configure first, because a custom module is code to maintain through every upgrade. When what comes out of the box does not solve it, the module is built apart from the core and with tests, to survive the version change.

    Odoo calculates the tax. Who checks it?

    We integrate Avalara, Odoo's official tax engine for Brazil, and built our own core that checks the calculation line by line against an auditable matrix, with CFOP and CST codes, base reduction and legal text per operation.

    Fatura › Prévia fiscal
    Fiscal preview of an invoice: the matrix reaches a 12% tax load and the tax engine 18%, with both cells highlighted in red and the divergence warning above

    In this example, with fictitious companies, the matrix applies a base reduction and reaches 12%. The engine charged 18%. The difference shows on the invoice, for someone to decide before moving on.

    • A fiscal preview on each invoice, line by line
    • The supplier's NF-e XML (Brazil's electronic invoice) becomes a draft bill
    • Mapping from the supplier's code to your product
    • Each rule validated with your company's accountant

    We do not just implement Odoo. We live in it.

    The group's bar, gym and agency run on Odoo. When a close does not add up, the problem is ours.

    Three operations of our own. Three uses with nothing in common.

    Ōkami

    Gym, with 40+, kids and fight training

    At Ōkami, an AI assistant on WhatsApp welcomes the prospect and records the trial class request. The front desk checks members in by name. And every day the system works out who is drifting away, with the reason written in their file. All of it on Odoo 19 Enterprise, with a custom gym module.

    Screens with fictitious data, in Portuguese.

    Ōkami › Alunos em risco
    List of fictitious members at risk at Ōkami, grouped into attention and at risk, with the written reason, adherence and days without check-in
    Ōkami › Entrada
    Front desk check-in screen at Ōkami: type the name and tap the member, with fictitious names

    Fabrik7

    Bar and brewery

    Restaurant point of sale, purchasing and inventory. 274 recipes deduct ingredients at each sale, and Odoo has already recorded nearly 100,000 stock moves.

    ATUO Group

    Agency and engineering

    CRM, prospecting and e-mail, each company with its own pipeline. The form at the end of this page lands in this same Odoo.

    The store buys. The factory already has the order.

    In a group with a factory and retail, one company's purchase order generates the sale at the other, with no double entry, and the point of sale and the online store share the same stock.

    Purchase at the store

    Loja › Compras
    Purchase order placed by the store with the factory of the same group, using fictitious companies

    Sale at the factory

    Fábrica › Vendas
    Sales order generated automatically at the factory from the store's purchase, using fictitious companies

    Implementation example, with fictitious companies, in Portuguese.

    All of Odoo, implemented by people who know what each app costs you later.

    • Odoo CRMCRM and salesA pipeline drawn from your real process, with fewer fields
    • Odoo Marketing AutomationMarketingJourneys and segmentation tied to the CRM
    • Odoo AccountingAccountingReconciliation, multi-currency and multi-company
    • Odoo InventoryInventoryWarehouses, routes, lots and replenishment
    • Odoo ManufacturingManufacturingBills of materials, routing and shop floor
    • Odoo ProjectProjectsHours, billing and profitability
    • Odoo EmployeesHRTeam, onboarding and permissions by role
    • Odoo Point of SalePoint of saleCash desk, restaurant and loyalty
    • Odoo eCommerceeCommerceA store with a single stock, B2C or B2B
    • Odoo WebsiteWebsitePages and forms that land in the CRM
    • Odoo StudioStudioQuick adjustments, with clear limits
    • Odoo DashboardsDashboardsIndicators for decisions, not decoration
    • AutomationsAlerts, approvals and rules you can test
    • IntegrationsAPIs, webhooks, payments and legacy systems
    • Odoo WhatsAppOfficial WhatsAppService and reminders inside Odoo
    • Odoo PurchasePurchasingOrder, receipt and true cost
    Free demoA clinical care platform on Odoo 19, ready to tryOnline booking, WhatsApp triage, reception, signed records, patient portal and management, in a fictitious clinic. Access is free and arrives by e-mail.
    How we start

    No chaos. No vague promise.

    Every engagement follows the same structure: understand the context, prove value fast, scale with governance.

    Technical and business discovery

    Clarity on what is feasible and where to start.

    An operable MVP in production

    Something running in the operation, not in a deck.

    Scale and continuous operation

    Evolution with governance, without restarting each cycle.

    What people ask us

    How does the implementation work?
    In phases, with the operation running. First what hurts most, live and in use, and only then the next module. An ERP rollout that becomes one big switchover day is the kind that fails most.
    We already have an Odoo that no longer keeps up. Will you take it over?
    Yes, and it is a common case. We start by understanding what was done and what depends on what, before changing anything. Sometimes the fix is removing customization, not adding more.
    Which versions do you work with?
    We have Odoo 18 and 19 Enterprise running in our own operations, so we know both day to day, including what changes from one to the other.
    Do you build custom modules or only configure?
    Both, in that order. Configure first, because a custom module is code to maintain through every upgrade. When what comes out of the box does not solve it, then yes, and the module is built apart from the core.
    What about artificial intelligence?
    Where it solves a concrete problem, like triaging a message or flagging who is drifting away. AI handles the routine within rules set by people, and the team takes over when the conversation calls for it. Without AI, Odoo must keep working.

    Where this has run

    The offer above has proof, and the proof has an address.

    Tell us what your operation needs from the ERP.

    Implementation, migration, or an Odoo already running that no longer keeps up with the business. Start with the problem, not the module.

    Engineering is not decoration. It is direction.