Odoo 19 for Fashion & Apparel:
Variant Management, Size Grids & Seasonal Planning

Your SKU Count Just Exploded and Your ERP Wasn't Built for It

A single garment style in fashion doesn't stay a single product for long. One women's cotton blouse becomes 5 colors × 7 sizes = 35 SKUs. Add a second fabric option and you're at 70. Multiply by 120 styles per seasonal collection and your catalog has 8,400 active variants — before accounting for last season's carryover styles that are still selling.

Generic ERPs handle this poorly. They either flatten variants into independent products (making size-run reorders impossible) or bolt on attribute matrices as an afterthought (creating performance bottlenecks at 10,000+ variants). Fashion companies end up managing size grids in spreadsheets, seasonal buy plans in Excel, and warehouse allocation in emails. The ERP becomes a bookkeeping system instead of an operational backbone.

Odoo 19 handles fashion natively — if you configure it correctly. This guide covers the complete setup: product variant architecture for color/size matrices, size grid templates that enforce consistent sizing across categories, seasonal collection planning with PLM, multi-warehouse allocation for retail and wholesale channels, ecommerce integration with variant selectors, and returns management for size exchanges. Every configuration is drawn from live fashion deployments.

Size Grid Templates: Enforcing Consistent Sizing Across Product Categories

A fashion catalog doesn't have one size range — it has many. Women's tops run XS through XXL. Denim runs 24 through 36 (waist) with inseam options. Footwear runs EU 35 through 46. Without size grid templates, product managers manually assign size values to every new product, leading to inconsistencies: one product uses "Extra Small" while another uses "XS", and your ecommerce filter shows both as separate options.

from odoo import models, fields, api


class FashionSizeGrid(models.Model):
    _name = 'fashion.size.grid'
    _description = 'Size Grid Template'

    name = fields.Char(required=True)  # e.g. "Women Tops"
    category = fields.Selection([
        ('tops', 'Tops & Blouses'),
        ('bottoms', 'Bottoms & Pants'),
        ('dresses', 'Dresses'),
        ('footwear', 'Footwear'),
        ('accessories', 'Accessories'),
    ], required=True)
    size_line_ids = fields.One2many(
        'fashion.size.grid.line', 'grid_id',
        string='Size Lines'
    )
    product_categ_id = fields.Many2one(
        'product.category',
        string='Default Product Category'
    )

    def action_apply_to_template(self, product_tmpl):
        """Apply this size grid to a product template.
        Creates the attribute line with all grid sizes.
        """
        size_attr = self.env.ref(
            'fashion_size_grid.attribute_size'
        )
        existing = product_tmpl.attribute_line_ids.filtered(
            lambda l: l.attribute_id == size_attr
        )
        size_values = self.size_line_ids.mapped(
            'attribute_value_id'
        )
        if existing:
            existing.write({
                'value_ids': [(6, 0, size_values.ids)]
            })
        else:
            product_tmpl.write({
                'attribute_line_ids': [(0, 0, {
                    'attribute_id': size_attr.id,
                    'value_ids': [(6, 0, size_values.ids)],
                })]
            })


class FashionSizeGridLine(models.Model):
    _name = 'fashion.size.grid.line'
    _description = 'Size Grid Line'
    _order = 'sequence'

    grid_id = fields.Many2one(
        'fashion.size.grid', ondelete='cascade'
    )
    sequence = fields.Integer(default=10)
    attribute_value_id = fields.Many2one(
        'product.attribute.value', required=True,
        domain="[('attribute_id.attribute_category',"
               " '=', 'size')]"
    )
    measurement_chest = fields.Float('Chest (cm)')
    measurement_waist = fields.Float('Waist (cm)')
    measurement_hips = fields.Float('Hips (cm)')
    measurement_length = fields.Float('Length (cm)')

The measurement fields on each grid line serve a dual purpose: they populate the size chart on your ecommerce product page and they feed into quality control checks during manufacturing. When a QC inspector measures a finished garment, Odoo compares the measurement against the grid template tolerance — flagging items that fall outside ±1.5cm of spec.

Size Conversion Tables

International customers need size equivalents. A size "M" in the US maps to "38" in Italy, "10" in the UK, and "170/88A" in China. Store conversions on the grid line and surface them on the ecommerce product page:

Seasonal Collection Planning: From Line Sheet to Purchase Order

Fashion operates on a seasonal calendar: Spring/Summer (SS) and Autumn/Winter (AW), each planned 6-9 months in advance. The planning cycle starts with a line sheet (the collection catalog), progresses through buy planning (how many units per style/color/size), and ends with purchase orders to manufacturers. Odoo doesn't have a native "season" concept, but the data model supports it with minimal customization.

