6.4 KiB
Requisição até à recepção na interface SGF
03/11/2026. Entregue uma nova entrada para preparar, editar, submeter e aprovar requisições na interface SGF, sobre o mesmo núcleo e livro de Compras usados pelas propostas, adjudicação, ordem e recepção. O ID da requisição é preservado no percurso completo. Não há cópia de aprovações nem outra reserva no host.
Demonstração8068
- Solicitante: preparar rascunho e submeter.
- Responsável do departamento: decidir a requisição e, mais tarde, a adjudicação, segundo as etapas originais.
- Compras: fornecedores/propostas, avaliação, escolha e ordem.
- Finanças: revisão distinta de fornecedores e avaliação individual de propostas.
- Armazém: recepção e movimento físico.
O contexto principal começa sem requisições, reservas ou compromissos, propostas, decisões, ordens ou recepções. Tem orçamento QA aprovado de1000MZN, centro autorizado e três fornecedores preparados na fixture. Um tenant estrangeiro contém dados negativos próprios e não está ligado a este contexto. As entradas automáticas de perfil existem apenas no launcher privado em loopback; demos anteriores preservadas.
Ensaio comprovado: solicitante prepara1UN/100MZN sem imposto, confere a prévia, confirma o rascunho e submete. O núcleo original reserva100MZN uma vez e exige aprovação distinta. A requisição aprovada aparece em propostas sem editar listas de IDs. Seguem-se três propostas100/120/140, seis avaliações, adjudicação aprovada, uma ordem/compromisso100 e uma recepção/movimento1UN. Uma segunda necessidade de50MZN foi rejeitada, libertando apenas a própria reserva. Uma tentativa de1001MZN foi recusada por insuficiência de orçamento.
O formulário suporta até50 linhas de consumíveis, serviços ou outros, com centro, data, fundamento e montantes explícitos. Nenhum preço, imposto, prioridade ou escolha é pressuposto. Equipamentos/peças e respectivos percursos técnicos não são expostos neste recorte.
Responsabilidade única
O adaptador reutiliza RequisitionWorkflow, InternalRequisitionPort, o ciclo comum InternalRequisitions, as regras originais de StoreRequisitionRequest e o orçamento nativo. Os três ficheiros do ciclo comum são fixados por manifesto e verificados antes do carregamento. As alterações do host limitam-se à configuração das novas fixtures; os movimentos do orçamento do host ficam inalterados durante o percurso.
Uma requisição nova fica admitida pelo contexto de empresa/unidade registado em sgf.request.command; as consultas seguintes a propostas, ordens e recepções verificam essa origem. Não se estabelece equivalência automática entre empresas/unidades. A API mantém funções nativas e direitos do host, com separação solicitante, aprovação, Compras, Finanças e Armazém.
Prévia executa o comando original em savepoint com rollback. Pode avançar sequências, mas não persiste requisições, reservas, avisos internos ou decisões; omite IDs temporários na criação. Confirmação revalida direitos, contexto, manifesto, validade e revisão, executa o comando e grava a origem SGF na mesma transacção. Falhar o recibo desfaz também o recibo nativo, linhas e auditoria. Repetição exacta recupera o resultado; outra carga com a mesma chave é recusada. Versões antigas exigem nova conferência. O histórico nativo é preservado e a interface mostra os25 eventos mais recentes por requisição.
Novos direitos de unidade, apresentados antes da preparação: purchasing_requests.view/prepare/submit/approve, exclusivamente QA. Não se alterou o catálogo público nem se concederam acessos reais. Novas identidades distintas permitem que a revisão de fornecedores por Finanças e a aprovação de requisições/adjudicações pelo departamento coexistam na mesma composição.
Provas e limitações
Prova consolidada: 103 verificações —30 da nova entrada,47 da integração até à recepção, três das guardas, seis da navegação,11 da demo, três do build/assets e três da fixação do pacote. Inclui dois workers201/200, recuperação após falha, permissões revogadas, versões antigas, acesso estrangeiro, reserva/libertação únicas e orçamento do host inalterado.
Entre a preparação QA e a demo surgiram alterações simultâneas no repositório de Compras, incluindo os workflows de ordens/recepções. Não foram alteradas ou desfeitas. A cópia inicialmente observada pela demo foi preservada em separado no directório privado; a demo passou a usar exactamente o pacote nativo testado em QA, mantendo as bibliotecas económicas e do ciclo comum fixadas. Uma prova adicional confirmou a integridade e a leitura do contexto vazio após a fixação. Esta identidade de código não valida implantação ou equivalência de todos os esquemas da base.
O primeiro teste encontrou um nome de tabela incorrecto no próprio verificador, antes dos comandos. Corrigiu-se para cb_budget_entries. O runner passou a exigir a prova da requisição concluída antes de iniciar a prova dependente. Na integração, o teste de repetição usava a identidade de Finanças para uma prévia do departamento; a aplicação recusou correctamente. Preservaram-se as37 verificações válidas e retomaram-se as10 restantes com a identidade correcta. A consulta de repetição usou um envelope QA reconstruído do recibo exacto; não se repetiu a decisão de negócio. Suites anteriores de fornecedores e módulos financeiros foram reutilizadas.
Requisições antigas ir_requests não foram convertidas. Já têm autoridade/reserva no host; a sua passagem exige um protocolo próprio de responsabilidade financeira e recuperação entre bases. Este incremento resolve o percurso de requisições novas, sem simular essa migração ou libertar saldos antigos.
Permanecem separados anexos, catálogos/equipamentos técnicos completos, regimes formais, correcções posteriores e instalação geral. Revisão visual, carga sustentada e capacidade de implantação continuam pendentes. Não houve ligação ao destino, alteração dos seis registos protegidos/cache/demos anteriores, migração/concessão real, activação de Compras, publicação, aceitação ou checkpoint.