SGF/docs/SERVICE_RECEIVABLES_DELIVERY.md

SGF-RECEIVABLES-SIM-v1 — entrega técnica isolada

27/10/2026, Africa/Johannesburg. Implementação do âmbito aprovado na secção 12 de SERVICE_RECEIVABLES_SCOPE.md. Pronto para revisão do utilizador; não constitui aceitação. Preservados 4276aca e alterações posteriores. Sem novo checkpoint ou publicação.

Funcional

• Obrigação explícita sobre ID exacto de documento sintético si_invoices, com fotografia e moeda preservadas; documento existente não cria dívida automaticamente. Rascunho/B1 não são origens aceites.
• Propostas imutáveis de obrigação, recebimento, observação e correcção. Cada decisão exige versão exacta e revisão actual da obrigação; confirmação/aprovação por identidade distinta do proponente. Propostas não são editadas: mudança exige nova proposta/revisão, conservando a anterior. Versões não suportadas são recusadas.
• Recebimento confirmado não afecta automaticamente o documento nem comprova reconciliação. Afectação exige comando próprio, saldo disponível e saldo do documento suficientes, na mesma empresa/unidade/cliente/moeda.
• Montantes exactos MZN, sem float ou truncagem: quantias precisam de ser exactamente representáveis a duas casas e respeitar o limite técnico. A base de dados recusa fracções adicionais antes de qualquer arredondamento de coluna. O motor fiscal existente não foi alterado.
• Excesso integral preservado por afectar. Sobreafectação recusada por inteiro; sem crédito, receita, reembolso ou adiantamento automático.
• Saldo, recebido, afectado e disponível derivados do histórico. Vencimento desconhecido não produz atraso; vencido apenas no dia posterior ao vencimento conhecido. Liquidação e reconciliação são dimensões distintas.
• Reconciliação 1:1 exclusivamente simulada, exacta, com observações independentes e identidades explícitas. Divergência permanece registada, sem tolerância; observação não cria recebimento. Reutilização indevida de observação/recebimento conferidos é recusada.
• Reversões integrais por proposta e aprovação; original preservado. Reverter recebimento exige antes libertar afectações e conferência activas, por operações explícitas. Redução sintética identifica documento TEST-REDUCTION-..., linha 1 e original. Redução acima do saldo é recusada; não modifica factura ou pedido fiscal de correcção.
• Comprovativo interno apenas no navegador, com origem, data de corte, revisão, valores e efeitos. Avisos permanentes TESTE — SEM VALIDADE FISCAL e SIMULAÇÃO — SEM MOVIMENTAÇÃO DE DINHEIRO. Não cria recibo fiscal nem novo PDF de recebimento.

Protecção e persistência

ServiceReceivables::guard() recusa execução fora de testing/browser-testing e executa TestingDatabaseGuard: destino efectivo sgf_tempo_test, cluster 127.0.0.1:55432, utilizador de testes próprio. A consulta normal devolve bloqueio e listas vazias sem depender das novas tabelas. Não existe flag de activação real.

Todos os INSERT nas seis tabelas novas têm também trigger que recusa uma base diferente de sgf_tempo_test ou porta diferente de 55432. Relações de documento, cliente, unidade e moeda são validadas na base; UPDATE/DELETE em massa recusados nos registos de história. Guardas de agregado e revisão serializam escritores por empresa, incluindo INSERT directo em SQL. Não se declara RLS ou autenticação de utilizador final por SQL: a autorização por sessão/contexto/direitos é revalidada no servidor, e a ligação administrativa continua uma fronteira distinta.

Comando, efeito, auditoria, evento e outbox ficam na mesma transacção. Chave por empresa/unidade/actor/acção, hash canónico e unicidades de acontecimento protegem repetições e nova chave sobre a mesma origem. Replay exige direito actual; não reaplica uma afectação entretanto revertida. Consumidor interno simulation_integrity_v1 marca entrega idempotente em tabela separada e verifica integridade; não contabiliza nem comunica com bancos.

A consulta bloqueia brevemente a linha da empresa para compor uma vista coerente. Todos os escritores usam a mesma ordem de bloqueio. É uma escolha limitada ao incremento local, com serialização ampla; não é promessa de escala para produção. Formulário antigo recebe conflito, exige actualização explícita e não grava sobre a revisão nova.

Provas e resultados

Ver resultado do navegador, imagem, concorrência e resultado agregado dos testes.

Prova principal efectuada com login real no Edge, sessão/cache isolados, CSRF activo, http://127.0.0.1:8001 e exclusivamente sgf_tempo_test. Não se usou actingAs para demonstrar entrada. As duas identidades sintéticas têm as funções equivalentes à matriz aprovada, sem poderes derivados dos nomes.