class FashionSeason(models.Model):
    _name = 'fashion.season'
    _description = 'Fashion Season'
    _order = 'year desc, season_type desc'

    name = fields.Char(compute='_compute_name', store=True)
    season_type = fields.Selection([
        ('SS', 'Spring/Summer'),
        ('AW', 'Autumn/Winter'),
        ('CR', 'Cruise/Resort'),
        ('PF', 'Pre-Fall'),
    ], required=True)
    year = fields.Integer(required=True, default=2026)
    date_design_start = fields.Date('Design Start')
    date_sample_deadline = fields.Date('Sample Deadline')
    date_buy_open = fields.Date('Buy Window Opens')
    date_buy_close = fields.Date('Buy Window Closes')
    date_delivery_start = fields.Date('First Delivery')
    date_delivery_end = fields.Date('Last Delivery')
    date_markdown_start = fields.Date('Markdown Start')
    state = fields.Selection([
        ('design', 'In Design'),
        ('sampling', 'Sampling'),
        ('buying', 'Buy Open'),
        ('production', 'In Production'),
        ('delivering', 'Delivering'),
        ('selling', 'In Season'),
        ('markdown', 'Markdown'),
        ('archived', 'Archived'),
    ], default='design')
    product_tmpl_ids = fields.Many2many(
        'product.template',
        string='Collection Styles'
    )

    @api.depends('season_type', 'year')
    def _compute_name(self):
        for rec in self:
            rec.name = '%s %s' % (
                rec.season_type or '', rec.year or ''
            )

The season model tracks the eight key milestone dates that govern the fashion calendar. Each date triggers downstream workflows:

• Design Start → Sample Deadline: PLM workflows for tech packs, fabric sourcing, and fit samples
• Buy Window Open → Close: Sales team enters pre-orders from wholesale accounts using size-run templates
• Production → Delivery: Purchase orders to manufacturers with delivery windows aligned to the season calendar
• Markdown Start: Triggers automated pricelist rules that apply progressive discounts (30% → 50% → 70%) based on remaining inventory levels

Size-Run Buy Planning

Wholesale buyers don't order "50 units of the blue blouse." They order size runs — a ratio that distributes units across sizes based on historical sell-through. A typical women's tops ratio is 1:2:3:3:2:1 (XS:S:M:L:XL:XXL). A buy of 120 units at this ratio becomes: XS=10, S=20, M=30, L=30, XL=20, XXL=10.

PLM for Fashion: Managing the Design-to-Production Pipeline

Odoo 19's PLM module tracks product lifecycle stages, but fashion needs an extended workflow: concept → tech pack → first sample → fit review → production sample → approved → in production. Each stage has specific deliverables, approval gates, and document requirements.

The tech pack is the central document in garment manufacturing — a detailed specification covering fabric, trims, construction, measurements, colorways, and packaging. In Odoo, attach tech packs as versioned documents on the product template using PLM's Engineering Change Order (ECO) workflow:

• Fabric & Trim BoM: Bill of materials listing shell fabric yardage, lining, buttons, zippers, labels, and hang tags — all with supplier and lead time data
• Construction Spec: Stitch type, seam allowance, wash instructions — attached as a PDF on the ECO
• Measurement Spec: Linked to the size grid template, with tolerances for QC inspection
• Colorway Approval: Lab-dip references stored as attachments with Pantone codes in a custom field

<record id="view_eco_form_fashion"
        model="ir.ui.view">
  <field name="name">mrp.eco.form.fashion</field>
  <field name="model">mrp.eco</field>
  <field name="inherit_id"
         ref="mrp_plm.mrp_eco_form_view"/>
  <field name="arch" type="xml">
    <xpath expr="//field[@name='tag_ids']"
           position="after">
      <field name="season_id"
             options="{'no_create': True}"/>
      <field name="tech_pack_status"
             widget="statusbar"
             statusbar_visible=
               "concept,techpack,sample,approved"/>
    </xpath>
    <xpath expr="//page[@name='misc']"
           position="inside">
      <group string="Garment Specifications">
        <field name="pantone_ref"/>
        <field name="fabric_composition"/>
        <field name="target_fob_price"/>
        <field name="target_retail_price"/>
        <field name="target_margin_pct"/>
      </group>
    </xpath>
  </field>
</record>

The margin fields on the ECO are critical for fashion buying. Buyers evaluate each style's viability based on Initial Markup (IMU): the ratio of retail price to FOB cost. A healthy IMU for mid-market fashion is 2.5x–3.0x. By embedding FOB target cost and retail price on the ECO, the buying team can filter styles by margin during the line review — killing underperforming styles before they consume production capacity.

