How to Implement Odoo for Garment & Apparel Business (2026 Guide)

1Who Odoo fits

Odoo is a practical choice for small and mid-size apparel businesses that want one system for sales, purchasing, stock, manufacturing and accounts, and that have a partner or in-house developer. It handles colour and size through product variants, has a working subcontracting flow, and lets you grow module by module.

It suits a factory that is ready to standardise its office processes and accept Odoo's way of doing sales orders, purchase orders, receipts and invoices. It suits a factory less well if the owner expects the ERP to replace the merchandisers' tracking sheets, the IE department's minute studies and the quality team's inspection reports in one move. Those are the parts of this guide where Odoo needs the most design work, custom code or a separate system.

Signs Odoo is a good choice

Odoo tends to work when the factory wants one ledger and has the people to maintain it.

• The business wants one ledger, one stock value and one set of purchase and sales documents, and today it has several.
• A partner with manufacturing experience is available, or the factory has at least one developer who can maintain custom modules through upgrades.
• Style counts per season are in the hundreds, and colour-size combinations can be controlled with the variant settings in section 11.
• Local e-invoicing is supported by an Odoo localisation for your country, or the partner has a plan for it (section 22).

Signs to slow down

Slow down when the expectations placed on Odoo belong to a planning, floor or development system.

• The factory expects Odoo to plan sewing lines hour by hour. Odoo's work orders are not a line-balancing tool (section 15).
• Buyers require EDI, compliance labels and portal uploads, and nobody has scoped them.
• Most of the order book is sampling and development. That work happens before any Odoo product exists.
• The go-live date falls inside peak season.

2Why no ERP fits apparel on its own

No general ERP fits apparel out of the box, because an ERP is built around a known item with one bill of materials, while a garment order starts as a style that is quoted, sampled and approved before any item exists. This is not an Odoo weakness. SAP, NetSuite, Dynamics 365 and every general ERP meet the same wall, which is why fashion add-ons and fashion-specific systems exist, and why even they leave much of the work outside. The same wall stands in front of brands and buying agents, whose styles, samples and approvals also come long before any purchase order (section 35).

An ERP is built around the transaction: a known item, a fixed bill of materials, a price, a receipt, an invoice. It is right to be strict about that, because strictness keeps the books correct. A garment order does not start there.

Forcing an ERP to do all of this means heavy customisation in the one system that most needs to stay standard. Every upgrade gets harder, the ledger fills with data finance never reads, and the merchandisers keep their spreadsheets anyway. The durable answer is to give the ERP the books and give the operations to a system built for them. Section 3 summarises that model and section 39 shows it in full.

3The recommended architecture, in short

Before discovery starts, agree which system owns which part of the business. Our recommendation is a split along the line in Example 1: Odoo keeps the books, and an operations system built for apparel runs everything from the style to the shipment.

With this split, the Odoo project stays close to standard: fewer custom modules, cleaner upgrades and a shorter project. The rest of this guide still explains how to bend Odoo toward garment production, because some factories choose to do that, and because a consultant needs to know what each choice costs. Where an area moves out of Odoo under the recommended model, the section ends with a short note. Section 39 describes the model in full, department by department.

4Business types, and what each needs from Odoo

"Apparel manufacturer" covers very different businesses. The business type decides who owns the material, what is invoiced, and which parts of Odoo carry weight. Settle it in the first discovery meeting, because a factory often runs two types at once, for example full package for one buyer and CMT for another.

The list above is general implementation practice. Treat it as a starting point for the discovery questions in section 6, not as a scope. Brands, buying agents and own-label retailers have their own part of this guide, starting at section 35.

5Who should be on an Odoo apparel project team?

An apparel Odoo project needs one decision owner for every design question, and most of those owners sit in the factory, not in IT. The partner configures and builds; the factory decides how styles, units, lots, costs and inspections work.

The table lists the roles we see on projects that go well. One person can hold several roles in a small factory. What matters is that every question in the fit-gap has a named person who can say yes.

Rules that keep decisions moving

Most delays in apparel projects come from decisions nobody owns. Four rules prevent them.

• One owner per decision. "Merchandising and finance will agree" produces no decision. Write one name against each fit-gap line.
• Decide in writing. Keep a decision log with the date, the owner, the option chosen and the options rejected. Discovery findings, design choices and change requests all go in it.
• The sponsor settles scope, not configuration. The sponsor decides whether T&A lives in Odoo or elsewhere. The merchandising head decides how it works.
• Key users are released from part of their day. A key user who is also running peak-season orders will not test properly.

6What should discovery workshops for an apparel factory cover?

Discovery for an apparel factory is one workshop per department, each walking a real, recent order from start to finish and asking where the data comes from, who changes it and what goes wrong. Use the factory's own orders, not a demo database. The polo order in this guide is the kind of order to bring.

Each workshop produces three things: the current flow as it really runs (including the spreadsheets), a list of findings mapped to the fit-gap lines in section 7, and a list of decisions with an owner. The question lists below are a starting set; add the factory's own.

Merchandising

Merchandising questions establish how orders arrive, change and are tracked.

• How does an order arrive: buyer PO by email, portal, EDI? What fields does it carry, and how often is it amended after confirmation?
• How are sizes and colours broken down, and do buyers order in ratio packs?
• What quantity tolerance do buyers allow, and how is a short or over shipment agreed?
• Is one buyer order split into several deliveries, each with its own date and destination?
• Where is the T&A calendar kept, who updates it, and who looks at it each morning?
• Which season and style numbering does each buyer use, and does the factory keep its own?

Development and sampling

Development questions establish what happens before an order exists.

• Which sample types does each buyer require, and in what order?
• How are sample rounds recorded: sent date, courier, comments, verdict?
• Where do tech packs live, and how is a revision after PP approval handled?
• Who prepares the quotation cost, from what inputs, and how many versions does a quote go through?

Purchasing and stores

Stores questions establish units, lots and what is measured at receipt.

• In which unit is each material bought, stocked and issued? Which suppliers invoice in a different unit from the one they deliver in?
• What is checked at receipt: weight, width, GSM, shade, shrinkage, four-point inspection? Who records it and where?
• How are dye lots and rolls labelled, and can the store find every roll of one lot today?
• Which materials are nominated by the buyer or supplied by the buyer?
• What happens to leftover fabric and trims after an order ships?

Cutting, production and subcontracting

Production questions establish the level of control and how output is counted.

• At what level is production controlled: per order, per style-colour, per delivery, per cut?
• How is the cut plan made per dye lot, and who checks that lots are not mixed?
• How is output counted today: per line per hour, per operator, at end of line?
• Which processes go outside (print, embroidery, wash, CMT) and how are pieces counted out and back?
• How are rejects, repairs and second-quality pieces recorded?

Industrial engineering and planning

IE questions establish where minutes and capacity come from.

• Are operation minutes (SMV) studied per style, taken from a library, or estimated?
• How is line capacity planned across the season, including subcontractors?
• What efficiency figure is used for planning, and how is actual efficiency measured?

Quality

Quality questions establish inspections, buyer standards and who may release a failed lot.

• Which inspections run: incoming fabric, cutting, inline, end of line, pre-final, final, measurement?
• Which buyers set their own AQL levels, and where are their quality manuals kept?
• Who may release a lot that failed inspection, and is that decision logged?
• Which lab tests and certificates are required per order?

Shipping

Shipping questions establish packing rules and documents per buyer.

• How are cartons packed: solid size, assorted, ratio? What carton labels does each buyer require?
• Which export documents are prepared per shipment, and who checks them against the letter of credit?
• Does any buyer require an advance shipping notice?

