SGF/docs/SGF_SETTLEMENT_PAGED_READ_DELIVERY.md

Pagamentos e afectações SGF — histórico paginado

Continuação posterior: consulta SGF separada dos bloqueios de escrita. O limite de autorização com bloqueios descrito no final corresponde ao estado desta entrega inicial; a continuação preserva os seus dados e provas, sem repetir as medições.

02/11/2026 — SGF-SETTLEMENT-PAGED-READ-SIM-v1. Implementação local sintética, continuação da ligação entre origem e selecção financeira. Fecha a leitura integral do livro de pagamentos na composição SGF de ensaio; não activa operações reais nem altera o cálculo ou os comandos financeiros.

Comportamento entregue

SupplierSettlements::listingPage() fornece quatro janelas independentes, ordenadas por ID decrescente: pagamentos, propostas de afectação, afectações confirmadas e eventos. Páginas de 25/100, contagens e filtros na base. Os parâmetros são payments_page, allocation_proposals_page, allocations_page, payment_events_page, payment_per_page, payment_q (referência literal), payment_state (all/proposed/confirmed/rejected) e payment (ID exacto no contexto).

A selecção de pagamentos por estado/referência/ID é aplicada antes da paginação e, por subconsulta, também às propostas, afectações e eventos desses pagamentos. Não se carregam todos os IDs correspondentes para a memória PHP. % e _ são caracteres literais na pesquisa. Página fora dos limites do resultado devolve janela vazia, sem regressar à leitura integral. Parâmetros desconhecidos, contexto injectado, IDs/estados/páginas inválidos recusam 422; pagamento indisponível no contexto recusa 403.

As decisões são lidas em conjunto para os pagamentos/propostas da página. Por afectar usa a soma de todas as afectações e reversões dos pagamentos apresentados, e não apenas das afectações que aparecem na janela. Propostas/decisões de reversão são carregadas para as afectações da página, com a origem correspondente lida conjuntamente no mesmo âmbito. O histórico preserva as afectações originais revertidas; não as omite nem as abate duas vezes.

A interface tem filtros e paginação para cada lista. Propostas, afectações e eventos permitem abrir o pagamento de origem mesmo quando este está fora da primeira página. Afectações ligam à evidência documental e ao reconhecimento. Os controlos conservam os filtros independentes de documentos e pagamentos; sair do foco de uma origem preserva o filtro de pagamentos. Seguir um link não concede autoridade de confirmação.

O SGF selecciona expressamente o novo leitor no controlador comum. A composição nativa conserva listing() e o contrato anterior, sem substituir o pacote instalado, activar candidatas ou acrescentar configurações reais. A disponibilidade continua limitada às guardas de ambiente/schema do ensaio. Nenhum direito novo foi criado: reutilizam-se supplier_payables.view, pa_access e a autoridade financeira existente.

Ensaio comparável

Base/role novas no cluster isolado 55439, distintas de todas as provas/demonstrações anteriores.61 obrigações de origens sintéticas explícitas reconhecidas com preparação/validação distintas. Um pagamento de 1,00 MZN,60 afectações de 0,01 MZN e uma reversão integral de 0,01 MZN foram registados pelos comandos existentes. Montante por afectar: 0,41 MZN, incluindo a reversão antiga que não está na primeira página de afectações.

Para volume,999 pagamentos são cópias sintéticas declaradas, com referências distintas e estados proposto/confirmado/rejeitado. Não equivalem a 999 workflows completos de compra/pagamento. Total: 1.000 pagamentos, 336 propostas, 393 afectações e 1.008 eventos. O recibo histórico copiado do ensaio anterior permanece íntegro e separado das novas origens sintéticas não históricas.

Estratégia	Tempo ms	Consultas	Pico heap PHP MiB	Pagamentos / propostas / afectações / eventos
Integral anterior	2.236,559	3.038	30	1.000 / 336 / 393 / 1.008
Janelas de 25	36,520	35	24	25 / 25 / 25 / 25
Janelas de 100	42,644	35	24	100 / 100 / 100 / 100
Pagamento original em foco	28,562	36	24	1 / 3 / 25 / 9

