Skip to Content

Custom Engineering / Nimex Solutions

Beyond Standard Odoo. Engineered for Your Business.

Explore the custom applications, advanced workflows, industry-specific systems and integrations engineered by Nimex Solutions to solve business challenges beyond standard ERP functionality.

Discuss Your Requirements Search the Solutions
  • 1,500+custom modules delivered
  • 500+engineering capabilities
  • 8industries served
Odoo versions supported

What we engineer

Nine engineering disciplines, wired into one ERP.

Every solution below extends standard Odoo instead of replacing it: the standard flows keep working, upgrades stay possible, and the custom layer does exactly what the business needs.

Standard Odoo core, kept intact Odoo 15 · 16 · 17 · 18 · 19 · 20

Turkish compliance

Türkiye compliance, engineered into Odoo Accounting.

Turkish finance runs on electronic documents with statuses that carry legal meaning. On top of Odoo's Türkiye localisation and its Nilvera connector, Nimex engineered the commercial e-Fatura workflow, e-Arşiv and e-İrsaliye issued from the records you already post, GİB-style return invoices and incoming-bill autofill; e-Defter is scoped per project with a certified provider, and we say so.

e-Fatura on Nilvera

The commercial e-Fatura, from scenario to the customer's answer.

Odoo's standard Nilvera connector sends a basic e-Fatura and reports whether it was transmitted. Turkish practice asks for more: the Ticari scenario, where the customer formally accepts or rejects within eight days; withholding and exemption rules that GİB validates strictly; the template agreed with each customer; and the officially rendered PDF on file. Nimex engineered all of it as an additive layer on the standard send pipeline.

  • Temel and Ticari scenarios, defaulted per customer and frozen once the document is sent.
  • Blocking pre-send checks: registered e-Fatura user, withholding (tevkifat) consistency, exemption codes.
  • Nilvera Preview and XML download: the exact UBL-TR document, rendered by the provider, nothing issued.
  • Two statuses kept apart: transmission, and the customer's accept or reject answer, synced hourly.
  • Official Nilvera PDF fetched after sending and pinned as the first attachment; missing PDFs backfilled.
  • UBL-TR extras: customer PO reference, customer-facing line text, the invoice's own exchange rate, templates per customer.
  • Fault-tolerant sync: one failing document never stops the rest of the batch.

Requires Odoo's Türkiye localisation with the Nilvera connector and a Nilvera account. Cancelling or objecting to a sent e-Fatura is not part of the suite.

Explore the e-Invoice Suite

e-Arşiv

e-Arşiv for everyone who is not an e-Fatura user.

The recipient decides the channel: a registered e-Fatura user receives an e-Fatura, everyone else an e-Arşiv invoice with the EARSIVFATURA profile. Standard Odoo already routes the document; Nimex made the e-Arşiv branch behave like the e-Fatura one for the user, without the parts that do not exist there.

  • Recipient checked against the provider's registry when the contact is saved.
  • e-Arşiv templates mirrored from the Nilvera account, defaulted per customer.
  • Preview without an alias, official e-Arşiv PDF archived as the main attachment.
  • No scenario, no accept or reject: the screen shows only what applies.
See e-Arşiv in the e-Invoice Suite

e-İrsaliye

The despatch note leaves with the truck, issued from the delivery.

Goods leaving the warehouse need an electronic despatch note issued through a GİB integrator. Standard Odoo can build the UBL XML with vehicle and driver data, and stops there. Nimex completed the workflow on the delivery order itself: validate the transport data, preview the official PDF, send, store the ETTN and archive the official document.

  • Hard validation of plate, drivers (with TCKN) and dispatch type before anything is sent.
  • Önizleme (PDF): the provider-rendered despatch note, without creating a document.
  • Recipient resolved automatically: their e-İrsaliye alias, or the GİB postbox.
  • Line prices and currency seeded from the sales order instead of zero.
  • Issue date frozen once sent; the actual despatch date follows the transfer.
  • Errors kept readable with Tekrar Gönder; queued dispatches sent every 30 minutes.

Outgoing deliveries in Türkiye, through Nilvera. Incoming e-İrsaliye, recipient answers and cancellation are not part of the solution.

Explore e-İrsaliye

Returns & incoming e-invoices

Returns GİB accepts, and incoming bills that arrive already filled.

A Turkish return is not a UBL credit note: it is an invoice with the type code IADE and a billing reference to each original invoice. Nimex added that document, books customer returns received as e-invoices on the textbook accounts, and rebuilt the import of supplier e-invoices so the accountant reviews instead of retyping.

  • İade e-documents with InvoiceTypeCode IADE, Temel profile and BillingReference to every original invoice.
  • Original GİB numbers filled from the reversed invoice, format-checked before sending.
  • Incoming İade from a customer converted to a draft credit note: 610, 191.11 return VAT, 120.
  • Incoming bills: vendor matched on VKN/TCKN, products via supplier codes, the vendor's default expense account.
  • XML payable amount stored and compared with the rebuilt total; mismatches flagged.
  • Draft-first mode: documents uploaded to the provider as drafts for the accountant to release.

On Odoo 19 the outgoing İade covers vendor returns; customer returns arrive as the customer's own İade e-Fatura and are booked automatically. Outgoing İade in both directions is available on Odoo 18. Draft-first mode where configured.

Returns and incoming bills in detail

e-Defter

e-Defter: scoped per project, with a certified provider.

We do not ship an e-Defter module, and we will not pretend otherwise. When a project needs the electronic ledger, we scope the integration with the company's GİB-certified e-Defter provider: Odoo stays the source of the posted journal, and the provider remains responsible for producing, signing and submitting the ledger.

Not an existing Nimex module. What exists today next to it: the journal-entry import with dry run and the landscape journal-entry printout of the accounting toolkit.

Discuss an e-Defter project

Accounting & finance

Cheques, collections and the accountant's toolkit, posted by the operation that causes them.

The instruments standard Odoo does not model: the full cheque lifecycle with its 120/320 entries, bank collections from every bank landing in Odoo bank statements through Bulut Tahsilat, and the small helpers Turkish accountants ask for on day one, from TCMB rates to statements per currency.

Turkish accounting toolkit

The small tools Turkish accountants ask for on day one.

