Pagamentos e afectações sintéticos — entrega técnica, 29/10/2026

Implementado o incremento seguinte às obrigações, nas duas composições, com uma única implementação financeira. Disponível apenas nas demonstrações isoladas: Compras http://127.0.0.1:8005/demo e SGF http://127.0.0.1:8006/demo. Seleccionar preparação, validação ou consulta; reconhecer primeiro a obrigação existente, com outra identidade, e seguir a ligação «Pagamentos e afectações». Não é uma autorização de utilização real nem aceitação da entrega.

Responsabilidade e código

O código comum reside em packages/payables/src/SupplierSettlements.php, SettlementSchema.php, SettlementHttp.php e ui/settlements.php. Carregamento e apresentação em bootstrap.php e src/Workspace.php. src/Payables.php conserva a responsabilidade única pelo saldo: principal menos histórico confirmado existente e afectações novas confirmadas. Não se escrevem pagamentos externos legados para representar novamente o mesmo facto.

Os adaptadores são app/Modules/Purchasing/SupplierPaymentsController.php no SGF e app/Http/Controllers/SupplierPaymentsController.php em Compras, apoiados nos respectivos SupplierPayables.php. Contexto, pessoa, organização e direitos são revalidados no servidor pelos adaptadores existentes; o motor recebe contexto explícito. Rotas em routes/web.php de cada aplicação. A página anterior de obrigações apresenta a ligação quando disponível. No SGF, resources/js/WorkspaceNavigation.jsx e app.jsx incluem a entrada; nenhuma concessão real foi adicionada.

Não se equiparam tenant, empresa e unidade. Referências factuais são únicas dentro da empresa, mesmo entre unidades; a consulta e execução continuam limitadas pelo contexto autorizado. Não há dependência de vendas ou de um SGF remoto.

Percurso e montantes

A obrigação reconhecida mantém 10 000 MZN de base, imposto documental de 1 600 e principal de 11 600 MZN, sem recálculo fiscal.
Preparação propõe um pagamento sintético de 4 000 MZN com data factual e referências artificiais de facto/evidência SIM-….
Outra pessoa confirma com motivo e referência de evidência. O saldo da obrigação continua 11 600 MZN; o pagamento confirmado tem 4 000 MZN por afectar.
Preparação propõe a afectação de 4 000 MZN à obrigação; outra pessoa confirma. Saldo 7 600 MZN, por afectar zero. Origem, versão, decisões e histórico permanecem consultáveis.

O vencimento continua desconhecido, atraso indeterminado e dias de atraso sem valor. A data factual do pagamento não preenche o vencimento. Montantes são cadeias decimais convertidas exactamente em cêntimos inteiros, sem floats ou arredondamento novo. Não houve substituição ou actualização de dependências.

Pagamento proposto, confirmação e afectação são acontecimentos distintos. Rejeições não alteram dívida. Há afectações parciais, vários pagamentos por obrigação e um pagamento distribuído por vários documentos compatíveis. Excesso fica por afectar. Referências estáveis e conteúdo normalizado impedem duplicações por novas chaves, versões ou pedidos simultâneos; incompatibilidades geram conflito. Comandos, decisões, movimentos, auditoria e eventos/outbox são atómicos e duráveis. A revogação e a separação por actor e pessoa são verificadas também após espera pelo bloqueio.

Provas e alcance

docs/proofs/supplier-settlements.json: ambas as composições aprovadas, mesmo SHA-256 comum 156bd40f3080de66a73c0befd975990e9d7010c2a232a86d751d4db3af4fae93. Factura realmente conferida pelo percurso existente de Compras; sequência 11 600 → confirmação sem abatimento → afectação → 7 600, com vencimento/dias nulos.
Repetição, referências/evidências duplicadas, conteúdo incompatível, insuficiência, rejeição, identidade/pessoa, isolamento, versão alterada, informação insuficiente, revogação, imutabilidade, falha injectada e recuperação aprovados. Doze corridas PostgreSQL entre processos, com esperas de bloqueio observadas; apenas um efeito por facto.
A prova multidocumento usa um adaptador de origem sintético explícito do mesmo núcleo: dois documentos liquidados, terceiro de outro fornecedor intacto, excesso de 400 MZN por afectar e duplicação entre unidades recusada. Não equivale a outro percurso completo de facturas na interface de cada host.
Regressões anteriores de obrigação e histórico aprovadas (payables-http.json, payables-history.json). Compras: 526 testes aprovados, 2 ignorados, 4 383 asserções, SQLite em memória. Ignorados preexistentes: users with two factor enabled are redirected to two factor challenge e security page is displayed. Cobertura MFA permanece pendente; não são testes do efeito monetário, comprovado separadamente.
Builds de SGF e Compras, TypeScript de Compras, PHPStan da aplicação e das novas classes comuns e Pint aprovados. JavaScript da interface conferido sintacticamente.
supplier-settlements-demo-access.json: páginas/API e ligação das obrigações verificadas por HTTP/HTML nas três funções de cada demonstração. Sem comandos monetários nessas bases. Não foi realizada revisão visual nem ensaio manual da equipa. A prova do adaptador não substitui essa revisão.

Automação: scripts/payables-demo.ps1 proof -Settlements, settlements-http-proof.mjs, settlements-probe.php. Bases e identidades de prova descartáveis, separadas das demonstrações e bases habituais. A revisão do navegador continua pendente; não se contornou o bloqueio da ferramenta.

Habilitação e preservação

scripts/settlements-install.php instala nove tabelas ps_*, com restrições e triggers imutáveis, apenas após guarda efectiva de base QA local. Em cada demonstração foram adicionados sete direitos sintéticos às três identidades existentes, sem criar contas, documentos ou pagamentos. settlements-demo-state.php e os recibos supplier-settlements-demo-compras.json / supplier-settlements-demo-sgf.json comprovam por hashes a preservação dos documentos, histórico, contas e acessos anteriores. A demonstração orçamental não foi alterada.

Estas tabelas não constituem uma migração aplicada a desenvolvimento ou produção. O instalador está limitado ao ensaio. Uma futura disponibilização fora de QA exige migração própria, contexto operacional, permissões, backup/restauro e tratamento aprovado dos históricos. Nenhuma base habitual, acesso real, dependência, publicação ou push foi alterado neste incremento.

Limites e próximos passos

Novos pagamentos sobre obrigações provenientes de importação histórica são recusados neste recorte. O circuito de confirmação/rejeição dos pendentes importados continua separado e preservado; não se incorporam liquidações antigas como dívida integral.
Uma ligação pagamento/obrigação é imutável e única. Aumentar posteriormente essa mesma ligação ou reverter uma confirmação exige um futuro percurso explícito de correcção; não está entregue. Outros pagamentos podem afectar a mesma obrigação.
Não há execução de banco/caixa, reconciliação, reembolsos, crédito automático, cobranças, documento fiscal/PDF, contabilidade, stock ou efeitos orçamentais adicionais. Outbox durável não significa ligação bancária ou contabilística entregue.
Fazer o ensaio visual curto nas duas demonstrações e recolher dificuldades da equipa. Depois decidir aceitação e eventual checkpoint exclusivamente local. Não foi criado checkpoint de encerramento.

Esta entrega complementa obrigações a fornecedores; não substitui as aceitações e limitações anteriores.

7.7 KiB Raw Blame History