Aronlight — Open Questions for Ricardo

Some Aronlight products are sold as 3CCT or tunable white (e.g. ILAR-03294 Nexa 50W 3000K/4000K/5000K). When an RFQ asks for the product without specifying CCT (case 20 Voltel did exactly this), what should the agent assume?

Alternative: withhold the quote and auto-reply asking the client to specify CCT first.

We are proposing 4000K because the real case 20 quote shipped without CCT specified — implying the team is comfortable letting the client clarify after. Blocking on every multi-CCT RFQ would slow down the standard distributor flow significantly.

Confirm the 4000K default, propose a different value, or tell us to ask the client every time.

From RFQ #109, IT01.1: inbound product had no IP specification, but Flávio chose IP69K (food processing / high-pressure washdown grade). Nothing in the email or line text indicated this — it appears to come from knowledge of the product family ("SALI" = kitchen/washdown context).

• (a) Are there product families or description keywords that always imply a minimum IP grade regardless of what the customer specifies? (e.g. "SALI" → IP69K, "exterior" → IP65 minimum)
• (b) Is there a mapping of installation context → minimum IP we could encode as a rule? (e.g. food processing = IP69K, exterior = IP65, bathroom = IP44)
• (c) If the customer specifies a lower IP than the application requires, should the agent flag this and suggest the correct IP, or silently upgrade and note the change?

Rule 1 logic: sum(length_m × W/m per SKU) × 1.20 → pick smallest PSU that covers it. W/m values calculated from Odoo catalog (2026-06-20) — please confirm or correct:

230V strips (SlimStrip AC, Project Strip 230V AC): Rule 1 does NOT fire. These products say "230V AC" in the product name and run direct from mains — no PSU needed. Confirmed from Odoo catalog.

Still needed: any strip SKUs missing from this table (e.g. ILAR-01404 COB PRO — no clear length in name), and confirmation these W/m values are correct.

Or should the profile always be suggested and the reviewer removes it?

Is ILAR-03322 the right default? Any missing connector SKU?

Is the 5-luminaire threshold right, or should the flag fire on any commercial order regardless of count?

In the Alfilux proposal (ORCLB2600497), bundles are priced with a single "DVDI" placeholder line at full price, and all sub-components listed at €0.00001. Examples: IT05 (CONJUNTO PERFIL MICRO 38 + FITA LED 14.4W) and IT16 (CONJUNTO PERFIL DELTA SPM20).

"DVDI" is not a product reference — it is an Alfilux-internal pricing code meaning "no direct equivalent / bundle." The agent currently cannot parse this structure.

• (a) When we see a DVDI-priced bundle, should the agent match the sub-components individually and build the Aronlight equivalent? Or treat the whole block as a single custom line?
• (b) Is "DVDI" specific to Alfilux, or do other distributors use the same convention?
• (c) For IT05 (LED strip profile bundle), the correct response required summing individual run lengths from a note field and sizing PSUs from that total. Is this the standard approach for all LED strip bundles from distributors?

From RFQ #109: two different Onlight products (OHONCSHOOT.13, IT02 and OHBBEQSRM.13, IT09) both mapped to ILAR-03699 (GABI D65 5W). Flávio quoted them as separate lines (6 units and 4 units), not consolidated to one line of 10. IT02 was also reduced from 10 to 6 — the remaining 4 appear to be covered by IT09.

• (a) When two inbound items map to the same Aronlight SKU, should the agent keep them as separate lines or consolidate into a single line with summed qty?
• (b) IT02 was quoted at 6 units, not the requested 10. The remaining 4 appear covered by IT09 (same SKU). Should the agent understand this split, or always quote 1:1 on quantity?
• (c) Is there a rule for when same-SKU consolidation applies vs. when items should stay separate (e.g. different rooms, different circuits)?

When an email arrives with an empty body ("ver anexos") and the attachment is unreadable (corrupted, expired link, wrong format):

Or should the team always be notified so they can follow up personally?

Case 19, Saltoki: "50 metres of ILAR-01691 neon RGB tube." Product sold in 5m reels → 50m = 10 reels, each needing a PSU.

Is reel length always in the product name? Are there other strip/tube SKUs sold by reel we should know about?