Around the e-documents sits a set of accounting helpers that make Odoo book the way a Turkish accountant does: the right exchange rate, rates entered the Turkish way, statements per currency, and journal entries loaded from a spreadsheet with an audit trail.

  • TCMB buying rate (ForexBuying) stored as the company rate, instead of the buy/sell average.
  • "1 Döviz = Şirket PB" on the invoice: 1 USD = 40.000000 TRY, kept in sync with Odoo's rate and carried into the e-Fatura.
  • Bank lines re-valued with corrected FX rates in bulk; bulk un-reconcile in one action.
  • Journal-entry import from a Turkish-headed template: Test Et dry run, optional auto-post, persistent import log.
  • Multi-currency customer statements and a year-filtered partner ledger with matched payments.
  • One-screen payment registration on posted invoices and bills (Odoo 18).
Find accounting tools in the directory

Cheque management

Every cheque state, every 120/320 entry, posted by the operation that causes it.

Cheques are a core payment instrument in Turkish B2B trade, and Odoo has no model for the states accountants track. Nimex built a cheque application on Odoo Accounting: a received cheque is taken against posted invoices, and each operation, from portfolio and collection to collateral, endorsement, bounce and return, is a wizard that posts its own balanced entry.

  • Received cheques: Taslak, Alındı, Portföyde, Tahsile Gönderildi, Teminat, Ciro Edildi, Tahsil Edildi, Karşılıksız, İade Edildi, İptal Edildi.
  • Issued cheques from vendor bills (Çekle Öde) on the 320.01 given-cheques payable.
  • Collection with bank fee (102 / 760.01), endorsement settling a vendor's bills (320 / 120.04), bounce on 120.05 or reopening the invoice.
  • Operation history with previous and new state; daily reminders for maturing, overdue and bounced cheques.
  • Dashboard of portfolio, collection, collateral and endorsed totals; risk level per customer.

Accounts and behaviour switches are configured per company. States change by user operations, not by a bank feed; cheque printing and promissory notes are not included.

Explore Cheque Management

Banking & collections

Collections from every bank, in Odoo bank statements.

Companies collecting from hundreds of customers across several banks use a multi-bank collection service. Nimex connected Bulut Tahsilat to Odoo: incoming transfers become bank statement lines on the right journal with the right customer, and whatever cannot be matched waits in an auditable pool.

  • Customers, tax ids and TR IBANs pushed to the service, with a sync status on each contact.
  • Settled payments fetched every 30 minutes or on demand, each stored once with its raw payload.
  • Journal resolved from the company IBAN; customer by sender id, IBAN, VKN/TCKN or payment code.
  • Unmatched payments held in the Bulut Havuz pool and sent to a journal singly or in bulk.
  • A fetch log with counters and per-payment detail for every run.

Delivered on Odoo 18. Reconciliation with invoices then happens in standard Odoo; outgoing payments are not part of the integration.

Find it in the directory

Manufacturing & industrial systems

Three manufacturing architectures, each built for its factory.

Standard Odoo Manufacturing turns a confirmed order into production at once. These three plants needed a decision layer in between, and each needed a different one. They are three separate systems with their own data models: none of them is a generic module configured three ways, and we never present one as another.

  1. Commercial equipment manufacturing

    Make-to-order positions
    Planned per
    sales-order position, multi-level recipe
    Supply
    make, buy, stock or subcontract per component
    Release
    planner approval, position by position
    Planning cockpit

  2. Batch process manufacturing

    Bulk batches filled into packs
    Planned per
    one bulk product and colour, in kg
    Supply
    a procurement planner fed by approved plans
    Release
    one approval opens batch and filling orders
    Batch planner

  3. Life-sciences kit production

    Volumes from concentrations
    Planned per
    kit order, reactions and target concentrations
    Supply
    fulfilment scenario per component kind
    Release
    one LOT minted, orders in dependency order
    Kit configurator

Commercial equipment manufacturing · flagship

Advanced Manufacturing Planning Cockpit

For a made-to-order equipment manufacturer every order position is a one-off configuration, so confirming the sale is the wrong moment to start production. The cockpit holds each manufactured line at confirmation and builds a draft plan: the planner chooses the recipe, decides make, buy, stock or subcontract per component, collects the drawings and sees cost and margin per position. Manufacturing and purchase orders exist only after the planner approves.

  • No stock move, manufacturing order or purchase request until the position is approved.
  • Multi-level component tree (up to 12 levels) with a supply method per component.
  • Drawing requests in Documents per project, order and position, with a one-click waiver.
  • Readiness per position with the first blocking reason; partial release per position.
  • Cost and margin per position, live, on the discounted subtotal before tax.
Explore the planning cockpit

Batch process manufacturing · flagship

Industrial Production & Procurement Planning

A process plant makes one bulk product in kg batches and fills it into packed variants. The planner turns consolidated sales demand into a target, batches, filling orders and material requirements in seven guided steps; one approval releases every manufacturing order. A separate procurement planner computes what is still to buy from the approved plans and ends at draft purchase orders the buyer controls.

  • Target = sales need − free bulk in stock + extra production.
  • Batches = target ÷ the smallest of the largest compatible machines per recipe role, rounded up.
  • Bulk left after filling is computed live and can never go negative.
  • To buy = required − on hand − on order; one draft purchase order per vendor and currency.

Batches carry kg and dates only: machines and kettle are chosen on the floor, and no purchase order is created automatically.

Explore production & procurement planning

Life-sciences kit production · flagship

Laboratory Production Automation

Diagnostic kit components are volumes, not fixed bill-of-materials quantities: they follow from the reaction count, the reaction volume, stock and target concentrations and a production overage. A confirmed kit order opens a production plan that computes every volume, the water back-fill and the plate packing, mints one kit LOT and generates the manufacturing orders in dependency order, with purchases for what is short.

  • Per-reaction volume = reaction volume ÷ (stock ÷ target concentration) × overage.
  • Water back-fill = mix total − Σ oligo volumes; a negative value blocks generation.
  • Plates and boxes derived from reactions for pre-plated kits; Falcon tubes sized for tube kits.
  • One LOT minted before the orders and stamped on every made-to-order component.
Explore laboratory production automation

Life-sciences kit production · shop floor

Custom Shop-Floor Applications

