Before answering the questions below, read the full research repo and explore the scripts, data, and case studies in detail: https://github.com/Adapt-to-AI-B2B/aronlight-erp-research

Seven decisions before Phase 1 starts:

1. GitHub — New repo under the Aronlight org (recommended: aronlight-quoting-agent), or build inside this research repo? The research scripts (01–06) live here and can be ported directly to Django.
2. First task — We propose: Django project setup + catalog sync management command (Phase 1). Does this match how you want to start, or do you have a different entry point?
3. Stack — Confirm: Django + Vue 3 + PostgreSQL + Redis + Celery + Docker Compose. Any deviations?
4. Manel call — Do you want to be on the call with Manel when we go through Batch 1 questions, or receive answers async when they come in?
5. Timeline — When can Phase 1 start? Phase 2 is the first point where Manel's answers become relevant.
6. Agent vs. platform — We are starting with a single quoting agent for Aronlight. At what point does it make sense to think about this as a platform — one that handles multiple types of agents, potentially across clients? Should the architecture account for that from Phase 1, or do we build lean and revisit?
7. AI best practices alignment — We will share a Best Practices Guide for AI systems separately (covers the maturity path from single agent to autonomous platform). When should we review it together — before Phase 1 starts, or once the first version is running?

The problem: Aronlight receives ~3,000 RFQ emails per month. Half list competitor product codes (Philips, iGuzzini, KATOA) with "ou equivalente." Each rep manually looks up competitor specs, finds the closest Aronlight product, and builds the quote in Odoo line by line. A complex RFQ takes 30-60 min. It is the bottleneck.

What the Adaptto AI Quoting Agent does: Takes the input — email, Excel, PDF, or image — extracts the product line items (regardless of how they are described: Aronlight SKU, Aronlight product name, competitor model, or vague description), finds the right Aronlight product for each line, and generates a draft Odoo sale.order ready for the sales rep to review and approve. The rep goes from reading the email to clicking "Create a proposal in Odoo" in under 5 minutes.

What needs to be taken into consideration: Inputs arrive in multiple formats — email body, Excel BOQ, PDF specification, or image. Each needs a different extraction path before we even start matching. Inside those inputs, customers write SKUs inconsistently ("ILAR01691", "ilar 1691", "IL-AR-01691") vs the catalog format ("ILAR-01691"). Many inputs are also BOQs (Bill of Quantities — see Q5), where one customer line expands to 2-3 Odoo order lines. All three — format handling, SKU normalisation, and BOQ expansion — affect matching accuracy before we even reach the spec comparison step.

What's been verified (this repo):

• Odoo XML-RPC API: connected, 4,324 products synced, 0 null SKUs (380 use non-standard prefixes — see Q1)
• Client matching: 100% on 7 real PT/ES company name variants
• Input parsing: tested on 19 real RFQ emails across all input types
• SKU matching: works for exact + fuzzy; spec matching for competitor refs is the remaining gap
• BOQ expansion: confirmed with real Odoo quote PDFs — 7-position RFQ → 17 lines (9 product + 8 section headers). Real expansion ~1.3× per position.
• ~47 competitor product datasheets researched and labeled as training data (cases 01–06 + 08, 12, 14, 16, 18)

The three hardest problems:

1. Competitor reference matching (~50% of volume — estimated from 19-case sample) — a subset of customers send a Philips, iGuzzini, or KATOA code and ask for an Aronlight equivalent. Others request Aronlight products directly by SKU or name — the agent handles both. For competitor refs, we need spec comparison. Wattage is not a hard filter (+11% to +140% accepted). Dimensions and IP rating are.
2. BOQ expansion — 1 customer line becomes 2-3 Odoo lines (luminaire + driver if DALI + accessory if applicable + emergency if required). The system needs to know the expansion rules per product family.
3. Catalog quality — 1,874 of 4,416 products sit under categ_id="All" with specs buried in free text. This limits automated spec matching until Manel recategorizes them.

