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

Incremento posterior, ainda sem aceitação: reversão integral e nova afectação. Substitui apenas a exclusão de desenvolver reversões integrais neste ensaio; mantém os checkpoints aceites, a revisão visual pendente e a ausência de habilitação pública. As demonstrações persistentes não foram actualizadas por consequência deste desenvolvimento.

Actualização de 30/10/2026: consolidação automática sem navegador. Complementa as provas abaixo, sem as substituir; cobertura adicional de repetição da confirmação, identidade distinta e eventos únicos aprovada nas duas composições. Revisão visual continua pendente.

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.

Consolidação do percurso — 30/10/2026

Retoma expressamente autorizada para corrigir utilização nas interfaces existentes, sem novo módulo, habilitação pública ou alteração da página inicial limpa. Esta secção complementa a entrega anterior; não declara aceitação ou encerramento.

Correcções efectuadas:

Trocar função em pagamentos devolvia sempre às obrigações. A entrada QA conserva agora next=payments, limitado a destinos fixos permitidos. Destino externo é recusado; sem parâmetro, permanece o comportamento anterior. Sessão renovada e identidades/permissões revalidadas como antes.
A página de obrigações mostrava o principal mas omitia saldo após afectações novas quando não existia histórico importado. Mostra agora principal preservado, afectações confirmadas e saldo da posição canónica existente, igual à página de pagamentos; nenhum segundo cálculo foi criado.
Entrada e etapas explicam o percurso completo, alternância entre Preparar e Validar e a diferença entre confirmar pagamento e afectar dívida. Versão e validador ficam legíveis sem abrir JSON. «Saldo canónico» passa a «saldo por liquidar».
Pagamentos totalmente afectados deixam de ser oferecidos para novas afectações, permanecendo em consulta/histórico. Não se alterou o comando no servidor nem se criou correcção/reversão.
Detalhes de validação passam a ser apresentados com foco no erro; indicação de processamento e âncora da secção de resultado após sucesso. Repetição do mesmo conteúdo conserva a chave. JavaScript exercitado com DOM/fetch simulados em VM; não é execução visual em navegador.

Verificação automática	Compras	SGF
Factura efectivamente conferida e obrigação reconhecida	11 600 MZN	11 600 MZN
Pagamento proposto	4 000 MZN	4 000 MZN
Confirmação por outra identidade, antes de afectar	Dívida 11 600; por afectar 4 000 MZN	Dívida 11 600; por afectar 4 000 MZN
Proposta de afectação ainda não confirmada	Dívida 11 600 MZN	Dívida 11 600 MZN
Afectação confirmada por outra identidade	Saldo 7 600; por afectar zero	Saldo 7 600; por afectar zero
Repetição com novas chaves	Um pagamento e uma afectação	Um pagamento e uma afectação
Saída/reentrada em Consulta	Histórico/saldo recuperados	Histórico/saldo recuperados
Vencimento e dias de atraso	Nulos; atraso indeterminado	Nulos; atraso indeterminado
Ambas as páginas	Principal 11 600, afectado 4 000, saldo 7 600	Principal 11 600, afectado 4 000, saldo 7 600
Observação visual	Bloqueada	Bloqueada

Prova nova: docs/proofs/supplier-settlements-interface-20261030.json. As páginas e disponibilidade dos formulários foram conferidas por HTTP/HTML; os comandos foram enviados aos mesmos endpoints protegidos dos formulários. Sintaxe do JavaScript renderizado e feedback/reutilização da chave/âncora foram verificados separadamente. Não se automatizaram cliques, disposição, scroll ou submissão num navegador real. A origem mantém base 10 000 e imposto documental 1 600, sem recálculo.

Repetição: C:/laragon/bin/python/python-3.10/python.exe scripts/settlements-interface-run.py, a partir de sgf-tempo. O runner verifica portos livres 8007/8008, provisiona bases/roles descartáveis, instala o schema só nessas bases, corre settlements-interface-check.mjs e remove os seus processos/bases/roles no finally. Não reinicia 8005/8006. Nessas demonstrações persistentes confirmou-se somente entrada/consulta/saída, ligações e perfil de consulta sem formulários: scripts/settlements-persistent-access.mjs e docs/proofs/supplier-settlements-persistent-access-20261030.json. Nenhum comando financeiro foi executado nos cenários persistentes; preservados os desenvolvimentos posteriores de Compras.

As provas anteriores não foram regravadas. O SHA do núcleo SupplierSettlements.php foi comparado com a prova anterior: igual. Motor e adaptadores de autorização/contexto não mudaram; as provas anteriores de concorrência, falha/recuperação e isolamento foram reutilizadas, sem repetir toda a bateria técnica. Sintaxe PHP, check existente de navegação/página inicial limpa e builds das duas aplicações conferidos nesta retoma.

Ficheiros de aplicação alterados: packages/payables/ui/page.php, packages/payables/ui/settlements.php, scripts/payables-demo-entry.php. Acrescentados os três scripts de verificação acima e provas/documentação. Sem dependências, permissões, schema habitual, dados reais, publicação, push ou checkpoint de encerramento.

Bloqueio visual concreto: a skill Computer Use inicializou, mas sky.list_apps() devolveu «Computer Use native pipe is unavailable: failed to connect native pipe (OS error 2)». A skill Browser indicada no catálogo não estava instalada no caminho fornecido. Não se contornaram os bloqueios nem se declararam ecrãs observados. Falta revisão em navegador, incluindo legibilidade, foco, scroll, ecrã estreito e mudança de função. Correcções entregues para revisão, sem aceitação presumida.

Mantêm-se os limites anteriores: sem bancos/caixa, correcções de afectações, novos pagamentos sobre obrigações importadas, reconciliação, contabilidade, stock ou orçamento adicional. Página inicial preservada sem cartões/resumos. O percurso não foi habilitado no domínio público.

14 KiB Raw Blame History