Operators work gloved at benches and freezers, so dense back-office screens and personal logins slow them down. The lab floor is a full-screen, tablet-first application: sign in with a PIN or face recognition, see only the lanes of your work centres, check the components and the LOT, and produce with one tap. It is a separate application that replaces standard Odoo Shop Floor for the kit flow, not a reskin of it.

  • Lanes per lab operation, bound to work centres and visible only to allowed operators.
  • Children before parent: a kit cannot be produced before its mixes.
  • Produce finishes the work orders, closes the order and records the LOT and the operator.
  • Orders that need an Odoo wizard go back to the back office; wizards are never auto-answered.

Face sign-in runs browser-side recognition with liveness prompts; only descriptors are matched on the server. It is not a certified biometric system.

Explore shop-floor applications

Commercial equipment manufacturing · logistics

Subcontracting & supply automation

Mixing in-house production with subcontracting means locations, operation types, rules and routes that are easy to get wrong by hand. One button per company builds the whole topology, so every order line flows to the right manufacturing, purchase or subcontracting document. Route-created RFQs are then split by vendor currency automatically.

  • Seven locations, ten operation types and six routes, created per company by an administrator.
  • Each manufacturing order carries the sales position and stamps it on the produced serials.
  • Daily, gap-free serial numbers for finished goods, also for “Produce All”.
  • Draft RFQs split per vendor currency, linked source to child; confirmed orders untouched.
See subcontracting solutions in the directory

Costing & performance

Know the margin before production, and after delivery

The planning cockpit shows cost and margin per position while the plan is still a draft. After delivery, project profitability matches every delivered serial with the purchase cost of that exact unit plus the project's expenses. On the shop side, deadlines read in plain language and many orders move in one step.

  • Position cost from vendor and subcontractor prices, split into purchase, subcontracting and in-house material.
  • Project margin serial by serial, predicted or finalised, in any display currency.
  • Bulk start-date change with a warning when a deadline would be missed.

Serial cost comes from the purchase line or receipt of that unit; in-house manufacturing cost is not derived from manufacturing orders.

Find costing and reporting solutions

Quality & traceability

Repeat until it passes, trace one LOT through the kit

In batch process manufacturing a failed measurement is not the end: the batch is corrected and sampled again. Laboratory criteria with per-recipe limits create Odoo quality points, and a failed repeatable check inserts the next attempt right after it. In kit production one LOT ties the kit to every made-to-order component, and limit-of-detection panels are planned alongside the main kit, under its LOT.

  • Shared criteria library: measured ranges or pass / fail, at an operation or at the end.
  • No range means the value is recorded and the lab decides.
  • Bulk stock components keep their own lots; made-to-order ones carry the kit LOT.
  • LoD sub-products: 1 µL per positive-control target plus water to the kit volume.
Find quality and traceability solutions

Inventory & logistics

Stock promised, despatched and shipped from the records that already exist.

Standard Odoo moves the goods; the engineering around it promises stock without reserving it, issues the legal despatch note from the delivery, books the carrier and prints the export paperwork, all from the same transfer.

All inventory and logistics solutions

Sales & CRM

Quotations that behave the way the commercial team actually works.

Frozen once sent, discounted to the agreed total, built from the customer's own spreadsheet, printed in two languages, and for dealers and resellers, quoted from their own portal or opportunity.

All sales and CRM solutions

Purchasing

From the plan to the vendor, one draft order per currency.

Purchase requests split by vendor currency, prices derived from vendor costs on a schedule, orders loaded from spreadsheets, and a planner that turns approved production plans into the purchase orders that are still missing.

All purchasing solutions

Custom applications

Complete applications, built inside Odoo.

Where a process has no standard app, we build one on Odoo's own framework: its records, security, reporting and upgrades. The catering platform below is the flagship; the other applications live in their own chapters of this page.

Catering & food service operations

A complete contract-catering operation, built inside Odoo.

Corporate catering lives on a daily promise: the right number of meals at every customer, every service day, billed without disputes. Nimex built a complete Catering application on Odoo Sales, Inventory and Accounting: contracts with menus, service days and holidays; a daily order link each customer answers from a phone; quotations, meal deliveries and e-İrsaliye data created on their own; one weekly invoice per customer that carries its delivery notes into e-Fatura; WhatsApp and e-mail behind one stop switch; and a dashboard for the questions operations asks every morning.

The weekly cycle

From tomorrow's order link to Friday's single invoice.

The day before every service day, the scheduler opens one order per contract, prefilled from the contract's menus, with a quotation behind it and a secret link for the customer. The customer answers from a phone; at the deadline the day confirms itself and the meal delivery is created with its vehicle and drivers. On the invoicing day, every delivered and not yet invoiced day of a customer becomes one invoice, one line per day.

  • One order per contract and service day, never a second: the database refuses duplicates.
  • The quotation follows the customer's quantities line by line while it is still a quotation.
  • Validating the delivery, from the form, the barcode app or a bulk action, marks the day Delivered.
  • Cancelled and struck-out days never reach an order line, a delivery or the invoice.
  • Invoice lines carry the service date; the invoice note lists each day's e-İrsaliye number and menus.

Link time, change deadline and invoicing day are settings (shown: 09:00, 08:00 on the service day, Friday 18:00, auto-post on). Menus are invoiced on delivered quantities. Transmission to GİB is done by the e-Invoice Suite.

Explore the Catering Operations Platform

Contracts & customers

The contract decides what is served, on which days, at what price.

Each customer's standing agreement is a catering contract: who receives the daily link, which pricelist applies, which menus go out in which standard quantities, which weekdays are served and which days are exceptions. Everything downstream, from tomorrow's order to Friday's invoice, is read from it.

  • Responsible contact picked from the customer's own people; the link goes to their mobile.
  • Contract pricelist, defaulting to the customer's; every daily quotation is priced with it.
  • Breakfast, lunch, dinner or custom menus with standard quantities, optionally tagged by weekday.
  • Weekday ticks, "Serve (even on a holiday)" and "Do not serve" windows, and a bilingual public-holiday table.
  • Standing vehicle plate and drivers for the e-İrsaliye of every delivery.
Catering in the solutions directory

Daily ordering

A link instead of a phone call: tomorrow's meals, ordered from a phone.

