6.8 KiB
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.
- Armazém — receber depois da emissão.
- Consulta da adjudicação e aprovações, 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: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.