# Comercial → Recebíveis → Contabilidade — entrega sintética

03/11/2026. `COMMON-LEDGER-SALES-RECEIVABLE-SIM-v1` implementado localmente após a autorização expressa «Autorizar o ciclo sintético proposto», no [recorte apresentado](GENERAL_LEDGER_SALES_RECEIVABLE_SCOPE.md). Inclui código, interface, provas e demonstração própria. Não equivale a aceitação, checkpoint ou conclusão operacional de toda a aplicação.

## Percurso entregue

A factura vem do workflow existente de emissão de teste, incluindo série, cálculo, decisões e PDF imutável. Base **862,07**, imposto documental **137,93**, total **1.000,00 MZN**; o cálculo exacto **137,9312** e a diferença **0,0012** continuam preservados. Não foi criada outra política fiscal.

O núcleo contabilístico único recebe callbacks explícitos do host SGF. O reconhecimento tem três linhas: D `QA-CLIENTES` 1.000 / C `QA-VENDAS` 862,07 / C `QA-IMPOSTO-TESTE` 137,93. A obrigação a receber exige a aprovação financeira existente e não gera outro reconhecimento contabilístico. Recebimentos confirmados de 400 e 600 são afectados explicitamente; cada afectação é capturada, revista por identidade distinta e lançada, D `QA-LIQUIDACAO-CLIENTE` / C `QA-CLIENTES`. A reversão financeira de 400 exige a decisão existente e origina uma proposta contabilística inversa; não devolve dinheiro.

O percurso integral termina com **quatro lançamentos, nove linhas, débitos/créditos brutos de 2.400 MZN e saldo de clientes/recebíveis de 400 MZN**. O fecho QA exige conferência distinta do conjunto de factos e configuração e revalida tudo após obter a serialização da empresa. Não há reabertura.

A interface liga documento/PDF, posição financeira, propostas, decisões, afectações, reversão, impactos contabilísticos, versões, diário/extracto e fecho. As listas são paginadas no servidor em janelas de 25; decisões são lidas em conjunto para os registos visíveis. Não se recalcula a dívida num segundo motor: a posição usa o estado autoritativo de `ServiceReceivables`. As trocas Comercial/Financeiro/Contabilidade são explícitas e verificam a geração de contexto antes do comando. Uma página desactualizada não se autoactualiza para aprovar no contexto de outra aba. Falhas na obtenção do PDF e recusas financeiras devolvem o contexto corrente à Contabilidade.

## Integridade e composição

`SalesSchema` só instala numa base QA SGF nova, com livro vazio. O writer anterior foi alargado, não copiado. As constraints diferidas conferem a quantidade de linhas, contas, montantes e fotografia exacta revista; o trigger de inserção de linhas recusa inclusive uma terceira linha acrescentada posteriormente a um lançamento de duas linhas. A quarta linha é recusada. Originais e decisões permanecem append-only.

As confirmações repetidas revalidam permissões/contexto antes de recuperar o resultado; versões/fontes/regras/períodos alterados exigem nova conferência. Recibos de idempotência, lançamento, linhas e histórico pertencem à mesma transacção. As falhas injectadas nas quatro fronteiras de escrita foram revertidas e a repetição recuperou sem duplicar.

Foi encontrado e corrigido um caso de integração: a obrigação de cliente e a de fornecedor podem ter o mesmo ID inteiro em tabelas diferentes. O filtro antigo `obligation_id` ficou expressamente limitado a efeitos de fornecedor; `sales_invoice_id` identifica a origem comercial. A prova mista mantém um lançamento de cada tipo no mesmo livro e confere ambos no fecho, sem misturar eventos ou totais. A origem de fornecedor desta prova é uma recepção sintética controlada; não demonstra importação histórica SGF viva ou composição completa da interface de Compras.

O SGC autónomo continua a funcionar sem Sales e recusa explicitamente estas origens quando não estão compostas. O artefacto financeiro congelado da entrega anterior e a demonstração 8052 não foram substituídos. As instalações/demos anteriores não receberam o novo schema.

## Guardas e direitos

A opção `SGF_SALES_LEDGER_QA` fica desligada na ausência de configuração. A extensão aceita apenas `testing`/`browser-testing`, opção explícita, PostgreSQL loopback **55439**, cluster de regressão esperado, base `payable_sgf_<12 hex>` e role não elevada `payable_history_sgf_<mesmo identificador>`, com destino efectivo conferido. A regra antiga de `sgf_tempo_test` não foi retirada. Os instaladores existem apenas no harness explícito; o arranque não aplica migrações.

Foram reutilizados direitos existentes, exclusivamente em novas fixtures:

| Perfil QA | Contabilidade | Recebíveis |
|---|---|---|
| Preparação | view, prepare, post, period_prepare, period_close | view, prepare, allocate, correction_request |
| Validação | view, validate, period_validate | view, confirm, correction_approve |
| Consulta | view | view |

São **sete direitos contabilísticos distintos e nove concessões contabilísticas por fixture**, sem os direitos de correcção técnica desnecessários neste ciclo. Os três perfis têm consulta da factura de teste e contexto empresa/unidade. A emissão inicial reutiliza o workflow e identidades fiscais da fixture; a revisão contabilística não concede competência fiscal. As permissões auxiliares do construtor de fixtures foram removidas antes de entregar a nova demonstração. Nenhuma concessão real ou pública foi alterada.