The customer never needs an Odoo account. The secret link opens a phone-first page in Turkish or English with the day's menus, their photos and contents. The answer lands on the order with a chatter note of what changed, and the window closes at the configured deadline, after which the day confirms itself.

  • Steppers per menu and Confirm; "Change my order" while the window is open.
  • "Cancel today's delivery" with a confirmation and an undo until the deadline.
  • "Days I will not need meals": single days or ranges up to 62 days, each one reversible until its own deadline.
  • Deadline as a time on the link day or on the service morning, or switched off.
  • Back office: bulk confirm, cancellation reserved to named users, a To-Do when a customer cancels or restores.

Quantities only, of the menus on the contract. No customer login, no online payment.

Operations

The morning's four questions, answered from the live orders.

How much food goes out today, and to whom? What does tomorrow look like, and who has not answered? Did anyone cancel? How heavy is the week? The catering dashboard answers exactly these, and the daily-order list answers the rest: grouped by customer and service date, every meal count adds up to the day totals and to what Friday's run will invoice.

  • Today's meals and deliveries against yesterday; tomorrow's meals with the change deadline.
  • Awaiting Customer: tomorrow's orders nobody has answered yet.
  • Cancellations of today and tomorrow, one tap away.
  • A seven-day load strip where closed days and public holidays are named, not blank.
  • Today's and tomorrow's delivery lists with search, and Create Bulk Invoices.

The week-by-customer table is the daily-order list grouped by customer and service date; the dashboard's own week view is a seven-day strip. Cancelled days never count as meals.

See the whole platform

Deliveries & logistics

Meal deliveries with their own operation, vehicle and drivers.

Catering deliveries do not drown in the warehouse's outgoing stream: they run through a dedicated Meal Deliveries operation, scheduled on the service day and born with the contract's plate and drivers, ready for the e-İrsaliye. One tick-and-click validates the day's deliveries, and the kitchen gets its list in Excel.

  • A Meal Deliveries operation per warehouse with its own sequence, created at installation.
  • Scheduled date = service day 08:00; service-date column on the meal delivery list only.
  • Bulk "Gönderildi": full demand, no backorders, skipped records reported, never a blocked batch.
  • Bulk vehicle and driver assignment for any selection of deliveries.
  • Günlük Yemek Listesi: delivery number, customer, menu and quantity, with the day's total.
The e-İrsaliye integration

Invoicing & e-Fatura

One invoice per customer per week, readable line by line.

One day of food is one sales order, so a five-day customer would collect five invoices a week. The invoicing run bundles every delivered, not yet invoiced day of a customer into one invoice: each line names its service date, and the note lists every day's e-İrsaliye number and menus, the table the customer's accounts team checks before approving.

  • Weekly on the chosen day and hour, and on the last day of the month if it falls earlier; once per day at most.
  • No lower date bound: a day missed by an earlier run lands on the next invoice instead of being lost.
  • Drafts for review or posted automatically; "Create Invoices Now" and Create Bulk Invoices on demand.
  • The same line dates and delivery note when an accountant invoices through the standard wizard.
  • The note travels to the e-invoice provider as the UBL-TR note, in text or HTML table format.
The e-Invoice Suite

Communication

Links, quotations and invoices over WhatsApp, behind one stop switch.

The daily link, quotations, pro-formas and invoices leave Odoo over WhatsApp, by hand or automatically, and every send or failure is written in the record's chatter. A weekly bilingual e-mail tells each customer what was served. One red button stops every automatic message at once.

  • Link popup with the responsible contact preselected and an "already sent" warning.
  • Automatic link send only when three switches are on: WhatsApp automation, auto-link, customer automations.
  • Invoice PDF with a templated message, Odoo's PDF or the official e-invoice PDF; WhatsApp in the standard Send wizard.
  • Last invoice of each selected contract in one bulk action, each invoice once.
  • Weekly summary e-mail in Turkish and English: day, menu, count and total, copied into the contract chatter.

WhatsApp through the WhatsApp Web protocol, not the official Business API. The weekly summary is sent by e-mail only.

WhatsApp inside Odoo

Every verified capability

Seventy-two capabilities in one catering system.

Each item below exists in the delivered code. Where a capability depends on a setting or another Nimex solution, it says so.

Contracts & customers13

  • Catering contract per customer: numbered, with start and end dates and a chatter.
  • Responsible contact chosen from the customer's own sub-contacts.
  • Contract pricelist, defaulting to the customer's, pricing every quotation.
  • Unit price per menu shown on the contract, straight from that pricelist.
  • Menu lines: breakfast, lunch, dinner or custom, with a standard quantity.
  • Menus tagged by weekday (Menu 1 Mon/Wed/Thu, Menu 2 the rest).
  • Guard: every served weekday must be covered by at least one menu.
  • Served weekdays as ticks, Sunday off by default.
  • "Serve (even on a holiday)" and "Do not serve" windows, filled from a holiday and trimmed.
  • Public-holiday table with Turkish and English names, national or religious, seeded for two years.
  • One service-day rule: period, do-not-serve, serve, holiday, weekday, in that order.
  • Next order creation time and next service day shown on every contract.
  • One-click chain: daily orders, sale orders, deliveries, invoices.

Menus3

  • Catering menus flagged on the product; only flagged products can be picked.
  • Menu photo cropped to a square on upload, served at phone size.
  • Dish contents in Turkish and English, shown in the page's language.

Quotations & orders7

  • Quotation created with every daily order, on the contract pricelist.
  • Delivery date of the quotation = the service day, so the delivery is scheduled right.
  • Line-by-line sync while the quotation is open, from the phone or the back office.
  • Confirming the day confirms the quotation into a sales order.
  • A cancelled day cancels its quotation; a restored day reopens it.
  • Reset to Draft reopens a confirmed quotation for new quantities.
  • Sales list filters: catering or regular orders, service date today, this week, this month.

Daily ordering17

  • Scheduler checks every minute and opens the next service day's orders at the link send time.
  • One order per contract per date, enforced by the database.
  • Order prefilled with the contract's menus for that weekday.
  • Open an order by hand for today or any later service day, with the link sent at once.
  • Secret link per order: a token-only page, no account or login.
  • Page in Turkish by default, English on one tap, choice remembered.
  • Steppers and Confirm: state Updated by Customer, chatter note of each change.
  • "Change my order" until the window closes.
  • Cancel the day with a confirmation; undo until the deadline.
  • "Days I will not need meals": days or ranges up to 62 days, reversible per day.
  • Change deadline: a time on the link day or on the service morning, or off.
  • Auto-confirm at the deadline, today and later only; one failure never stops the rest.
  • Bulk "confirm selected" that skips what cannot be confirmed and says so.
  • States Draft, Updated by Customer, Confirmed, Delivered, Cancelled; link Not Sent, Sent.
  • Back-office cancellation only for users named in the settings.
  • A delivered day cannot be cancelled or reset.
  • To-Do for the catering manager when a customer cancels or restores a day.

