Odoo Repairs Implementation
Repair orders, parts consumed, warranty and re-invoicing.
Odoo Repairs manages items in for repair: what came in, what was used, what is under warranty and what gets invoiced. It links to stock, so parts consumed move correctly.
Odoo Repairs is a Community app, licensed LGPL, and it was rebuilt in Odoo 17. A repair order is now a set of stock moves against a repair operation type, and the money side has moved off the repair order onto a linked sale order. The separate part and fee lines that older versions carried, and the invoice method on the repair itself, no longer exist. Any guide, demo or proposal that invoices straight from a repair order is describing Odoo 16 or older.
The projects that go wrong are rarely the ones with difficult repairs. They are the ones where nobody decided who owns the goods sitting on the workshop bench. Odoo Inventory assumes you own what is in your locations, and a customer device received on a normal receipt lands in your on hand quantity and your stock value. Settle the ownership question and the warranty question first. Most of what is left is configuration.
Who Odoo Repairs is for
- → Electronics, appliance and mobile device workshops taking units in over a counter and returning them to the customer.
- → Authorised service centres doing warranty work for a manufacturer and recharging it, alongside chargeable out of warranty jobs.
- → Machinery, tool and equipment dealers who sell serialised units and then service, overhaul and refurbish the same units.
- → Refurbishers who buy back stock, strip it, replace components and resell, where consumed parts must land on the cost of the resold unit.
- → It is not for maintaining plant you own, which belongs in the Maintenance app, and not for fixing things at a customer site, which belongs in Field Service.
- → It is a weak fit for a workshop that runs on its own board columns, because repair order states are fixed and there is no stage model to extend.
Key features
- ✓ Repair order from a sale or RMA
- ✓ Parts consumed against stock
- ✓ Warranty versus chargeable
- ✓ Quotation before repair
- ✓ Return to customer workflow
- ✓ Repair history per serial number
What Odoo Repairs actually does
The repair order after the Odoo 17 rewrite
The order carries the product to repair, the quantity, its lot or serial number, the customer, a responsible user, a scheduled date, tags, a two level priority and a repair operation type belonging to a warehouse. Parts sit in a table of stock moves, each typed as Add, Remove or Recycle. Only Add moves ever reach the customer bill. States are New, Confirmed, Under Repair, Repaired and Cancelled. Put a serial tracked product on the order and Odoo forces the quantity back to 1, because a serial is one physical thing. The order prints as a PDF that doubles as a job sheet, and nothing is invoiced from this record.
Quoting before the work starts
Create Quotation on the repair builds a sale order and copies the Add parts onto it. Labour goes on as service product lines, because the fee lines that used to sit on the repair order were removed. The customer approves, the repair proceeds, then that sale order is invoiced. One structural limit shapes everything downstream: a repair order holds exactly one sale order. Attempt a second and Odoo refuses by name, and the button disappears once a sale order is linked. Sales is not an optional extra to budget for either. Repairs declares sale_management as a dependency, so installing one installs the other, and both are Community.
Selling a repair as a product
The flow also runs the other way. A product carries a Create Repair flag, and confirming a sale order containing it raises the repair order automatically, linked back to the order line. That is how a fixed price service, a bench diagnostic or a refurbishment SKU gets sold from a quotation or the webshop. The link stays live in both directions. Cancelling the repair writes the originating sale order line down to zero quantity, and putting a quantity back on that line reopens the cancelled repair rather than creating a second one. One quirk to design around: for a serial tracked product a quantity of three creates three separate repair orders, while any other product gets one order for the full quantity.
Warranty against chargeable
The repair order has an Under Warranty flag. Tick it and every sale order line that came from an Add part is priced at zero, so the job produces a document and no revenue while the cost still posts through stock valuation. That is what makes a warranty cost figure possible at all. The flag works on lines that already exist, zeroing them when ticked and recomputing them from the pricelist when unticked. Two limits matter before you design around it. There is no entitlement check behind it, so it stays a whole order decision made by a person at a counter. And it reaches only the lines that came from parts, so a labour service line somebody typed onto the sale order by hand keeps its price and quietly turns a warranty job into a billable one.
Parts, stock and what leaves the shelf
Every part is a real stock move from a real location, so reservation, forecasting and valuation behave as they do everywhere else in Inventory. The order shows a component status of Available, Expected or Late, computed against the scheduled date, which is the closest thing to a waiting for parts view. Serialised spares ask for a serial number on the move. A component taken out of the unit goes either to a removal location or to a recycle location, both set on the operation type. Each warehouse also gets its own repair make to order rule, so a part can be procured for the job instead of sitting unavailable. Where the product category is set to automated valuation, consumption posts to the stock accounts according to whether the company runs Anglo-Saxon or Continental accounting.
The unit coming in and going back out
A repair order carries a Return field linking it to the return picking that brought the unit in, so the inbound leg is documented against the original delivery. There is a shortcut in that direction. Tick Create Repair Orders from Returns on the operation type and a Repair button appears on the return itself. The condition catches people out: the button only shows on a picking that is genuinely a return against an earlier delivery, so a unit you never sold has to be received some other way and the repair raised by hand. The outbound leg gets no such help. Sending the unit back is a delivery you raise yourself, nothing on the repair order will chase you for it, and Odoo ships no RMA app to hold the two legs together.
History against a serial number
Per unit history is better than most people expect. A lot or serial record carries three separate counters: repairs still open on that unit, repairs already completed on it, and the repair orders that consumed that serial as a spare part inside somebody else's job. The third one is the interesting one, because it answers where a specific component ended up. Alongside the traceability report that covers what was done to this machine and what went into it. What is missing is anything customer facing. There is no portal view and no printable service history document.
How we configure Odoo Repairs
Decide who owns the goods in your building
The customer device is not your stock, and Odoo will not work that out on its own. Switch on Consignment in the Inventory settings to get an owner field on receipts and quants, then receive each unit against the customer as owner. Do it before the first live receipt, not after. This one decision drives the valuation treatment, the month end conversation with your accountant and whether a stock count means anything, and it is the hardest thing on this page to reverse once trading has started.
Operation types, and where the workshop physically is
Each warehouse gets one repair operation type out of the box, and that record is where the geography is decided. Beyond the usual source and destination it carries four more defaults that only repairs use: where the unit to be repaired comes from, where it goes once repaired, where a part removed from the unit is put away, and where a recycled part goes. Point the repaired product destination at a workshop location that exists on the map, so a job waiting on a back ordered part is somewhere physical rather than in a status nobody can see. A bench location per technician is worth the effort where small spares walk off shelves.
Products, spares and a labour catalogue
The things you repair need product records, with serial tracking on anything a customer will later ask you about. Spares are inventory tracked goods with a real cost, not a generic miscellaneous line. The naming changed across versions and it confuses people mid upgrade: what Odoo 17 called a storable product is expressed in Odoo 18 and 19 as a Goods product with inventory tracking switched on. Labour is a set of priced service products, so a diagnostic, a bench hour, a minimum charge and a rush fee, rather than one hourly rate. Those products are what quotations are built from and what margin reporting groups by, and the ones that should raise a job on sale get the Create Repair flag.
What the data migration actually involves
Three imports matter: customers, the installed base as lot and serial records against the right products, and open jobs as draft repair orders. Warranty expiry is not a standard field anywhere in Odoo 17 or later, so if the business needs one it has to exist before the import runs rather than after. Historic job history rarely earns its place as repair orders. Export it, attach the documents to the serial or the customer, and keep the old system readable for a year.
Upgrading from Odoo 16 or earlier
Repair lines, repair fees, the invoice method and the warranty expiry date the repair order used to carry were all removed in 17. Old repairs do not map onto the new model line for line, and the invoicing history ends up somewhere else. Anything that read those tables, so a job costing report, a BI extract or a portal integration, has to be rewritten against stock moves and sale order lines. Close open repairs on the old version before cutover so nothing has to be rebuilt by hand, and run the upgrade of historic repair data on a copy of the live database before anyone commits to a date.
Where Odoo Repairs projects go wrong
Repair states are fixed
New, Confirmed, Under Repair, Repaired and Cancelled. There is no stage model, so awaiting parts, awaiting customer approval and ready for collection are not columns you can add. Those are the columns a workshop actually runs on. The kanban view that ships is a mobile card layout, not a stage board. What you can add without Studio is Properties, defined per repair operation type, which gets you fault codes, an accessories checklist or a customer reference as real fields on the order. Properties hold data. They do not drive the status bar and they are not a workflow. Anything past that is a custom stage field, and that belongs in design rather than in week three.
Warranty is a checkbox, not an entitlement check
Odoo holds no warranty period on a product or a serial, no lookup back to the original sale and no expiry calculation. The expiration date that can appear on a lot belongs to the Expiration Dates setting and is a shelf life control for perishable goods, not a warranty term. A person at the counter decides, and the zero pricing follows that decision. Where warranty leakage costs real money, add a warranty end date to the serial, computed from the delivery date, and an automation rule that sets or blocks the flag. Budget it as a small build, because a bare checkbox gets ticked whenever the customer argues hard enough.
Consignment fixes the valuation, not the quantity
A device received on an ordinary receipt increases both on hand quantity and stock value for goods you do not own. Consignment fixes the half that matters to the accounts, because a quant whose owner is not your company is excluded from valuation outright. It stays in on hand quantity. The quantity computation only filters by owner when something explicitly asks it to, so forecasts, reordering rules and the available quantity shown on the product still count customer units unless you park them in a location you exclude deliberately. Receiving against a product with inventory tracking off avoids both problems and costs you serial traceability. Choose deliberately, because switching approach a year in means restating stock.
No labour time is captured on the repair order
There is no timer and no timesheet line on a repair order. Hours are a quantity somebody types onto a sale order line after the job is done. If technician utilisation or true job cost matters, run a project task beside the repair order and timesheet against that, or accept that the hours are an estimate dressed as data. Utilisation is the report every repair business asks for around month three, and it cannot be built backwards out of data nobody captured.
A scheduled date is not a capacity plan
The repair order has one date and one responsible user. There is no bench, no work centre, no duration and no load view, so a workshop with twelve technicians cannot see who is full next Tuesday. The shipped search view will not even group by responsible user, only by customer, product, status and company, so a per technician view becomes your first customisation rather than your fifth. Manufacturing solves capacity with work centres and repairs deliberately does not use them. The Enterprise Planning app schedules people rather than repair orders, so joining the two is custom work. Sequencing by hand is fine at ten jobs a day and falls apart at fifty.
The customer cannot see their repair
The portal exposes quotations, sale orders and invoices. Repair order status is not published to it, so a customer asking whether the unit is ready gets a phone call. At counter volume that is a measurable staffing cost. The options are a custom portal page, or status emails and SMS driven by automation rules on the repair order state. Budget for one of them rather than discovering it at go live, when the counter staff are the ones who find out.
What it works with
- + Inventory, for parts, serial numbers, the return that brings the unit in and the delivery that sends it back
- + Sales, which installs with Repairs as a dependency and carries the quotation, the approval and the invoice
- + Purchase, for spare parts sourcing and reordering rules on fast moving components
- + Accounting, for stock valuation entries and, in Enterprise, the country e-invoicing connectors
- + Project and Timesheets, both Community, when technician hours have to be costed against a job
- + Helpdesk in Enterprise, where an agent raises the repair from a customer ticket
- + Field Service in Enterprise, when the fix happens at the customer site rather than the bench
- + Maintenance, for machines you own, which is a different app from repairs you sell
Odoo Repairs by country
Saudi Arabia (KSA)
ZATCA Phase 2 splits repair billing in two. A standard invoice to a business customer has to be cleared through Fatoora before it is valid, so the unit cannot be handed over against a written slip and the counter depends on an API being up. Consumer counter work is a simplified invoice, stamped locally and reported within 24 hours, which keeps the queue moving. Both carry Arabic and a QR code. Integration waves keep stepping down by revenue, so confirm which wave your turnover puts you in rather than assuming a small workshop is out of scope.
United Arab Emirates
Electronic invoicing runs through an Accredited Service Provider rather than a direct link to the tax authority, so the Odoo side is an integration to that provider and picking the provider is a procurement decision before it is a technical one. The published phasing starts with the largest taxpayers and brings the rest in behind them, and B2C sits outside the current scope, so a walk in counter stays simple. The piece worth designing early is warranty work recharged to an overseas manufacturer, which is a cross border service invoice with its own tax treatment.
India
Sending a customer machine out to a specialist and getting it back is job work. It moves on a delivery challan under rule 55 with an e-way bill above the state threshold, in both directions, which is two more documents for every subcontracted repair. A repair invoice also mixes goods and services, so parts carry HSN codes and labour carries SAC codes, often at different rates on one document. Above INR 50 million of turnover that invoice needs an IRN and a signed QR code back from the portal before it reaches the customer.
Pakistan
One repair invoice can straddle two tax authorities. Spare parts are federal sales tax to the FBR, while the repair service is provincial, so SRB in Sindh, PRA in Punjab, KPRA in Khyber Pakhtunkhwa or BRA in Balochistan. That is two registrations, two returns and a tax mapping in Odoo that splits the same document by line type, which is the part most templates get wrong. FBR digital invoicing then sits on top as a clearance step, with the invoice number and QR code coming back from PRAL or a licensed integrator before you can issue.
Turkey
A device travelling to the workshop and back needs an e-Irsaliye dispatch note in each direction, so the delivery you raise after the repair is a compliance document rather than housekeeping. Billing then splits by counterparty: e-Fatura where the customer is registered in the system, e-Arsiv for everyone else, which at a counter means checking the register before printing. Archived e-documents have to remain in Turkiye, so hosting is settled by the compliance rule and not by preference.
Egypt
The ETA portal wants every line item coded, against a GS1 GTIN or an EGS code you register yourself, so a spare parts catalogue has to be mapped before the first invoice will clear and a miscellaneous parts line simply will not pass. Invoices are signed with a CAdES-BES seal held on an HSM or a USB token, so the certificate has to be reachable from wherever invoices are issued, which shapes whether billing can run from a branch counter at all. Consumer repair counters fall under the separate e-receipt system.
Germany
Two years of statutory liability for defects is not billable work, and it is a different thing again from a commercial warranty or a paid service contract. All three have to be distinguishable on the order, because the entitlement and the accounting differ. GoBD requires the job card, the photos and the handover signature to stay unalterable and traceable for the retention period, which is an attachment and archiving policy rather than a plugin. Since January 2025 every German business has had to be able to receive a structured e-invoice, so parts suppliers can send XRechnung or ZUGFeRD today, with the obligation to issue phasing in from 2027.
United Kingdom
There is no B2B e-invoicing mandate, but Making Tax Digital requires an unbroken digital link from the repair invoice through to the VAT return, so job totals cannot be rekeyed through a spreadsheet along the way. HMRC submission from Odoo lives in the UK localisation on Enterprise rather than Community, and for a workshop of any size that single point often decides the edition. NHS trusts procure over Peppol, so servicing medical equipment under an NHS contract makes access point capability a contractual matter rather than a preference.
Odoo Repairs FAQs
Is Odoo Repairs a Community or an Enterprise app?
Repairs is Community and LGPL licensed, so repair orders, part moves, the warranty flag and the link into Sales cost nothing in licence terms. What surrounds it often is not. Helpdesk, Field Service, Studio, Barcode and the country e-invoicing connectors are Enterprise. Price the workflow rather than the app, because a Community repairs build that then needs ticket intake and a clearance connector is an Enterprise build with extra steps.
What happens when a unit turns out to be beyond economic repair?
You cancel the repair order, which is allowed at any point before it is marked Repaired and blocked afterwards. Where the repair came from a sale order, cancelling it writes the originating line down to zero quantity, so the job stops being billable without anyone editing the order. A diagnostic fee sitting on that same order as a separate line is untouched, which is the usual reason for charging one up front. After that it is a physical problem rather than an Odoo one. Customer property goes back out on a delivery, your own stock is scrapped through Inventory, and neither happens automatically from the repair order. Disposing of a customer unit needs their agreement in writing whatever the system permits.
Can one job be part warranty and part chargeable?
Not on one repair order, because the flag covers the whole order and zeroes every part line on it. The clean pattern is two repair orders, one covered and one chargeable. Both can hang off a single sale order so the customer still receives one document, but only where that sale order created them, from two lines carrying the Create Repair flag. Building it the other way round will not group them, since each repair raises a quotation of its own. The alternative is one chargeable repair with the covered lines discounted to zero and the reason written on the line, which is quicker to set up and much worse to report on later.
Can we recharge warranty work to the manufacturer?
Yes, as two documents rather than one. The customer job runs under the warranty flag at zero, and the recharge is a separate sale order to the manufacturer carrying the parts and the agreed labour rate. Odoo has no claim model, no claim number and no reconciliation between the two, so the link is a field you add or a reference somebody types. Where the manufacturer pays on their own cycle, that recharge then ages in receivables like any other customer balance, and nobody notices it slipping unless one person owns the report.
Can we charge a diagnostic fee before we know what the repair will cost?
Yes, and it uses standard sale order tooling rather than anything in Repairs. Sell a priced diagnostic product, then invoice it either as an ordinary line or through the down payment option on the invoicing wizard, which takes a percentage or a fixed amount. Use the down payment where the fee is meant to be credited against the final bill, because it posts now and nets off against the closing invoice by itself. The case to settle in design is the customer who declines the quote. The fee is invoiced, no parts were consumed, and somebody still has to raise the delivery that returns the unit.
We already have a year of customer units in our stock value. How do we unwind it?
Fix the flow first, then the history, or the work gets done twice. Turn on Consignment and route every new intake through an owner so the problem stops growing that same week. The units already counted come out through an inventory adjustment against a dedicated location, posted as one movement with the valuation correction agreed with your accountant in advance rather than dribbled quietly across months. Expect to reconcile serial by serial, because that is the only way to tell a customer unit from your own once both have sat in the same location.
Can customers book a repair from our website?
Not from the Repairs app itself, which has no website intake. The nearest standard route is to sell a diagnostic or fixed price repair product carrying the Create Repair flag, so a webshop order or an accepted quotation raises the repair order on confirmation. The other common patterns are a website form that creates a lead, or a Helpdesk ticket on Enterprise that an agent turns into a repair. Intake is the easy half. Telling the customer their unit is ready is the part that needs building.
What reporting comes out of the box?
Less than most buyers assume. Repair orders ship with a list, a graph and a pivot, grouped by customer, product, status or company, plus margin and revenue on the sale orders, stock valuation on the parts consumed and the per serial repair counts on the lot record. There is no turnaround time report, no first time fix rate and no technician utilisation, because the timestamps and hours behind them are not all captured. Each of those is a stored computed field plus a view, which is a small job scoped at the start and an awkward one bolted on in year two.
How long does a repairs implementation take?
A single counter with one warehouse, one repair operation type, a spares catalogue and a quotation flow is a matter of weeks. What adds months is predictable: consignment ownership across several branches, manufacturer warranty recharge, a clearance e-invoicing integration that has to be certified before go live, and an installed base import. Serial number data quality moves the date more than configuration ever does, because a unit whose serial does not exist in Odoo cannot be repaired against.
Related Operations modules
Odoo IoT
Scales, printers, scanners and payment terminals on the shop floor.
Odoo Field Service
Scheduling, on-site tasks, timesheets and invoicing from the field.
Odoo Fleet
Vehicles, contracts, fuel, services and driver assignment.
Odoo Inventory
Stock moves, warehouses, barcode, lots.