40 lines
5.3 KiB
Markdown
40 lines
5.3 KiB
Markdown
# 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](integration/sgf-cash-access-proposal.json). 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.
|