---
type: metric
nome: "Ticket Médio"
pergunta: "qual o valor médio por pedido faturado, no período?"
decisao_associada: "mesma checagem diária de Receita Líquida — usada para diagnosticar SE uma receita fraca é mix de pedidos menores (ticket caindo) antes de decidir ação de desconto"
formula_negocio: "Receita Líquida do período dividida pela quantidade de pedidos distintos faturados no mesmo período"
formula_lumo: 'SUM([fact_pedido_item]."VALOR_LIQUIDO") / COUNT(DISTINCT [fact_pedido_item]."NUNOTA")'
camada: tabela
mask: MOEDA
aditividade: nao-aditiva
inclusoes: "mesmo universo de Receita Líquida — STATUSNOTA = 'L'"
exclusoes: "mesmo de Receita Líquida — bonificação (TIPMOV='B') não conta como pedido nem entra no numerador ou denominador"
coluna_data: DTNEG
grao_temporal: dia
meta_threshold: "sem meta — ver Receita Líquida (metricas/receita-liquida.md)"
owner: "Marcos Aurélio — Diretor Comercial"
aviso_apos: "mesmo de Receita Líquida — mesma fonte, mesma carga"
sla_cliente: "mesmo de Receita Líquida"
teste_reconciliacao: 'lumo app query app:vendas-executivo --fields X<expr_ticket_medio>:EXPR vs lumo credential query credential:sankhya "SELECT SUM(VALOR_LIQUIDO)/COUNT(DISTINCT NUNOTA) FROM TGFITE WHERE STATUSNOTA=''L'' AND TIPMOV<>''B''"'
fonte: "/lineage.md#ticket-medio"
confianca: confirmado   # ver incognitas.md
validado_por: "Marcos Aurélio — Diretor Comercial"
validado_em: "2026-04-08"
canal: "mesma call de validação de métricas de Receita Líquida"
evidencia: "denominador reusa a chave (NUNOTA) já validada no Grain Check (ver tabelas/fact_pedido_item.md#evidência-de-profiling); numerador é o mesmo de Receita Líquida"
---

# Notas

Ticket Médio é a armadilha clássica de aditividade — o card existe como par
didático de `receita-liquida.md` para deixar isso explícito:

- **Nunca somar** Ticket Médio ao longo do tempo ("ticket médio da semana" ≠
  soma dos 7 tickets médios diários).
- **Nunca tirar média das médias por loja** ("ticket médio da rede" ≠ média
  aritmética do ticket médio das 5 lojas — lojas com volumes diferentes pesam
  diferente).
- O widget SEMPRE recalcula a partir dos componentes aditivos — soma o
  numerador (Receita Líquida) e o denominador (contagem distinta de pedidos)
  no grão pedido, e só então divide, depois de agregado no nível exibido.

**Por isso o `dataSource` é `X<id>:EXPR`, nunca `<coluna>:AVG`.** Métrica de
razão vira **expression de aplicação** no Horus, com a `formula_lumo` acima: o
`SUM` e o `COUNT` agregam no nível de agrupamento do widget e a divisão vem
depois, que é exatamente a regra das duas linhas anteriores. Um sufixo `:AVG`
sobre uma coluna faria a média aritmética do que já estava calculado, ou seja,
a média das médias que este card existe para proibir.

Repare que o `teste_reconciliacao` consulta a **expression**, e não
`ticket_medio:AVG`. Um teste com `:AVG` roda e devolve um número, então a
contradição com as notas acima passa despercebida. A tabela de sufixos está em
`lumo-cli:references/data-modeling.md`, e a regra de agregação por classe de
aditividade em `lumo-design:references/aditividade.md`.
