SGF/docs/SERVICE_RECEIVABLES_SCOPE.md

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: 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: identidade exacta, recebimento, afectação e recibo distintos; FT 10/2026 não se confunde com FT 11/2026 pelo valor.
• Delimitação B, entrega B1, 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, incluindo aplicação posterior da migração/concessões, e conformidade, secção 11: 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. 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.