SGF/docs/SGF_CASH_NEXT_SCOPE.md

Próxima lacuna operacional: Caixa QA

Estado10/11/2026: autorizado, implementado e verificado na8085 — ver SGF_CASH_DELIVERY.md. O diagnóstico seguinte conserva o contexto anterior à aprovação. A directiva executiva autoriza continuar funcionalidades; a regra de apresentar novos direitos antes de conceder acessos continua aplicável. A matriz anterior dos documentos não inclui poderes de Caixa. Não usar service_receivables.view, a emissão de recibos ou a aprovação de uma factura como autorização para despesas ou fecho de Caixa.

O menu de Oficinas → Financeiro declara correctamente Caixa, despesas, abertura e fecho ainda ausentes. A pesquisa em app, packages e serviços nativos de Compras não encontrou motor de Caixa reutilizável. A consulta SELECT-only nas duas bases QA existentes encontrou zero concessões dos quatro direitos propostos. Não foram criados schema, flag, motor, sessão ou movimento de Caixa.

Recorte funcional agrupado

No Financeiro da mesma8085, e regressão existente, um livro de Caixa QA em MZN, com as seguintes funções completas, sem mais demonstrações:

1. Abertura deliberada com saldo inicial explícito0, preparação e revisão distintas, responsáveis e contexto identificados.
2. Conferência individual de um recebimento sintético1000 já efectivamente confirmado na nova factura-recibo. Escolha e declaração explícitas do meio Caixa com comprovativo; o documento anterior não prova por si entrega em numerário. Fonte exclusiva e recuperação por chave. Não emitir outra factura, outro recibo, dívida ou entrada financeira duplicada. Os documentos e a origem anteriores mantêm-se imutáveis.
3. Uma despesa fictícia nova50, com beneficiário, descrição, data e comprovativo QA, preparação e revisão distintas, limite pelo saldo disponível. Sem pagamento real, retenção/imposto presumido ou obrigação a fornecedor criada automaticamente.
4. Contagem950 fundamentada, revisão distinta e fecho só com versão/contexto/origens actuais, movimentos confirmados e valorizados. Divergência não gera ajuste automático. Uma alteração/reversão da origem impede declarar a caixa reconciliada sem nova conferência; não desencadeia reembolso.
5. Histórico e extracto por período, filtros e páginas25/100, indicação de preparador/revisor e estados anteriores/posteriores. Consulta genérica não adquire poderes de movimentação. Não há reabertura de Caixa fechada neste recorte.
6. Duas origens explícitas no mesmo diário: reclassificação1000 D QA-CAIXA/C QA-LIQUIDACAO-CLIENTE, e despesa50 D QA-DESPESA-CAIXA/C QA-CAIXA. A classificação não reconhece dinheiro pela segunda vez. Contabilidade prepara/revê/aplica pelos direitos e writer existentes; fecho de Caixa e conferência do período não ignoram origens ou lançamentos pendentes. Contas/regras apenas nas fixtures QA existentes, sem implantação empresarial.

O exemplo terminado conserva950 na Caixa QA. Os25 lançamentos anteriores e todos os exemplos aceites ficam intactos; só serão acrescentados os dois lançamentos escolhidos e conferidos. Não inferir que QA-LIQUIDACAO-CLIENTE é uma conta bancária real.

Direitos exactos a autorizar

Quatro nomes novos, oito concessões por base QA existente, apenas empresa2/unidade2:

Direito	Perfis QA existentes	Âmbito
cash.view	Financeiro preparação13/revisão14; Contabilidade preparação15/revisão16; consulta17	Consulta e rastreabilidade
cash.prepare	Financeiro preparação13	Abertura, classificação, despesa e contagem propostas
cash.review	Financeiro revisão14	Revisão distinta das propostas
cash.close	Financeiro revisão14	Fecho após contagem preparada por outra pessoa e conferências válidas

Matriz exacta. Não são novos utilizadores/perfis, funções nativas, roles PostgreSQL ou direitos reais/PUBLIC. Não se alteram os direitos de administração ou emissão fiscal. As consultas documentais/financeiras já aprovadas são reutilizadas; não há nova concessão implícita de escrita noutro módulo.

Provas e limites da eventual autorização

Após aprovação: implementar o bloco inteiro, provar primeiro na regressão existente e disponibilizar limitadamente na8085 depois dos testes afectados, sem pedir autorização por campo/teste do mesmo recorte. Ensaiar acesso indevido, isolamento por empresa/unidade/módulo, revisão própria, versão antiga, limites de saldo, fonte já classificada/revertida, duas confirmações concorrentes, repetição sem duplicação e falha/recuperação. Confirmar fecho recusado com divergências/origens pendentes e preservação dos25 lançamentos anteriores. Não repetir suites alheias válidas.

Sem dinheiro, operações, contas ou acessos reais; sem banco, POS, AT, emissão fiscal, salários, reabertura ou ajuste automático. Sem novas bases/portas/demonstrações, SGC, publicação, candidata de Compras, checkpoint ou aceitação presumidos. Os seis registos e a cache bloqueada continuam fora dos alvos. Visual, carga sustentada, conformidade real e implantação permanecem separados.

Provas privadas do diagnóstico: regressão single-integration/20261110-174122-692e202d/cash-rights-readonly.json;8085 single-integration/20261110-174122-55d06675/cash-rights-readonly.json. Ambos SELECT-only, zero concessões/operações.