What is a BOQ? A Bill of Quantities (BOQ) is the document an architect or contractor sends to suppliers when specifying lighting for a construction project. It lists numbered positions — one per fixture type — with a quantity, a competitor brand+model reference, and sometimes specs. Example: "Position 2 — Philips DN142B, 110 units, round recessed downlight, IP20, 3000K, ou equivalente." The BOQ is not an order; it is a specification. Aronlight's job is to propose equivalent products for each position and quote a price. A single BOQ position typically becomes 2-3 lines in Odoo (luminaire + driver + accessory).

Scope note: This is the target flow — the full system as it should work when complete. Phases 1–3 cover the top three boxes only (parse input, match client, match line item). BOQ expansion and Odoo write are Phase 4, blocked on Manel's Batch 1 answers (Q 1-8, 1-9, 1-10).

Before build, four things need design decisions not shown here: (1) where state lives between steps — Django model, Redis job, or DB row; (2) error and fallback paths for each box — what happens when Claude API fails or Odoo is unreachable; (3) what "human review" looks like in practice — UI, email notification, or Odoo task; (4) observability — every Claude call should be traced (prompt, completion, latency, cost) from day one, not added later.

  Customer email / Excel / image

            │
            ▼
  ┌─────────────────────────┐
  │  Parse input            │  Extract line items + detect format
  │  (Claude API)           │  (email / Excel / PDF / image)
  │                         │  Attachment-only → request file
  └─────────────────────────┘
            │
            ▼
  ┌─────────────────────────┐
  │  Match client           │  Email exact → VAT → fuzzy name (WRatio)
  │                         │  ≥75% auto · <75% ⚠ human confirms
  └─────────────────────────┘
            │
            ▼
  ┌─────────────────────────┐
  │  Match each line item   │  Exact SKU → alias table → fuzzy name
  │                         │  → spec match on catalog text
  │                         │  ≥90% auto · 60-89% ⚠ review · <60% ✗
  └─────────────────────────┘
            │
            ▼
  ┌─────────────────────────┐
  │  BOQ expansion          │  1 input line → N Odoo lines
  │                         │  luminaire + driver (DALI?) + accessory
  │                         │  + emergency (ILEM-?) per product family
  └─────────────────────────┘
            │
            ▼
  ┌─────────────────────────┐
  │  Human review           │  Sales rep sees flagged items, confirms
  │  (5 gates)              │  or corrects. Nothing writes to Odoo yet.
  └─────────────────────────┘
            │
            ▼
  ┌─────────────────────────┐
  │  Odoo write             │  draft sale.order + sale.order.line
  │  (on approval only)     │  position labels as line_note
  └─────────────────────────┘
            │
            ▼
       Sales rep sends
       quote to customer

Input types handled:

Django models needed:

OdooProduct      # cached catalog (sync daily via management command)

OdooPartner      # cached customers (sync daily)
ProductAlias     # short name → OdooProduct (BERG, CUBE, OTTO, PRADA, LUPO, NEXOR)
BrandLookup      # competitor brand prefix → canonical brand name (fix "OH" problem)
SkuMapping       # customer SKU / product name → Aronlight SKU register (cumulative)
RfqRequest       # inbound request: source, raw content, parsed items, status
RfqLineItem      # parsed line + match result + status (auto/review/unclear/no_match/non_automatable)
RfqOdooLine      # expanded Odoo line per RfqLineItem (1 RFQ line → N Odoo lines)

Odoo API call pattern:

• Auth once per Django request (or cache uid in Redis with 1h TTL)
• Read-only during matching; write only on explicit "Create in Odoo" action
• Daily sync: product.template + res.partner → local DB (no live API during matching)
• Sync both company_id=2 (ES) and company_id=3 (PT) — tag origin on each record
• Odoo write: sale.order + sale.order.line only after human approval

Input pipeline:

Email / Excel / Image

       ↓
   Classify input type (A/B/C/D/E/BOQ) — per-line, not per-email
       ↓
   04_input_parser.py logic (Claude API for Type B/C/D)
       ↓
   Structured items: [{description, qty, unit, sku_hint, specs, confidence}]
       ↓
   Unit normalization (m→rolls, etc.)
       ↓
   05_sku_matching.py logic (email → VAT → fuzzy name → spec match)
       ↓
   BOQ expansion: 1 line → [luminaire, driver, accessories, emergency]
       ↓
   RfqLineItem with status: auto | review | unclear | no_match | non_automatable
       ↓
   Human gate → Odoo draft sale.order

Human-in-the-loop gates (5 mandatory):

1. Client match < 75% → stop, show "new client?" prompt
2. Any unclear item → stop, show clarification question for customer
3. SKU match 60–89% → show proposed match, require sales rep confirm
4. no_match or non_automatable item → stop, route to senior sales
5. Final order → always human approval before Odoo write

Claude API usage in production:

• Type A: no Claude needed (regex SKU extraction)
• Type B: Claude for name/spec extraction from unstructured text
• Type C: Claude vision (if image) + spec comparison
• Type D: Claude for full advisory extraction
• Estimated: 60-70% of requests need Claude; ~30% (Type A) are pure code

Research skills — reference implementations of the logic you're building:

Raffaello and Giuseppe built four Claude Code skills during the research phase (in .claude/skills/ in this repo). These are not part of the Django product — they are the prompts and decision trees used to analyse the 19 cases. Riccardo does not run them; he uses them as reference implementations when writing the corresponding Django service.

The /assess-email skill in particular documents every edge case found — read it before implementing InputParserService.

A sales rep gets an RFQ email. Here's what they do in the agent from start to finish:

Screen 1 — Input

┌─────────────────────────────────────────────────────────────┐

│  Adaptto AI Quoting Agent                      Aronlight PT │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  [Paste email text]   [Upload Excel]   [Upload image/PDF]   │
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  Subject: Pedido cotação — AlpLuz — Philips refs      │  │
│  │  From: alpluz.lda@gmail.com                           │  │
│  │  ...                                                  │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
│                                          [Parse →]          │
└─────────────────────────────────────────────────────────────┘

Screen 2 — Review: client + line items

┌─────────────────────────────────────────────────────────────┐

│  Adaptto AI Quoting Agent                      Aronlight PT │
├──────────────────────────────────┬──────────────────────────┤
│  CLIENT                          │  7 items · 2 need review │
│  AlpLuz Lda  ✓ 98% match         │                          │
│  partner_id 148126               │   [Create in Odoo ▸]    │
├──────────────────────────────────┴──────────────────────────┤
│  #  Input                           Match           Status  │
│  ──────────────────────────────────────────────────────── ─ │
│  1  RS150B · 33 un · IP65 3000K     Luso 8W         ✓ auto │
│  2  DN142B · 110 un · IP20 3000K    Una II 15W      ⚠ review│
│  3  RC132V · 22 un · 300×1200mm     Painel Backlit  ✓ auto │
│  4  WL055V · 22 un · wall IP65      Fisher IP54     ⚠ review│
│                                     + Noa IP65 alt          │
│  5  WL140V · 22 un · circular       RUMU + Aro Preto ✓ auto│
│  6  WL140V · 11 un · no ring        RUMU            ✓ auto │
│  7  WT120C · 11 un · 600mm IP65     TITAN 1200      ✓ auto │
└─────────────────────────────────────────────────────────────┘

Screen 3 — Review a flagged item

┌─────────────────────────────────────────────────────────────┐

│  ← Review item 1 of 2                                       │
├─────────────────────────────────────────────────────────────┤
│  Customer wrote:  "DN142B 110 un"                           │
│  Competitor:      Philips DN142B · 9.8W · IP20 · 3000K     │
│                   round downlight · recessed                │
│                                                             │
│  Proposed match:  Una II  ILAR-01571                        │
│                   15W (+53%) · IP65/44 · 3CCT · €29.90/un  │
│                   Match score: 78%                          │
│                   ⚠ Wattage over-spec · IP upgraded         │
│                                                             │
│  [✓ Accept]  [Search catalog]  [Mark unclear]  [No match]  │
└─────────────────────────────────────────────────────────────┘