O isolamento aplica-se a tenant, empresa, unidade e associações de módulo. Uma origem não partilhada não aparece no selector nem pode ser capturada pelo ID. Continua a bloquear o fecho se estiver por contabilizar: esconder uma origem da interface não a transforma num período completo.

## Provas

[Manifesto com hashes e resultados](proofs/common-ledger-sales-receivable-20261103.json). As bases de prova e a demonstração da equipa são distintas. Não foram repetidas suites alheias ao incremento.

| Evidência | Resultado |
|---|---|
| HTTP real, CSRF e ciclo completo | 95 verificações; recusas 419/403/409/422, impactos, versões, repetição, quatro lançamentos/nove linhas e fecho |
| Regressão de fonte, regra, período, guardas e recuperação | 3 cenários / 29 verificações; alterações revertidas |
| Schema final e isolamento | 12 verificações; tenant/empresa/unidade, direitos revogados, terceira linha tardia, quarta linha e paginação do histórico |
| Associações por módulo | 4 verificações, incluindo completude do período; alterações revertidas |
| Ciclo completo no schema final | 10 verificações, reconciliação final de documento/PDF/contas e leitura HTTP adicional de 10 verificações |
| Concorrência | 6 processos reais; detalhes abaixo |
| Compatibilidade fornecedor SGF / ciclo SGC | 74 asserções / 23 verificações; SGC também recusa Sales sem capacidade composta |
| Coexistência cliente/fornecedor | IDs coincidentes, filtros/eventos/totais separados, dois lançamentos/cinco linhas e fecho conjunto |
| Demonstração nova | 29 verificações HTTP, três perfis, zero efeitos financeiros/contabilísticos iniciais |
| Formulários renderizados | 10 verificações em Node VM: tipos exactos, chaves estáveis, recusa de geração antiga e recuperação de contexto/PDF |

Na concorrência, dois aplicadores aguardaram a transacção que detinha o bloqueio da empresa; PostgreSQL identificou esperas `tuple`/`transactionid` e a cadeia até ao processo titular. Uma consulta terminou antes da libertação, vendo apenas o estado confirmado. Após rollback do titular, ambos terminaram com **o mesmo lançamento de três linhas**, sem duplicação. Outra confirmação de fecho aguardou uma afectação de 400 que foi efectivamente confirmada pelo titular: respondeu **409**, exigindo nova conferência. Depois de contabilizar a afectação e rever nova fotografia, dois fechos concorrentes devolveram **o mesmo fecho e a mesma versão 2**. Este cenário termina em saldo **600**, dois lançamentos/cinco linhas, e é distinto do percurso integral que termina em 400. Uma verificação posterior, só de leitura, comparou explicitamente a factura actual com `document_revision` nos dois lançamentos e confirmou o hash do PDF.

As provas de 95 verificações HTTP e concorrência precedem o reforço SQL da inserção tardia; continuam válidas para o comportamento nelas medido. O novo schema foi comprovado separadamente pelo ciclo integral, provas SQL/isolamento, coexistência e leitura HTTP final. Uma tentativa inicial de prova de contexto estrangeiro falhou no helper de dados e foi revertida; não é contada como prova aprovada. A prova corrigida usa outra base. O campo histórico `default_sales_flag` da primeira reconciliação final representa a configuração QA activa; a prova específica `sales-defaults.json` verifica separadamente o default ausente **false**.

Os formulários foram exercitados com DOM/rede simulados sobre o JavaScript efectivamente renderizado. Isto não é execução num navegador nem revisão visual. A sintaxe PHP/JavaScript afectada e `git diff --check` são registados no manifesto. PHPStan/Pint não estão instalados neste SGF; não se declaram essas ferramentas executadas nem se acrescentaram dependências.

## Demonstração e limites

Entrada: **http://127.0.0.1:8053/qa/sales-demo**. Escolher Preparação, Validação ou Consulta; o guião permite abrir várias sessões/perfis e percorrer o circuito. Base, sessão, assets e cookie próprios, só loopback. Começa com uma factura realmente emitida pelo workflow de teste e **sem obrigações, recebimentos, afectações ou lançamentos**, para a equipa decidir individualmente. Não usar a demonstração como fixture descartável nem reiniciar decisões da equipa.

Continuam pendentes e separados: revisão visual, carga sustentada e capacidade de implantação; classificação/contas/fiscalidade reais, desenho de permissões SQL operacional e composição operacional entre módulos. Não foram medidos novos volumes de 1.000/5.000/10.000 para este ciclo, criados índices ou declarada capacidade a partir destes ensaios. As provas de carga anteriores permanecem preservadas com o seu âmbito original.

Não foram feitos uso real, migração no destino, publicação, push, activação de Compras, reabertura, lançamentos de stock/custos/salários ou alterações de direitos reais. Os seis registos sem associação, a cache bloqueada, os checkpoints anteriores, as demonstrações anteriores e o trabalho alheio ficaram fora das escritas deste incremento. Não se criou checkpoint nem se presumiu aceitação.