compras/docs/cancelamento-ordens-emitidas.md

C2 — cancelamento integral de ordens emitidas

Âmbito autorizado em03/11/2026 exclusivamente para implementação. config/order_cancellation.php mantém enabled=false. A migração000003 não foi aplicada ao piloto,não existem novas políticas publicadas nem ordens canceladas por esta entrega. MFA e acessos existentes permanecem inalterados.

Percurso e responsabilidades

1. Uma política própria da empresa define permissão e vigência deste circuito. Reutiliza o mesmo motor de publicação das políticas de controlo de compras,com tabelas próprias:proponente administrativo e dois validadores administrativos distintos,que devem continuar elegíveis até à publicação. São três identidades administrativas;não há atribuição automática de perfis. A política anterior à emissão permanece separada.
2. Compras pede cancelamento integral,com fundamento e referência/descrição da documentação de suporte. Não pode ser o requisitante original. Reutiliza ordem,fornecedor,artigos,valores e compromisso;chave de operação oculta permite repetição sem duplicar o pedido. Suporte é uma referência textual,não upload de ficheiro ou validação de autenticidade.
3. Só é admitida ordem emitida sem qualquer recepção ou factura,mesmo que rejeitada/estornada. Os pagamentos nativos dependem de factura;existência desta já bloqueia o circuito. Não inclui transferências bancárias,liquidações,reembolsos,notas de crédito ou documentos posteriores.
4. O pedido pendente bloqueia nova execução:recepção,registo de factura,reemissão e preparação/alteração das ligações de importação/entrega. Oculta as opções operacionais aplicáveis,sem apagar os documentos. A suspensão persiste se a capacidade for desligada;não desligar como forma de contornar um pedido pendente.
5. Finanças decide com identidade distinta do requisitante,autor da adjudicação,emissor da ordem e autor do pedido. Função,empresa,conflitos,base e política são novamente conferidos sob bloqueio. A rejeição preserva ordem e compromisso e permite retomar execução. Pode rejeitar um pedido cuja política expirou/mudou;aprovação exige a política publicada preservada ainda vigente.
6. Aprovação e reversão do compromisso são uma transacção única,com auditoria. Replicar a mesma decisão pela mesma identidade não volta a lançar valores;alterar decisão/fundamento é recusado. Pedidos rejeitados são preservados;outro pedido exige nova chave e todas as verificações novamente.
7. Só o requisitante original,na mesma área e com autoridade nativa para requisitar,pode preparar o rascunho ligado,com nova data e justificação. Reutiliza os artigos/estimativa originais,sem copiar propostas,avaliações,validações técnicas,aprovações ou reserva. A ligação evita duplicar rascunhos após repetição e o novo processo segue os percursos existentes.

Documento original e reversão

A ordem emitida é imutável. O seu estado original permanece issued;o estado operacional passa a «cancelamento pendente» ou «cancelada» pela projecção dos registos de cancelamento. A requisição é marcada cancelada na aprovação. Número,linhas,snapshot e aprovações originais não são reescritos. A consulta e impressão identificam o estado operacional;reprodução do original não autoriza execução.

A capacidade aditiva packages/order-cancellation/src/CommitmentReversal.php escreve no mesmo livro canónico budget_entries,sem substituir o pacote orçamental instalado. O seu SHA-256 é conferido antes de executar. Reverte exactamente o compromisso original,na dotação e base originais,por novo lançamento order-cancel-ID,sem recalcular IVA,câmbio ou estimativa. Exige compromisso integral ainda disponível,reserva zero e dotação aprovada. Divergências bloqueiam a decisão. Documentos legados explicitamente sem controlo e sem lançamentos não geram uma reversão fictícia;se o snapshot declara controlo mas faltam lançamentos,o circuito recusa.

Os18hashes dos artefactos existentes são conferidos separadamente;isto não representa nova instalação de pacotes noSGF ou publicação comercial da capacidade. ApenasMZN,como o controlo instalado. A função de reversão exige a transacção e o bloqueio da empresa fornecidos pelo adaptador;outros alojamentos precisam de integração própria,não devem chamar o escritor isoladamente.

Integração e limites

Pedidos e políticas aparecem nas tarefas elegíveis;após cancelamento,o requisitante vê a preparação do rascunho. Ligações focadas conservam acessíveis pedidos pendentes antigos. Registos são paginados e respeitam visibilidade nativa por processo/empresa. A origem abre a ordem ou o processo conforme a autoridade existente,sem conceder acesso adicional.

Desactivar tecnicamente a capacidade não resolve pendências;estas conservam a suspensão. A resolução exige capacidade disponível e decisão autorizada. Publicar política desactivada impede novas aprovações,mas permite rejeitar pendências enquanto a capacidade técnica estiver disponível. Migração,activação e políticas reais exigem preparação e autorização próprias. Nenhuma decisão é tomada automaticamente,nem são enviados avisos externos.

Não inclui cancelamento parcial,recepções/facturas/pagamentos existentes,devoluções,desalfandegamento,compensações,reembolsos ou assinatura digital. Revisão visual,carga e instalação comercial permanecem separadas. Os testes usamSQLite emmemória ePostgreSQL descartável;outros drivers não foram certificados. Provas issued-order-cancellation.json e issued-order-cancellation-pg.json.

Evidências de fecho

Regressão dos percursos afectados:159testes/2014verificações de compras,ordens,recepção,facturas e orçamento. Fecho dirigido após as ligações finais:43testes/284verificações de cancelamento e recepção. Estas baterias sobrepõem-se e não devem ser somadas. PostgreSQL descartável12testes/91verificações,mais3ensaios de processos concorrentes com espera no bloqueio da empresa observada:pedido antes da recepção,recepção antes do pedido e dupla aprovação com uma só reversão. Bases descartáveis removidas.

PHPStan sem erros nos ficheiros afectados,Pint,formataçãofrontend,TypeScript,compilação e18hashes originais aprovados. Capacidade nova de reversão tem hash próprio conferido. A análise passou a reconhecer também o escritor de recepção já instalado,com validação do identificador devolvido,sem alterar o artefacto selado.

Inspecção transaccional só de leitura do piloto confirmou estrutura000003 ausente,zero políticas/cancelamentos,camposMFA vazios e nenhuma atribuição da competência deAuditoria. HTTP porAdmin,Compras eFinanças confirmou circuito indisponível503 e ordens existentes consultáveis,sem comandos de cancelamento/política. Fonte:issued-order-cancellation-pilot.json e issued-order-cancellation-http.json. Sem revisão visual completa ou implantação comercial declaradas.