Screen 4 — Odoo preview before write

┌─────────────────────────────────────────────────────────────┐

│  Odoo Preview — AlpLuz Lda                         draft    │
├─────────────────────────────────────────────────────────────┤
│  [note]  IL01                                               │
│  ILAR-01108  Luso 8W D80 IP65           ×33    €  962.61   │
│  [note]  IL02                                               │
│  ILAR-01571  Una II 15W 3CCT IP65/44    ×110   €3,289.00   │
│  [note]  IL03                                               │
│  ILAR-02979  Painel 300×1200 Backlit    ×22    €  781.00   │
│  [note]  IL04                                               │
│  ILAR-00960  Fisher 10W IP54            ×22    €1,031.36   │
│  [note]  alternativa                                        │
│  ILAR-02683  Noa 12W 3CCT IP65          ×22    €  658.68   │
│  [note]  IL05                                               │
│  ILAR-02971  RUMU 9-16W Switch          ×22    €  517.00   │
│  ILAR-02976  Aro Bezel Preto            ×22    €   46.64   │
│  [note]  IL06                                               │
│  ILAR-02971  RUMU 9-16W Switch          ×11    €  258.50   │
│  [note]  IL07                                               │
│  ILAR-02135  TITAN 1200 IP65 36W        ×11    €  471.35   │
│  ───────────────────────────────────────────────────────    │
│  Total  €4,732.73                                           │
│                                                             │
│  [✓ Create in Odoo]    [Export PDF]    [← Back to review]   │
└─────────────────────────────────────────────────────────────┘

The Odoo preview is the real quote structure — position labels as line_note, accessories on their own line, alternatives separated by an "alternativa" note. Exactly what Aronlight's sales team produces manually today.

Findings that must be respected regardless of implementation choices:

1. Do not filter partners by customer_rank — 36% of real buyers have customer_rank=0 in staging. Use email exact match → VAT exact match → fuzzy name as the chain instead.
2. Spec matching must parse product name free text — the structured spec fields (ip_rating, dali, rated_power_w, etc.) exist in the Odoo schema but are 0% populated across all 4,416 products. There is no field-query shortcut.
3. Query both companies — company_id=2 (ES) and company_id=3 (PT). Partners are shared; sales reps sometimes create quotes in the wrong entity. Tag origin on every cached record, never filter by company during matching.
4. Do not build Phase 4 until Manel answers Q 1-8, 1-9, 1-10 — BOQ expansion rules (what drives 1→N lines, accessory bundling, driver line format) are unconfirmed. Building the wrong structure means every Odoo write produces the wrong quote.
5. Human approval before every Odoo write — no auto-create of sale.order. The agent proposes; the sales rep approves. Hard gate, not a preference.
6. ILAR- / ILDV- / ILEM- are distinct product families — never mix them in expansion logic. ILAR = luminaire, ILDV = driver (DALI projects only), ILEM = emergency unit.
7. Wattage is not a hard filter for competitor substitution — research confirmed +11% to +140% deviation accepted in real quotes. Filter first by category + dimensions + IP, rank by lm proximity. Rejecting on wattage alone produces wrong matches.
8. Product dependency rules do not exist in Odoo — they must be built — the accessory_product_ids field is almost empty (2 of 4,324 products). The system needs a configurable product dependency table (product_sku → companion_sku + type + trigger). Without it, the system can match the right luminaire but cannot generate a complete Odoo quote. Manel must supply the rules; the data model must exist before Phase 4.

These constraints come from the AI System Best Practice Guide shared separately (see Q7). The guide covers 10 maturity levels (L1–L10) and 6 architectural layers. The notes below translate the relevant parts into constraints for this specific build.

RECEIVED → PARSING → CLIENT_MATCHED → ITEMS_MATCHED → AWAITING_REVIEW → APPROVED → WRITTEN_TO_ODOO
                ↓              ↓                ↓                ↓
          PARSE_FAILED   CLIENT_NOT_FOUND   PARTIAL_MATCH    ODOO_WRITE_FAILED

