The initial Delivery created at the time of creating SO can be modified. Delete the generic product and add the line for the specific variant directly on the delivery.

On validation, the SO would now be updated with the variant line. Since delivery is of variant the invoicing would be for variant product and not the generic one, if product invoicing policy is set to delivered qty.

The SO would however need to updated with the unit price as well.

Optimal way would be to modify the SO - change the generic product’s order qty to ‘0’ while adding the variant  product as an additional line. Delivery Order would update with the variant to deliver.

When adding any product with variants to a quotation or sales order, Odoo automatically displays a Product Configurator popup that requires selecting specific attribute values. odoo +2 While designed for existing products, this architecture could be extended for the user's use case.

Use blanket order modules to establish framework agreements at the template level, then create release orders when customers request delivery with specific variants.

Workflow:

1. Create blanket order referencing product template, agreed quantities, and pricing
2. Collect deposit against blanket order (custom field/logic needed)
3. When customer requests delivery, create release SO with specific variant
4. MTO triggers manufacturing for the release order
5. Final invoice generated on delivery

Pros: Leverages existing modules; cleaner separation of agreement vs. execution

Cons: Requires custom deposit handling on blanket orders; two-document workflow adds complexity; variant must still be specified at release order creation (not at picking)

Recommended modules: Sales Agreements (CLuedoo) or OCA sale_blanket_order + custom integration

Add a product_template_id field to sales order lines allowing orders with templates, then resolve to specific variants at picking creation.

Technical changes required:

• Add product_template_id field to sale.order.line model
• Modify SO line validation to accept template-only lines
• Create wizard triggered before picking creation for variant specification
• Override _action_launch_stock_rule() to use resolved variant
• Handle invoice line creation from delivery rather than SO line

Pros: Single sales order document; variant selection happens at appropriate time

Cons: Breaks standard SO → Stock → Invoice flow; requires careful handling of partial deliveries where different lines specify variants at different times

Build a dedicated sale.call.off.order model between blanket agreements and deliveries, with complete variant specification workflow.

Architecture:

1. sale.framework.agreement – Template-level contract with deposit tracking
2. sale.call.off.order – Customer delivery request specifying variants
3. Modified picking and MO creation from call-off orders
4. Balance invoicing linked to call-off fulfillment

Pros: Purpose-built for the workflow; cleanest data model separation

Cons: Highest development effort (~80-150 hours); parallel document structure to maintain

A critical constraint for the user's MTO workflow: manufacturing orders cannot be created at the template level. Odoo +2 For products where variants share most components (the user mentions "variants generally don't require additional cost invoicing"), a single template-level BOM with variant-specific components where needed works efficiently.

Master Production Schedule (MPS) allows demand forecasting but operates at the product level, not template level. Rough-cut capacity planning without variant specification would need to aggregate manually or use work center-level capacity tracking, which is variant-agnostic.

For the stated volume of ~50 SOs/day with 10% having 5-20 partial deliveries, the system must handle potentially 25-100 partial deliveries daily. Standard Odoo's backorder functionality supports this volume, but the custom variant-specification workflow needs efficient UI—the OCA stock_picking_variant_mgmt matrix interface would help significantly.

Given the requirements and Odoo's architectural constraints, Approach 2 (template reference with picking-stage resolution) combined with OCA modules offers the best balance of development effort versus workflow fidelity.

Phase 1: Foundation (40-60 development hours)

• Install OCA sale_manual_delivery to control delivery creation timing
• Install OCA stock_picking_variant_mgmt for variant matrix on pickings
• Add product_template_id and is_template_order fields to sale.order.line
• Modify Product Configurator to allow "Order as Template" option

Phase 2: Workflow Implementation (30-50 development hours)

• Create variant specification wizard for delivery orders
• Override picking creation to require variant resolution
• Implement validation to prevent shipping without variant specification
• Handle partial deliveries with per-line variant tracking

Phase 3: Invoicing Integration (20-30 development hours)

• Configure "Delivered quantities" invoicing policy
• Ensure balance invoices reference resolved variant (for inventory valuation)
• Test down payment → delivery → balance invoice flow end-to-end
• Handle edge cases: returns, cancellations, variant changes

Total estimated development: 90-140 hours for an experienced Odoo developer

Data model changes should add fields to sale.order.line rather than creating parallel models where possible—this preserves compatibility with standard Odoo reports, analytics, and future upgrades.

Invoicing accounts need attention. Down payments use a service product with configurable income accounts. When the balance invoice references the actual variant, accounting entries should use the product category's accounts. odoo Ensure the Down Payment product's account and the variant's account align properly or configure explicit account mappings.

Testing scenarios must cover:

• Single SO line → single delivery with variant → invoice (basic)
• Single SO line → multiple partial deliveries with different variants each
• Multiple SO lines → mixed delivery timing and variants
• Deposit refund if order cancelled before variant specification
• Variant specification after partial MTO production started

Upgrade path considerations: Custom fields and overrides touching sale.order, stock.picking, and account.move models will require review with each Odoo major version upgrade. Document customizations thoroughly and prefer extending models via inheritance over direct modification.

Odoo 18 Enterprise's standard functionality cannot implement the requested sales workflow where product templates are sold with deposits and variants specified at delivery time. The platform's architecture requires variant specification at sales order creation, and this constraint flows through manufacturing and invoicing.

Custom development is unavoidable but can be scoped reasonably at 90-140 hours by leveraging OCA modules for manual delivery control and variant picking management. The most practical approach adds template-level ordering capability to sales orders with a specification wizard at picking creation, preserving standard down payment and invoicing functionality.

For organizations seeking to minimize custom code, an alternative is adapting the business process: create framework agreements (blanket orders) at the template level, then generate release orders with specific variants when delivery is requested. This requires less technical modification but introduces a two-document workflow that may not match current business practices.

No off-the-shelf module solves this problem—it represents a genuine gap in Odoo's product configuration capabilities that affects industries selling configurable products with deferred specification, including furniture, apparel, and custom manufacturing.