7.6 KiB
Recepção de mercadoria no SGF — entrega funcional QA
03/11/2026. Está implementado o percurso ordem → conferência no SGF → confirmação → movimento único → histórico. A configuração operacional permanece desactivada no destino.
Demonstração utilizável
Nova composição isolada, com uma ordem de 2 cx, nenhuma recepção e nenhum movimento inicial:
- Recebedor sintético: conferência e confirmação.
- Leitor sintético: consulta sem capacidade de confirmar.
- Emissor da ordem: a política original impede receber a própria ordem.
Seleccionar a ordem, preencher guia/data, escolher armazém, marcar a linha e indicar quantidades recebida/aceite, qualidade e artigo. Conferir o impacto e confirmar. Aceitar integralmente 2 cx conclui a ordem; recepção parcial conserva os acumulados. Reservas/rejeições exigem evidência e não se tornam aceitação automaticamente. Abrir a recepção no histórico mostra o documento e o movimento original.
Se a resposta se perder, repetir a mesma confirmação recupera o registo original. O formulário conserva a chave preparada. Alterar campos exige nova prévia; uma origem entretanto alterada exige nova conferência. A prévia tem validade de dez minutos; o histórico permanece consultável sem repetir comandos.
As entradas automáticas acima pertencem apenas ao launcher privado em loopback, fora das rotas operacionais. Cookie, armazenamento e bases são novos; 8039, 8062/8063 e restantes demonstrações permanecem preservadas.
Workflow e autoridade únicos
ReceiptRuntime compõe localmente o ReceiptWorkflow original de Compras, incluindo políticas, validação, conflitos, quantidades cumulativas, auditoria e hooks de lotes/reposição. Não usa um conector HTTP ou um novo algoritmo de recepção. O empacotamento transforma somente tokens PHP de namespace App para permitir coexistência com os modelos SGF. Expressões de negócio e strings não mudam; originais e pacote têm hashes fixados.
O writer físico continua a ser inventory-write/releases/0.1.0, manifesto f0b99e591f9a4df135e685f64ceffad77bed259222debe0f34c20f95e3cad800. Não existe cópia SGF concorrente de recepções ou movimentos. Documento, linhas, movimento, auditoria original e proveniência SGF pertencem à mesma transacção nativa. A proveniência regista contexto/operador SGF, versão da composição e recepção; falhar essa auditoria desfaz a confirmação inteira. Repetições não duplicam efeito ou proveniência.
Operador, tenant de origem, empresa/unidade SGF, ordens e armazéns são ligados explicitamente na fixture. Não se presume equivalência numérica entre identificadores nem se fazem associações automáticas. A prévia cifrada vincula operador, contexto, ordem, revisão, versão da composição e prazo. Na confirmação, o workflow original revalida a operação.
O host bloqueia e revalida os direitos/participação até terminar a transacção nativa; não escreve uma segunda cópia de negócio. Ligação, autenticação e ambiente temporários são restaurados no sucesso e na recusa. O contexto de execução de reposição conserva o singleton original.
Os direitos apresentados durante a implementação são purchasing_receipts.view e purchasing_receipts.confirm, ambos de unidade, apenas nas novas fixtures. Não foram adicionados ao catálogo público ou concedidos a contas reais. A política nativa permanece obrigatória, incluindo separação do emissor. O percurso pertence a Compras e usa sessão, CSRF e geração de contexto. A ligação na página de Compras depende da capacidade explícita e do direito na unidade.
Configuração desligada/produção recusam antes de aceder à fonte. Host, porta, bases/roles, cluster, localização e manifesto estão restringidos às composições QA novas. Não se instala ou activa a candidata de Compras no destino.
Provas dirigidas e reutilização
Manifesto com resultados e hashes: 68 verificações de auxiliares, não 68 percursos de negócio independentes.
| Grupo | Verificações | Resultado |
|---|---|---|
| Percurso HTTP SGF | 30 | Prévia sem efeitos, recepção parcial/qualidade, movimento único, histórico, repetição e recusas de contexto, versão, acesso e quantidade cumulativa |
| Concorrência/recuperação | 10 | Dois workers e sessões independentes: mesma chave201/200; intenções diferentes201/409; falha após inserção física, rollback e recuperação |
| Proveniência atómica | 6 | Falha da auditoria desfaz documento/movimento/auditoria original; recuperação sem duplicação; ordem integralmente aceite chega a complete |
| Contrato de composição | 4 | Desligado/produção sem SQL; contexto nativo e restauração do host |
| Entrada React | 6 | Capacidade/direito/unidade, desligado e preservação de requisições |
| Demonstração sem consumir decisões | 9 | Perfis, página/script e fingerprint de negócio inalterado |
| Assets compilados servidos | 3 | Página inicial e JS/CSS correspondem ao build privado |
Na regressão, uma ordem recebeu 1 cx/0,75 aceite e mais 1 cx/1 aceite: dois movimentos, 1,75 cx no total, com quality_pending. Outro cenário completou 2 cx por quatro recepções de 0,5 cx, incluindo concorrência e recuperação. Estes dados são de regressão; a demonstração continua sem recepções iniciais.
As primeiras21 e depois29 verificações válidas foram conservadas e reutilizadas após corrigir duas expectativas do auxiliar: o validador original devolve422 para armazém de outro tenant antes da verificação de ligação; a tabela nativa de facturas é invoices. Não se repetiram as confirmações já aprovadas nem se apagou a execução parcial. As suites gerais, a fila administrativa e a carga anterior não foram repetidas.
Durante a conferência detectou-se alteração paralela ao GoodsReceiptController de Compras. Foi preservada; esse controlador não é usado pelo adaptador, que chama directamente o workflow original. O pacote continua fixado na versão testada e o manifesto regista os dois hashes, sem adoptar ou sobrescrever o trabalho alheio.
Estado, limites e próximo método de trabalho
Funcionalidade tecnicamente encerrada em QA: interface SGF até ao histórico com workflow e writer originais. A ordem de entrada é uma fixture emitida; não se declara criação/emissão de ordens pela interface SGF ou repetição de adjudicação/aprovação. A instalação geral de procurement continua separada.
O selector apresenta até100 artigos da origem; pesquisa completa de catálogos maiores permanece pendente. Ordens e histórico têm paginação no servidor. Não se validam carga sustentada, revisão visual, Octane com workers persistentes, separação owner/runtime ou capacidade de implantação. As roles novas são proprietárias somente das suas bases QA; o pacote com namespace próprio é uma composição delimitada.
Sem factura, obrigação, pagamento, lançamento ou ligação stock–custos por consequência da recepção. Seis registos protegidos, cache bloqueada, provas/demonstrações anteriores e configurações/direitos reais preservados. Sem publicação, activação no destino, aceitação presumida ou checkpoint.
Após a orientação do utilizador, as próximas entregas devem concluir conjuntos funcionais e reutilizar provas válidas. Definir contratos entre módulos durante a construção e testar as fronteiras alteradas/percurso completo na ligação. Não substituir conclusão de funcionalidades por novos ensaios de optimização.