8.8 KiB
Percurso integrado de conferência financeira e lançamento
02/11/2026 — SGF-PAYABLE-LEDGER-FLOW-SIM-v1. Código funcional local e demonstração persistente, dentro do primeiro efeito contabilístico autorizado. Não constitui conclusão de todos os módulos do ERP.
Entrada e resultado entregue
Abrir http://127.0.0.1:8049/qa/ledger-demo. Escolher Preparar/aplicar, Rever com outra identidade ou Consultar. É outra base/role, no cluster de regressão 55439, com cookie próprio. Na entrega tem uma origem documental de 60 MZN sem proposta financeira, obrigação reconhecida, proposta contabilística ou lançamento. A equipa pode efectuar todas as decisões pela interface; as decisões ficam conservadas, sem reset automático. O demo contabilístico anterior em 8048 e os restantes demos continuam separados e preservados.
O percurso funcional agora é:
- Preparador abre a conferência da origem e prepara a proposta financeira.
- Outra identidade confere a fotografia e reconhece a obrigação.
- Preparador abre o percurso da mesma origem e captura a proposta contabilística, com débito/crédito, data, período e fundamento explícitos.
- Revisor aprova ou recusa a revisão contabilística exacta.
- Preparador aplica uma vez. Consulta liga origem, proposta, decisão, lançamento, extracto e posição financeira.
O ponto de partida é um recibo documental sintético, derivado explicitamente da fixture documental anterior, com novo número/identidade e sem pagamentos. Não é uma nova factura produzida por um workflow vivo de Compras. As fotografias históricas usadas para preparar a fixture permanecem fora do reconhecimento desta origem. Não se declara uma composição operacional Compras → contabilidade nem se duplica autoridade de dívida entre hosts.
Integração no código
GET /general-ledger/flow?source=<origem-local> reúne a cadeia por tenant/empresa/unidade, sob REPEATABLE READ READ ONLY quando dono da transacção. Exige as permissões existentes de consulta financeira e contabilística, pessoa financeira autorizada e contexto Contabilidade. Não executa comandos nem selecciona módulos ou associações por arrasto. Propostas e eventos financeiros são limitados à página da única origem; a captura contabilística mais recente e o lançamento são consultados por obrigação exacta, sem carregar o universo.
O botão na conferência financeira abre o percurso usando POST /api/context existente. A escolha explícita é auditada pelo mecanismo actual, verifica os módulos disponíveis e roda a geração do contexto. Não há troca silenciosa de identidade nem novo endpoint de concessão. O caminho de regresso à posição financeira conserva a origem.
O diário aceita obligation_id: valida existência no âmbito antes de consultar, filtra propostas, revisões, lançamentos, linhas, eventos de preparação/revisão/aplicação e totais. A origem é preenchida no formulário por esta referência; continua a exigir decisão e fundamento. Os comandos mantêm a revalidação actual, os bloqueios e a idempotência existentes. Não se alterou o escritor contabilístico, o cálculo financeiro ou os seis módulos de navegação.
Provas novas e reutilizadas
- 46 verificações HTTP na base nova
0beaac7382b0: sequência completa desde zero obrigações, selecção de módulos existente, contexto antigo 409, fonte indevida/parâmetros injectados 403/422, leitor sem escrita, falta de reconhecimento, falta de revisão, revisão obsoleta, repetições pela mesma/outra chave, conteúdo conflitante, fotografias, links, extracto e relatório financeiro. - 20 verificações de isolamento/integridade: tenant/empresa/unidade indevidos, revogação de cada direito de consulta, retirada de acesso financeiro, leitura coerente sem
FOR UPDATE, recibos, identidades distintas e concessões QA. Sondagens de mutação dentro de transacções revertidas. - 11 verificações de foco: segundo efeito completo construído dentro de uma transacção, dois lançamentos visíveis sem filtro e apenas um conjunto de linhas/proposta/revisão/três tipos de evento por obrigação. Página vazia não repete resultados. O segundo efeito foi integralmente revertido; o original permanece.
- 22 verificações de preparação na base independente
c24bf87a54fd/demo 8049: três funções, páginas, selecção de módulo, cookies separados e ausência de efeitos de negócio. Não foram emitidos comandos financeiros ou contabilísticos nessa base.
Resultado da sequência HTTP: uma obrigação de 60 MZN, um lançamento de débito 60/crédito 60, duas linhas e um evento de aplicação. Repetir não duplica; o relatório financeiro continua com principal e saldo de 60 MZN. As consultas não liquidam a dívida.
O primeiro diagnóstico HTTP completou a escrita, mas detectou um link de retorno em falta na página de consulta. Foi conservado em 01661f3f404d; não foi resetado, repetido ou contado como prova aprovada. O link foi corrigido e a sequência final foi executada numa base nova. Uma preparação do teste adicional de foco detectou importações PHP ausentes no auxiliar, antes de criar o segundo efeito; corrigida, sem alterar o motor. Provas concluídas recusam sobrescrita.
Reutilizados os ensaios anteriores: núcleo contabilístico e concorrência, carga financeira 1.000/5.000/10.000 e páginas 25/100, bloqueio de confirmações e leitura sem bloqueio, fila administrativa, carga, concorrência e HTTP423. Não se repetiram estas suites ou matrizes. Os manifestos anteriores permanecem intactos e têm hashes registados no novo manifesto. A sua fonte corresponde à versão ensaiada então; as alterações actuais de foco/ligação têm as provas novas acima.
Não foram experimentados índices nem realizados benchmarks nesta entrega. Os resultados anteriores mantêm as suas condições: a leitura financeira por página ficou em 67 consultas; o relatório integral de 10.000 posições ainda levou cerca de 12,6 s no ensaio. Isso não é capacidade de implantação validada. O campo flow_query_count do auxiliar de isolamento contém todas as consultas observadas, incluindo as sondagens posteriores; não é uma medição de custo isolado da página e não é usado como benchmark.
Estado e limites concretos
| Capacidade | Estado desta consolidação |
|---|---|
| Conferência financeira → obrigação → revisão → lançamento → extracto/posição | Percurso funcional sintético integrado, entregue e demonstrável em 8049 |
| Writer único, revisão distinta, concorrência, falha/recuperação e repetição | Núcleo anterior preservado; evidência anterior reutilizada, integração/foco novos provados |
| Fila administrativa, leitura conjunta, índices de ensaio e HTTP | Entrega anterior consolidada; seis pendentes não decididos |
| Compra viva → composição SGF → reconhecimento contabilístico | Não entregue por esta passagem; origem actual é recibo sintético |
| Contabilizar liquidações, estornar/corrigir lançamento e fechar/reabrir períodos | Excluídos do primeiro efeito autorizado; não implementados por arrasto |
| Composição contabilística autónoma SGC | Adaptador/instalação não entregues nem activados |
| Fiscalidade, contas reais, operações empresariais e implantação | Pendências de implantação separadas, sem novos acessos/migrações reais |
| Revisão visual e carga sustentada | Pendentes separadas; HTTP não substitui revisão visual |
Novas concessões reais: zero. Direitos QA continuam os quatro já autorizados, seis concessões por fixture nova, sem herdar competências. Sem dependências novas, build público substituído, cache limpa, associação automática, activação de Compras, publicação, aceitação ou checkpoint. Assets já compilados e válidos foram copiados apenas entre storages privados; as mudanças novas são PHP/Blade, sem alteração React que exigisse repetir o build.
Reprodução sem afectar demos
Node/PHP fixados no projecto. scripts/ledger-run.mjs new sgf,ledger-flow-setup cria outra base/role. Usar o tag retornado em scripts/ledger-flow-http.mjs, depois fases PHP ledger-flow-cases e ledger-flow-focus-cases de scripts/payable-history-sgf-proof.php. A base de regressão conserva o resultado; não a usar como demo vazio nem repetir a escrita.
Para outra demonstração, provisionar outra fixture, copiar apenas os assets privados já verificados e executar scripts/ledger-demo.mjs <tag>, depois scripts/ledger-flow-demo-check.mjs <tag>. Credenciais/settings/cookies/logs permanecem na área privada. Nenhum script deve usar as bases empresariais ou a cache protegida.