Pular para o conteúdo principal

Investigação: "Alfa Romeo" aparecendo dentro de "Fiat" no relatório Por Marca

Sintoma​

No relatório Por Marca (Emplacamento), ao expandir a marca Fiat e clicar em "ver mais", aparece uma linha de modelo chamada "Alfa Romeo" — como se fosse um modelo da Fiat. O "62" mencionado no relato é a posição/índice da linha na lista ordenada por volume (a Fiat tem ~20-23 "modelos" no ano; Alfa Romeo aparece por último, com volume mínimo), não um volume de 62 unidades.

Causa-raiz confirmada​

A origem é o dado, não o código do relatório. O código em brand-service.ts (buildGridRows + query aggRows) apenas agrupa por m.fabricante e aninha m.grupomodeloveiculo sob a marca — não há nenhuma lógica de mapeamento/correção no caminho do relatório. Confirmado por leitura do arquivo: o Map de marcas é keyado só por r.fabricante, exatamente como vem do mart.

Consultei ao vivo dw_emplacamento_mart.emplacamento_kpi_dia (env SUPA_DB_*, host aws-1-sa-east-1.pooler.supabase.com, schema dw_emplacamento_mart/dw_emplacamento):

1. grupomodeloveiculo distintos com fabricante = 'FIAT'​

25 valores, entre eles um valor literal 'ALFA ROMEO' (não é "Stelvio", "Giulia", "Tonale" etc. — é a string "ALFA ROMEO" usada como nome de grupomodeloveiculo):

147, 500, 500E, ALFA ROMEO, ARGO, BRAVO, CRONOS, DOBLO, DUCATO, FASTBACK,
FIORINO, IDEA, MOBI, PALIO, PALIO WEEKEND, PULSE, PUNTO, SCUDO, SIENA,
STRADA, TIPO, TITANO, TORO, UNO, WEEKEND

2. Existe fabricante = 'ALFA ROMEO' correto e separado​

Sim. Os modelos modernos/reais da marca Alfa Romeo (Giulia, Giulietta, Spider, Montreal) já estão corretamente classificados sob fabricante = 'ALFA ROMEO' no mart — não há confusão aí:

fabricante='ALFA ROMEO', grupomodeloveiculo='GIULIA'     vol=4
fabricante='ALFA ROMEO', grupomodeloveiculo='SPIDER'     vol=3
fabricante='ALFA ROMEO', grupomodeloveiculo='GIULIETTA'  vol=1
fabricante='ALFA ROMEO', grupomodeloveiculo='MONTREAL'   vol=1

(Não há Stelvio/Tonale emplacados na base ainda; nenhum desses aparece sob fabricante='FIAT' — só o bucket genérico 'ALFA ROMEO'.)

3. Cruzamento com dw_emplacamento.dim_veiculo​

A dim_veiculo tem fabricante, modelo e grupomodeloveiculo como colunas separadas. As 3 linhas que originam o problema:

veiculo_nkfabricantemodelogrupomodeloveiculosegmento
101699|419|2|1FIATFIAT/ALFA ROMEOALFA ROMEOAutomóvel
101902|419|2|1FIATFIAT/ALFA ROMEO 2300 TIALFA ROMEOAutomóvel
101902|419|2|100FIATALFA ROMEO 2300 TIALFA ROMEOAuto (Não Identificado)

Esses são veículos vintage — o "FIAT/Alfa Romeo 2300", carro que a Fiat comercializou/rebadge-ou no Brasil nos anos 1970-80 quando a Alfa Romeo brasileira foi incorporada pela Fiat. O fabricante = 'FIAT' nessas 3 linhas é plausivelmente correto do ponto de vista do registro histórico (o DETRAN/RENAVAM registra o fabricante legal, que era Fiat). O problema é que o grupomodeloveiculo derivado do texto do modelo (que contém a substring "ALFA ROMEO") virou 'ALFA ROMEO' — um nome que colide semanticamente com o nome da marca Alfa Romeo, fazendo a UI do relatório (que usa grupomodeloveiculo como rótulo de "modelo" dentro da marca) exibir "Alfa Romeo" como se fosse um modelo da Fiat.

