SGF/docs/GENERAL_LEDGER_SALES_RECEIVABLE_DELIVERY.md

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. 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. 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.