# PRD — Missoes/Compras (MVP)

## Problema / dor

O fluxo de compras dentro do produto Genesis hoje é informal. Não há trilho de aprovação documentado, não existe sugestão automática baseada em estoque/consumo, e o que sai pro fornecedor não é padronizado. Resultado: rupturas de estoque, compras impulsivas, gasto fora de alçada e auditoria difícil.

O cliente final precisa de um fluxo coeso **Sugestão → Pedido (editável) → Aprovação por alçada → XML pro ERP**, com regras de alçada configuráveis por categoria de produto e faixa de valor, espelhando como compras "sérias" funcionam em ERPs (Sankhya/Bling/SAP/Protheus).

## Personas (alto nível)

- **Comprador / Solicitante** — recebe a Sugestão, transforma em Pedido, edita itens/quantidades e submete pra aprovação.
- **Gestor de filial** — aprova/rejeita pedidos dentro da alçada dele (ex.: insumos até R$ 5.000).
- **Diretor** — aprova pedidos acima da alçada do gestor (ex.: insumos acima de R$ 50.000).
- **Admin** — configura as regras de alçada (cliente × categoria × faixa de valor → quem aprova).

> Mapeamento exato pra papéis/permissões Genesis fica com o PO.

## O que precisa fazer (alto nível) — MVP

1. **Sugestão de Compras**
   - Motor que propõe **itens + quantidades** combinando:
     - **Estoque mínimo** — saldo atual em `produtos_estoque` × mínimo configurado (por produto/filial).
     - **Histórico de consumo** — média/projeção dos últimos N dias de saída.
   - Gestor revisa a sugestão e converte em Pedido (com edição de itens/qtde).

2. **Pedido de Compra**
   - Editável enquanto rascunho: itens, quantidades, fornecedor (escolha manual no MVP), observações.
   - Submetido entra na fila de aprovação.

3. **Aprovação por alçada**
   - Regras configuráveis por **cliente × categoria de produto × faixa de valor**, definindo o aprovador (automático / gestor / diretor / outro).
   - **Cadeia hierárquica iterativa**: se valor passar da alçada do gestor, escala pro diretor; cada nível registra decisão e justificativa.
   - **Tela admin de regras** incluída no MVP (CRUD das regras).

4. **Geração de XML**
   - Pedido aprovado vira XML do pedido pra envio ao ERP do cliente (download e/ou envio).
   - **Layout específico em aberto** — provavelmente Strategy + `Adapters/<Erp>/` plugando via Registry (espelhando `Edicaorota/Adapters/Romaneio`). Definição do(s) layout(s) é dúvida em aberto pro PO.

5. **Histórico / auditoria**
   - Cada transição de status (rascunho → submetido → aprovado/rejeitado/escalado → XML gerado) registrada com **quem + quando + comentário opcional**.
   - Visualização do trilho completo na tela do pedido.

## Fora do escopo (próximas fases)

- **Recebimento físico** de mercadoria, conferência contra pedido e tratamento de divergências.
- **Vínculo com NF de entrada** (`Missoes/Notascompra`).
- **Cotação** — vai em PRD próprio (`PRD/cotacao/`) como módulo Strategy reutilizável. Compras MVP integrará via Registry/Adapter quando Cotacao existir. Por enquanto, fornecedor é escolhido manualmente no Pedido.
- **Pedido baseado em demanda de Pedidos de venda** em aberto.
- **Sugestão manual** (drag-and-drop do catálogo) — só se houver demanda na v2.
- **Delegação temporária** de aprovação (gestor de férias) — avaliar v2.

## Restrições / dependências conhecidas

- **Padrão arquitetural V2:** Sondas (não Inteligencias), Laboratorios pra casos de uso, Validators dedicados, Enums backed com FSM, Callbacks Registry pra extensibilidade. Referência canônica: `Logistica/Edicaorota`.
- **Multi-tenant:** `customerControl=true, companyControl=true` (filial dentro do cliente).
- **Depende de cadastro de categorias de produto** em `produtos` — verificar se já existe; se não, vira pré-requisito do PRD (sub-tarefa do PO ou PRD-pré-requisito separado).
- **Depende de `estoque_minimo` / `estoque_maximo`** em `produtos` (provavelmente faltam) — mesmo tratamento.
- **XML:** layout indefinido. PO precisa levantar com clientes-piloto antes do TL desenhar a Strategy. Considerar layout-base + Adapters por ERP.
- **Cadeia de aprovação** precisa mapear "gestor de filial" e "diretor" no modelo de usuários/papéis Genesis. PO confirma.
- **Integração futura com Cotacao**: o data model do Pedido deve permitir referenciar uma cotação aceita (`cotacao_id` opcional) sem que isso vire pré-requisito do MVP.

## Métricas de sucesso (alto nível)

- **% de pedidos originados de Sugestão automática** (vs criados do zero) — sinal de adoção do motor.
- **Tempo médio submissão → decisão** (aprovação ou rejeição).
- **% de pedidos aprovados sem ajuste de itens/quantidades** — sinal de que a Sugestão acerta.
- **Cobertura de auditoria** — 100% dos pedidos com trilho completo de status + autores.
- **Compras dentro de alçada correta** — zero pedidos aprovados por nível abaixo do que a regra exige.

## Inspirações / referências

- Módulos de Compras de ERPs (Sankhya, Bling, SAP, Protheus) — fluxo "requisição → cotação → pedido → recebimento".
- Internamente: `Logistica/Edicaorota` (V2 canônico, especialmente o pattern Callbacks Registry + Adapters/Romaneio para extensibilidade), `Mensageria/Otp` (Registry de canais).

## Dúvidas em aberto pro PO

1. **Layout XML** — 1 layout-base + Adapters por ERP, ou 1 layout único? Quais ERPs no MVP?
2. **Categoria de produto** — já existe em `produtos`? Quem cadastra? Faz parte do MVP de Compras ou é pré-requisito?
3. **Estoque mínimo / máximo** — campos existem em `produtos`? Cadastro entra no escopo?
4. **Mapeamento de papéis** — "gestor de filial" e "diretor" hoje são papéis no Genesis ou precisam ser introduzidos? Como se vinculam a filial?
5. **Notificação de aprovador pendente** — via Mensageria/Otp (whatsapp/email) ou caixa de entrada in-app? Ambos?
6. **Pedido rejeitado** — volta pra rascunho (editável) ou termina e exige novo pedido?
7. **Delegação temporária de aprovação** — entra no MVP ou v2?
8. **Fornecedor no MVP** — `Missoes/Fornecedores` (shell hoje) precisa ser preenchido como pré-requisito, ou Compras MVP usa apenas string-livre?
9. **Histórico de consumo pra Sugestão** — qual fonte canônica? Sai de movimentação de estoque, de pedidos de venda, ou de uma view nova?
10. **Janela do histórico** — N dias é configurável (cliente decide) ou fixo (ex.: 30/60/90)?