Os SHA-256 das quatro janelas de 25/100 são iguais aos recortes correspondentes do leitor anterior, normalizando a ordenação e excluindo apenas a nova referência navegável local_source_id. A posição completa do pagamento original também é igual;0,41 MZN não é calculado pelas 25 afectações visíveis. A terceira página mostra as 10 afectações antigas restantes e a reversão original, sem mudar esse valor.

Condições: PHP 8.4.27, 512M, processo independente por estratégia, aquecimento igual pela consulta do pagamento original, mesma base e sequência integral → 25 → 100 → foco. Uma amostra por estratégia; outros processos locais não controlados. Memória é heap alocado, não RSS; o framework já tinha 24 MiB alocados. Zero pico adicional numa página não significa memória zero. Nenhum índice foi criado ou experimentado; o ganho observado combina janelas limitadas e leitura conjunta. Não se isolou o contributo de cada técnica.

Este ensaio mede 1.000 pagamentos de liquidação. Não substitui nem repete as medições anteriores de 1.000/5.000/10.000 documentos de origem SGF ou nativos; os universos e as dependências são diferentes.

Verificações e preservação

• Seis cenários novos, 53 asserções: janelas independentes/disjuntas, ordenação, totais, filtros nos pais/filhos, pesquisa literal, soma integral com reversão fora da página, origem recuperável e janelas vazias.
• Isolamento exercitado com pagamento e filhos de outra unidade, incluindo uma afectação estrangeira que referencia o pagamento local: não entra na soma, contagem ou resposta. Direito de consulta revogado recusa acesso apesar do direito documental geral.
• Uma leitura anterior não permite confirmar proposta antiga: uma nova reversão actualiza o ciclo; a confirmação antiga recusa e não grava decisão. Falha injectada durante a leitura desfaz a transacção do leitor e a consulta seguinte recupera sem reparação.
• 29 verificações HTTP pelo kernel real: quatro janelas, filtros, foco antigo, 100 registos, 422/403/409, CSRF 419, decisão recusada ao leitor, links/formulários, escape HTML e no-store. Um complemento dirigido verificou que sair da origem preserva o filtro e a página de pagamentos. Servidor temporário loopback 8047 encerrado; nenhum navegador usado.
• Pós-ensaio só de leitura confirmou o fingerprint financeiro integral igual ao baseline após a preparação do volume. Todos os comandos de alteração nos testes foram revertidos; os dados sintéticos preparados ficam conservados na base própria. As provas anteriores foram reutilizadas e conferidas por hash, sem repetir suites alheias, benchmarks ou resets. Sintaxe PHP/JavaScript e diferenças verificadas.

Manifesto: resultados, condições e hashes. Preparação explícita: scripts/settlement-page-run.mjs cria nova base/role e cenário; fases nomeadas não sobrescrevem provas concluídas. Medição: scripts/settlement-page-bench.mjs <tag> reutiliza medições existentes. HTTP: scripts/settlement-page-http.mjs <tag>. Consolidação sem repetir trabalho: scripts/summarize-settlement-page.mjs <tag>. Settings, credenciais, cookies e logs permanecem privados.

Limites separados

A consulta de liquidação conserva os bloqueios de autorização existentes no tenant/empresa e actor. Não se demonstrou melhoria de contenção, concorrência sustentada ou capacidade de implantação. Contagens e filtros ainda fazem trabalho na base sobre os registos correspondentes; uma dependência documental individual pode ser grande. A fotografia é por pedido, sem instantâneo congelado entre páginas visitadas por uma pessoa. Comandos continuam a revalidar saldos, versão/ciclo, independência, permissões e contexto actuais.

Não se acrescentou fornecedor histórico SGF vivo, cutover operacional, execução bancária, reconciliação ou contabilidade. Seis registos protegidos, cache bloqueada, direitos/dados reais, demonstrações e trabalho alheio preservados. Sem migração no destino, activação de Compras, publicação, aceitação ou checkpoint presumidos. Revisão visual, carga sustentada e implantação permanecem pendências distintas.