Finance

Finance questions establish currencies, payment terms, import costing and tax.

• Which currencies are used for sales, purchases and wages? How are exchange differences booked today?
• How are buyers paid: letter of credit, down payment, open account? Which buyers deduct chargebacks?
• How is imported material costed: are freight, duty and clearing added to the material cost?
• Is the factory in a free zone or under a temporary-admission regime, and what reports does that require?
• Which e-invoicing and tax reporting rules apply?

7The apparel fit-gap checklist for Odoo: 52 lines

A fit-gap checklist lists every requirement an apparel business has and records, line by line, whether Odoo meets it as standard, meets it with configuration, needs custom code, or is better handled outside Odoo. The 52 lines below cover product, BoM and costing, materials, production, quality, sales and shipping, and finance.

The answers are our assessment of Odoo 17 to 19 for a typical full-package garment factory. Where a line depends on the Enterprise edition, it says so. Confirm each line against your version and your partner's modules before you sign a scope.

Key: Standard works as delivered · Configure settings, fields or light Studio work · Custom build a code module or third-party app · Operations layer better run in an apparel operations system and passed to Odoo

Counted from this table, 10 of the 52 lines are standard, 19 need configuration, 14 need custom code and 9 are better run outside Odoo. That count is our assessment for a typical full-package factory, not a survey. A CMT factory drops most of the costing and material lines; a mill adds process lines this list does not cover.

8Odoo Enterprise vs Community for manufacturing, and where to host it

Odoo Community includes the Manufacturing (MRP) app, but Shop Floor, Quality, PLM, Barcode and Studio are Enterprise-only on Odoo's editions page, so most garment factories that run production in Odoo need Enterprise. Choose the edition and the hosting after the fit-gap, not before it: several features a sewing floor depends on are in Enterprise, and most apparel projects need custom modules that Odoo Online cannot run. Odoo's own editions page is the reference; confirm each line there before you quote it to a client.

A factory that chooses Community to save licence cost usually rebuilds barcode, quality and shop-floor capture itself, or buys them from a third party. Put that cost in the comparison.

Which hosting option suits an apparel project?

Odoo.sh or on-premise suits most apparel projects, because they allow custom modules; Odoo Online suits a project that keeps Odoo close to standard.

If you follow the recommended architecture, the Odoo side may stay standard enough for Odoo Online. That depends on what the integration needs: an API connection works from outside, while a file exchange run by a scheduled job inside Odoo is custom code. Check before choosing.

How much does Odoo cost for a garment factory?

The cost of Odoo for a garment factory depends on the edition, the plan, the number of users, the hosting and, above all, the partner work and custom modules the fit-gap calls for; licence fees are usually the smaller and more predictable part. Odoo publishes its current prices on its pricing page; we do not repeat them here because they change.

The fastest way to lower the total is to shrink the custom-build column. Every line moved to standard Odoo or to an operations system is a module nobody has to port.

Questions to settle with the partner

Settle these with the partner before signing, because each changes the cost and the upgrade path.

• Which Enterprise apps does the fit-gap actually need, and for how many users?
• Which custom modules are planned, who owns their code, and who ports them at each upgrade?
• Is there a staging copy for testing each release against real data?
• Which Odoo version will go live, and when will the next upgrade be due?

9Odoo vs ERPNext for garment manufacturing

Odoo and ERPNext both model a style as a template with colour and size variants and both support subcontracting; Odoo offers more manufacturing apps (Quality, PLM, Shop Floor) in its paid Enterprise edition, while ERPNext is fully open source but has needed a BOM per variant for subcontracting (a fix was merged in September 2026; check your release). Neither covers sampling, T&A, size-graded consumption or AQL for apparel out of the box. ERPNext is an open-source ERP built on the Frappe framework.

Which should a garment factory choose?

Choose on the fit-gap, the partner and local compliance, not on the product name. From practice, Odoo tends to suit a factory that wants Enterprise apps for quality and shop floor and a large partner network; ERPNext tends to suit a factory with in-house developers that values an open-source licence. In both, the parts of this guide marked custom build remain custom build, and in both, customisations must be carried through each upgrade.

ERPNext facts from its documentation and GitHub (see sources). Items marked "not verified" were not found in ERPNext's documentation; demo them.

10How should product categories and materials be set up in Odoo for apparel?

Set up Odoo product categories by how each material is bought, stocked, costed and tracked: fabrics, yarns, trims, packaging, subcontract services and finished garments each get their own category, because the category carries the costing method and the stock accounts. Apparel is not one product type. The garment category decides the size system, the main material, the unit it is bought in and the processes it goes through. Set Odoo's product categories and attribute sets from this, not from the chart of accounts alone.

Materials, and how each is bought and used

Each material has its own purchase unit, usage unit and receipt checks, and the Odoo setup must follow them.

In Odoo, give fabrics, yarns, trims, packaging, finished garments and subcontract services their own product categories, because the category carries the costing method and the stock accounts. Put lot tracking on fabric and yarn; most trims do not need it.

What each category carries in Odoo

In Odoo, the costing method (Standard, AVCO or FIFO) and the inventory valuation (Automated or Manual) are set on the product category, under Inventory ‣ Configuration ‣ Product Categories in the Odoo 18 documentation. Lot tracking is set per product, and units per product. Two documented rules shape the category design for apparel:

• Landed costs apply only to AVCO or FIFO categories. Odoo's landed-cost documentation states that products receiving landed costs must belong to a category with a costing method of AVCO or FIFO. Keep imported fabric and trims out of Standard categories if you want freight and clearing added to their cost.
• Units convert only inside a unit category in Odoo 17 and 18. Buying buttons by the gross and issuing them by the piece works, because both are counts. Buying jersey in kilograms and cutting in metres does not (section 12).

With operations on top: the style, its bill of materials by category and its consumption are built in the operations layer. Odoo still needs the categories and costing methods above, because it holds stock value and the payables.

11How do you set up size and colour variants in Odoo for apparel?

Model the style as the product template and each colour, size and (where it applies) fit or inseam as an attribute; the variants are the combinations. In the Odoo 18 documentation, variants are switched on under Sales ‣ Configuration ‣ Settings ‣ Product Catalog, and attributes are managed under Sales ‣ Configuration ‣ Attributes. Each attribute has its own creation mode:

Do the arithmetic before choosing. Ten colours, twelve sizes and three inseams give 360 variants for one style. On Instantly, a season of 80 styles fills the product list with close to 29,000 records.

Lock the attribute set before go-live. Adding an attribute to a template that already has variants disrupts the existing variants, and users report archived and recreated records on Odoo's forum. The change a merchandiser thinks is small, adding "fit" to an existing style, becomes a data-migration task.

For order entry, Odoo Sales offers a variant grid: a colour by size quantity matrix on quotations and sales orders, for products with at least two variants. Grid entry on purchase orders is not documented as a core feature; third-party modules exist on the Odoo Apps store.

Naming and codes

Agree a code pattern before the first import, for example P2041-NVY-L for style, colour and size, and hold the buyer's own style number in a separate field. Keep the Odoo internal reference short and stable, because users edit it and integrations must never rely on it (section 34). Keep one size attribute per size scale, so an "S" on a polo and an "S" on a bra band never share a value by accident.

With operations on top: styles, colourways and size breakdowns live in the operations layer, and Odoo only needs the finished-goods items that are actually sold and invoiced. The variant count in Odoo drops to what ships.

12How do you convert kilograms to metres for fabric in Odoo?