Momento observado no navegador	Recebido	Afectado	Por afectar	Saldo do documento
Obrigação confirmada	0,00	0,00	0,00	1 000,00
Dois recebimentos confirmados, antes das afectações	1 000,00	0,00	1 000,00	1 000,00
Afectação de 400	1 000,00	400,00	600,00	600,00
Afectação adicional de 600, antes da conferência	1 000,00	1 000,00	0,00	0,00
Duas observações conferidas em simulação	1 000,00	1 000,00	0,00	0,00

O documento sintético de 1 000,00 foi produzido pelo percurso de emissão já aceite, parametrizando apenas a fixture: preço sem imposto 862,07 + IVA de ensaio documental 137,93 = 1 000,00. Não foi atribuída taxa zero nem alterado o motor fiscal. Isso prepara a origem do ensaio; não valida tributação real.

Os testes abrangem ainda: 400+500 após redução sintética de 100; excesso de 100 por afectar; divergência de 0,01; reversões dependentes e repetidas; redução depois de liquidação; observação repetida/reutilizada; escala/limites, datas/vencimento, evidência ausente, origem e IDs manipulados, separação de autores, consulta sem alteração, revogação, contexto antigo, empresa irmã, unidade não autorizada e SQL em massa. Falhas injectadas no outbox desfazem também o efeito financeiro; resposta perdida recupera o mesmo resultado. Falha e repetição da entrega interna não duplicam efeitos.

Seis cenários com dois processos realmente sobrepostos: mesma confirmação produz um efeito e um replay; 400+700 disputando saldo de 1 000; duas afectações disputando o disponível de um recebimento; escritores SQL concorrentes; reversão versus conferência; duas reduções sobre a mesma revisão. Conflitos não repartem valores silenciosamente e não produzem saldo negativo. A prova SQL insere deliberadamente efeitos sintéticos directamente, apenas para verificar as guardas; não representa um comando autorizado de aplicação ou fluxo com auditoria completo.

Resultado final: 39 testes, 711 asserções, zero falhas/erros; compilação Vite 8.3.5 aprovada, sem alteração de dependências. Filtro relevante: ServiceReceivablesTest|ServiceInvoiceTest|InternalConfirmationTest|DatabaseSafetyTest. A instância do navegador foi parada antes da regressão final; essa regressão recria apenas a base de testes. As imagens/resultados permanecem; os IDs da demonstração não são garantidos numa repetição. A revisão final reforçou a resolução do cliente pela versão imutável em a_history e fixou hash/referência de origem nos novos registos; não depende do rascunho actual. Proposta recusada permanece sem obrigação aberta e sem efeito de atraso.

Percurso exacto para repetir no navegador

Com autorização de demonstração sintética, preparar a base de testes pelo comando de testes abaixo e garantir que não existe outra prova activa. Os preparadores recusam fixtures preenchidas: não apagam dados para conseguir continuar. Se a porta 8001 estiver ocupada, parar e identificar; nunca terminar processos de outro projecto.

powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 test '--filter=ServiceReceivablesTest|ServiceInvoiceTest|InternalConfirmationTest|DatabaseSafetyTest'
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 npm run build
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/browser-proof.ps1 start
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 php scripts/receivables-fixture.php --env=testing

Credenciais aleatórias apenas no ficheiro local protegido já usado pelo preparador, nunca no relatório/chat. Não usar contas reais na instância de prova.

1. Entrar como gestor sintético, seleccionar Empresa Horizonte — Demonstração → Unidade Central — Demonstração → Recebimentos simulados.
2. Escolher documento exacto TEST-SERIE-ISOLADA/1, montante 1 000,00; Propor obrigação, com vencimento vazio para provar a pendência.
3. Sair e entrar como validador sintético; seleccionar mesmo contexto; Confirmar proposta da obrigação. O proponente não pode confirmar a sua proposta.
4. Voltar ao gestor e propor recebimentos 400.00 e 600.00, cada um com data declarada não futura, ID de acontecimento diferente e evidência explicitamente artificial. Voltar ao validador e confirmar cada proposta. O saldo continua 1 000 até haver afectação.
5. Voltar ao gestor e Afectar explicitamente 400 e 600 nos respectivos recebimentos. Conferir saldo zero, disponível zero e ambos ainda sem reconciliação simulada.
6. Preparar duas observações artificiais, escolhendo o recebimento exacto em cada uma, valores 400/600, datas, IDs de observação distintos e evidências de fonte simulada.
7. Voltar ao validador e Conferir correspondência exacta em cada observação. Abrir Consultar comprovativo interno e verificar referência documental, montantes, revisão, autores e avisos. Nenhuma descarga de recibo/PDF novo.
8. Para os cenários concorrentes independentes: sgf.ps1 php scripts/receivables-concurrency.php --env=testing; para verificar/guardar o agregado do caso principal e entregar eventos internamente: sgf.ps1 php scripts/receivables-proof.php --env=testing. Não executar concorrência contra a obrigação principal.
9. Terminar com powershell -NoProfile -ExecutionPolicy Bypass -File scripts/browser-proof.ps1 stop antes de voltar a executar testes destrutivos. A aplicação normal conserva a sua ligação.