Research is done. Here's the recommended build sequence, scoped to what's verified and unblocked.

What you can build now vs. what must wait for Manel

Phase 1 — Catalog sync (weeks 1–2)

Goal: Django talks to Odoo, local DB is populated, sync runs daily.

• Django project + Docker Compose (Postgres, Redis, Celery)
• odoo_client.py already exists in this repo — port to Django settings
• Management command: sync_catalog — pulls product.template + res.partner for both company_id=2 and 3
• Models: OdooProduct, OdooPartner, SkuMapping, ProductAlias, BrandLookup
• Populate ProductAlias with known short names from cases: BERG, CUBE, OTTO, PRADA, LUPO, NEXOR, LUKE, RUMU, LUSO, UNA, FISHER, NOA, TITAN — map to Odoo SKUs (ask Manel to confirm)
• Blocker: 1,874 products under categ_id="All" — needs Manel to recategorize in Odoo before sync is useful for spec matching

Phase 2 — Input parsing + client matching (weeks 3–4)

Goal: sales rep pastes an email, gets a client match and a list of extracted items.

• Port 04_input_parser.py into a Django async task (Celery + Claude API)
• Client matching service: email exact → VAT exact → fuzzy WRatio (from 03_client_matching.py)
• Models: RfqRequest, RfqLineItem
• Vue 3 UI: upload input → show client match + item list with confidence badges
• No Odoo writes yet — read only

Phase 3 — SKU matching + review UI (weeks 5–7)

Goal: each line item gets a proposed Aronlight match; sales rep can accept, reject, or reassign.

• Port 05_sku_matching.py into Django matching service
• Match pipeline: exact SKU → ProductAlias → fuzzy name → spec text-parse on raw_description
• Accumulate SkuMapping register — repeat customers get instant match
• Vue 3 review UI: line items with status badges (auto/review/unclear/no_match), accept/reject flow
• All 5 human gates wired (client match, unclear items, low-confidence SKU, no_match, final approval)
• Spec matching for Type C (competitor refs) goes here — see section below on training data

Phase 4 — BOQ expansion + Odoo write (weeks 8–10)

Goal: approved matches become a real Odoo draft sale.order.

• Model: RfqOdooLine (N lines per RfqLineItem)
• BOQ expansion rules: per product family — does it need a driver? an accessory? emergency unit?
• Odoo preview screen (Screen 4 above)
• Final approval gate → write sale.order + sale.order.line via XML-RPC
• Position labels as line_note entries, "alternativa" separator for paired candidates

Open scoping decisions — to discuss with team

These three are NOT decided. They need a call with Manel and Riccardo before Phase 1 starts.