Odoo cannot convert fabric kilograms to metres as standard in versions 17 and 18, because kilograms and metres sit in different unit categories and Odoo converts only inside a category. Knitted fabric is usually bought by weight and cut by length. The conversion depends on the fabric's weight per square metre (GSM) and its width, so it differs for every fabric and often for every roll.

GSM means grams per square metre: the weight of one square metre of the fabric. A 180 GSM jersey weighs 180 g per square metre.

Odoo 17 and 18 group units into categories, and conversion works only inside a category. Kilograms (weight) and metres (length) are in different categories, so there is no built-in conversion between them. The usual answers are a conversion factor held on each fabric, or buying and consuming in the same unit. Never use one factor for all fabrics. In the Odoo 18 documentation, units are enabled under Inventory ‣ Configuration ‣ Settings, categories are managed under Inventory ‣ Configuration ‣ UoM Categories, and the product form carries a separate Purchase UoM.

Odoo 19 reworked units of measure: categories and the separate purchase unit are gone, and packagings are merged into units. Anything you design or integrate around units must name the version it was built for.

Three workable designs

There are three workable ways to hold knit fabric in Odoo 17 and 18, each with a trade-off.

With operations on top: the operations layer records a measured lot record per receipt (GSM, width, shrinkage) and works consumption in the unit the cutting room uses. Odoo can stay in the purchase unit, kilograms, for stock value and payables.

13How do you track dye lots and fabric rolls in Odoo?

Track fabric by lot in Odoo and use each lot as one dye lot, then make the lot mandatory on every receipt and every issue to cutting. A dye lot is a batch of fabric dyed together; fabric from two dye lots can differ slightly in shade, so pieces cut from two lots show a colour difference once sewn into one garment. Cutting must stay within one lot. Track fabric by lot and use the lot as the dye lot. Make the lot mandatory when fabric is issued to cutting, and refuse mixed lots on one cut.

In the Odoo 18 documentation, lots are enabled under Inventory ‣ Configuration ‣ Settings ‣ Traceability (Lots & Serial Numbers), and each product is set to track "By Lots" on its General Information tab. Each operation type has two lot switches: Create New lets users create lots on that operation, and Use Existing ones restricts them to lots that already exist. For fabric, allow new lots on receipts and allow only existing lots on issues to production.

Tracking each roll is a design choice: a serial number per roll gives roll-level issue and return, a package per roll keeps the lot as the unit. Shade group, actual width and actual GSM per roll are not standard lot fields and need custom fields.

A shade band is a set of approved shade references for one fabric colour, used to judge whether a new lot is close enough to the standard. Buyers often allow shade groups within the band (for example A, B and C), and a garment must stay within one group. Odoo has no shade band object; it is a custom field on the lot or a record in another system.

With operations on top: shade bands per fabric, the measured lot record and the incoming inspection that carries the dye lot sit in the operations layer. Odoo still holds the lot on receipts and issues, so stock value and traceability stay correct.

14How do you handle size-dependent fabric consumption in Odoo BoMs?

Odoo holds one quantity per BoM line, so fabric that grows with size needs either a line per size, each limited to its variants with "Apply on Variants", or a separate BoM per size group; generate those lines from a consumption table rather than typing them. One BoM per style works well for components that change by colour. Each BoM line has an Apply on Variants setting; left blank, the line applies to every variant, so red thread can be limited to red garments.

Fabric consumption is harder, because it grows with size. An XL uses more fabric than an S. Odoo expresses this with a BoM line per size group or separate BoMs, and with 12 sizes that is a lot of lines to maintain. Projects that go well generate those lines from a consumption table (base size, grading per size, marker efficiency) instead of typing them.

The same variant rule applies to operations and by-products. Odoo's documentation on manufacturing with variants says the principle used for components also applies when configuring operations, and a Consumed in Operation field decides at which operation a component is used. A hand-embroidery step that only the navy colourway needs can be limited to navy variants.

A BoM of type Kit is exploded at delivery. It suits sets and ratio packs sold as one unit, not garments you manufacture.

Marker efficiency is the share of the fabric in a cutting marker that ends up in garment pieces; the rest is waste between the pieces. Shrinkage is the fabric the garment loses in washing or finishing, planned into the pattern. Keep the two apart: they come from different people (CAD and lab), change for different reasons, and are argued about with different suppliers.

With operations on top: the consumption engine (marker efficiency, shrinkage, woven construction) and the net-to-buy across the order book run in the operations layer, which passes the purchase quantity to Odoo. Odoo does not need size-graded BoM lines.

15How do you model cutting, sewing and finishing with Odoo work centers?

Model cutting, sewing, finishing and packing as Odoo work centers, and list the garment's operations with their minutes on the BoM's Operations tab; this gives work orders and a labour cost, but it does not balance a sewing line. A work center in Odoo is a place where operations run, with its own working hours, efficiency and cost per hour.

In the Odoo 18 documentation, work orders are switched on under Manufacturing ‣ Configuration ‣ Settings (Work Orders), and work centers are created under Manufacturing ‣ Configuration ‣ Work Centers. A work center carries working hours, a Time Efficiency multiplier, a Capacity (units processed at the same time), an OEE Target, a Cost per hour, setup and cleanup times, alternative work centers and allowed employees. Operations are added on the BoM's Operations tab, each assigned to a work center.

What an operation duration means in a garment factory

SMV (standard minute value) is the time a trained operator needs for one operation at a normal pace, including allowances. A polo has 15 to 25 sewing operations. You can list each one as an Odoo operation, or group them into a few steps per department. Grouping keeps work orders manageable; listing every operation gives a detailed cost but floods the work-order list.

With operations on top: the planning heat-map (lines and subcontractors, 52 weeks), production orders with job cards per department and the WIP board run in the operations layer. Odoo receives material issues for stock value and does not need work orders at all.

16Where do sampling, approvals and the T&A calendar live in an Odoo project?

Odoo has no object for garment samples, buyer approvals or a T&A calendar, so an Odoo project must build them as custom work, borrow another app for them, or keep them in an operations system. Before a single bulk garment is cut, the buyer approves the product in stages. Each stage can take several rounds, and each approval unlocks the next step of the order. Miss one, and the factory is ordering fabric or cutting on a spec the buyer has not agreed.

A PP (pre-production) sample is a garment made in the actual bulk fabric and trims, which the buyer approves as the reference that bulk production must match. A T&A (time and action) calendar is the list of an order's milestones, each with a planned date worked back from the ex-factory date, an actual date and an owner.

Every round has a sent date, a courier and tracking number, the pieces sent, the buyer's comments and a verdict: approved, approved with comments, or rejected. The T&A calendar hangs on these dates.

Odoo has no object for this. Teams build it from project tasks, helpdesk tickets or a custom module, and more often it lives in email. The typical failure is bulk fabric ordered, or cutting started, on the strength of an approval nobody can find.

What a custom sampling module must hold

If the project builds sampling inside Odoo, the module needs a small set of records that link to the style and the order. The list below is the minimum we would design.

• A sample request per style and colourway, with its type (lab dip, strike-off, fit, size set, PP, TOP, shipment).
• Rounds under each request: sent date, courier, tracking number, pieces sent, buyer comments, verdict, verdict date, who recorded it.
• A link from the approved round to the spec version it approved, so a later revision cannot silently replace it.
• A block on the next step: bulk dyeing waits for the lab dip, cutting waits for the PP sample.
• T&A milestones that take their actual dates from the rounds instead of from someone typing them.

With operations on top: dev approvals (lab dip, strike-off, sample, shipping mark) with rounds, courier details and the buyer's verdict, the T&A calendar with its critical path, and the PP approval that locks the style version for the order all live in the operations layer. Odoo needs none of it.