Communication10

  • Order link over WhatsApp from a popup, responsible preselected, repeat-send warning.
  • Automatic link send at creation behind three switches.
  • Sends and failures ("not connected", "no mobile number") logged in the chatter.
  • Posted invoice PDF over WhatsApp: Odoo PDF or the official e-invoice PDF.
  • WhatsApp as a method in Odoo's invoice Send wizard, single or bulk.
  • Last invoice of each selected contract in bulk, once per invoice.
  • Quotations, pro-formas and order confirmations over WhatsApp.
  • Editable message templates, seeded once and never overwritten.
  • Emergency stop in the settings and on the dashboard; master switch for customer automations.
  • Weekly bilingual meal summary by e-mail, logged on the contract, sendable on demand.

Deliveries & logistics8

  • Meal Deliveries operation per warehouse with its own sequence.
  • Operation created at installation, and for new warehouses on first use.
  • Contract plate and drivers written on every delivery for the e-İrsaliye.
  • Validating the transfer marks the day Delivered and sets delivered quantities.
  • Bulk "Gönderildi" to full demand without backorders.
  • Bulk vehicle and driver assignment wizard.
  • Service-date column on the meal delivery list only.
  • Daily meal list in Excel: delivery number, customer, menu, quantity, total.

Invoicing & finance10

  • One invoice per customer for every delivered, uninvoiced day.
  • Days missed by an earlier run are picked up by the next one.
  • Invoicing weekday and hour, plus the last day of the month.
  • Once-per-day guard: frequent checks never create a second invoice.
  • "Create Invoices Now" in the settings, Create Bulk Invoices on the dashboard.
  • Draft invoices for review, or posted automatically.
  • Each line suffixed with its service date.
  • Delivery table in the invoice note: e-İrsaliye number or delivery reference, date, menus and quantities.
  • Note sent as the UBL-TR note, per-day line names on the e-invoice (with the e-Invoice Suite).
  • Invoice-to-days link: "Catering Days (n)" on the invoice, the invoice on each day.

Operations dashboard4

  • Today's meals and deliveries, with the change against yesterday.
  • Tomorrow's meals, the deadline, and customers who have not answered.
  • Cancellations of today and tomorrow.
  • Seven-day load with closed days and holidays named; delivery lists with search.

Not part of the system: menu planning, recipes and ingredient stock, allergen management, route planning, customer portal accounts, online payment, SMS.

Explore the Catering Operations Platform

API & third-party integrations

The systems around your ERP, connected to the right records.

Messaging, telephony, card payments, carriers and label printers each hold part of the story. We connect them to Odoo through their own interfaces, so every message, call, payment, parcel and label lands on the contact, quotation, transaction or delivery it belongs to. For each one below: the two systems, the data between them, the event that starts the sync and what happens in Odoo.

Messaging · WhatsApp

WhatsApp conversations inside Odoo, on the right contact and quotation.

Sales and support teams answered customers on a phone the ERP could not see. We built a complete WhatsApp Web client inside Odoo: the company number is paired once by scanning a QR code on the Odoo screen, conversations sync live, every chat is matched to its contact by phone number, and a quotation or invoice PDF leaves from the record itself and is logged in its chatter.

Runs on the unofficial WhatsApp Web protocol (a QR-paired session), not the official WhatsApp Business API: no Meta Business fees and no approved templates, and messages reach only numbers that use WhatsApp.

WhatsAppcompany number · QR-paired Web session

messages · media · delivery and read status →← replies · PDFs from records

OdooContacts · Sales · Invoicing

Starts when
a customer writes, or a user presses WhatsApp on a contact, quotation or invoice
Result in Odoo
the chat sits on the matched contact; the sent PDF is a note in the record's chatter
  • Chats matched to contacts by a stored phone key; link, unlink or create a contact by hand.
  • Send dialog with recipient, message template and PDF generated on demand.
  • Every message shows pending, sent, delivered, read, or failed with Retry.
  • Session survives a server restart; per-number access for users and managers.

Document automation

Quotations, pro-formas and invoices over WhatsApp, behind one stop switch.

WhatsApp becomes a sending method in Odoo's invoice Send wizard, next to e-mail and including bulk sends. Quotations offer quotation, pro-forma and order-confirmation texts with their PDFs; a contract-catering operation sends its daily order links automatically when the scheduler creates them. One global switch stops every automated send while the manual buttons keep working, and each success or failure is logged in the record's chatter.

Explore the WhatsApp integration

Telephony · cloud PBX

Every finished call lands in Odoo with its recording, transcript and score.

An after-sales desk took dozens of calls a day on a cloud PBX and typed the tickets by hand afterwards, or not at all. We connected the PBX's call-detail API and its AI add-on to a Call Centre app in Odoo: when a call ends, its record arrives with the caller matched to the customer, the recording, the transcript and the provider's analysis, and a routing rule opens the Field Service task.

Cloud PBXcall-detail API · recordings · AI add-on

call record · recording · transcript · scores →

OdooCall Centre · Field Service · Contacts

Starts when
a call ends on the PBX (webhook, with a two-minute poll as backup)
Result in Odoo
a call record on the customer, a Field Service task by rule, dashboard figures
  • Webhook and poll de-duplicated on the PBX's unique call id.
  • Caller matched on the last 10 digits of any phone field; unknown numbers get a To-Do.
  • Scores from 0 to 5 for satisfaction, sentiment, keywords and closing.
  • Rules: inbound only, answered only, minimum duration, wait for the analysis (30 min by default).
  • Recordings streamed through Odoo, kept 90 days by default.

Ingestion is post-call, not a live screen pop. Transcripts and scores are generated by the PBX provider's AI service; Odoo itself calls no language model.

Explore the call-centre integration

Payments · iyzico (standard Odoo provider, deployed by Nimex)

