# Serviços — contas a receber, recebimentos parciais e reconciliação simulada

27/10/2026, Africa/Johannesburg. Versão 0.2. **Âmbito aprovado pelo utilizador; ver secção 12. Sem aplicação de migrações, concessões ou operações por este registo.**

## 1. Base preservada e incremento mínimo

Directório confirmado: `C:\laragon\www\sgf-tempo`. Base Git: `4276aca`, entrega técnica aceite de documento de teste no navegador e PDF. Preservar integralmente alterações posteriores, incluindo a migração `060000` e as oito concessões já aplicadas, respectivas provas e a revisão documental de conformidade. Não fazer checkout/reset desse checkpoint para iniciar este trabalho.

Fontes reutilizadas, sem novo cotejo fiscal do InvesteMoz:

- [Percurso de serviços](SERVICES_WORKFLOW_SPEC.md): cenário 1 000,00 → 400,00 + 600,00, variante redutora e reconciliação simulada. Esta proposta recorta parte de C; não autoriza o fecho ou a contabilidade previstos naquele roteiro.
- [Matriz documental](BILLING_DOCUMENTS_FIELD_SPEC.md): identidade exacta, recebimento, afectação e recibo distintos; FT 10/2026 não se confunde com FT 11/2026 pelo valor.
- [Delimitação B](SERVICES_B_SCOPE.md), [entrega B1](SERVICES_B1_DELIVERY.md), preparação documental, pré-visualização e cálculo aceites: não converter confirmação interna ou cálculo em dívida exigível.
- [Entrega técnica de emissão](SERVICE_INVOICE_TEST_DELIVERY.md), incluindo aplicação posterior da migração/concessões, e [conformidade, secção 11](SERVICE_INVOICE_ISSUANCE_SCOPE.md#11-conformidade--cotejo-dirigido-de-27102026): emissão/configuração real permanecem bloqueadas. Não repetir provas aceites ou reabrir responsáveis/série/fiscalidade.

Leitura dirigida do código actual: `ServiceInvoicing` já fixa documento, fotografia, PDF, identidade, contador, auditoria, evento/outbox e comando idempotente, exclusivamente no ambiente isolado seguro. `si_correction_requests` guarda pedidos sem efeito monetário. `DraftValues`/Brick Math fornecem aritmética decimal exacta; o contexto e as permissões vêm da fundação. Não foram localizados módulos/rotas/migrações operacionais de contas a receber, recebimentos, afectações ou reconciliação na pesquisa dirigida de `app/Modules`, `routes` e `database/migrations`.

| Já existe e deve ser reutilizado | Falta neste incremento proposto |
| --- | --- |
| Cliente/serviço da empresa; documentos da unidade; sessão, CSRF, contexto e permissões explícitas | Obrigação operacional de teste, com abertura explícita e saldo derivado |
| Documento sintético imutável `si_invoices`, identidade e fotografia preservadas | Recebimento proposto/confirmado, afectação explícita e reversões rastreáveis |
| Aritmética exacta, auditoria e padrões transaccionais/idempotentes | Invariantes de disponibilidade, saldo e concorrência entre recebimentos/afectações |
| Eventos/outbox de A, B1 e emissão, com semânticas próprias | Eventos específicos deste percurso; observações e conferência exclusivamente simuladas |
| Pedido de correcção documental sem efeito | Documento redutor sintético independente e aplicação explícita à obrigação, sem correcção fiscal real |

Não reconstruir acontecimentos a partir do estado actual dos cadastros nem consumir eventos B1 como dívida. Reutilizar mecanismos, sem mudar a semântica dos eventos existentes ou activar consumidores contabilísticos.

## 2. Recorte e linguagem da demonstração

Uma empresa sintética, uma unidade, um cliente, um documento de origem sintético e **MZN explicitamente seleccionado no cenário**. Montante documental de teste: 1 000,00, já fixado na fotografia; não recalcular IVA nem deduzir taxa zero desse montante. Não utilizar Tempo Lda/SEGI, Aurora, contas reais ou o cálculo condicionado real como fixtures.

Só admitir como origem uma identidade exacta de documento de teste elegível produzido pelo percurso já aceite. Uma fixture poderá prepará-lo pelos mecanismos existentes; não inserir uma factura fingindo contornar prontidão/guarda. Uma obrigação por documento neste recorte, sem prestações parceladas, múltiplos documentos ou repartição entre unidades/clientes. Integração futura de facturas reais exige âmbito próprio.

Avisos permanentes nas listas, detalhes, observações e comprovativo interno: **«SIMULAÇÃO — SEM MOVIMENTAÇÃO DE DINHEIRO»** e **«TESTE — SEM VALIDADE FISCAL»**. Obrigações e recebimentos de teste não representam dívida ou pagamento reais. Não criar recibo fiscal, factura-recibo, série real ou nova numeração fiscal. Não acrescentar PDF neste incremento: o PDF de origem existente continua preservado.

Excluir câmbio, múltiplas moedas, retenções, descontos financeiros, adiantamentos, afectações entre clientes/unidades, devoluções de dinheiro, taxas bancárias, importações bancárias e conciliação agregada de vários recebimentos. Também fora: lançamentos, reconhecimento, apuramento fiscal, fecho e publicação. Um excesso é uma excepção ligada a esta obrigação existente, não autorização para gerir adiantamentos.

## 3. Entidades, ligações e campos

Todas as entidades operacionais levam ID estável, tenant/empresa/unidade imutáveis, cliente, moeda explícita quando monetárias, marcador sintético controlado pelo servidor, autor, instante de registo UTC e zona/data civil relevante. Contexto validado no servidor; IDs enviados pelo navegador não autorizam relações. Cliente é reutilizado do cadastro empresarial, sem cópia por unidade; o snapshot de origem conserva a identidade histórica.

| Entidade | Ligações e campos específicos mínimos | Efeito próprio |
| --- | --- | --- |
| Documento de origem | ID `si_invoices`; empresa/unidade/cliente; tipo, série, número; versão/hash da fotografia; montante e moeda fixados; referência legível de teste | Fonte documental. Existir não abre obrigação nem regista recebimento neste recorte |
| Obrigação a receber | Documento exacto único; snapshot do montante e identidade usados; fundamento de abertura sintético; data de abertura; vencimento opcional, origem do vencimento e data de corte da consulta; versão e confirmação | Confirmação explícita abre saldo operacional **de teste**. Não determina exigibilidade do IVA ou reconhecimento contabilístico |
| Proposta de recebimento | Obrigação/cliente/contexto; montante positivo; data declarada do recebimento distinta da data de registo; origem sintética e identificador estável do acontecimento; evidência de teste e hash; versão, proponente, estado | Regista declaração ainda por confirmar. Não reduz saldo nem prova dinheiro em banco |
| Confirmação/recusa de recebimento | ID e versão da proposta; decisão, autor distinto, instante, motivo e referências da evidência | Confirma valor recebido de teste disponível para afectação. Não afecta documento nem reconcilia automaticamente |
| Afectação | ID do recebimento confirmado + obrigação + documento exacto; montante positivo, moeda; autor/instante; versões revistas e comando | Reduz saldo do documento e disponível do recebimento, atomicamente. Uma afectação não é outro recebimento |
| Comprovativo interno | Referência técnica estável da confirmação; recebimento e afectações identificados; valores e data de corte da vista | Consulta interna da evidência. Não é recibo fiscal nem novo evento monetário; reabrir não muda montantes |
| Observação de fonte simulada | Fonte/lote de teste, ID externo único nesse âmbito, cliente, moeda, valor, data, referência exacta do recebimento/documento e hash do conteúdo | Evidência artificial independente. Não cria recebimento ou afectação |
| Correspondência de reconciliação | Observação + recebimento confirmado; valores/datas/referências conferidos, decisão, autor, instante, versão e motivo | Marca **reconciliado em simulação**, nunca reconciliação bancária real. Um vínculo activo por observação e por recebimento neste recorte |
| Correcção/reversão operacional | Tipo, alvo exacto, versão, montante/efeito calculado, motivo, proponente, decisão, autores e vínculos de reversão | Operação compensatória imutável. Não edita, apaga ou substitui o original |
| Documento redutor sintético | ID próprio, tipo `TEST-REDUCTION`, documento e linha originais, montante positivo, moeda, motivo, fotografia e validação; aplicação única à obrigação | Redução de teste independente, sem nota fiscal real. Não deriva de `si_correction_requests` |
| Comando, histórico, evento/outbox | Chave, actor/âmbito/acção, hash canónico, versões, correlação/causação, resultado e estado de processamento separado | Recuperação sem duplicação; eventos específicos, sem efeitos contabilísticos ou externos |

Cardinalidades limitadas: documento 1 → 0/1 obrigação; obrigação 1 → N recebimentos ligados; recebimento 1 → N afectações históricas, todas para essa única obrigação; afectação → 0/1 reversão integral; recebimento → 0/1 reversão integral; recebimento 1 ↔ 0/1 observação activa de reconciliação. Documentos redutores ligam-se à obrigação e original sem alterar a fotografia deste. Não implementar um motor geral de distribuição por carteira.

Vencimento desconhecido guarda `null` e pendência, nunca a data actual, zero ou próxima facturação. Datas declaradas futuras/incompatíveis exigem recusa ou pendência explícita segundo o cenário; nenhum relógio de teste passa a data operacional real. Correcções de vencimento exigem nova versão justificada e autorizada, não edição silenciosa; essa autorização é incluída na proposta de correcções abaixo.

## 4. Estados e transições independentes

| Objecto / dimensão | Estados e transições propostos |
| --- | --- |
| Obrigação: abertura | Proposta → aberta por confirmação; proposta → recusada. Documento inválido/rascunho/B1 bloqueia abertura. Não há abertura automática ao receber evento de emissão |
| Obrigação: saldo | Sem afectação / parcial / liquidada, derivados do saldo líquido; pode voltar a parcial/aberta por reversão aprovada, sem apagar liquidação histórica |
| Obrigação: vencimento | Desconhecido / não vencida / vencida, derivado separadamente para saldo positivo na data de corte explícita. Proposta: vencida quando data de corte civil for posterior ao vencimento; no próprio dia ainda não vencida. Saldo zero: liquidada, sem valor vencido actual |
| Recebimento | Proposto → confirmado ou recusado. Só confirmado participa na disponibilidade; confirmado → revertido por decisão compensatória, respeitando dependências. Recusa e correcção da proposta preservam versões |
| Afectação | Pedido válido → aplicada atomicamente; aplicada → revertida integralmente por decisão própria. Pedido inválido não cria afectação aplicada. Não existe estado aplicado com saldo negativo |
| Reconciliação | Não conferida → correspondência proposta → reconciliada em simulação ou divergente. Divergência não reduz diferenças nem confirma recebimento. Reconciliada → desfeita por decisão rastreável; nunca voltar por edição directa |
| Correcção operacional | Proposta → aprovada/aplicada atomicamente ou recusada. Aprovação desactualizada não executa sobre valores entretanto alterados; requer nova revisão |
| Redução documental de teste | Documento sintético preparado → validado → aplicação explícita única à obrigação. Não converte pedido de correcção fiscal em documento válido |

Não usar um único estado «pago/reconciliado». É admissível documento liquidado com dois recebimentos não conferidos; ou recebimento reconciliado em simulação mas parcialmente por afectar, com documento ainda aberto. Nada aqui fecha período ou determina datas fiscais.

## 5. Aritmética, excepções e preservação

Proposta `SGF-RECEIVABLES-SIM-v1`, a aprovar para os testes. Usar Brick Math no servidor, cadeias decimais na API e armazenamento exacto. Reutilizar o limite técnico de até 16 algarismos inteiros/8 decimais das entradas existentes, validando também resultados e capacidade do armazenamento antes de persistir. Para este recorte MZN, montantes devem ser exactamente representáveis a duas casas: aceitar `400`, `400.0`, `400.00` como iguais; recusar `400.001`, notação exponencial, float e valores fora do limite. Não truncar ou arredondar para caber. Esta proposta de representação de recebimentos não altera a política de IVA, preços ou fotografias aceites.

Definições, só com efeitos confirmados/aplicados e não revertidos, na mesma moeda e data de corte:

- `D`: valor fixado do documento; `C`: reduções sintéticas aplicadas; `A`: soma líquida das afectações activas.
- `Saldo_documento = D − C − A`, sempre maior ou igual a zero.
- `R`: valor confirmado do recebimento ainda não revertido; `AR`: afectações activas desse recebimento.
- `Disponível_por_afectar = R − AR`, sempre maior ou igual a zero.
- Montante a afectar `x > 0` deve cumprir **simultaneamente** `x ≤ Disponível_por_afectar` e `x ≤ Saldo_documento`.

Histórico preserva valores exactos originais e compensações; apresentar separadamente original, reduções, recebido, afectado, por afectar e saldo, sem chamar ao total recebido «pago no documento» se não foi afectado. Saldos actuais são projecções verificáveis dos movimentos, não campos livremente editáveis. Totais agregados que ultrapassem a capacidade declarada provocam erro explícito e rollback, nunca overflow/coerção.

| Excepção | Tratamento proposto |
| --- | --- |
| Recebimento superior ao saldo | Registar/confirmar o valor integral com aviso explícito de excesso. Não o cortar nem afectar automaticamente. Afectação acima do saldo é recusada por inteiro; o utilizador pode submeter afectação menor. Excesso fica por afectar e pendente de decisão futura, sem receita, crédito comercial, adiantamento ou reembolso automático |
| Mesmo pedido repetido | Recuperar resultado e identidades originais, sem outro movimento/evento. Mesmo identificador com conteúdo diferente é conflito |
| Mesmo acontecimento com outra chave | Unicidade da origem + ID estável do acontecimento no âmbito impede nova confirmação/recebimento. Mesmo valor/data/cliente não prova duplicação; sinais de possível duplicado mostram alerta, não fusão ou eliminação automática |
| Fonte sem identificador suficiente | Pendência e confirmação bloqueada até atribuição de identidade interna estável da evidência sintética. Não inventar referência bancária |
| Moeda ausente/diferente, outro cliente/unidade ou documento homónimo | Recusa. Sem conversão, transferência de saldo ou procura aproximada por valor |
| Documento já liquidado | Novo recebimento ligado ao documento é excepção de excesso; não reabre dívida. Afectação positiva recusada |
| Redução deixa dívida líquida inferior ao já afectado | Recusar aplicação, preservando proposta. Exigir reversão explícita da afectação suficiente; depois revalidar redução. A quantia libertada fica por afectar, sem devolução automática |
| Reversão do recebimento com afectações/reconciliação activas | Bloquear até desfazer reconciliação e reverter afectações por operações aprovadas separadas. Sem cascata oculta. Reversão do recebimento cancela registo de teste, não executa estorno bancário |
| Erro em recebimento confirmado | Reversão integral rastreável e nova proposta, ligada ao original, se necessária. Não alterar montante, cliente, unidade, data ou moeda do confirmado |
| Divergência de fonte | Mostrar valor declarado, valor observado e diferença exacta. Não compensar diferença, alterar recebimento ou marcar reconciliado por tolerância |

Reversões são integrais neste primeiro recorte; devolução parcial, abatimento ou transferência exigem extensão. A afectação revertida não volta a aplicar-se por replay do comando original: o replay devolve a operação histórica com o seu estado actual; nova intenção necessita nova chave e revisão.

## 6. Reconciliação apenas simulada e comprovativo

Registar observações artificiais num espaço de teste identificável, sem upload de extractos reais ou acesso a bancos. Propor correspondência por referências explícitas; validar recebimento confirmado, identidade do documento/cliente/âmbito, mesma moeda, montante exacto integral e datas da observação declaradas. A data bancária e a data de recebimento são campos distintos; não forçar igualdade nem inferir uma da outra. Sem regra/evidência suficiente, manter pendência. Não fazer matching automático só por cliente, data e valor.

Conferência é acção explícita, com permissão e autor. Neste recorte, correspondência 1:1 e sem tolerância monetária: 399,99 não reconcilia 400,00. Observação repetida com mesmo ID/hash recupera a original; conteúdo diferente para esse ID gera conflito. Não reutilizar observação já conferida noutro recebimento. A reversão da conferência liberta o vínculo por evento compensatório, conservando a história. Uma observação pendente não gera recebimento e uma afectação não gera observação.

Comprovativo interno apenas no navegador, sem série de recibo: identidade técnica do recebimento, estado, evidência sintética, moeda, valores recebido/afectado/disponível, afectações e respectivas identidades documentais. Mostrar data de corte/versão da consulta e reversões; sem substituir silenciosamente uma vista aberta. Se no futuro houver comprovativo emitido/entregue, exigirá fotografia e regras próprias. Não confundir esta vista com recibo fiscal nem marcar o cliente como tendo recebido um comprovativo por o operador o consultar.

## 7. Exemplos sintéticos e resultados esperados

Todos os exemplos usam fixtures independentes; nunca alterar o caso principal para simular uma variante. IDs abaixo são rótulos, não IDs reais fixos. Documento `DOC-TEST-A`, fotografia de 1 000,00 MZN, obrigação `OB-A` aberta explicitamente, sem vencimento informado. Não é necessário refazer o cálculo fiscal da factura para testar o subpercurso; a fixture de origem satisfaz o percurso de emissão de teste já aceite.

| Passo do caso principal | Recebido acumulado | Afectado acumulado | Por afectar | Saldo OB-A | Reconciliação |
| --- | ---: | ---: | ---: | ---: | --- |
| Confirmar abertura OB-A | 0,00 | 0,00 | 0,00 | 1 000,00 | Não aplicável |
| Confirmar R-A de 400,00 | 400,00 | 0,00 | 400,00 | 1 000,00 | Não conferida |
| Aplicar AF-A de 400,00 | 400,00 | 400,00 | 0,00 | 600,00 | Não conferida |
| Repetir confirmação R-A e AF-A | 400,00 | 400,00 | 0,00 | 600,00 | Sem alteração |
| Confirmar R-B de 600,00 | 1 000,00 | 400,00 | 600,00 | 600,00 | Não conferida |
| Aplicar AF-B de 600,00 | 1 000,00 | 1 000,00 | 0,00 | 0,00 | Ambas não conferidas |
| Conferir OBS-A=400 e OBS-B=600 | 1 000,00 | 1 000,00 | 0,00 | 0,00 | Duas correspondências simuladas |

O saldo era zero **antes** da conferência. Repetir conferências não cria movimentos. Sem vencimento, os passos com saldo positivo mostram «vencimento por definir», não «vencido». Com vencimento sintético 10/11/2026 e corte 11/11/2026, 600,00 em aberto são vencidos; corte 10/11 não produz atraso sob a convenção proposta.

Variantes obrigatórias:

1. **Redução:** documento `DOC-TEST-C` de 1 000,00; R-C=400 afectado → saldo 600. Documento independente `TEST-REDUCTION-C`, 100,00, explicitamente ligado ao original/linha, validado e aplicado uma só vez → dívida líquida 900, afectado 400, saldo 500. R-D=500 afectado → saldo zero. Original continua 1 000,00. Repetição da redução não subtrai outros 100; pedido `si_correction_requests` sozinho não reduz nada.
2. **Excesso:** documento de 1 000; primeiro 400 afectado; segundo recebimento 700 confirmado. Tentar afectar 700 recusa, saldo continua 600 e disponível 700. Afectar explicitamente 600 deixa saldo zero e 100 por afectar. Reconciliação simulada de 700 pode ser conferida como recebimento integral; os 100 continuam pendentes. Nenhuma receita/restituição nasce daí.
3. **Divergência:** R=400, observação=399,99 → diferença 0,01; reconciliação divergente, sem alterar afectação ou saldo. Observação para documento B de igual valor não confere R de documento A.
4. **Reversão:** após caso principal, proposta de reversão de R-B é bloqueada pelas dependências; desfazer conferência de R-B e reverter AF-B reabre saldo 600, com R-B=600 por afectar; reverter R-B deixa recebido líquido 400. Originais, decisões e evidências permanecem. Repetir cada reversão tem efeito único.
5. **Redução após liquidação:** tentar reduzir 100 quando 1 000 já afectados recusa por excesso de afectação. Reverter integralmente a afectação de 600, aplicar redução de 100 e afectar de novo 500, com confirmação própria → saldo zero e 100 por afectar. Não automatizar estes passos ou simular devolução.

## 8. Responsabilidades e permissões — proposta nova, sem concessões

As funções de emissão, série, configuração visual e validação fiscal já aprovadas não mudam. **Não implicam poderes de recebimentos.** Propõe-se separação entre preparação e confirmação, com identidade distinta verificada no servidor, inclusive quando houver delegação organizacional. A utilização de uma sessão de outro utilizador não serve como prova técnica de separação de autores.

| Acção / direito proposto | Osmane — proposta | Samira — proposta |
| --- | --- | --- |
| Consultar percurso — `service_receivables.view` | Sim | Sim |
| Preparar obrigação e recebimento/evidência — `service_receivables.prepare` | Sim | Não |
| Confirmar/recusar abertura de obrigação e recebimento — `service_receivables.confirm` | Não | Sim, distinta do proponente |
| Aplicar afectação explícita de recebimento confirmado — `service_receivables.allocate` | Sim | Não |
| Conferir observação e correspondência simuladas — `service_receivables.reconcile` | Não | Sim |
| Propor redução sintética, reversão/desconciliação ou correcção de vencimento — `service_receivables.correction_request` | Sim | Não |
| Validar/recusar e aplicar atomicamente correcção operacional de teste — `service_receivables.correction_approve` | Não | Sim, distinta do proponente |

Proposta: **oito concessões**, quatro por conta: Osmane com view, prepare, allocate e correction_request; Samira com view, confirm, reconcile e correction_approve. Os nomes representam funções propostas, não regras no código. Antes de aplicar acessos, apresentar contas existentes conferidas, acções e âmbito exactos para confirmação específica. Nenhuma concessão é efectuada por este documento.

Todos estes direitos são da unidade explicitamente autorizada da empresa, condicionados também à pertença e `unit.view`; sem direito empresarial que abra operações de outras unidades. Para uma futura aplicação nominativa, propor apenas Tempo Lda/SEGI, sujeita a confirmação específica; desenvolvimento e demonstração usam identidades e âmbitos sintéticos equivalentes em `sgf_tempo_test`. Sem gestão de concessões, poderes universais ou activação de recebimentos reais. A view dá acesso ao comprovativo interno; não autoriza reabrir PDF/documento sem direito próprio.

## 9. Integridade, concorrência, idempotência e recuperação

Propostas técnicas para futura implementação, sem DDL nesta etapa:

1. **Fronteira de ambiente:** nova guarda específica deste percurso permite mutações/provas só em `testing`/`browser-testing` e após `TestingDatabaseGuard` confirmar `sgf_tempo_test` no cluster próprio. Não depender apenas de etiqueta TEST, frontend ou variável de ambiente. Ambiente normal recusa mesmo com permissões. Não relaxar `ServiceInvoicing::guard()` ou reutilizar a aplicação normal para provas.
2. **Isolamento também na base:** FKs compostas/constraints/triggers asseguram igualdade de tenant/empresa/unidade/cliente/moeda entre obrigação, origem, recebimento, afectação, evidência e reversão. Âmbitos, montantes confirmados e snapshots imutáveis, inclusive UPDATE/DELETE em massa. Eloquent scope não é fronteira completa. Inserções por ligação fora do âmbito devem falhar, não apenas os formulários.
3. **Autorização:** revalidar sessão, CSRF, contexto, pertenças, direitos e versões no pedido e dentro da transacção antes do efeito. Revogação/mudança de contexto invalida formulário aberto; não grava noutra unidade. Tarefas/consumidores também verificam origem e ambiente, sem credenciais de administrador ou bypass.
4. **Unicidades:** obrigação por documento; acontecimento por origem/ID estável/âmbito; observação por fonte/lote/ID; decisão terminal por versão; reversão integral única por alvo; aplicação única de redução; correspondência activa 1:1. Uma nova chave HTTP não ultrapassa unicidades de negócio.
5. **Comando idempotente:** chave obrigatória por âmbito/actor/acção, hash canónico das entradas, alvo e versões. Números equivalentes são normalizados exactamente. Repetição idêntica devolve IDs/efeitos já gravados; alteração de alvo/conteúdo/versão gera conflito. Revalidar direito de consulta antes de devolver replay; não revelar resposta de outro autor/unidade. Mesma chave usada noutro contexto não reutiliza resultado anterior.
6. **Saldos sob bloqueio:** bloquear obrigação, recebimentos e vínculos afectados numa ordem global documentada; revalidar saldo/disponível e versões dentro da mesma transacção. Dois comandos que competem pelo mesmo saldo não podem ambos gastar o valor. Operações por SQL directo também devem passar pelos invariantes da base, com serialização dos agregados; CHECK por linha sozinho não controla somas concorrentes.
7. **Atomicidade:** movimento/decisão, projecção de saldo/versionamento, resultado do comando, auditoria e evento/outbox numa transacção. Falha de qualquer parte desfaz o conjunto. Eventos como `receivable.opened`, `receipt.confirmed`, `allocation.applied/reversed`, `reconciliation.simulated_confirmed/reversed` e `synthetic_reduction.applied` têm schema, origem e causação explícitos. Nada os trata como autorização de lançamento ou transferência.
8. **Resposta perdida:** após commit, retry recupera resultado original; antes do commit, nenhum efeito fica aplicado. Pendente de negócio é diferente de erro técnico. Chave de comando em curso não pode bloquear indefinidamente: usar transacção/timeout e retry limitado, sem criar outro acontecimento para contornar erro.
9. **Concorrência e falhas:** conflito de versão exige nova revisão explícita. Deadlock/serialização pode ter retry técnico limitado com a mesma chave, revalidando tudo; não reutilizar decisão de aprovação sobre estado materialmente diferente. Confirmação simultânea, afectações concorrentes e reversão concorrente com reconciliação devem ter um resultado coerente único.
10. **Recuperação e consumidor:** outbox entregue pelo menos uma vez, consumidor interno idempotente por ID de evento; trabalho/estado de entrega separado do evento imutável. Falha após consumir não duplica projecção. Verificação read-only reconcilia movimentos com saldos derivados; divergência gera falha visível, nunca ajuste automático ou reconstrução do histórico. Sem processamento contabilístico.

## 10. Ecrãs mínimos e critérios de aceitação futuros

Reutilizar login, cabeçalho e contexto existentes. Ecrãs: (1) lista/detalhe de obrigação com identidade documental e saldos discriminados; (2) preparação e fila de confirmação de recebimentos; (3) afectação explícita e comprovativo interno; (4) observações e conferência simuladas; (5) pedidos/decisões de correcção e linha do tempo. Podem ser separadores de um mesmo percurso, sem criar portal ou painel geral de tesouraria. Mostrar apenas acções autorizadas, com recusa também no servidor.

Provas a implementar **só após aprovação**, com login real sintético no navegador e instância isolada, sem confundir `actingAs` com prova de autenticação:

- Caso principal e cinco variantes da secção 7, com identidades e somas exactas explicáveis. Liquidar não reconcilia; reconciliar não afecta nem cria recebimento. Rascunho, B1 e simples pedido de correcção recusados como origem de dívida/redução.
- Vencimento desconhecido, no próprio dia, vencido, saldo parcial e saldo zero em cortes explícitos; ausência nunca vira atraso. Datas fiscais e conformidade do caso real permanecem como estavam.
- Zero/negativo, escala excessiva, limite/overflow, moeda em falta/diferente e dados sem evidência recusados sem escrita parcial; 400,00 não se torna 399,99 por tolerância.
- Repetição de cada comando; mesma chave com conteúdo diferente; nova chave sobre mesma origem/observação; repetição após reversão; não duplicar montantes, decisões, afectações ou eventos.
- Dois processos realmente sobrepostos: mesma confirmação; afectações de 400+700 contra saldo 1 000; duas afectações disputando o mesmo disponível; redução/reversão/conferência concorrentes. No cenário 400+700, no máximo uma delas aplica integralmente com as versões iniciais; a outra é recusada/revista, sem saldo negativo ou divisão implícita.
- Falha injectada antes do commit, na auditoria/outbox e resposta perdida após commit; nenhum órfão e um único resultado recuperável. Consumidor repetido e interrompido não duplica projecção.
- URL/API, ID adulterado, empresa irmã do mesmo tenant, unidade não autorizada, outro cliente e dados históricos; revogação com efeito no pedido seguinte e formulário aberto após troca de contexto. SQL em massa não transfere, apaga ou altera originais nem contorna somas.
- Separação de proponente/confirmador, consulta sem alteração, emissão/administração sem novos poderes; aprovações antigas não autorizam novos movimentos. Nenhum acesso empresarial atravessa unidades.
- Guardas recusam base diferente de `sgf_tempo_test`, ambiente normal mesmo com novos direitos, documento não sintético e tentativa de fixture na base normal. Não alterar ligação da aplicação normal nem terminar processos alheios para libertar portas.
- PDF/fotografia de origem, B1, dados/permissões anteriores e oito concessões de emissão preservados. Executar apenas regressões tocadas pelo incremento, sem repetir suites aceites por rotina. Compilação se houver React; no presente documento não foi executado teste ou build.

## 11. Decisões realmente novas e proposta para aprovação

Não pedir novamente regime/IVA, responsáveis de séries/emissão, série nova, plano contabilístico ou aceitação do cálculo. Não condicionar esta demonstração sintética a uma nova pesquisa fiscal. São novas e ainda propostas:

1. **Circuito operacional e acessos:** confirmar a matriz da secção 8, incluindo confirmação por identidade distinta, afectação por Osmane e reconciliação/correcção por Samira. Concessões concretas continuam sujeitas a confirmação específica posterior.
2. **Tratamento das excepções:** confirmar excesso explicitamente por afectar; sobreafectação recusada por inteiro; sem automatismo de reembolso/crédito; reversões integrais com dependências explícitas; redução posterior à liquidação bloqueada até libertar afectação suficiente.
3. **Convenções do ensaio:** confirmar MZN explícito, representabilidade exacta a duas casas, vencido só após o dia de vencimento, ausência de vencimento como pendência, reconciliação 1:1 sem tolerância e comprovativo interno apenas no navegador. São decisões operacionais deste recorte, não validação fiscal de recibos.

**Proposta concreta:** autorizar futuramente um único incremento técnico isolado `SGF-RECEIVABLES-SIM-v1`, com abertura explícita de obrigação sobre documento de teste existente, recebimentos 400/600, confirmação separada, afectações manuais exactas, saldo derivado, comprovativo interno, conferência de duas observações sintéticas, variantes de excesso/divergência/reversão/redução e eventos duráveis. Reutilizar contexto, aritmética e padrões já entregues; acrescentar apenas entidades, comandos e vistas necessários a esse percurso. Não criar motor financeiro geral.

A futura execução deve apresentar o delta aditivo e base de destino antes de qualquer migração em desenvolvimento e as concessões exactas antes de aplicação. Este documento **não aprova nem executa** esses passos. Implementação/demonstração continua restrita à base de testes, sem operações reais, autorização de emissão, recibo fiscal, banco, contabilização ou fecho. Série/configuração real e emissão permanecem bloqueadas; as pendências de conformidade não são encerradas por esta proposta.

## 12. Aprovação do âmbito

Em 27/10/2026, após apresentação da secção 11 e da matriz de permissões, o utilizador respondeu **«confirmo o ambito»**. Ficam aprovados o recorte `SGF-RECEIVABLES-SIM-v1`, o circuito e matriz funcional da secção 8, o tratamento das excepções e as convenções de ensaio da secção 11. As referências anteriores a estas decisões como propostas pendentes são históricas; não devem voltar a ser submetidas como decisões novas.

A aprovação da matriz funcional não aplica as oito concessões: contas, acções e âmbitos exactos continuam sujeitos à confirmação específica antes da aplicação. Mantém-se a apresentação prévia do delta aditivo e base de destino antes de qualquer migração em desenvolvimento. O presente registo apenas documenta a aprovação do âmbito; não executa implementação, testes, migrações ou escrita operacional.

Recebimentos e reconciliação mantêm-se exclusivamente sintéticos em `sgf_tempo_test`, sem recibos fiscais, dinheiro, lançamentos, fecho ou publicação. Preservar `4276aca` e alterações posteriores, aprovações existentes e bloqueio de emissão/configuração real.

## 13. Execução técnica posterior autorizada

Em 27/10/2026, o utilizador autorizou expressamente implementar `SGF-RECEIVABLES-SIM-v1`, código/testes e demonstração apenas no ambiente isolado. A entrega e os resultados estão em [SERVICE_RECEIVABLES_DELIVERY.md](SERVICE_RECEIVABLES_DELIVERY.md). As restrições anteriores a implementação referiam-se à etapa documental e foram substituídas apenas neste âmbito técnico. Migração em desenvolvimento e aplicação das oito concessões reais continuam sem execução e sujeitas às confirmações específicas previstas. A autorização não retira o bloqueio de emissão real nem constitui aceitação da entrega.