17How does Odoo subcontracting work for CMT, washing, printing and embroidery?

Odoo subcontracting sends components to an outside processor on a purchase order and receives the finished item back, consuming the components on receipt; it fits one outside step well and a chain of processors less well. In the Odoo 18 documentation it is switched on in the Odoo Manufacturing (MRP) app under Manufacturing ‣ Configuration ‣ Settings (Subcontracting, under Operations), and a BoM of type Subcontracting names one or more subcontractors.

CMT (cut, make, trim) means the factory sews garments from fabric the buyer supplies and charges only for the labour; in subcontracting, the same term describes a factory that sends cut panels to another unit to be sewn. Job work is the South Asian term for the same arrangement.

Basic, resupply and dropship subcontracting

Odoo documents three subcontracting workflows, and the difference is who supplies the components.

The resupply flow runs like this:

1. A subcontracting BoM names the subcontractor.
2. Confirming the purchase order to that subcontractor creates the receipt, and a resupply order that sends the components out.
3. Components move to the subcontractor's location when the resupply is validated.
4. Receiving the finished goods consumes those components.

Garments often visit several processors: cut panels to a printer, then to a sewing unit, then to a wash. Each step becomes its own intermediate product and subcontracting BoM, or custom work. Modelled as one step, the factory loses sight of where its goods are between processors.

Subcontractor tracking a factory expects

A factory expects to see, per processor, what went out, what came back, what was lost and whether the loss is inside the agreed allowance. Odoo shows stock at the subcontractor's location; the allowance, the reject reasons and the balance per order are design work or a report to build.

With operations on top: subcontract steps sit on the production order in the operations layer, and subcontractors appear on the planning heat-map beside the factory's own lines. Odoo receives the subcontractor's purchase order and the payable.

18How do you cost a garment in Odoo, and where does the garment costing sheet live?

Odoo costs stock by product category (Standard, AVCO or FIFO) and adds freight and duty to receipts with landed costs, but the garment costing sheet used to quote a buyer is built before any Odoo product exists and usually lives outside Odoo. A garment costing sheet lists fabric, trims, making, washing, testing, freight, finance cost and margin per piece, and adds up to the price quoted to the buyer.

• Costing method is set per product category: Standard, Average (AVCO) or FIFO. Standard is common for finished garments; AVCO or FIFO for fabric and trims.
• Landed costs spread freight, duty and clearing over receipts, by quantity, weight, volume, equal share or current cost. Use them for imported fabric, including under temporary-admission and free-zone regimes.
• Multi-currency and exchange differences are native, which suits selling in USD or EUR while paying costs locally.
• Down payments on sales orders are native, by percentage or fixed amount.

Pre-costing a style for a quote (fabric, trims, CM, washing, testing, freight, finance cost, commission, margin) is usually done before an Odoo product exists, so it tends to live outside Odoo.

How do you configure landed costs in Odoo for imported fabric and customs duties?

Switch on Landed Costs in Odoo Inventory, create each import charge as a service product marked as a landed cost, and apply the charges to the fabric receipt with a split method per charge. A landed cost is any cost of bringing goods to the factory beyond the supplier's price: freight, insurance, customs duty, clearing and bank charges.

In the Odoo 18 documentation, the setting is under Inventory ‣ Configuration ‣ Settings, in the Valuation section (Landed Costs). Landed-cost products must be of type Service, with Is a Landed Cost ticked on the Purchase tab. The products that receive the cost must sit in a category costed by AVCO or FIFO. The documented split methods are Equal, By Quantity, By Current Cost, By Weight and By Volume.

Choose the split per charge. Sea freight follows weight or volume; clearing and bank charges usually follow value; a duty charged per kilogram follows weight. For a factory in a free zone or under temporary admission, duty may be zero or suspended, and the rules for what must be reported are local. Agree them with the customs broker and finance before configuring.

With operations on top: the cost engine (fabric, trims, decoration, CMT, overhead, margin to FOB, with landed cost and dated exchange rates), the standard cost sheet and quotations with approval thresholds run in the operations layer. Odoo holds the landed cost that actually hit the receipts, for stock value.

19Can Odoo run quality control and AQL inspection for garments?

Odoo Quality (an Enterprise app) creates pass-fail, measurement and instruction checks on receipts, work orders and deliveries, but it does not contain ISO 2859-1 sampling tables, so AQL inspection needs custom work or a separate system. AQL (acceptance quality limit) inspection checks a random sample drawn from a lot and accepts or rejects the whole lot according to how many defects the sample contains.

In the Odoo 18 documentation, control points are created under Quality ‣ Quality Control ‣ Control Points. A control point targets an operation (such as a receipt, a delivery or a manufacturing operation) and products or product categories. Its frequency is All, Randomly (a percentage) or Periodically; its check types include Instructions, Pass-Fail, Measure, Take a Picture, Register Production, Worksheet and Spreadsheet. With Multi-Step Routes on, a warehouse can receive in three steps (input, then quality, then stock), which creates a Quality Control location for goods on hold.

Quality control at cutting, stitching, dyeing and printing

A garment factory inspects at each stage where a defect is cheaper to catch than at the end. Dyeing and printing usually happen at a dye house or printer outside the factory, so those checks land on the receipt of the goods coming back.

An Odoo random frequency of 4.17% gives about the same number of pieces as the final sample in Example 16 for this one lot size. It is not an AQL plan: under ISO 2859-1 the sample size comes from the lot-size band and the inspection level, and the lot is accepted or rejected against fixed acceptance numbers.

Acceptance numbers as published in ISO 2859-1 Table II-A, reproduced in common AQL references (see sources).

With operations on top: typed inspections (incoming, cutting, PP, DUPRO, final AQL, pre-shipment, measurement), the AQL engine on ISO 2859-1 at the buyer's level, CAPA, needle and metal control and quality grades (only first-quality pieces count as shippable) run in the operations layer. Odoo sees the delivery only once it is cleared.

20How do you handle cartons, packing lists and shipping documents in Odoo?

Odoo Inventory packs goods into packages on a transfer and prints delivery documents, but assorted and ratio cartons, buyer carton labels and pack-level packing lists usually need custom work. A package in Odoo is a physical container holding one or more products; in the Odoo 18 documentation, packages are switched on under Inventory ‣ Configuration ‣ Settings (Operations), and the Put in Pack button places the items of a transfer into a new package.

Documents a garment shipment needs

An export shipment of garments carries a standard set of documents, and a letter of credit may require each to match exactly.

With operations on top: shipments per delivery, packing and cartonisation, and ship clearance against the buyer's terms run in the operations layer. Odoo receives the dispatch and raises the customer invoice.

21How does Odoo handle multi-currency, letters of credit, down payments and chargebacks?

Odoo Accounting handles foreign currencies, exchange differences and down payments as standard; letters of credit and reason-coded chargebacks need design, because Odoo has no letter-of-credit object. Garment exporters usually sell in USD or EUR, buy some materials abroad and pay wages locally, so every order touches at least two currencies.

Multi-currency and exchange differences

Currencies are activated in Odoo Accounting and exchange differences are booked automatically when a payment settles an invoice at a different rate. In the Odoo 18 documentation, currencies are activated under Accounting ‣ Configuration ‣ Currencies, automatic rate updates are set under Accounting ‣ Configuration ‣ Settings (Currencies), and the exchange-difference journal and gain and loss accounts under Accounting ‣ Configuration ‣ Settings (Default Accounts). The multi-currency page describes realised differences; for period-end revaluation of open balances, check your version and localisation.

Down payments