iyzico card payments, deployed so the order only counts as paid once Odoo has verified it.

Turkish web shops need a local acquirer with 3-D Secure and TRY. Odoo 19's standard iyzico provider handles the hosted checkout; we deploy and configure it for eCommerce checkout and invoice portal payments, and add what Turkish shops still need around it, starting with the billing-address guard below. The payment counts only once Odoo has fetched it again itself and checked the amount.

OdooPayment Providers · eCommerce · Invoicing

signed initialise · detail →← page URL · token · status

iyzicohosted checkout · 3-D Secure

Starts when
the shopper clicks Pay now with iyzico selected
Result in Odoo
the transaction is Confirmed, Pending or Error from the verified status
Verified iyzico statusOdoo transaction
SUCCESSConfirmed
INIT_THREEDS · CALLBACK_THREEDS · INIT_BANK_TRANSFER · INIT_CREDIT · PENDING_CREDITPending
FAILUREError with iyzico's message

Payment by redirection only: refunds, instalments, saved cards and manual capture are not part of this provider. Card data never reaches Odoo.

Companion · checkout address guard

iyzico rejects an incomplete buyer address. A companion guard sends the shopper back to the address form until name, street, city and country are filled (for the delivery address too when the cart holds physical goods) instead of an error at the last click.

Find payment solutions in the directory

Shipping · Yurtiçi Kargo and Aras Kargo

Shipments, labels and tracking from the delivery order.

Turkish shippers hand their parcels to Yurtiçi Kargo and Aras Kargo, whose web services standard Odoo does not speak. Our connectors add each carrier as a delivery method: from a validated delivery the warehouse registers the shipment at the carrier, receives the tracking numbers and the barcode label, and a scheduled job brings the carrier's tracking status back onto the delivery and its chatter.

OdooInventory · delivery methods

receiver · parcels · desi · kg →← tracking numbers · label · status

CarrierYurtiçi Kargo · Aras Kargo web services

Starts when
the warehouse sends a validated delivery to the carrier; then on schedule
Result in Odoo
tracking reference and label on the delivery; each status change in its chatter
  • The delivery reference is the shipment key at the carrier.
  • Yurtiçi can return printer-ready ZPL for Zebra printers, or the label renders as PDF.
  • Cancellation before pickup, multi-parcel desi and weight and cash-on-delivery parameters are part of the documented flow, enabled per carrier contract.

Details vary per carrier contract: operations, status names, label formats and options depend on the carrier account and web-service version. The flow shown follows Yurtiçi Kargo's documented operations.

Explore the cargo integrations

Labeling · BarTender

Production labels on on-premises BarTender printers, sent from Odoo.

Labels are printed with BarTender on a Windows PC inside the plant network, which a cloud ERP cannot reach. Instead of opening the firewall, an on-premises agent asks Odoo for work over outbound HTTPS with a station code and token; Odoo hands it frozen print jobs with lot, expiry and QR data, and the agent reports back printing, done or failed.

Odoo prepares the label data; BarTender renders and prints it with the customer's .btw templates. The station agent runs on the customer's PC.

OdooInventory · Manufacturing

← poll with station code and tokenprint jobs: lot, expiry, QR data →

BarTenderstation agent · plant printers

Starts when
a user prints from a configured record or a production plan
Result in Odoo
jobs move queued → claimed → printing → done, or failed with requeue
  • Template records map an Odoo model to a .btw file and its named data sources.
  • One click on a production plan fans out the whole kit's labels with one shared LOT.
  • Stations show heartbeat and online state; stale claims are requeued every 5 minutes.

Bilingual serial labels and custom PDF documents printed by Odoo itself belong to Reporting, documents & data.

Find labeling solutions in the directory

Other business systems

Terminals, banks, rates and e-documents, grouped by what they do.

The same discipline applies to every system around the ERP: name both ends, the data and the trigger, and write the result onto a standard Odoo record.

  • Point of sale

    EFT-POS terminal bridge

    Odoo POSamount →
    ← approval · RRN    Terminal bridge

    On a card payment the POS sends the amount to a lightweight, token-secured bridge service and waits for the card; an approval completes the payment line with its RRN, a decline shows the message and Retry.

    A bridge pattern proven against a terminal simulator: a prototype, not a certified terminal integration. No refunds or settlement.

    Find it in the directory

  • Banking & collections

    Bulut Tahsilat collections

    Odoo Accountingcustomers · IBANs →
    ← bank receipts    Bulut Tahsilat

    Customers, tax ids and IBANs go to a multi-bank collection service; incoming receipts fetched every 30 minutes become bank statement lines on the right journal and customer, and the rest wait in a review pool.

    See it in Accounting & finance

  • Exchange rates

    TCMB buying rates

    Odoo currencies← daily ratesTCMB

    The Central Bank of the Republic of Türkiye's daily rates are stored as the buying rate Turkish accountants book with, and invoices show the rate as "1 foreign currency = company currency".

    See it in Accounting & finance

  • e-Documents

    Nilvera and GİB

    Odoo InvoicingUBL-TR →
    ← statuses    Nilvera · GİB

    e-Fatura, e-Arşiv and e-İrsaliye documents exchanged with GİB through Nilvera, with their statuses back on the invoice and the delivery.

    See it in Turkish compliance

Another system to connect? Discuss an integration

Automation, approvals & business applications

Business rules enforced by the system, not by memory.

Approvals that follow the real reporting lines, an organisation chart HR reshapes on the screen, floor plans whose every unit status comes from its lease, and roles and rules the server keeps whatever the user clicks. Built as applications inside Odoo, on the same records the rest of the business uses.

Organisation & approval engine

Any button, behind an approval that follows the org chart.

A rule names a model, one of its buttons, the authorised approvers, an optional condition such as an amount threshold, and a company. When anyone else presses that button, Odoo sends a request up the employee’s manager chain instead of running it: straight to the first authorised manager, or step by step through every manager in between. The chain is read from Employees at every step, so when a manager changes, the next step goes to the new one.

  • Enforced on the server: the protected method is wrapped, so screens, RPC calls and imports all need an approved request, which is consumed once used.
  • The record is locked while a decision is pending; only chatter and activity fields stay writable.
  • Approve or decline from the form banner, the chatter activity or the daily task board. A decline carries a reason and a “Fix and resubmit” activity.
  • On approval the original action runs as the approver; the requester gets a note and a live notification with Open.

