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

Continuação posterior: [consulta SGF separada dos bloqueios de escrita](SGF_SETTLEMENT_READ_ISOLATION_DELIVERY.md). 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](SGF_PAYABLE_EVIDENCE_FOCUS_DELIVERY.md). 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](proofs/sgf-settlement-paged-read-20261102.json). 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.