Pedido de Compra (PO)

Quando o PO é criado

Em 3 caminhos possíveis:

1. Automático após aprovação da cotação (caminho principal)

Quando a cotacao_decisao é aprovada pelo diretor, o engine de aprovação dispara um callback que:

• Cria 1 PO por fornecedor vencedor
• Cada PO recebe os itens atribuídos àquele fornecedor (suporta vencedor misto)
• Status inicial: emitido
• Atualiza requisição para pedido_emitido

2. Direto sem RC (contrato-mestre)

Para fornecedores recorrentes com contrato-mestre vigente (ex: concreto usinado, aço), o comprador pode emitir PO direto sem passar por RC/cotação. Vai pela alçada de pedido_compra (gerente para valores > R$ 1k).

3. Manual via UI

Suprimentos → tab Pedidos → "Novo pedido" — para casos especiais.

Conteúdo do PO

Campos críticos

almoxarifado_destino_id

Se preenchido, dispara entrada automática no estoque quando o recebimento for aprovado.

Pode ser configurado:

• Manualmente no PO
• Default por empreendimento (se você opera com almoxarifado central)

→ Estoque

Confirmação do fornecedor

Emitido o pedido, o comprador baixa o PDF e o envia ao fornecedor pelo canal combinado — não há disparo automático pela plataforma. Quando o fornecedor confirma, é o comprador quem marca o pedido como confirmado. Não existe status "aguardando confirmação": até essa marcação o pedido continua emitido.

O fornecedor com acesso ao Portal consulta o pedido a partir de emitido (e enquanto ele estiver confirmado, em_transito, entregue_parcial ou entregue). É consulta em modo leitura: o Portal não registra aceite.

Estados

São 9, e a lista é fechada no banco por uma CHECK em purchase_orders.status — status fora dela não é aceito.

Caminho principal:

rascunho → aguardando_aprovacao → emitido → confirmado → em_transito → entregue_parcial → entregue
   ↑                │
   ├── rejeitado ←──┤        (a alçada recusou)
   └────────────────┘        (a aprovação foi cancelada antes de decidir)

rascunho → emitido                       (nenhuma política de alçada alcança o valor)
qualquer status não-terminal → cancelado (entregue e cancelado são terminais)

• rejeitado — a alçada recusou. O pedido volta a rascunho, para correção e reenvio.
• cancelado — encerra o pedido a partir de qualquer status não-terminal. Pedido com recebimento efetivo não pode ser cancelado: material que já entrou se resolve por devolução, não apagando o documento que o trouxe.
• entregue e cancelado são terminais. Não há saída deles — nem para reabrir.
• De emitido, confirmado ou em_transito o pedido pode ir direto a entregue, sem passar por entregue_parcial, quando a entrega é única.
• De rascunho o pedido vai direto a emitido quando nenhuma política de alçada alcança o valor. Ninguém aprovou — a alçada é que não chegou até ali, e a tela avisa isso.

A transição (não só o valor) é validada no banco por uma allowlist — a trigger tg_po_guard_status_transition —, e ela vale para todo caminho de escrita. Nas telas e rotas de pedido a recusa chega como erro de negócio, nomeando a transição recusada (HTTP 409), não como erro de sistema.

O que não é status do pedido

Alteração do pedido

Quantidade de item só é editável enquanto o pedido está em rascunho ou aguardando_aprovacao. Depois de emitido o valor fica travado — é o que impede uma edição posterior de passar por fora da alçada já aprovada. Para mudar o que foi emitido, cancele e reemita.

Alteração formal numerada, com aprovação e aplicação próprias — o aditivo — existe para contrato de empreitada, não para o pedido de compra. Ver Contratos de empreitada.

Cancelamento

Cancelar leva o pedido ao status terminal cancelado e estorna o comprometido do nó orçamentário. A trigger recusa o cancelamento se houver recebimento efetivo — recebimento rejeitado pela alçada ou do tipo recusa (nenhum item aceito) não bloqueia, porque nada entrou.

Consequência comercial do cancelamento (multa, aviso ao fornecedor) é acordo do contrato, não regra do sistema.

Reserva orçamentária

Emissão do PC converte o compromisso parcial da RC em compromisso total no nó orçamentário. Se valor do PC > valor estimado da RC, o excesso passa pela política de alteracao_orcamento antes da emissão.

Próximo passo

Após PO emitido, fornecedor entrega → almoxarife recebe:

→ Recebimento + 3-way match

Permissões