3.4 KiB
Recuperação de comprovativos financeiros integrada — 03/11/2026
A consulta contabilística por chave passa a oferecer três domínios explícitos: Contabilidade, reconhecimento de fornecedor e liquidação de fornecedor. A escolha nunca procura automaticamente noutro motor. O resultado é histórico, do próprio autor no âmbito actual, não valida dependências actuais nem executa/reenvia comandos.
GET /api/general-ledger/financial-receipts/{domain}/{key}, com domain=recognition|settlement, reutiliza os motores financeiros e os callbacks de leitura existentes. Exige acesso à Contabilidade e à origem; liquidação exige ainda o direito próprio payments_view. Sem herança entre direitos, concessões novas ou activação de Compras. O percurso antigo de comprovativos contabilísticos mantém-se.
ReceiptReader restringe os dois domínios a tabelas fixas, filtra tenant/empresa/unidade/autor/chave e exige autorização própria de leitura. Não usa a autorização de comandos como fallback. O host cobre a consulta com REPEATABLE READ READ ONLY. Ausência de domínio instalado é recusa explícita, não saldo zero; chave ausente e chave de outro autor não revelam comprovativos. Respostas usam no-store e recusam parâmetros de contexto.
O formulário partilhado das páginas contabilísticas permite escolher o domínio, faz só GET, limpa o resultado anterior na recusa e mostra JSON como texto. Não guarda pedidos, não inventa resultado quando a chave falta e não permite executar operações pela consulta. Nenhum novo direito, migração, dependência ou efeito financeiro.
43 verificações dirigidas numa base/role nova QA55439 (6070063f42f2):13 de serviço,6 do leitor comum,19 HTTP e5 do JavaScript renderizado em Node VM. Cobrem chave igual nos dois domínios, direitos separados/revogados, autor diferente, filtro de tenant/empresa/unidade, domínio inválido, ausência de autorizador de leitura, UUID/contexto/módulo inválidos, ausência de fallback para Contabilidade, transacção só de leitura, zero bloqueios, escape como texto e ausência de repetição automática.
O comprovativo de reconhecimento provém do workflow efectivo de fornecedor60 já aprovado, executado exclusivamente na fixture nova. Para provar colisão de chaves, o comprovativo de liquidação foi inserido como fixture de infra-estrutura, com qa_fixture=true e state=no_business_effect. Não representa preparação, confirmação ou execução de pagamento. Há zero pagamentos na base; a consulta conserva fontes, direitos e contagens dos dois livros de comprovativos. Um auxiliar de teste precisou de capturar explicitamente o contador no closure antes de gerar a prova válida; a tentativa parcial não é contada.
Manifesto: provas e hashes. Provas anteriores preservadas por hash; suites financeiras e benchmarks alheios não repetidos. Demos anteriores, seis associações, cache bloqueada e trabalho em curso preservados. Sem acessos reais, publicação, activação de Compras ou checkpoint.
Limites: sem arquivo de pedidos perdidos quando a chave já não existe, histórico SGF vivo, comunicação bancária ou nova validação do estado financeiro. Não se instalou esta capacidade no SGC nem se substituíram os pacotes congelados. Revisão visual, carga sustentada e implantação continuam pendentes; HTTP e Node VM não são prova visual ou capacidade operacional.