SGF/docs/SGF_ORDER_TO_RECEIPT_DELIVERY.md

# Ordens de compra e recepção no SGF — bloco funcional QA

03/11/2026. Entregue o percurso **adjudicação aprovada → conferência da ordem → emissão única → recepção por Armazém → movimento físico → histórico**, na mesma composição SGF sintética. O fornecedor e as condições já aprovadas não são redigitados ou escolhidos automaticamente pela interface.

## Experimentar

Nova demonstração em8065, sem ordem emitida, compromisso, recepção ou movimento iniciais. A adjudicação sintética de100MZN, 1UN, imposto zero, foi preparada e aprovada distintamente pelos workflows originais. O orçamento canónico tem100MZN reservados; a emissão ainda depende da decisão individual.

- [Compras — conferir e emitir](http://127.0.0.1:8065/qa/enter/actor?open=1).
- [Armazém — receber depois da emissão](http://127.0.0.1:8065/qa/enter/validator?open=1).
- [Consulta da adjudicação e aprovações](http://127.0.0.1:8065/qa/enter/issuer?open=1), sem emissão.

Em Compras, abrir a adjudicação, conferir fornecedor, montante, linhas, entrega e aprovações; abrir o impacto e emitir explicitamente. A fotografia original passa a estar disponível e a acção de emissão desaparece. Repetir uma resposta perdida recupera a mesma ordem.

Entrar depois como Armazém, abrir a ordem em Recepção, preencher guia/data, escolher o armazém e o artigo QA, marcar a linha e indicar1.000 recebida/aceite, qualidade Conforme. Conferir e confirmar. O histórico referencia a ordem efectivamente emitida e o único movimento físico. O emissor não recebe a própria ordem; Armazém não emite ordens.

Estes links de entrada só existem no launcher privado de loopback. A8064 e anteriores permanecem disponíveis no seu âmbito original, sem reset ou substituição. A8065 usa bases, cookie e armazenamento próprios.

## Código funcional

`OrderController` reutiliza `PurchaseWorkflow::canIssue/issue`, `ProposalComparison`, políticas e orçamento originais. Reutiliza também a composição local já entregue para recepções. Não se criou outro motor de selecção, pontuação, orçamento ou stock.

A composição com namespace próprio conserva o pacote original de modelos/serviços. As duas dependências económicas efectivamente usadas, `ProposalScoring` e `QuotationPricing`, são carregadas byte a byte da fonte original, com manifesto separado e recusa de versão incompatível; não se altera o pacote de Compras instalado. A primeira tentativa revelou esta dependência em falta antes de qualquer emissão e foi preservada. Após a ligação exacta, o percurso integrado passou.

O host exige `purchasing_orders.view` ou `.issue`, direitos explícitos de unidade criados somente nas fixtures QA. A política nativa também permanece obrigatória: consulta por funções elegíveis, emissão por Procurement, validação actual de aprovações, conflitos, propostas, fornecedor, montantes e orçamento. Direitos de recepção são distintos. O catálogo/concessões públicos não foram alargados.

A prévia cifrada vincula operador, contexto, adjudicação, revisão dos dados e versões da composição/bibliotecas, com prazo de dez minutos. Na confirmação, a revisão é recalculada e o workflow original revalida a emissão. O documento, linhas, compromisso e auditorias original/SGF pertencem à mesma transacção nativa. Falhar a proveniência desfaz toda a operação. Repetições devolvem a fotografia emitida, sem criar outra ordem ou compromisso.

A unidade SGF está ligada explicitamente à requisição/adjudicação de origem e ao armazém. Uma ordem criada dessa requisição torna-se elegível para a recepção nesse mesmo contexto; não depende de editar depois uma lista de IDs. Isto não associa registos antigos a módulos nem procura equivalências por números ou nomes.

O compromisso pertence exclusivamente ao orçamento canónico da origem. Não é duplicado no orçamento do host SGF; as concessões orçamentais auxiliares da fixture do host foram retiradas por não pertencerem a este bloco. A passagem de uma requisição SGF para a adjudicação nativa ainda precisa do seu contrato próprio. O campo legado `budget_checked=false` do snapshot original não foi reescrito: a evidência efectiva está em `budget_control` e no compromisso canónico provado.

## Verificação do bloco

[Manifesto, provas e hashes](proofs/order-composition-20261103.json):49 verificações de auxiliares, sem contar como49 percursos de negócio independentes.

| Grupo | Verificações | Resultado |
| --- | ---: | --- |
| Percurso integrado HTTP |28| Consulta/prévia, controlo de funções, fonte alterada, permissões revogadas, aprovação inelegível, falha/rollback, dois workers, ordem/compromisso únicos, recepção e histórico |
| Guardas de activação |3| Desligado e produção recusam antes de SQL |
| Demonstração sem consumir decisões |9| Perfis exactos, páginas/scripts e fingerprint canónico preservado; zero ordens, compromissos e movimentos |
| Navegação React |6| Capacidade, direito, unidade, desligado e preservação da ligação de recepções |
| Build privado servido |3| Página inicial e assets JS/CSS correspondem ao build |

Na regressão, uma falha injectada na auditoria SGF deixou ordens, linhas, compromisso e auditoria exactamente no estado anterior. Retirada a causa, dois workers/sessões independentes obtiveram201/200 para a mesma emissão. Ficaram uma ordem, um compromisso100MZN e uma auditoria de cada tipo. A recepção posterior criou um só movimento de1UN e completou a ordem, sem factura ou consumo orçamental por arrasto.

Foram usadas as provas anteriores de recepções e dos motores comuns. A validação nova concentra-se nas fronteiras alteradas e no percurso completo; não foram repetidas suites gerais, avaliações de carga ou provas da fila administrativa.

## Limites e preservação

O bloco parte de uma adjudicação efectivamente aprovada em fixture. A interface SGF de propostas, selecção e aprovação de adjudicações não está entregue por este incremento; não se inventam aprovações para emitir. A demonstração também não é uma instalação operacional de todo o procurement nem uma validação de fiscalidade real.

Revisão visual, carga sustentada, implantação e separação SQL owner/runtime continuam pendentes. As roles novas são proprietárias apenas das suas bases QA. Não há prova de execução Octane com workers persistentes. O selector de artigos da recepção mantém o limite conhecido de100 itens.

Configuração de ordens desligada por defeito; activá-la não dispensa a guarda integral QA. Sem publicação, activação de Compras no destino, contas/acessos reais, pagamentos, contabilização, alteração da ligação stock–custos ou checkpoint. Seis registos protegidos, cache bloqueada, demonstrações/provas válidas e trabalho alheio preservados.