A down payment in Odoo is an invoice for part of a confirmed sales order, later deducted from the final invoice. In the Odoo 18 documentation, it is created from the confirmed order with Create Invoice, choosing Down payment (percentage) or Down payment (fixed amount). A down-payment account can be set on the product category.

Letters of credit

A letter of credit is a bank's promise to pay the exporter when documents that match the credit's terms are presented. Under ICC's UCP 600 rules, which most credits follow, documents must be presented within 21 calendar days after the shipment date unless the credit says otherwise, and never after the credit expires. Odoo has no LC object: the credit number, amount, latest shipment date, expiry, presentation period and required documents need custom fields or a custom model, and a check before shipment that the documents will match.

Chargebacks

A chargeback is an amount a buyer deducts from a payment for a claimed failure: a late shipment, a wrong carton label, a missing or wrong advance shipping notice. It arrives as a short payment. Record the shortfall against a chargeback account, one account or analytic tag per reason, and keep the buyer's deduction notice attached. Without reason codes, nobody can tell whether the factory loses money to labels or to lateness.

With operations on top: finance stays in Odoo in full. The operations layer sends the orders, deliveries and purchase requests that the invoices and payables are built on; no money amounts travel through its ERP API.

22Does Odoo support e-invoicing and localisation for garment exporting countries?

Odoo publishes fiscal localisations per country, and for Egypt it documents integration with the Egyptian Tax Authority's e-invoicing system; for every other country, check Odoo's localisation page and a local partner before assuming compliance. E-invoicing rules change often, so treat any statement older than the current tax year with care.

Egypt (ETA e-invoicing)

Odoo's Egypt page documents two modules: Egypt - Accounting and Egyptian E-invoice Integration, compliant with the Egyptian Tax Authority (ETA) e-invoicing requirements and available from Odoo 15.0. Setup, per the Odoo 18 documentation:

1. Register the system on the ETA portal to receive a Client ID and Client Secret, and enter them under Accounting ‣ Configuration ‣ Settings (ETA E-Invoicing Settings).
2. Complete the company's tax ID and address, the branch with its ETA activity code, customer tax details, and product barcodes and units.
3. Give each person who signs invoices a USB signing key.
4. Install a local proxy (the Odoo installer's IoT option) to bridge the USB key and the database, then link the key in Accounting.

The page does not state which edition includes the e-invoicing integration; confirm with Odoo or your partner.

Other garment-exporting countries

Turkey, Pakistan, Bangladesh, India, Vietnam, Morocco, Tunisia and others each have their own invoicing, VAT and export-incentive rules. We have not verified Odoo's coverage for them in this guide. Check Odoo's fiscal localisation list for your version, ask the partner which statutory reports they have delivered before, and test an e-invoice end to end in staging before go-live.

Factories in free zones or under temporary admission often report the import and re-export of materials to customs. Odoo stock moves carry the quantities, but the report format is local and usually custom.

23In what order should you configure Odoo for a garment factory?

Configure Odoo for a garment factory from the ledger outward: company, currencies and taxes first, then units, variants and lots, then product categories and costing, then warehouses and routes, then manufacturing, subcontracting and quality, and only then the products themselves. Each step depends on the one before it; loading products before units and categories are final means reloading them.

The menu paths below come from the Odoo 18 documentation. Odoo 17 and 19 are close, but labels move between versions, and Odoo 19 changed units of measure. Check each path on the version you deploy.

Two product-level switches complete the setup. A product that is made in the factory needs the Manufacture route on its Inventory tab, and a fabric needs "By Lots" in its tracking field. Both are easier to set in the import file than by hand.

24Which custom Odoo modules does an apparel implementation usually need?

An apparel Odoo implementation that keeps operations inside Odoo usually needs between a handful and a dozen custom modules, covering fabric units, lot attributes, size consumption, cutting control, packs, sampling, AQL, letters of credit and buyer documents. The list below is from implementation practice; the names are descriptive, not real packages. Look for maintained modules on the Odoo Apps store or from the Odoo Community Association before writing your own, and check each one against your version.

Every module in the table is code someone must port at each Odoo upgrade. That is the real cost of keeping operations inside Odoo, and it recurs.

25Should you use Odoo Studio or custom modules for apparel changes?

Use Odoo Studio for simple fields, views and automations on your own records, and write business logic such as unit conversion, size consumption and AQL as version-controlled modules. Studio is an Enterprise tool for building fields, views and automation rules without code.

From practice: Studio changes on core models such as the sales order, the stock move and the BoM make upgrades harder, because they are not reviewed and versioned like code. Keep a register of every Studio change, with its owner and reason, and move anything that holds logic into a module.

26Which systems does an Odoo apparel implementation integrate with?

An Odoo apparel implementation typically connects to a PLM or tech-pack system, a shop-floor system, EDI with retailers, banks, and an operations layer; each connection needs one owner per field and links stored on permanent ids. The table shows the usual source of truth for each kind of record, based on general practice.

Rules for every connection

Four rules prevent most integration faults. They apply whether the other side is a PLM, a floor system or an operations layer.

• Link on Odoo's integer id or an external ID, never on an order reference or product code a user can edit.
• One writer per field. If two systems can change the same quantity, one of them is wrong without knowing it.
• Show disagreements to a person. When the other system says something different, put it on a review list; never overwrite silently.
• Make receivers safe to call twice, so a retried message does not create a second purchase order.

Odoo's API choice depends on the version; section 34 covers it. Odoo's pricing page lists external API access under its Custom plan at the time of checking; confirm what your subscription includes before designing an API integration, and consider a file exchange if it is not included.

27How do you migrate apparel data into Odoo?

Migrate only open and active apparel data into Odoo (active styles, open orders, open purchase orders and stock by lot), load it in dependency order with External IDs, and have each department head sign off the loaded figures. History stays in the old system or an archive. Odoo's import tool accepts CSV and Excel files, offers templates for common records, and uses the External ID column so that re-importing the same file updates records instead of duplicating them.

Load order

Each object depends on the ones above it. Load and check each level before starting the next.

The cut-off rule

A cut-off rule states the exact moment after which every transaction is entered in Odoo and not in the old system. Write it as a date and time, name what happens to documents in flight (a truck at the gate, an inspection half done), and stop receiving into the old system at that moment. Stock is counted at the cut-off and loaded as it was counted, not as the old system said.

Cleansing

Clean data before it is loaded, never after. The usual work in an apparel migration is listed below.

• Merge duplicate suppliers and materials ("Navy Jersey 180", "Jersey 180 NVY").
• Retire styles with no order in two seasons.
• Give every fabric one purchase unit, and every roll in stock its lot.
• Map old size labels to the new attribute values, one scale at a time.
• Split any "open" order line that is already partly delivered into delivered and open quantities.

External ID,Product Template,Size,Internal Reference,Sales Price
p2041_nvy_s,Men's piqué polo P-2041 Navy,S,P2041-NVY-S,4.26
p2041_nvy_m,Men's piqué polo P-2041 Navy,M,P2041-NVY-M,4.26
p2041_nvy_l,Men's piqué polo P-2041 Navy,L,P2041-NVY-L,4.26
p2041_nvy_xl,Men's piqué polo P-2041 Navy,XL,P2041-NVY-XL,4.26
p2041_nvy_xxl,Men's piqué polo P-2041 Navy,XXL,P2041-NVY-XXL,4.26

Order,Product,Quantity,Unit Price,Subtotal
SO-P2041,p2041_nvy_s,300,4.26,1278.00
SO-P2041,p2041_nvy_m,750,4.26,3195.00
SO-P2041,p2041_nvy_l,900,4.26,3834.00
SO-P2041,p2041_nvy_xl,750,4.26,3195.00
SO-P2041,p2041_nvy_xxl,300,4.26,1278.00

Open PO:  P00457, navy jersey 180 GSM, 925 kg ordered, 0 kg received
Stock:    buttons 15 mm navy, 9,504 pcs, location WH/Stock, no lot

Sign-off

Each owner signs a one-page check of their data: record counts against the old system, totals (stock value, open order value, open payables) and five records picked at random and checked on screen. A migration with no signatures is a migration nobody owns when the first figure is wrong.

28How should you test an Odoo apparel implementation end to end?

Test an Odoo apparel implementation with end-to-end scenarios that follow one real order from the buyer's PO to cash, run by the factory's key users on migrated data, each step with an expected result written down before the test starts. Testing screens one by one proves the configuration works; only end-to-end scenarios prove the business works.

The 13 scenarios below cover the flows where apparel projects usually break. Run each at least twice: once by the partner to find faults, once by the key users to accept the result.

Test script: subcontract embroidery with loss

Scenario T5 proves that panels sent out, panels returned and panels lost add up. The polo's chest logo is embroidered outside, with a 1% allowance.

Test script: short shipment within tolerance

Scenario T6 proves that a short shipment inside the buyer's tolerance is invoiced on what shipped. The buyer allows ±3%; the factory ships 2,940 pieces, 30 short in M and 30 short in L.

Step 4 of T6 needs the tolerance check from section 24; standard Odoo has no quantity-tolerance field on a sales order.

29How should you train a garment factory's staff on Odoo?

Train each role only on the screens and scenarios it will use, in the local language, on the factory's own styles and orders, and have key users teach their colleagues. A merchandiser does not need the accounting menus, and a floor supervisor needs one screen that works, not an introduction to Odoo.

Train close to go-live, so that what people learn is still fresh, but not so close that there is no time to repeat a session. Keep each session short and practical: people learn by entering an order they recognise.

Floor operators and supervisors are trained on whatever captures floor output. If that is a kiosk or scanner screen, the training is minutes, not hours; if it is Odoo's office forms, expect the data never to arrive.

30What does an Odoo cut-over plan look like for a garment factory?

An Odoo cut-over plan is a day-by-day list of the steps that move the factory from the old system to Odoo: freeze, final loads, stock count, opening balances, checks and the first live transactions, each with an owner and a go or no-go point. Rehearse it once in full on a copy before the real weekend.

31When should a garment factory go live on Odoo, and how long is hypercare?

Go live between seasons, in the lowest-volume weeks and before a new wave of cutting starts, and keep the partner in close support until at least the first month-end close is done in Odoo. Hypercare is the period right after go-live when the project team stays on hand to fix issues daily.

• Timing. Avoid the weeks before a main shipment window, the month-end of the financial year, and any audit. A go-live in peak season turns every small fault into a missed shipment.
• Parallel running. A short, bounded parallel run of the books can help finance compare figures. Running the whole factory in two systems rarely works, because people keep using the one they trust.
• Duration. Practitioners commonly plan hypercare of four to eight weeks. That range is judgement, not a measured standard; the rule that matters is that nobody leaves before the first month-end close in Odoo is complete.
• Issue log. Keep one list: date, who, what happened, severity, owner, status. Review it daily in the first two weeks.
• Exit criteria. Hypercare ends when the month-end closes on time, no issue blocks shipping or invoicing, and key users handle first-line questions without the partner.

32What are the most common mistakes when implementing Odoo for apparel?

The most common mistakes in apparel Odoo projects are variant explosion, one kg-to-metre factor for every fabric, one average consumption for all sizes, dye lots not enforced at cutting, and Community chosen when Enterprise features were needed. The list below comes from implementation practice, not from Odoo's documentation.

1. Variant explosion.Too many attributes on Instantly, or attributes added after go-live.
2. One conversion factor for all fabrics.Stock value looks right while the cutting room runs short.
3. All sizes on one fabric quantity.Large sizes run short and small sizes leave surplus.
4. Dye lots not enforced at issue.Shade differences are found at final inspection instead of at cutting.
5. The manufacturing order used as the production plan.Line balancing, operation times and bundle flow need their own place.
6. Ratio cartons and buyer packing lists underestimated.Assorted cartons are not a native concept.
7. Community chosen, Enterprise features needed.Barcode, quality and shop-floor screens are rebuilt at a higher cost.
8. Heavy Studio changes on core models.Every version upgrade gets harder.
9. Multi-step subcontracting modelled as one step.Goods disappear between processors.
10. Version mixing around Odoo 19 units.A unit design or integration written for 17 or 18 is deployed on 19, where unit categories and the purchase unit are gone.
11. External API access not checked against the plan.An integration is designed before anyone confirms the subscription includes API access.

The 15 general failure modes, and how each shows up in Odoo

Apparel ERP projects fail in the same fifteen ways whatever the ERP. The table maps each one to where it appears in an Odoo project and how to prevent it.

33What must be decided before an Odoo apparel go-live?

Decide the variant model, the unit design for every fabric, the lot rules, the costing method per category, the hosting, and which system owns sampling, T&A and floor capture before go-live, because each is expensive to change once transactions exist. The full list:

• The attribute set per product category, and the variant creation mode of each attribute.
• Style as the template, or style-colour as the template with size as the only attribute.
• The unit design for every fabric and yarn, and how kg-to-metre is converted.
• Lot, serial or package for rolls; which lot fields are mandatory at receipt.
• Lot rules per operation type: new lots at receipt, existing lots only at issue.
• Costing method per product category, and which categories take landed costs.
• Hosting: Odoo Online allows no custom Python modules, Odoo.sh allows custom modules through Git, on-premise gives full control and full upgrade responsibility. Apparel projects almost always need custom modules.
• What stays in Studio and what is written as a version-controlled module.
• Which system owns sampling, T&A, planning, floor capture and quality: Odoo, custom modules or an operations layer.
• How buyer-supplied fabric is held so it never enters stock value.
• The quantity tolerance rule and who may approve a shipment outside it.
• How profitability per order is tagged.
• Whether the subscription includes the API access the integrations need.

34Which Odoo API should an apparel integration use, by version?

Build new integrations for Odoo 19 and later on the JSON-2 API, and keep an XML-RPC or JSON-RPC adapter for customers still on Odoo 17 and 18. The version decides the endpoint, the authentication and even some field names.

Odoo 19 deprecates XML-RPC and JSON-RPC, and Odoo has announced their removal in Odoo 22 and Odoo Online 21.1. Build new integrations on JSON-2 where the customer runs 19, and keep an RPC adapter for customers on 17 and 18.

• Log in as a dedicated integration user with an API key and only the access groups it needs.
• Link records by Odoo's integer id or an external ID. Never by the order reference or product code, which users can edit.
• Pin field names per version. Fields are renamed between versions and a field map written for 17 can break on 19.
• Push and pull. Since Odoo 17, automation rules can send a webhook notification. Polling on write_date stays the dependable baseline, so make the receiving side safe to call twice.

Core models an operations system reads and writes: res.partner, product.template, product.product, sale.order, purchase.order, stock.picking, stock.lot, mrp.production, mrp.bom, account.move.

Before building, confirm the customer's plan includes external API access; Odoo's pricing page lists it under the Custom plan at the time of checking. Where it does not, a scheduled file exchange is the alternative.

POST /api/v1/erp/po-status
Idempotency-Key: odoo-po-457-confirm

{"rows": [{"request_ref": "PR-1042",
           "erp_po_id": "457",
           "erp_po_number": "P00457",
           "status": "Purchase Order",
           "date": "2026-10-21"}]}

35If you don't manufacture: brands, buying agents and own-label retailers

This part is for businesses that design, source or sell garments while factories make them: brands and wholesalers, buying agents and buying houses, and retailers developing their own label. They need Odoo for purchasing, landed cost, selling and the books, and they can skip most of the manufacturing setup in Parts 3 and 4.

The polo order in this guide looks different from their side of the table. The factory sees 3,000 polos to make. A brand sees 3,000 polos to buy at USD 4.26 FOB, bring into its warehouse and sell to retailers. A buying agent sees an order it placed for a client, which it must follow through samples, production and inspection, and on which it earns a commission. Neither of them cuts fabric, so neither needs size-graded BoMs, work centers or dye-lot rules at cutting. Both still meet the wall described in section 2, because their hardest work also happens before and around the transaction.

One distinction decides the whole Odoo design for these businesses: whether the business takes ownership of the goods. A brand and an own-label retailer do, so they need stock, landed cost and payables. A buying agent does not, so for the agent Odoo is an invoicing and accounting system and little else. When people search for an "ERP for fashion brands" or an "ERP for clothing brands", they usually mean the first case; "buying house ERP" and "sourcing agent software" usually mean the second, where the real need is order follow-up across factories.

36Which Odoo apps does a fashion brand or buying agent need, and which can it skip?

A brand needs Odoo Purchase, Inventory, Sales and Accounting; a buying agent usually needs only Sales or Invoicing and Accounting; neither needs work centers, routings or the manufacturing setup a factory builds. The table is our recommendation from implementation practice; confirm the plan and edition against the pricing page before quoting.

Buying from factories on FOB and CMT terms

A brand buying finished garments on FOB terms raises an Odoo purchase order to the factory for the finished style, one line per colour and size variant, and pays the factory's vendor bill. The style and its variants are set up exactly as in section 11, but the product carries the Buy route instead of Manufacture. Odoo documents grid entry on sales orders; on purchase orders it is not documented as a core feature, and third-party apps add it, so a brand ordering 25 sizes and colours per style should test how its buyers will key a purchase order.

An Incoterm, such as FOB, can be set on invoices and vendor bills in the Other Info tab, with an Incoterm location, per Odoo 18's Incoterms page. The Incoterm tells finance who pays the freight and insurance after the goods leave the factory, which decides which landed costs the brand must add.

When the brand buys the fabric itself and pays a factory only to cut and sew (CMT), the brand's fabric goes to the factory and garments come back. In Odoo that is the resupply or dropship subcontracting flow from section 17, which is part of the Manufacturing app: install it for the subcontracting BoM and leave work centers and routings off. Where the factory ships straight to a retailer, Odoo's documented dropship route turns a sales order into a request for quotation to the vendor, so the goods never enter the brand's warehouse.

Brands commonly pay a factory a deposit before production. Odoo's documented down-payment flow is on the sales side (section 21); how a deposit to a factory is recorded and later matched to the vendor bill is a design point for finance. Import letters of credit opened for a factory need the same custom record as the export credits in section 21, because Odoo has no letter-of-credit object.

How do fashion brands calculate landed cost in Odoo?

A brand calculates landed cost in Odoo the same way a factory does for fabric: each import charge is a Service product flagged "Is a Landed Cost", applied to the receipt of the garments with a split method, and the garment's product category must use AVCO or FIFO. The documented split methods are Equal, By Quantity, By Current Cost, By Weight and By Volume (section 18).

The difference for a brand is the category. A factory usually holds finished garments at standard cost, but landed costs apply only to AVCO or FIFO categories, so a brand that imports garments should put them in an AVCO or FIFO category from the start.

Selling wholesale to retailers

A brand sells wholesale on Odoo sales orders, and the variant grid lets a sales team key a retailer's order by colour and size on one screen (section 11).

Large retailers usually trade by EDI: the purchase order (850), the advance ship notice (856) and the invoice (810). We did not find retail EDI among the standard apps in Odoo's documentation. Plan for a third-party connector or an EDI provider, and check that it supports your Odoo version and each retailer's rules.

Retailers also deduct chargebacks for late delivery, label errors or a wrong ship notice. Record each accepted deduction as a credit note against the invoice: in Odoo 18, the Credit Note button on a posted customer invoice opens a dialog with a Reason field, which is where the chargeback reason goes. Use one fixed list of reasons, so that finance can see whether the brand loses money to lateness, labels or ship notices. A deduction the brand disputes stays open on the invoice until it is settled.

Can Odoo handle a buying agent's commission?

Yes. A buying agent invoices its commission in Odoo as a service product on a customer invoice to the buyer, with no stock, no receipt and no vendor bill for the goods. Create a service product such as "Buying commission" in an income account, invoice it in the buyer's currency, and let multi-currency book any exchange difference when the buyer pays.

Commission is often earned on the shipped value. Agree the basis with each buyer and write it into the invoice description. Some agents are paid by the factory instead of the buyer; then the same service invoice goes to the factory. Either way, the agent never owes the factory for the goods, so Odoo holds no payable for them.

37What does Odoo handle poorly for brands and buying agents?

Odoo handles the transactions of a brand or agent well, and handles poorly the work that decides whether those transactions go right: development and sampling with many factories, T&A across factories, following production that happens elsewhere, inspections at the vendor, and one status for each order across many factories and buyers. These gaps are larger for a brand than for a factory, because none of this work happens in the brand's own building.

From practice, this is why many brands and buying houses keep Odoo lean and run order follow-up in a separate tool. It is the same answer as for a factory: the ERP keeps the books, and a system built for the work runs the work.

38How does MerchandiserOS fit a brand or buying agent on Odoo?

MerchandiserOS runs a brand's or buying agent's development, samples and approvals, T&A, the orders placed with factories, sourcing, the planning view across subcontracted factories, quality inspections and shipping follow-up, while Odoo keeps the books. It is the same split as for a factory (section 39), seen from the buying side, and it suits private label sourcing as much as a brand's own collection.

MerchandiserOS offers workspace set-ups for a Brand and a Buying agent alongside the factory set-ups, so the screens start from how that business works.

The two connect the same way as for a factory: through the MerchandiserOS ERP API or a file exchange. A person approves every change that comes back from Odoo, and money amounts stay in Odoo. Retail back-office work (stores, point of sale, allocation to stores and open-to-buy planning) is outside MerchandiserOS's scope. A retailer keeps that in its retail systems, and MerchandiserOS covers the sourcing and follow-up up to the goods leaving the factory.

·Glossary of apparel and Odoo terms

Short definitions of the apparel and Odoo terms used in this guide.

AQL

Acceptance quality limit: an inspection method that checks a random sample from a lot and accepts or rejects the lot on the number of defects found, using ISO 2859-1 tables.

AVCO

Average cost: an Odoo costing method that values stock at the running average of receipts.

BoM

Bill of materials: the list of components and quantities to make one product. In Odoo, it can also list operations and by-products.

CM, CMT

Cut and make, or cut, make and trim: the labour charge for making a garment, and a factory model where the buyer supplies the fabric and the factory charges only for making.

Colourway

One colour version of a style, with its own fabric shade and trims.

Cut-over

The planned switch from the old system to Odoo, around a fixed cut-off moment.

Down payment

An invoice for part of a confirmed sales order, deducted from the final invoice.

DUPRO

During-production inspection, done once part of the order is packed.

Dye lot

A batch of fabric dyed together; pieces from different dye lots can differ in shade and must not be mixed in one garment.

ECO

Engineering change order: Odoo PLM's record for revising a BoM through approval stages.

Ex-factory

The date goods leave the factory for shipment.

External ID

An import key in Odoo that lets the same file be imported again to update records instead of duplicating them.

FIFO

First in, first out: an Odoo costing method that values stock at the cost of the oldest receipts first.

FOB

Free on board: the price of goods loaded at the port of shipment; in garment trade, the usual quoted price per piece.

GSM

Grams per square metre: the weight of fabric.

Hypercare

The period after go-live when the project team fixes issues daily.

Lab dip

A small dyed fabric sample sent to the buyer to approve a shade before bulk dyeing.

Landed cost

Every cost of bringing goods to the factory beyond the supplier's price: freight, insurance, duty, clearing, bank charges.

Letter of credit (LC)

A bank's promise to pay an exporter when documents matching the credit's terms are presented.

Marker efficiency

The share of fabric in a cutting marker that ends up in garment pieces.

MO

Manufacturing order: Odoo's order to make a quantity of a product from its BoM.

POM

Points of measure: the garment measurements in a tech pack, with a tolerance per size.

PP sample

Pre-production sample: a garment in bulk fabric and trims that the buyer approves as the reference for production.

Product template, variant

In Odoo, the template is the style; each variant is one combination of attribute values, such as navy, size L.

Ratio pack

A pack or carton holding sizes in a fixed ratio, for example 1 S, 2 M, 2 L, 1 XL.

Shade band

A set of approved shade references for a fabric colour, used to judge each new lot.

SMV

Standard minute value: the time a trained operator needs for one operation at a normal pace.

Size/colour matrix

A grid of colours by sizes used to enter or show order quantities for each combination.

Strike-off

A sample of a print or embroidery on the actual fabric, approved before bulk.

T&A calendar

Time and action calendar: an order's milestones with planned dates worked back from ex-factory, actual dates and owners.

TOP sample

Top of production: the first bulk pieces, checked against the PP sample.

UCP 600

The ICC's rules for documentary credits, which most letters of credit follow.

Work center

In Odoo, a place where operations run, with working hours, efficiency and cost per hour.

·Checklists: an Odoo apparel implementation on one page

The checklists below repeat the decisions and checks from each part of this guide, in project order.

Discovery

Discovery is complete when every item below is ticked.

• Business type settled for each buyer: CMT, full package, or both.
• One decision owner named for each area.
• One workshop per department, walking a real recent order.
• All 52 fit-gap lines answered with evidence, decision and owner.
• Architecture decided: what Odoo owns, what runs in an operations layer.
• Edition, plan, hosting and API access confirmed against the fit-gap.

Design

Design is complete when every item below is decided and written down.

• Product categories with costing method and valuation; landed-cost categories on AVCO or FIFO.
• Attribute set and creation modes locked; code pattern agreed.
• Unit design per fabric and yarn, for the exact Odoo version.
• Lot as dye lot; lot rules per operation type; roll design chosen.
• Size consumption source decided.
• Work centers, operations and minutes; what stays in planning outside Odoo.
• Subcontract chains modelled step by step.
• Inspection points, AQL plan source and override rights.
• Carton rules and buyer documents per buyer.
• Currencies, down payments, LC records, chargeback reasons, e-invoicing.

Build, data and testing

Build, migration and testing are complete when every item below is proven on the go-live version.

• Configuration done in dependency order, on the go-live version.
• Custom modules listed with owners and upgrade plan; Studio changes registered.
• Integrations link on permanent ids, with one writer per field.
• Migration loaded in order, with a cut-off rule and signed totals.
• All 13 end-to-end scenarios passed by key users.

Go-live

Go-live is ready when every item below is in place.

• Training done per role, on the factory's own orders.
• Cut-over rehearsed once in full.
• Go-live date between seasons, away from year-end and audits.
• Go or no-go point and fall-back defined.
• Hypercare runs at least until the first month-end close in Odoo.

·Sources

Odoo documentation pages were checked on 26 September 2026 against the version named. Menu paths are from the Odoo 18 documentation unless stated.

1. Odoo 18 documentation, Product variants — odoo.com
2. Odoo 18 documentation, Order product variants (grid entry) — odoo.com
3. Odoo 18 documentation, Manufacturing with product variants — odoo.com
4. Odoo 18 documentation, Multilevel BoMs — odoo.com
5. Odoo 18 documentation, Configure a manufacturing product — odoo.com
6. Odoo 18 documentation, Work centers — odoo.com
7. Odoo 18 documentation, By-products — odoo.com
8. Odoo 18 documentation, Subcontracting (enabling) — odoo.com
9. Odoo 18 documentation, Basic subcontracting — odoo.com
10. Odoo 18 documentation, Subcontracting resupply — odoo.com
11. Odoo 18 documentation, Shop Floor overview — odoo.com
12. Odoo 18 documentation, Engineering change orders (PLM) — odoo.com
13. Odoo 18 documentation, Units of measure — odoo.com
14. Odoo 19 documentation, Units of measure — odoo.com
15. Odoo 18 documentation, Lot numbers — odoo.com
16. Odoo 18 documentation, Packages — odoo.com
17. Odoo 18 documentation, Three-step receipts — odoo.com
18. Odoo 18 documentation, Using inventory valuation — odoo.com
19. Odoo 18 documentation, Landed costs — odoo.com
20. Odoo 18 documentation, Quality control points — odoo.com
21. Odoo 18 documentation, Down payments — odoo.com
22. Odoo 18 documentation, Multi-currency system — odoo.com
23. Odoo 18 documentation, Credit notes and refunds (Credit Note button, Reason field) — odoo.com
24. Odoo 18 documentation, Incoterms on invoices and bills — odoo.com
25. Odoo 18 documentation, Dropshipping — odoo.com
26. Odoo 18 documentation, Egypt fiscal localisation — odoo.com
27. Odoo 18 documentation, Export and import data — odoo.com
28. Odoo 18 documentation, Hosting — odoo.com
29. Odoo 19 documentation, External JSON-2 API — odoo.com
30. Odoo 19 documentation, External RPC API (deprecation) — odoo.com
31. Odoo 17 documentation, Automation rules and webhooks — odoo.com
32. Odoo editions (Community and Enterprise comparison) — odoo.com
33. Odoo pricing — odoo.com
34. Odoo forum, variants recreated when an attribute is added — odoo.com
35. ISO 2859-1, Sampling procedures for inspection by attributes — iso.org
36. AQL tables and acceptance numbers — qima.com · tetrainspection.com · inspection levels: qualityinspection.org
37. UCP 600, documentary credits — uscib.org · tradefinanceglobal.com
38. EDI transaction sets — 1edisource.com · celigo.com
39. ERPNext repository and licence — github.com
40. ERPNext item variants — docs.frappe.io
41. ERPNext issue #54715, subcontracting and template BOM — github.com · issue #41950, manufacturing with many variants — github.com
42. ERPNext version 16 — frappe.io · Landed Cost Voucher — docs.frappe.io
43. Frappe REST API and token authentication — docs.frappe.io · docs.frappe.io

Corrections. Odoo changes between versions, and a menu path or a feature boundary can move in a single release. If you find a statement here that your version contradicts, report a correction with the version and the page you checked; we correct the guide and note the change and its date at the top of this section. We re-check the Odoo facts in this chapter at least once a year and after each major Odoo release.

Odoo is a trademark of Odoo S.A., used here only to name the product. This guide is not endorsed by Odoo S.A. ERPNext and Frappe are trademarks of their owners. Garment.io is named because MerchandiserOS integrates with it; this guide is not endorsed by Garment.io.