Delta aditivo — NÃO aplicado em desenvolvimento

Migração 2026_10_27_070000_create_simulated_receivables.php, com SQL em database/sql/receivables.sql. migrate:status consultado em sgf_tempo_dev confirmou Pending. Foi aplicada/recriada apenas pela suite em sgf_tempo_test.

Cria seis tabelas:

Tabela	Finalidade
sr_records	Propostas/documentos sintéticos e referências imutáveis de obrigação, recebimento, observação e correcção
sr_effects	Decisões, afectações, reconciliações, reduções e compensações imutáveis
sr_commands	Idempotência e resultado recuperável
sr_events	Evento versionado por comando, com origem/correlação
sr_outbox	Captura durável apenas de simulação
sr_deliveries	Marca imutável de entrega do consumidor interno idempotente

Acrescenta FKs, índices de unicidade, CHECKs, funções/triggers próprios para relações, precisão, saldos, revisões, separação de autores e imutabilidade. Amplia o CHECK de permission_grants com sete nomes de acção exclusivamente de unidade; não atribui direitos nem altera alternativas anteriores. Não modifica documentos/B1/cálculos/catálogos ou as tabelas si_*. down() recusa destruição de história; sem reset/fresh ou rollback destrutivo em desenvolvimento.

Proposta pendente, a confirmar antes de executar: aplicar exclusivamente este delta em sgf_tempo_dev, preservando dados/acessos, com comparação de integridade antes/depois. Não executado. Mesmo instalada em desenvolvimento, a guarda de aplicação e os triggers impedem INSERT operacional deste ensaio nessa base. Não é proposta de activação real.

Oito concessões — proposta separada, NÃO aplicada

Contas/âmbito conferidos por leitura através de scripts/receivables-grants-preview.php, que não tem modo de aplicação. Tenant #1, Tempo Lda, empresa #1 / SEGI, unidade #1, sem extensão a outra unidade. Todos os oito direitos estavam ausentes nessa conferência.

Conta existente	Novas permissões propostas, prefixo service_receivables.	Quantidade
#1 — Osmane Nala, nala@tempo.co.mz	view, prepare, allocate, correction_request	4
#2 — Samira Nal, onala@me.com	view, confirm, reconcile, correction_approve	4

Exigem confirmação específica antes da aplicação, separada da migração. Sem gestão destes acessos, herança, emissão, banco, reconhecimento ou fecho. Não foram aplicadas às contas reais; apenas equivalentes sintéticos receberam direitos na fixture de testes. Uma eventual concessão local não permite executar recebimentos reais nem contornar o bloqueio.

Ficheiros e limites

Código novo: app/Modules/Services/ServiceReceivables.php, Http/ServiceReceivablesController.php, resources/js/ServiceReceivablesWorkspace.jsx; integração em routes/web.php e resources/js/app.jsx. Migração/SQL acima. Testes e fixtures: tests/Feature/ServiceReceivablesTest.php, tests/Support/ReceivablesFixture.php; InvoiceFixture ganhou parâmetro de preço com valor anterior preservado por omissão. Scripts: receivables-fixture.php, receivables-worker.php, receivables-concurrency.php, receivables-proof.php, receivables-grants-preview.php. Documentação e provas referidas neste relatório.

Sem dependências/ferramentas novas. Não se modificou o motor exacto, ServiceInvoicing::guard(), fotografias B1 ou aprovações existentes. Não se repetiu investigação fiscal do InvesteMoz nem se lhe acedeu neste incremento. Nenhum dado de demonstração entrou na base normal; migração e direitos novos permanecem pendentes. Não foi produzido recibo fiscal, PDF de recebimento, movimento de dinheiro, lançamento, fecho ou comunicação externa.

Limites deliberados: uma moeda MZN, uma linha e obrigação por documento, um documento por recebimento, conferência integral 1:1, reversões integrais, sem edição de propostas/efeitos confirmados, sem câmbio/adiantamentos/retenções/descontos/reembolso. Uma operação que precise de extensão é recusada; não se finge que cabe no caso simples. Conformidade e emissão/configuração reais continuam bloqueadas. Entrega técnica não significa aceitação do utilizador ou autorização do incremento seguinte.