Built on Odoo 18. One pending request per record and button; no parallel or quorum approvals.

Explore the approval engine

Drag-and-drop organisation chart

HR reshapes the hierarchy directly on the chart.

A full-screen chart of every employee by manager, multi-company aware, with search, department highlighting, focus on one team, a minimap and print. In edit mode HR drags a card onto its new manager, edits names and titles in place, adds a direct report, or archives a manager and lets their team move up a level. The approval engine reads the same reporting lines.

  • A cycle check refuses a manager who would report to their own report; every move can be undone.
  • The side panel lists the approval rules the person can approve.
  • Writes run with the user’s own access rights; reading uses Odoo’s public employee data.
Find it in the directory

Interactive office & facility management

Floor plans where every unit’s status comes from its contract.

A technology-park campus rents offices, open-plan desks, incubator rooms and workshops across buildings and floors. Nimex built a full-page application inside Odoo, from campus, building and floor down to unit, contract and tenant, with each floor drawn to scale in metres. Status is never typed in: it is derived from the unit’s contracts and the expiry threshold, the same way on the server and on the screen.

  • Vacant, occupied, expiring within the threshold (60, 90 or 120 days), reserved for a future start, or under maintenance.
  • New tenant with contract, renewal by years and a percentage increase, vacate today, at month end or at contract end, and undo.
  • Monthly rent = unit area × rate per m²; the area is computed from the drawn rectangle, circle or polygon.
  • Overlapping contracts, and contracts on units under maintenance, are refused.

Odoo 18, Turkish interface in production. No rent invoicing; the architectural drawing is an image underlay, not a CAD import.

Explore floor plans & tenancy

Role-based access & business rules

Rules the server keeps, whoever clicks.

Some rules are too important to leave to training: who may open an application, when a quotation stops being editable, how purchase requests are split, when an expense becomes a purchase, what happens when a deal is won. Each runs in Odoo’s server layer, so it holds for every screen, import and integration.

  • Company roles on the user form write the access groups and hide whole applications server-side; assistants quote and discount, but the unit price and purchase, transfer and manufacturing records stay read-only.
  • Quotations freeze once sent, confirmed or cancelled; only a bypass group edits them, while confirmation and invoicing keep working.
  • Route-generated RFQs split into one per vendor currency, each at the vendor’s own price, linked to their source.
  • Project field expenses, approved by accounting, become purchase orders linked back to the expense.
  • A won deal opens its delivery project with a kick-off task and renewal reminders before the licence ends.

The roles shown were engineered for one manufacturer’s organisation and are fixed in code for it; the pattern is reusable.

See all automation solutions

Activity task board

Every activity on one board: overdue, today, tomorrow.

A standalone board for all Odoo activities, whatever document they belong to: columns for overdue, today, tomorrow and the days ahead, grouped by day, week, month, type, source or assignee. Managers see and reschedule everyone’s activities; everyone else sees and completes their own. Approval requests land here as cards with Approve and Decline.

  • Done, reschedule, assign and open the record from the card.
  • A soft browser chime when a task lands on your desk, with mute for a day, a week, a month or a custom period.
  • Only managers can edit or delete other people’s activities, anywhere in Odoo.

Notifications stay in the browser; nothing is pushed to phones.

Find it in the directory

Portals, websites & eCommerce

The ERP, opened to dealers, customers and learners.

Dealers who quote at their own prices, corporate customers who adjust tomorrow’s order from a link on their phone, learners who buy a course pack and receive a certificate anyone can verify. Each front end writes straight into the Odoo records behind it — quotations, deliveries, invoices, memberships — with no second system to reconcile.

Business partner portal

Dealers quote and order at their own prices.

Wholesalers want dealers to serve themselves without opening the public shop or the full catalogue. Partner programs set a default pricelist, payment term and the portal features a tier may use; each dealer’s partner profile sets its program, portal users, allowed products, categories and warehouses. In the portal the dealer sees live KPIs, builds a quotation in three steps at partner prices and confirms it: the sales order is created in Odoo, ready for the back office.

  • Program tiers with default pricelist and payment term; dealer price tiers generated as formula rules from a reference pricelist, a discount and a minimum quantity.
  • Products restricted per partner, in bulk from the product list (add, remove, replace).
  • KPIs from live records: open quotations, open orders, unpaid and overdue invoices.
  • Standard quotation routes are closed to partner users; every portal action is audit-logged with IP and user agent.

Odoo 19. No online payment in the portal; the profile has a credit-limit field, but blocking orders at the limit is not part of what we claim.

Explore business partner portals

Customer order links

A portal without a login: tomorrow’s order, confirmed from a link.

For contract catering, each corporate customer receives a secret, bilingual link to the next day’s order and adjusts it from the phone until the deadline. Odoo keeps the quotation in step, creates the delivery and bundles every delivered day into one weekly invoice.

See the catering chapter Explore catering operations

eLearning commerce & certificates

Course packs on the shelf, certificates anyone can verify.

A training academy sells on Odoo eCommerce. One bundle product unlocks a set of courses the moment its order is confirmed, and course and bundle products sit in the shop like any other product. Every completed certification exam receives a token; both certificates carry a QR code that opens a public page confirming learner, course, date, result and score.

  • Enrolment through Odoo’s own membership API at order confirmation, never duplicated when an order is confirmed again.
  • KVKK-compliant sign-up: surname and mobile required, no account without explicit consent, checked on the server.
  • The payment step waits until the billing address is complete — the data Turkish gateways such as iyzico require.
  • Verification page: Valid or Invalid, Passed or Did Not Pass, score against the passing score, and which certificates exist.

Odoo 19 Community. No revocation or expiry: the page reflects the exam record as it stands.

Find it in the directory

Software reseller CRM

Licence pricing on the opportunity, a quotation in one click.

A reseller of engineering-simulation software sells node-locked and floating licences, as annual subscriptions or one-time purchases. Odoo’s CRM has no product lines, so Nimex added a Product Interest tab: each line carries the plan, the licence type, a discount and the final price, and the expected revenue is their sum. New Quotation copies the lines into the order; confirming one quotation cancels its siblings and marks the opportunity Won.

  • Floating = node-locked × 1.3, for the configured licence categories only.
  • Subscription and one-time products are never mixed in one opportunity.
  • Subscription dates follow the licence start date: end = start + plan period − 1 day.
  • The won deal opens its delivery project with a kick-off task and renewal reminders, as shown under business rules.