Some RFQs (e.g. case #44, Alfilux with Delta/Onlight/Drees products) contain only competitor brand codes where Aronlight carries the category but not the brand. The agent always returns a suggestion for every line — all flagged needs_review — but the rep must dismiss each one individually. For a 50-item cross-brand RFQ this creates significant friction.

Two options:

• Option A — Suppress: when no confident equivalent is found, return "no equivalent found" and leave the line blank. Rep fills manually.
• Option B — Flag: always show the best candidate found, clearly marked "requires verification — competitor brand not in catalog." Rep uses it as a starting point.

• (a) For a cross-brand RFQ like the Alfilux example, does Flávio prefer to start from a blank line (Option A) or a flagged suggestion he can reject (Option B)?
• (b) Is there a confidence threshold? E.g. show when ≥70% confident, suppress below?
• (c) When Aronlight carries zero equivalent in a product category (e.g. a specific driver brand not stocked), should the agent flag as "catalog gap" or leave blank?

Priority: MEDIUM — already tracked in GitHub as #237 (P2, open), so it's on the engineering backlog independent of this FAQ. Downgraded 2026-07-06.

A proportion of RFQs from distributors (e.g. Alfilux, Victor Silva) arrive as: "Em anexo, enviamos uma proposta da [Brand] — é possível dar-nos o equivalente?" The email body contains no project description, no room types, no installation context. All product information is in the PDF attachment.

This pattern makes every context-based matching improvement irrelevant — installation_context is always "unknown" for this RFQ type.

• (a) What percentage of Aronlight's inbound RFQs are distributor "equivalent" requests with no project context?
• (b) For these RFQs, what is the correct agent behaviour: pure spec-for-spec substitution (match on wattage, IP, CCT only), or flag missing context and ask the distributor to provide it?
• (c) Do distributors ever provide context on request, or is it typical to expect a straight equivalent without discussion?
• (d) For distributor RFQs, does Flávio still apply application-based overrides (IP uprating, CCT change) — or is it always a strict spec-for-spec match?

Case 16: Aura Light BOGT3 and MILA M appear discontinued — no current datasheet online.

Does Aronlight have an archive of competitor datasheets we could query?

Aronlight publishes a public product catalog at aronlight.com/catalogo/aron-catalog. It is not yet documented how this page and "Tabela" fit into the quoting workflow described elsewhere in this doc (Odoo pricelists — see PRICE-2, DISC-1).

• (a) Is aronlight.com/catalogo/aron-catalog used internally by sales/back office when preparing a quote, or is it a client-facing page only?
• (b) What is "Tabela" in this context — a price list separate from the Odoo pricelists, a printed/PDF catalog, or another document? Is it the same thing as the public Catalog page, or different?
• (c) If Tabela and/or the public Catalog are sources of truth for product info or pricing, does the agent need to read them directly, or is everything already mirrored in Odoo (catalog.json export)?

Priority: MEDIUM — need to know if this is a separate system for pricing/catalog info or already covered by Odoo (see PRICE-2, OD-1, OD-2).

Some inbound RFQs arrive as a formal BOQ position code with no functional spec and only a bare label, e.g.:

8.1.5.1.1.1   L2   89 un   Com

No wattage, CCT, IP, or descriptive text beyond "Com" is given, yet the resulting quote line matched it to:

[ILAR-01960] 150W Campanula Master II 3CCT 3000K/4000K/5000K IP65 — 89 Unidades @ €68,7480 — Total €6.118,57

• (a) What information actually determined this match — the BOQ position code itself (8.1.5.1.1.1), a caderno de encargos / project spec sheet referenced by that code but not included in what was sent, or prior knowledge of this client's or project's typical spec?
• (b) Is the position code meaningful on its own — does it map to a recurring catalog of BOQ line types Aronlight has seen before, or is it project-specific and only resolvable by reading the full caderno de encargos?
• (c) For the agent to replicate this, what does it need beyond the bare RFQ line — should it always request the full caderno de encargos when a line arrives as a position code with no spec, or is there a faster process used in practice today?

Priority: MEDIUM — this pattern is currently a single observed example; downgraded 2026-07-06 pending Flávio's answer on whether it's common enough to justify architecture work.

From the Ayelen Montenegro call (2026-07-06): today, a client with unpaid invoices isn't flagged when an order is loaded. The whole order gets entered, stock gets checked, everything proceeds normally — and only at the very last step ("validate the pick," right before dispatch) does a pop-up warn the client is blocked for outstanding debt. Concrete example: an order for Adichem SRL (forwarded by an agent) got stuck this way; she had to manually notify the agent afterward that the client owes money and can't be shipped until resolved.

• (a) Is client credit/debt status available as a field the agent could check before processing a line, rather than discovering it only at pick-validation?
• (b) If detected upfront, what should the agent do — hold the whole order, process everything except that client's lines, or flag it for the rep to decide?
• (c) Is this specific to the Italy agent-mediated flow, or does the same late-surfacing behavior apply to all markets (PT, ES)?

Priority: MEDIUM — real, live workflow gap reported directly by the person doing the job; causes rework and manual client notification after the fact.

Case 20 (Voltel, 2026-06-15) showed that real quotes include stock alerts inline: "Artigo indisponível — previsão de entrega: 13/7/26." The agent must replicate this — silently quoting an out-of-stock product is worse than not quoting it.

Without these answers, v1 will either skip the alert entirely (silently quoting unavailable stock) or block too aggressively.

Priority: MEDIUM — re-elevated 2026-07-06. Downgraded to Low earlier the same day on "4 of 6 sub-questions already shipped" — but the Ayelen Montenegro call is live, current, first-hand evidence this exact pain point is unsolved for her today: "insufficient stock" shows as a bare warning, she must click into each product individually to see quantity + arrival date, and she explicitly wants the auto "need 80, have 40, rest arrives on [date]" behavior this item already proposes. The backend features shipped (#50, #51), but haven't reached her actual workflow yet.

Every Aronlight orçamento today carries 3 PT-tax-law-required elements that v1 must preserve when the agent writes back to Odoo (or generates a proposal directly). Example from Voltel OR 2026/13707:

Priority: MEDIUM. Affects every quote, but Odoo likely auto-generates ATCUD/QR already per "What we believe" above, and GitHub has the corresponding issue (#52) at P3. Downgraded 2026-07-06 pending evidence of actual exposure.

Voltel OR 2026/13707 shows TWO discount columns on every line:

· 1st Disc. = 48 (= 48 %)

· 2nd Disc. = 0

PRICE-1 confirms 1st Disc. is the partner pricelist (Voltel = 48 % flat off list). What 2nd Disc. represents semantically is not yet confirmed.

If C is right, the calculation is net = list × (1 − d1) × (1 − d2). If A or B, the agent only needs to consume the value from Odoo, not compute it.

Hyp A effectively confirmed for Spain (Adriana Fernandes call, 2026-07-06): she described exactly this pattern — a salesperson grants an ad hoc extra discount on specific line items (e.g. client's standard 60% plus 2% extra on 3 items), which Odoo has no structural way to capture — she corrects it manually at invoicing every time. Matches Hyp A: a manual, per-order, salesperson-driven addition, not a product rule or pricelist cascade.

Does NOT generalize to Italy (Ayelen Montenegro call, 2026-07-07): for Italian clients, the second discount is a fixed, known value per client profile (typically 20%, sometimes 10%), not a per-order negotiation — closer to Hyp B in spirit, but not yet captured as a product rule either. A working combined pricelist ("ITALIA 50+20%") already exists in Odoo but is assigned to zero customers — the fix is assignment, not construction. See aronlight#398.

Net finding: 2nd Disc. semantics are market-specific, not universal. Spain = ad hoc negotiation (Hyp A). Italy = fixed-per-client, mechanically solvable, just not wired up. Still needs Ricardo/Manel to confirm PT and France.

Doesn't block v1, but the data model needs both columns and the semantic determines whether the agent ever fills 2nd Disc. vs always reads it from Odoo.

ILAR-02135 (Armadura TITAN 1200 IP65 36W 3CCT Prep. EM/Sensor) and ILAR-02137 (Armadura TITAN 1500 IP65 48W 3CCT) are currently in Odoo category "Armaduras Industriais", mapped to our INDUSTRIAL search bucket.

When a customer provides the SKU directly, we find them. When a customer describes the product by spec ("armadura IP65 36W emergência"), the agent's category pre-filter excludes them before the vector search runs — they are invisible. Both were MISS in eval cases #35 and #44.

Note: "Prep. EM/Sensor" in the product name means prepared for emergency/sensor (knockout holes for optional modules) — not that the product is a sensor. The Odoo category "Armaduras Industriais" may be correct; the question is whether it matches the full scope of use.

• (a) Are TITAN armaduras exclusively quoted in industrial projects (factories, warehouses), or do they also appear in mixed-use projects (garages in residential buildings, commercial warehouses, parking structures)?
• (b) If they appear outside pure industrial contexts, should they move to a different Odoo category — or is the fix on our side (widen code to also search INDUSTRIAL when an IP65 armadura is requested)?

Priority: MEDIUM — determines whether the fix is in Odoo or in code.