---
type: incognitas
---

# Incógnitas — Distribuidora Vale Sul

Lista plana, sem agrupamento por fase ou gate (schema completo em
`../../incognitas.md`). Cada registro é uma lacuna que ainda não virou
`confirmado` em algum campo do bundle — a régua de densidade espera 8 campos
fixos preenchidos por registro, nunca uma pergunta solta.

Mistura deliberada de `dono`: três registros são `dono: cliente` (viram
`pergunta_cliente` na lista automática) e dois são `dono:
precisa-acesso-banco` (resolvem por profiling/acesso a schema — um ao
Sankhya, outro ao schema já existente do dw-desk — nunca pergunta ao
cliente final) — o gabarito não pode mostrar só o caso mais comum.

```yaml
- id: cancelamento-pedido
  campo: metricas/receita-liquida.md#exclusoes
  hipotese: "quando um pedido já faturado (STATUSNOTA='L') é cancelado depois,
    em mês posterior, o Sankhya reabre a MESMA linha (NUNOTA/SEQUENCIA) como
    'C' — a receita do mês da venda original é restated retroativamente, não
    lançada como estorno num mês novo"
  confianca: a-perguntar
  dono: cliente
  gatilho: "confirmar em transcrição de call sobre o fluxo de estorno OU
    select de exemplo de um NUNOTA que mudou de 'L' para 'C' depois de já ter
    sido carregado no DW"
  pergunta_cliente: "Quando um pedido já faturado é cancelado depois
    (estorno), o valor sai retroativamente do mês da venda original, ou
    vocês lançam o estorno como um registro novo no mês em que ele foi
    cancelado?"
  risco_se_errar: "se for restatement retroativo e o dashboard não recarregar
    o histórico, Receita Líquida de meses já fechados fica inflada
    silenciosamente; se for lançamento novo e a skill assumir restatement, o
    mês do estorno conta a baixa duas vezes"

- id: retencao-lgpd-pedido-item
  campo: tabelas/fact_pedido_item.md#retencao_dw
  hipotese: "reter os dados de fact_pedido_item pelo mesmo prazo do ERP de
    origem (sem prazo definido hoje no Sankhya), até o cliente definir uma
    política própria"
  confianca: a-perguntar
  dono: cliente
  gatilho: "confirmar política de retenção com o cliente (jurídico/
    compliance) OU aplicar o prazo padrão contratual Horus se o cliente não
    tiver política própria definida"
  pergunta_cliente: "Por quanto tempo os dados de pedido devem ficar
    armazenados no DW? Existe um prazo de expurgo definido pela política de
    dados de vocês (LGPD)?"
  risco_se_errar: "reter dado além do necessário é risco de compliance LGPD;
    expurgar cedo demais quebra comparativo histórico (ex.: 'mesmo mês do
    ano passado') sem aviso"

- id: dt-alteracao-origem-nulos
  campo: tabelas/fact_pedido_item.md#coluna_particao_tracking
  hipotese: "os 12% de DT_ALTERACAO NULL são registros antigos, gravados
    antes do trigger de auditoria existir no Sankhya — não é gravação ativa
    perdendo o tracking hoje"
  confianca: a-perguntar
  dono: precisa-acesso-banco
  gatilho: "acesso direto ao Sankhya (DBA ou Rafael Nogueira — TI Vale Sul)
    para inspecionar se DT_ALTERACAO é setado por trigger de banco ou pela
    camada de aplicação, e se o NULL concentra em datas antigas"
  pergunta_cliente: null   # dono: precisa-acesso-banco — resolve por
                            # profiling/acesso ao banco, nunca pergunta ao
                            # cliente
  risco_se_errar: "se o NULL for gravação ativa (não só histórico), a janela
    de lookback de 3 dias do load Temporal pode perder atualização de linha
    recente — duplicidade ou dado desatualizado no DW sem sinal de erro"

- id: rls-vendedor-detalhamento
  campo: aceite.md#papeis-com-acesso
  hipotese: "acesso restritivo por padrão: só Marcos, Camila e diretoria
    comercial veem receita de TODOS os vendedores; cada vendedor individual
    não acessa o dashboard nesta fase"
  confianca: a-perguntar
  dono: cliente
  gatilho: "confirmar lista nomeada de papéis com acesso amplo vs restrito
    antes do go-live"
  pergunta_cliente: "Além de Marcos e Camila, quem mais pode ver a receita de
    TODOS os vendedores? Um gestor de loja deve ver o número da própria
    loja, ou cada vendedor só vê o próprio?"
  risco_se_errar: "vendedor vê comissão/desempenho de colega sem autorização
    — risco de clima organizacional e possível violação de política interna
    de dados"

- id: calendario-chave-join-inferida
  campo: apps/vendas.md#relationships
  hipotese: "a coluna de chave de dim_calendario é `data` (grão diário), por
    convenção de nomenclatura do dw-desk — lineage.md documenta a aresta
    table-level DIMCAL --> FACT no diagrama e a origem TGFCAB.DTNEG ->
    fact_pedido_item.data no lado do FATO, mas não tem, na tabela
    'Dimensões (chaves usadas no fato)', uma linha explícita para o lado da
    dimensão como tem para as outras 4 (CODPROD/CODPARC/CODVEND/CODEMP)"
  confianca: a-perguntar
  dono: precisa-acesso-banco
  gatilho: "rodar `lumo columns table:dim_calendario` (dimensão conformada
    já existe no dw-desk do tenant, ver processos/faturamento.md#dimensões)
    para confirmar o nome físico da coluna de chave diária, e acrescentar a
    linha correspondente na tabela 'Dimensões (chaves usadas no fato)' de
    lineage.md"
  pergunta_cliente: null   # dono: precisa-acesso-banco — resolve conferindo
                            # o schema já existente do dw-desk, nunca
                            # pergunta ao cliente final
  risco_se_errar: "se o nome físico da coluna de chave em dim_calendario for
    diferente de `data` (ex.: data_chave, dt_calendario), o relationship
    declarado em apps/vendas.md não bate com o schema real do dw-desk — o
    erro só aparece no lint/push contra o schema, não antes"
```

# Perguntas para o Cliente (geração automática)

Os 3 registros com `dono: cliente` acima alimentam a lista que vai pro
documento final (ver `documento-template.md`, seção "Três vistas do mesmo
bundle") — o `rls-vendedor-detalhamento` é o que efetivamente falta fechar
antes do go-live, os outros dois (`cancelamento-pedido`,
`retencao-lgpd-pedido-item`) não bloqueiam a aprovação de `scope-v1.0`
(nenhum dos dois é campo estrutural do grain/fórmula já aprovado — ver
`log.md`).