The case studies produced 47 competitor product datasheets across 10 cases in docs/email_samples/*/research/*.md. Each one is a structured record: competitor brand + model, specs (dimensions, W, lm, K, CRI, IP, IK, driver type, mounting), and — for cases 02, 04, 06 — the correct Aronlight match is in match_summary.md.

This gives us labeled pairs: (competitor specs) → (Aronlight SKU + reasoning).

Three ways to use them:

1. Test dataset — measure accuracy before shipping

Parse all 47 datasheets into a JSON:

[

  {
    "competitor_ref": "Philips RS150B",
    "specs": {"dimensions_mm": 78, "W": 7.2, "IP": 65, "K": 3000, "mounting": "recessed", "shape": "round"},
    "correct_aronlight_sku": "ILAR-01108",
    "correct_name": "Luso 8W D80 IP65"
  },
  ...
]

Run the spec matching algorithm against all 43 before shipping. Target: ≥80% correct SKU without human intervention. Anything below is a signal to tune the scoring weights, not to ship.

2. Few-shot examples for Claude at runtime (Type C)

When a new competitor ref arrives, send 2–3 similar examples as context in the Claude prompt:

Match competitor lighting products to Aronlight catalog items.


Example 1:
  Input: Philips RS150B · 7.2W · IP65 · ø78mm · 3000K · recessed spot
  Match: ILAR-01108 Luso 8W D80 IP65 · reason: ø78≈80mm, IP65, same category

Example 2:
  Input: KATOA BOX-E · 42W · IP20 · 597×597mm · 4000K · recessed panel
  Match: ILAR-XXXXX [Aronlight panel 600×600] · reason: panel format, dimensions match

Now match: [new competitor ref]

The examples anchor Claude to Aronlight's actual substitution logic (wattage tolerance, IP upgrade acceptable, dimensions primary). Without them, Claude defaults to generic LED knowledge which doesn't match how Aronlight commercial staff actually quote.

3. Category-specific scoring weights

The 43 cases reveal that the right spec fields vary by product category — not one universal scoring function:

Build the spec matcher as a category-aware scorer, not a flat field comparison. The category is always known from norm_category on OdooProduct.

All 13 RFQ cases were matched against Odoo staging using rapidfuzz + email/VAT/fuzzy-name strategy. Key findings for the build:

Odoo data quality issues (flag for Riccardo)

1. Email-to-partner mismatch (case 10 — Carolina Arquitecta)

carolinaportugalarq@gmail.com is assigned in Odoo to "Robin Kathuria" (VAT 312288743), not to Carolina Portugal. The email match returns the wrong partner with 100% confidence. The system would silently create a quote under the wrong customer. Action needed: data cleanup in Odoo + detect mismatch when VAT and email owner diverge.

2. VAT duplicate (case 11 — DELPA / Esfera de Fios)

Two different partners share VAT 514865881: DELPA ELECTRICPARTS LDA and Esfera de Fios. VAT is supposed to be a unique identifier in Odoo. Deduplication needed before VAT matching can be trusted for PT companies.

3. @aronlight.es email as CC (case 17 — Jordi Marco)

Every ES customer record in Odoo includes an @aronlight.es address as CC. When the sender is jordi.marco@aronlight.es, domain matching on aronlight.es returns the entire ES distributor network (40+ partners all score 100%). This breaks partner disambiguation for internally-forwarded requests. Action needed: detect @aronlight.es sender as internal channel (Q 2-16); route differently than external client emails.

Match results summary

Key architectural implications

Degenerate overlap (case 13 — Manuel & Sónia):

OR 2026/9807 is an 85-line blanket order. The [1,2,2] quantity signature of the advisory request matches it at 100% — but it is meaningless because small-quantity signatures match almost any large order. Type D advisory cases need a different matching strategy: don't use qty signature at all, match by recency + client relationship instead.

NON-AUTO type finds active client (case 15 — A.R.Costa ATEX):

A.R.Costa is an active, high-value Aronlight client (136 orders, 71% overlap on OR 2026/11485). The system correctly identifies them even though the product request is out-of-scope (ATEX emergency lighting, brand Cronus, Schuch). The right behavior: always do client matching; flag the line items as NON-AUTO but don't drop the client identity.

Saltoki multi-entity (case 19 — ES distributor with 40+ branches):

Large ES distributors (Saltoki, Rexel, Sonepar) have one branch per city in Odoo. A contact-level email (mzambrano@saltoki.es, individual) doesn't appear in Odoo at all. Domain match returns all branches. Resolution requires VAT-level disambiguation or branch-specific email on the RFQ.

Staging recency gap:

Cases 16 and 18 were sent 2026-05-28 — the same day as the match run. Quotes in progress (Flávio / Ricardo working on them) are not yet in staging Odoo. The system will correctly return "no match" for live in-progress quotes. This is expected, not a bug.

All open business policy questions are collected and deployed at:

https://aronlight-questions.pages.dev

The document is organized in three batches:

• Batch 1 (7 questions) — core design decisions; must be answered before build starts
• Batch 2 (22 questions) — matching quality and commercial process; can be answered during the build
• Batch 3 (8 questions) — v2 and later

Key Phase 3 blockers: Q 1-2 (equivalence thresholds), Q 1-6 (IP upgrade tolerance), Q 2-1 (DALI default), Q 2-2 (dimension vs wattage priority).

Key Phase 4 blockers: Q 1-8, 1-9, 1-10 (BOQ expansion rules — now in Batch 1).

Odoo data issues to fix before go-live (for Riccardo, not Manel):

• Case 10: carolinaportugalarq@gmail.com assigned to wrong partner in Odoo ("Robin Kathuria") — would silently create quotes under the wrong customer
• Case 11: VAT 514865881 duplicated across two distinct partners (DELPA ELECTRICPARTS LDA + Esfera de Fios) — VAT matching unreliable until deduped
• Case 17: All ES partner records include an @aronlight.es CC address — domain match on aronlight.es returns 40+ partners at 100% confidence, breaks disambiguation for internally-forwarded requests

Confirmed:

• [x] Staging DB name: aronlight-staging-32576046
• [x] Staging credentials: in .env (not committed)
• [x] NEXOR ILAR-03006: 1200×64×60mm, 36W, 4320lm, IP65, IK06, Class II, SS brackets — confirmed from official PDF datasheet
• [x] Philips BVP527 → Aronlight Ultramax 1710W DALI: Ricardo confirmed @3,158.67€/un, 12-15wk MTO

Detailed findings from each research question. Referenced from the main sections above.

import xmlrpc.client

common = xmlrpc.client.ServerProxy(f"{ODOO_URL}/xmlrpc/2/common")
uid = common.authenticate(DB, USER, PASSWORD, {})
models = xmlrpc.client.ServerProxy(f"{ODOO_URL}/xmlrpc/2/object")
uid is stable within a session — cache it

class OdooProduct(Model):

    odoo_id = IntField(unique=True)
    sku = CharField(max_length=50, unique=True)  # ILAR-XXXXX or ILDV-XXXXX
    name = TextField()
    odoo_category = CharField(max_length=200)
    norm_category = CharField(max_length=50)  # see Q1b
    list_price_eur = DecimalField()
    company_id = IntField()  # 2=ES, 3=PT
    raw_description = TextField()  # for spec text-parsing
    synced_at = DateTimeField()

class OdooPartner(Model):

    odoo_id = IntField(unique=True)
    name = CharField(max_length=200)
    vat = CharField(max_length=50, null=True)
    email = EmailField(null=True)
    company_id = IntField()  # 2=ES, 3=PT
    synced_at = DateTimeField()

SKU pattern:       /ILAR-\d{5}/  or  /ILDV-\d{5}/

Quantity patterns: "(\d+)\s*(un|uni|uds|uds\.|m|ml|mts|metros)"
Competitor brands: Philips, Osram, Aura Light, Karizmaluce, Castaldi, Encapsulite, Borealis,
                   Schuch, Iguzzini, KATOA, Soneres, Lucens, Schréder, LDV
Spec signals:      W (wattage), K (color temp), lm (lumens), IP (protection), IK (impact),
                   mm/cm (dimensions), deg (beam angle), CRI/Ra (color rendering)

[line_note]    "10.4.5.1.1   IL01"     ← position label, price=0, qty=0

[product]      ILAR-01108              ← luminaire

[line_note]    "10.4.5.1.5   IL05"

[product]      ILAR-02971              ← luminaire (RUMU)
[product]      ILAR-02976              ← decorative ring, same qty as luminaire

[line_note]    "10.4.5.1.4   IL04"

[product]      ILAR-00960              ← main option (Fisher IP54)
[line_note]    "alternativa"
[product]      ILAR-02683              ← alternative (Noa IP65)

[line_note]    position code

[product]      ILAR-XXXXX              ← luminaire
[product]      ILDV-XXXXX              ← driver (SKU selected by wattage range, reused across positions)
[product]      ILEM-XXXXX              ← emergency unit if required (distinct prefix)

STATUS_CHOICES = [

    ("auto", "Auto-matched — no review needed"),
    ("review", "Proposed match — sales rep confirms"),
    ("unclear", "Needs customer clarification"),
    ("no_match", "No Aronlight equivalent found"),
    ("non_automatable", "Requires human expert + photometric docs"),
]