Odoo 18 Enterprise with Subscriptions. Renewal reminders are tasks; renewal quotations are not generated automatically.

Find it in the directory

Data engineering, reporting & documents

Data in, documents out, without manual re-keying.

Spreadsheets from suppliers, customers and other systems become Odoo records through importers that test before they write and log every row. On the way out, the same records print the documents, labels and reports the business hands over, in the language and layout the recipient expects.

Smart imports

A 1,200-row catalogue, imported while you keep working.

Odoo's built-in import handles one model at a time and times out on large sheets. Our smart importers read a fixed, downloadable template, find its header row, test the file and estimate the run, then write products, vendor price lists, price tiers, customs data, bilingual texts and images from a ZIP in a background job with its own database cursor, logging every row as it goes.

Fixed template, no interactive column-mapping screen. Each row runs in its own savepoint: a failing row is rolled back and logged, any row error marks the log Failed, the other rows are committed.

  • Test first: headers validated, duration estimated as 8 s + 0.18 s per row.
  • Log states Draft, In Progress, Finished, Failed, with imported, updated, skipped and error counters.
  • Upsert on the product reference: a corrected sheet updates instead of duplicating.
  • Manufacturing variant: finished goods, in-house and subcontracted semi-finished parts and raw materials get their routes; a BoM importer builds bills of materials, subcontracted ones included, and returns a missing-items XLSX.
  • Laboratory and trading variants: multi-sheet workbooks with a dry run per sheet, header auto-detection, HS codes and customs texts.
Explore Smart Import & Reporting Systems

Bulk operational imports

Orders and entries from spreadsheets, tested before they exist.

Purchasing receives supplier offers as spreadsheets, sales receives customers' order lists, accounting receives entries from other systems. Each importer offers a template, a Test pass and a persistent log with one line per Excel row, so nobody re-keys a document and every created record traces back to its row.

  • Purchase orders: a filled vendor cell starts a new order; vendor match and strict modes; Tested With Errors, Tested OK, Done.
  • Quotations: test the customer's list, download the missing products as XLSX, import the lines in one step (50 to 300 lines, synchronous).
  • Journal entries: rows sharing an entry number become one entry, with a dry run, optional auto-post and an import log. Part of the Turkish accounting toolkit.

The purchase importer matches existing vendors and products, it does not create them; imports run on demand, not on a schedule.

Browse every import tool

Reports & documents

The paperwork leaves Odoo already filled in.

Quotation letters and proformas in the customer's language, packing lists with case numbers and packed dimensions, the customs set for an export delivery, a paper service report rebuilt as a worksheet the customer signs on the technician's phone, a handover act for Azerbaijan. Each is printed from the record that holds the data, on its own paper format.

  • Bilingual quotation letters, detailed quotations and proformas with a per-tax breakdown and sizes on the lines.
  • A company document layout selectable in Odoo's Document Layout settings.
  • Customs-ready product data: HS codes, bilingual customs texts, net and gross weights, lot production dates.

Layouts follow each company's own design: there is no layout designer, no electronic customs filing and no e-signature service behind these documents.

See the documents and how they are produced

Labels

One label per serial, with the order position on it.

Four-per-page A4 serial labels in English or Turkish carry the product, project, product and packed size, packed weight, the order position and a Code128 barcode. Printed from the delivery, serials are allocated to the order's positions in sequence; printed from the manufacturing order, the position comes from the order line stamped on the lot, before any delivery exists.

  • Print formats "2 x 2 (English)" and "2 x 2 (Türkçe)" in Odoo's own label wizard.
  • White-label variant with the customer's logo, with a clear error when the logo is missing.
  • Each lot remembers when, by whom and with which format it was last printed.

PDF labels. Thermal printers and production label templates run through a separate BarTender print queue.

See the BarTender print queue

Analytics with underlying records

Every total opens on the rows that make it.

A project's margin is computed serial by serial: the sales price of each delivered unit against the purchase cost of that very unit, plus the project's expenses, in predicted or finalized mode and any display currency. On the sales side, a dashboard lists every product promised on open quotations against free stock, with one-click Excel.

  • Cost resolved from the purchase line or receipt of the serial, falling back to the stock valuation layer.
  • Margin % = profit after expenses ÷ sales, with the recompute time on the report.
  • Promised products with free stock, over-promise, orders and salespeople; monthly sales and top products by type, exported to Excel with the same filters.
  • Dashboard access is a dedicated privilege enforced in the data layer, not just a hidden menu.

In-house manufacturing cost is not derived from manufacturing orders; the dashboard reports, it does not forecast.

Browse reporting solutions

Solutions directory

Explore All Custom Modules

Search our engineering catalogue of 69 complete solutions and 528 individual capabilities. Filter by business function, industry, Odoo application, solution type or integration; every entry is traced to delivered code.

Search the catalogue Browse the capabilities

Industry engineering

Built for the way each industry really runs.

The same engineering discipline, applied to very different operations. A few examples of what that meant in practice.

How we engineer

From the real process to code that survives upgrades.

Custom code is a liability unless it is designed, tested and documented like a product. This is the path every solution on this page went through.

  1. Process analysis

    We sit with the people who do the work, map the current flow and mark exactly where standard Odoo stops fitting.

    Process map & gap list
  2. Solution architecture

    Standard first: configuration where it is enough, a focused module where it is not, with data model, states and integrations agreed before coding.

    Data model, states, API contracts
  3. Iterative build

    Working increments on a staging copy of your database, reviewed with the key users every cycle, decisions recorded as they are made.

    Staging builds & decision log
  4. Integration & data

    External systems connected through their documented APIs, existing data migrated with dry runs and audit logs instead of manual re-keying.

    Connectors & migration logs
  5. Testing & acceptance

    Business rules exercised end to end with your scenarios, automated tests where the logic is critical, acceptance signed off by the process owners.

    Test scenarios & sign-off
  6. Go-live & improvement

    Controlled rollout, training on the real screens, and a maintained module that moves to the next Odoo version with you.

    Release notes & upgrade path
Chat with us