Onde está o problema: na derivação/classificação de grupomodeloveiculo dentro de dim_veiculo (ou no ETL upstream que popula essa coluna a partir do texto de modelo). Não é um bug do mart dw_emplacamento_mart (que só herda o dado) nem do código do relatório.

4. Volume real do problema​

Baixíssimo — isso é ruído histórico/vintage, não um erro sistemático atual:

ano=2025: fabricante=FIAT, grupomodeloveiculo=ALFA ROMEO → vol=2
ano=2026: fabricante=FIAT, grupomodeloveiculo=ALFA ROMEO → vol=1

(mês a mês: mai/2025=1, ago/2025=1, mai/2026=1 — provavelmente transferências/atualizações cadastrais de veículos antigos, não emplacamentos novos.) É a linha de menor volume da Fiat no ano, por isso só aparece no "ver mais" (paginação/expansão), na última posição da lista ordenada por acumAno desc — o "62" do relato é a posição na lista, não uma contagem de unidades.

Recomendação​

Dado o volume trivial (1-2 registros/ano) e o fato de a causa estar comprovadamente em dim_veiculo (upstream), duas opções:

Opção A — Fix no pipeline de dados (preferível)​

Corrigir a derivação de grupomodeloveiculo para essas ~3 linhas de dim_veiculo (ex.: usar um bucket como 'FIAT/ALFA ROMEO (VINTAGE)' ou agrupá-las em 'OUTROS'/'147' conforme convenção já usada para modelos raros).

  • Prós: corrige na fonte, sem duplicar lógica de correção em cada relatório que consome o mart (Por Marca, e potencialmente outros que também usam grupomodeloveiculo); mantém o dado consistente entre relatórios.
  • Contras: depende do time de dados (ETL/dim) — mesmo bloqueio já registrado para o refactor dos marts (docs/vona/marts-emplacamento.md); mudança pequena mas ainda assim atravessa outro time/pipeline, não é imediata.

Opção B — De-para no código do relatório (mitigação rápida)​

Se for necessário resolver antes do time de dados atuar, dá para adicionar uma exceção pontual em brand-service.ts, nas queries aggRows/dailyRows, excluindo ou reclassificando esse par específico:

-- na cláusula WHERE de aggRows/dailyRows/monthDatesRows:
AND NOT (m.fabricante = 'FIAT' AND m.grupomodeloveiculo = 'ALFA ROMEO')

ou, para manter o volume mas sob um rótulo que não colida com a marca real:

CASE
  WHEN m.fabricante = 'FIAT' AND m.grupomodeloveiculo = 'ALFA ROMEO'
    THEN 'ALFA ROMEO (FIAT VINTAGE)'
  ELSE m.grupomodeloveiculo
END AS modelo
  • Prós: resolve imediatamente, sem depender de outro time; escopo mínimo (uma linha de CASE/exclusão).
  • Contras: é um patch cosmético — se amanhã aparecer outro caso de grupomodeloveiculo colidindo com nome de marca (ex.: um "Chevrolet" aninhado em "GM" com grupomodelo="CHEVROLET" genérico), precisa de nova exceção manual; não corrige o dado para quem consome o mart fora deste relatório específico (ex.: por-território, por-ranking, boletim diário).

Sugestão: dado o volume irrisório e o fato de já haver um projeto de refactor dos marts bloqueado no time de dados (docs/vona/marts-emplacamento.md), vale registrar este achado como item adicional desse backlog (Opção A) em vez de aplicar um patch pontual — a menos que o "ver mais" com esse ruído esteja causando confusão visível para usuários de negócio no curto prazo, caso em que a Opção B é aceitável como tapa-buraco.