Máquina de estados do pedido — Estoque e Pedidos

1 · Todos os status e transições

Cada número é uma transição. Clique num número para ver quem dispara e o que acontece.

você pode fazer agora sai do estado atual, mas está bloqueada não sai do estado atual

Nenhuma transição escolhida. Reprovado, Cancelado e Atendido são estados finais: nada sai deles.

De para . Quem: , com . Módulo: .

2 · Quem está usando

O pedido foi feito por A etapa atual designa o seu setor ou perfil?

Etapas de autorização do município Módulo Distribuição e Termos ativo no município Desligado, o pedido aprovado fica parado em Aprovado: não há quem entregue. Veja 06-mapa-de-modulos.html.

Para percorrer o pedido inteiro, troque de perfil a cada passo: o que o Solicitante faz, o Gestor não faz, e vice-versa.

3 · O pedido

Ainda não existe pedido. Use a transição 1 ao lado para criar um.

Pedido 2026/000087 · Setor de Atendimento · dados fictícios

Item	Solic.	Aprov.	Distrib.	Saldo	A entregar

A SEMTRAS usa uma etapa só: o pedido cai numa caixa de entrada vista pela NSUAS 1 e pela NSUAS 2, e o veredito de um servidor de qualquer uma já decide. A quantidade aprovada nesta demonstração é sempre igual à solicitada.

Digite mais que o saldo ou que o aprovado e a entrega é recusada.

4 · O que dá para fazer agora

é um estado final: nenhuma transição sai dele. Para um novo pedido, use “Recomeçar demo”.

Não saem do estado atual

5 · Histórico do pedido

Cada transição grava quem fez, quando e de qual status para qual. É a trilha de auditoria do pedido.

Nada aconteceu ainda.

Quando	Quem	O quê	Status
			→,

6 · Tabela das transições

#	Transição	De	Para	Quem	Permissão	Módulo

Ações que não mudam o status

Regras da máquina

Um só lugar decide: o mapa de transições permitidas fica no enum do status. Nenhuma tela nem classe de ação muda o status por conta própria.
Parcialmente atendido e Atendido são consequência: o sistema compara a quantidade distribuída com a aprovada depois de cada entrega. Ninguém escolhe esses status à mão.
Enviado cobre a análise inteira: o número de etapas é configuração do município. Na SEMTRAS é uma só, e o veredito de um servidor da NSUAS 1 ou da NSUAS 2 decide. Num município com várias etapas, aprovar uma que não é a última não muda o status, só abre a seguinte.
Depois do envio o pedido não é editado. Quem aprova define a quantidade aprovada por item, e a solicitada fica guardada.
Segregação de funções: quem pediu nunca aprova nem reprova o próprio pedido, qualquer que seja o perfil.
Cada transição vai para a auditoria, com usuário, setor, data, hora e status antes e depois.
Entregar depende de módulos: sem Distribuição e Termos o pedido para em Aprovado. A baixa do saldo só acontece se Estoque estiver ativo, e a mudança de localização só se Patrimônio estiver.

Como fica no código

enum StatusPedido: string
{
    case Rascunho = 'rascunho';
    case EnviadoParaAprovacao = 'enviado_para_aprovacao';
    case Aprovado = 'aprovado';
    case Reprovado = 'reprovado';
    case ParcialmenteAtendido = 'parcialmente_atendido';
    case Atendido = 'atendido';
    case Cancelado = 'cancelado';

    /** @return list<self> */
    public function proximos(): array
    {
        return match ($this) {
            self::Rascunho => [self::EnviadoParaAprovacao, self::Cancelado],
            self::EnviadoParaAprovacao => [self::EnviadoParaAprovacao, self::Aprovado, self::Reprovado, self::Cancelado],
            self::Aprovado => [self::ParcialmenteAtendido, self::Atendido, self::Cancelado],
            self::ParcialmenteAtendido => [self::ParcialmenteAtendido, self::Atendido],
            self::Reprovado, self::Atendido, self::Cancelado => [],
        };
    }
}

// Pedido::transicionar() é o único caminho para mudar o status
public function transicionar(StatusPedido $para): void
{
    throw_unless(in_array($para, $this->status->proximos(), true),
        TransicaoInvalida::class);
    $this->update(['status' => $para]);
}

A Policy responde “este usuário pode agora?” e o enum responde “esse caminho existe?”. Os dois têm de concordar. No banco, um CHECK garante que o status é um dos sete valores.

Pontos assumidos nesta página, a confirmar com a SEMTRAS

Reprovado é final. O PDF não diz se o solicitante pode corrigir e reenviar. Aqui ele cria um pedido novo. Se puder reenviar, entra uma transição Reprovado para Rascunho.
Pedido parcialmente atendido que nunca se completa. Sem saldo ou sem interesse, ele fica aberto para sempre, e cancelar não vale depois de uma entrega. Falta uma forma de encerrar com pendência (um status novo ou uma justificativa).
A separação não tem status. O PDF lista sete, e a análise acrescenta a etapa de separação por Compras. Aqui ela é uma ação dentro de Aprovado. Se for preciso enxergar “em separação”, vira um oitavo status.
Cancelar um pedido já separado. A página permite cancelar em Aprovado. Falta decidir o que acontece com os itens separados e se o cancelamento depois da separação precisa de outro perfil.
Quem pode cancelar, e até quando: a página de perfis assume o próprio solicitante, enquanto não houve entrega. Gestor e Distribuição não cancelam.
Veredito simultâneo e revisão. A SEMTRAS definiu uma etapa só, em que basta um servidor da NSUAS 1 ou da NSUAS 2. Falta decidir o que acontece se dois servidores abrirem o mesmo pedido ao mesmo tempo (vale o primeiro a salvar?) e se uma decisão registrada pode ser revista, o que seria uma transição nova.

Status do PDF e transições propostas · pedido, setores e horários fictícios · fonte: docs/requisitos/analise-requisitos.md, seções 2 e 4. Permissões em docs/fluxos/05-perfis-e-permissoes.html, módulos em docs/fluxos/06-mapa-de-modulos.html e fluxo completo em docs/fluxos/01-fluxo-do-sistema.html.