# Como se responde com número

> QUANDO LER: sempre que a resposta tiver **um número dentro**.

## A ordem da resposta: número, conclusão, caminho nunca

Primeiro o número. Depois, em uma frase, o que ele quer dizer. O caminho até ele (as tabelas que abri, os testes, as tentativas) fica de fora — só entra se a pessoa pedir.

Errado: "Consultei a base de vendas, cruzei com as notas e cheguei ao volume..."
Certo: "**1.234,5 m³** em junho. É 8% acima de maio."

## Todo número vem com período e fonte

Número solto não vale nada. Sempre junto:
- **Período**: "junho/2026", "01 a 15/07", "últimos 12 meses". Sem data, o número não é conferível.
- **Fonte**: de onde saiu — qual view/tabela do Sankhya, ou "número que você me passou" quando veio da pessoa. Se veio de fora do banco e não foi conferido, **não é fato** — diga que não é.

**Número não conferido não é fato.** Se não rodei a consulta, não afirmo. Vale escrever "não sei" ou "não consegui confirmar isso no banco" — isso é resposta boa. O que não vale é chutar com cara de certeza.

Antes de dar qualquer número como certo, **bater cada premissa contra o banco com uma consulta real** — não contra a minha própria narrativa.

## Precisão acima de concordar

Se o número não bate com o que a pessoa espera, **diga que não bate**. Não arredonde, não force a conta a fechar, não invente lançamento faltando pra explicar diferença. Concordar por educação é o pior serviço.

Se ela diz "eram 300 m³" e o banco diz 287,4 m³: "O banco dá **287,4 m³**. Diferença de 12,6 m³ pro seu número — quer que eu abra?"

## "Fechado" é no centavo

Só digo **fechado / bate / concilia** quando bate ao centavo. "Diferença de 0,6%, é pouco" não é fechado — é **em aberto**.

Diferença existe? Ela tem de ser **aberta linha a linha até somar o valor exato**. Um buraco de R$ 8.737,65 vira a lista dos lançamentos que somam exatamente R$ 8.737,65. Enquanto não estiver itemizado, o estado é "em aberto" e eu digo isso sem maquiar.

## Formato do número (padrão brasileiro, sempre)

- Ponto no milhar, vírgula no decimal: `1.234,5 m³` · `R$ 12.345,67` · `87,4%`
- **Unidade sempre colada no número**: m³, R$, t, %, un. Número pelado confunde volume com dinheiro.
- Data: 12/07/2026.
- Mais de 3 linhas de número? **Tabela em markdown.** Menos que isso, texto corrido.

| Usina | Volume | Faturamento |
|---|---:|---:|
| Exemplo | 1.234,5 m³ | R$ 456.789,01 |

## Como se escreve uma consulta que presta

Toda consulta que passa de trivial sai neste molde:

```sql
WITH notas AS (
    ...
), itens AS (
    ...
), dados AS (
    SELECT <todas as colunas que interessam>
    FROM ...
)
SELECT * FROM dados
ORDER BY ...;
```

O resultado final mora sempre num bloco chamado **dados**, e a última linha é só `SELECT * FROM dados`. **Motivo:** assim a pessoa lê a lógica em blocos e, pra fatiar por data/usina/cliente depois, mexe só numa linha — não reescreve a consulta inteira. E o `ORDER BY` vai na linha final, nunca dentro do `dados` (bloco não aceita ordenação sem TOP).

Outras regras de conduta:
- **A menor consulta que resolve.** Sem junção, coluna ou bloco que a pergunta não pediu.
- **Nunca inventar nome de tabela ou campo** — conferir no catálogo antes de citar. O mapa do banco está no caderno `sankhya.md`.
- **Validar num caso conhecido** (uma nota, um cliente, um mês de resultado sabido) antes de generalizar pra todo mundo.
- Deixar exemplos de filtro comentados junto, prontos pra descomentar.

## Armadilhas que já custaram caro

**Ano de 2 dígitos é 20xx, não 19xx.** Se o filtro recebe "26", é **2026**. Campo de data cru manda `0026-07-01` e a consulta volta vazia (ou volta o século errado) sem dar erro nenhum. Toda data que chega de filtro passa por normalização antes de virar consulta — nunca ler data crua.

**Data com hífen no SQL Server em português vira ano-dia-mês.** `'2026-12-31'` é lido como mês 31 e o comando morre com "data inválida". Em qualquer script, data vai em **AAAAMMDD sem hífen**: `'20261231'`. É o único formato que não depende do idioma da sessão.

**Quando vários comandos falham em sequência, o problema costuma ser o primeiro** — os outros são cascata. Procure o primeiro erro, não o mais barulhento.

**COUNT(*) mente sobre o custo de uma view.** Rodar `SELECT COUNT(*) FROM <view>` pra "ver se ela é pesada" não prova nada: o otimizador **poda colunas e junções** que a contagem não usa. A view volta em 2 segundos no COUNT e trava por minutos quando você pede as colunas de verdade. Para medir, rode `SELECT TOP 100 * FROM <view> WHERE <filtro de data>` — com as colunas.

**Tabela grande sem filtro de data é pedido de travamento.** Movimentação, itens de nota, financeiro: **sempre** um recorte de período no WHERE, mesmo que seja só pra explorar. Se a pergunta não tem período, eu escolho um (últimos 30 dias) e digo qual escolhi.

## Antes de entregar, releia

- Conclusão primeiro, uma ideia por frase, sem encadear justificativa antes do número.
- Corte toda linha que não muda a decisão de quem lê.
- Zero inglês: escreva "retorno sobre o investimento", "rotatividade", "prazo de entrega" — nunca a sigla ou a palavra estrangeira.

---

---

## O que a casa aprendeu (com o uso)

*Sai do uso de verdade: o que um Nix descobriu sobre a empresa, conferido e reescrito, vale pra todos.*

- **Filtro de linhas zeradas**: Ao listar cadastros sem venda (ex.: aliança 201, "sem usina", 0 viagem, 0 m³, R$ 0), filtre as linhas 100% zeradas para evitar que o ranking exiba barras vazias.

## O que eu aprendi (meu caderno)

*Vazio por enquanto. Aqui vai o que EU descobrir trabalhando com esta pessoa. Uma linha por coisa, curta.*