Multi-Warehouse Allocation: Distributing Inventory Across Retail, Wholesale & Ecommerce

Fashion companies operate multiple channels with competing inventory needs: flagship stores need visual merchandising quantities (all sizes, all colors on the floor), wholesale accounts need bulk allocation for pre-booked orders, and ecommerce needs a shared pool for long-tail availability. Without a structured allocation model, the warehouse team plays favorites — and the ecommerce channel always loses.

Odoo 19's multi-warehouse and inter-warehouse transfer features handle this with a hub-and-spoke model:

Configure replenishment rules per variant per warehouse for retail stores. A flagship store might stock 2 units of each size for a core style (min=1, max=2), while a smaller store stocks only the core size range M–XL. When a sale depletes stock below the minimum, Odoo generates an internal transfer from the Central DC automatically.

The ecommerce warehouse uses the remaining DC stock as a virtual available pool. Configure it with route_ids that pull from Central DC on demand. This means every unit not allocated to wholesale or retail is automatically available for ecommerce orders — no manual allocation spreadsheets.

Ecommerce Integration and Size-Based Returns Management

Fashion ecommerce has a unique problem: return rates of 30-40%, driven primarily by size and fit issues. Generic return workflows treat every return as a refund. Fashion needs size exchanges as a first-class operation — keeping the revenue while shipping the correct size.

Configure the Odoo 19 ecommerce product page to minimize size-related returns before they happen:

• Size chart integration: Pull measurement data from the size grid template and display it as an expandable table on the product page
• Fit recommendation engine: A simple computed field that maps the customer's saved measurements (from their portal profile) to the nearest size in the grid
• Color-accurate photography: Use the color_hex field to generate swatch selectors that match product photography exactly
• Stock-by-size visibility: Show "Only 2 left" per size variant to reduce cart abandonment on popular sizes

Size Exchange Workflow

When a customer requests a return for "wrong size," the return workflow should default to exchange rather than refund. The exchange creates a new delivery order for the correct size variant while the return receipt processes the original:

class SaleReturnWizard(models.TransientModel):
    _name = 'fashion.return.wizard'
    _description = 'Fashion Size Exchange Wizard'

    sale_order_id = fields.Many2one('sale.order')
    original_product_id = fields.Many2one(
        'product.product', string='Original Item'
    )
    exchange_product_id = fields.Many2one(
        'product.product', string='Exchange For',
        domain="[('product_tmpl_id', '=',"
               " original_tmpl_id)]"
    )
    original_tmpl_id = fields.Many2one(
        related='original_product_id.product_tmpl_id'
    )
    return_reason = fields.Selection([
        ('too_small', 'Too Small'),
        ('too_large', 'Too Large'),
        ('wrong_fit', 'Wrong Fit/Style'),
        ('defective', 'Defective'),
        ('other', 'Other'),
    ], required=True)

    def action_process_exchange(self):
        self.ensure_one()
        # Create return picking for original
        return_picking = self.sale_order_id \
            ._create_return_picking(
                self.original_product_id
            )
        # Create new SO line for exchange item
        if self.exchange_product_id:
            self.env['sale.order.line'].create({
                'order_id': self.sale_order_id.id,
                'product_id':
                    self.exchange_product_id.id,
                'product_uom_qty': 1,
                'price_unit': 0,  # No charge
                'name': 'Size Exchange: %s -> %s'
                    % (
                    self.original_product_id
                        .display_name,
                    self.exchange_product_id
                        .display_name,
                ),
            })
            self.sale_order_id.action_confirm()
        # Log return reason for analytics
        self.env['fashion.return.reason'].create({
            'product_tmpl_id':
                self.original_tmpl_id.id,
            'from_size': self.original_product_id
                .product_template_attribute_value_ids
                .filtered(
                    lambda v: v.attribute_id
                    .attribute_category == 'size'
                ).name,
            'reason': self.return_reason,
            'date': fields.Date.today(),
        })
        return {
            'type': 'ir.actions.act_window',
            'res_model': 'stock.picking',
            'res_id': return_picking.id,
            'view_mode': 'form',
        }

The fashion.return.reason model is deceptively important. When you aggregate return reasons by product template and size over a season, patterns emerge: if 60% of returns for style DRS-042 are "Too Small," the size chart is wrong or the factory is cutting below spec. This data feeds back into the size grid measurements and QC tolerances — closing the loop between returns and production.

3 Fashion ERP Mistakes That Kill Sell-Through Rates

Optimization Metadata