49 lines
7.7 KiB
Markdown
49 lines
7.7 KiB
Markdown
# 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
|
|
|
|
1. 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.
|
|
2. Preparação propõe um pagamento sintético de **4 000 MZN** com data factual e referências artificiais de facto/evidência `SIM-…`.
|
|
3. 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**.
|
|
4. 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](SUPPLIER_PAYABLE_DELIVERY.md); não substitui as aceitações e limitações anteriores.
|