8.0 KiB
Propostas até à recepção no SGF — bloco funcional QA
03/11/2026. Entregue a interface de propostas → avaliações individuais → comparação → escolha fundamentada → aprovação distinta da adjudicação → ordem → recepção → movimento e histórico, reutilizando os controladores e serviços originais de Compras. Não há selecção ou pontuação inventadas pelo adaptador.
Demonstração disponível
Nova composição8066. Começa com uma requisição sintética aprovada de1UN/100MZN, reserva100MZN e três fornecedores fictícios de origem. Não começa com propostas, avaliações, adjudicação, ordem, recepção ou movimento. São decisões que a equipa pode experimentar.
- Compras: registar propostas, avaliar individualmente, escolher e submeter adjudicação; emitir depois da aprovação.
- Avaliador/conferente: avaliar propostas e decidir a adjudicação por identidade distinta.
- Armazém: receber apenas depois de existir ordem emitida; sem consulta económica ou adjudicação.
Percurso sugerido para reproduzir o ensaio: Compras regista as três propostas, com preços100/120/140MZN e sem desconto, e faz as suas avaliações. O conferente avalia cada uma individualmente. As notas8/5/8 usadas nos testes são apenas valores de ensaio, não estão preenchidas automaticamente. Compras volta a conferir a comparação, escolhe expressamente uma proposta elegível do topo e fundamenta a adjudicação. O conferente aprova ou recusa. Depois Compras emite a ordem e Armazém recebe a mercadoria.
Os formulários também permitem os tipos de desconto já suportados pelo motor original. Quantidades e linhas vêm da requisição; não são redigitadas. Campos de avaliação, fornecedor, escolha e decisão começam por preencher. A comparação incompleta permanece visível, sem tratar avaliações ausentes como zero. O histórico completo tem paginação de25 registos no servidor e consulta da evidência anterior/posterior.
Entradas automáticas de perfil existem somente no launcher privado em loopback.8064/8065 e demonstrações anteriores são preservadas. Cookie, armazenamento e bases desta entrega são próprios.
Reutilização e confirmação
SourcingController chama os métodos originais de QuotationController para registo/avaliação e PurchaseWorkflow para selecção/decisão. Preço, desconto, imposto documental de ensaio, elegibilidade, pontuação, conflitos, aprovações e orçamento continuam sob as regras originais. As bibliotecas económicas e o pacote de namespace permanecem fixados por manifesto. Não foi criada outra autoridade para orçamento ou stock.
Cada operação exige prévia e confirmação individual. A prévia chama o comando original num savepoint de rollback obrigatório: a validação e os montantes apresentados são os mesmos do circuito nativo, sem duplicar fórmulas. Todos os registos temporários, auditoria e alterações de reserva são desfeitos antes de devolver a prévia. Sequências PostgreSQL podem avançar, gerando lacunas de IDs; não se promete ausência de SQL de escrita ou numeração contínua. Não se atribui identificação documental temporária na interface. Esta técnica está limitada às bases QA guardadas e aos comandos seleccionados sem envio externo.
A confirmação revalida direitos/contexto, prazo e revisão, executa novamente o comando original e grava o resultado idempotente em auditoria append-only, na mesma transacção. O recibo inclui operador/contexto SGF, versões de origem, chave, hash do conteúdo e resultado. Falhar esse recibo desfaz também a proposta e a auditoria nativa. Repetir a mesma chave/conteúdo recupera o resultado; outro conteúdo é recusado. Uma prévia adulterada, outra origem ou uma revisão desactualizada não confirma.
Os direitos purchasing_sourcing.view/prepare/evaluate/select/approve são de unidade e foram concedidos apenas nas novas fixtures. As funções nativas também são verificadas. O preparador não aprova a própria adjudicação; a janela de propostas/avaliações fecha quando a adjudicação existe. Repetir um comando já confirmado continua a consultar o resultado original, sem reabrir essa janela. Após dez minutos, consultar o histórico quando a prévia tiver expirado.
A adjudicação nova fica disponível para ordens através da ligação explícita à requisição de origem; não se edita uma lista de IDs depois da criação. A emissão e a recepção usam os percursos já entregues. Não há associação automática de registos antigos a módulos.
Provas e correcção do arranque
Manifesto com resultados e hashes:74 verificações de auxiliares, não74 percursos de negócio distintos.
| Grupo | Verificações | Evidência |
|---|---|---|
| Percurso integrado HTTP | 47 | Três propostas, seis avaliações, comparação nativa, escolha, aprovação, ordem, recepção e histórico; acesso, revisão, falha, repetição e dois workers |
| Guardas de activação | 3 | Contrato do adaptador desligado/produção recusado antes de SQL |
| Integridade do carregador | 6 | Código conhecido executa; alterado, ausente e travessia recusados antes de execução; outros namespaces preservados |
| Demonstração sem consumir decisões | 9 | Capacidades exactas, páginas/scripts e fingerprint canónico inalterado |
| Navegação React | 6 | Capacidade, direito, unidade e preservação de ordens/recepções |
| Build servido | 3 | Página inicial e JS/CSS correspondem ao build privado |
A regressão produziu exactamente3 propostas,6 avaliações,1 adjudicação/decisão aprovada,1 ordem,1 compromisso100MZN,1 recepção e1 movimento físico. A regra de três propostas/dois avaliadores não pôde ser contornada. A escolha não ocorreu automaticamente. Confirmar duas vezes ou em dois workers deixou um único resultado. Uma falha injectada no recibo SGF desfez proposta, linhas e auditorias; retirada a causa, a mesma intenção concluiu correctamente.
A primeira leitura da demonstração atingiu30s no verificador que relia todos os ficheiros do pacote, antes do workflow. A tentativa e o timeout do auxiliar foram preservados. O manifesto continua fixado; cada classe é agora verificada por caminho e SHA256 antes de ser carregada, incluindo dependências ainda não utilizadas. A conferência integral do artefacto também consta do manifesto de entrega. Não se aumentou o limite para converter a falha em sucesso. As seis provas do carregador e a consulta final da demonstração passaram; o percurso de negócio47 já válido não foi repetido por esta correcção.
As provas anteriores dos motores, ordens e recepções foram reutilizadas. Sem suites gerais, repetição da fila administrativa ou novos ensaios de carga nesta entrega.
Fronteiras que permanecem
A entrada ainda é uma requisição nativa sintética aprovada com cadastro de fornecedores preparado. A passagem das requisições internas SGF para essa origem, sem reserva/orçamento duplicados, tem de conservar o seu contrato próprio. A preparação/validação do cadastro de fornecedores na interface SGF, regimes formais de concurso e revisões/cancelamentos posteriores não são declarados entregues aqui.
O orçamento canónico da origem é o único que recebe reserva/compromisso deste percurso; não se copia o efeito para o orçamento do host. O selector mostra até100 fornecedores explicitamente configurados. O cenário financeiro é de ensaio, com imposto zero, sem validação de fiscalidade ou critérios reais de cliente.
Revisão visual, carga sustentada, implantação, separação owner/runtime e workers persistentes continuam pendentes. As roles novas são proprietárias apenas das suas bases QA. Sem factura, pagamento, contabilização ou integração stock–custos por arrasto, publicação, activação de Compras no destino, aceitação presumida ou checkpoint. Seis registos protegidos, cache bloqueada, provas válidas, dados/acessos reais e trabalho alheio preservados.