SGF/docs/SUPPLIER_PAYABLE_DELIVERY.md

Obrigação a fornecedor — entrega técnica em verificação

Continuação SGF de 02/11/2026: adaptador de recibo histórico sintético implementado e provado, reutilizando o núcleo. Supera a ausência absoluta de fornecedor histórico apenas no ensaio por recibos explicitamente reconciliados; não instala fornecedor vivo, migração histórica operacional ou passagem de responsabilidade validada. As limitações históricas abaixo permanecem aplicáveis à implantação e às demonstrações preservadas.

Evolução posterior no projecto Compras: passagem explícita do histórico de pagamentos, PAYABLE-HISTORY-IMPORT-v1, implementada na fonte comum com migração 000022 preparada e activação separada desligada por omissão. Principal integral, dedução única de confirmados, pendentes/rejeitados preservados sem abatimento, revisor distinto e unicidade. Prova PostgreSQL histórica e regressão anterior nas duas composições aprovadas; não aplicada às bases habituais/demos. O adaptador SGF anterior permanece sem fornecedor de histórico; não se declara essa ligação entregue no SGF. Sem novos pagamentos, reconciliação, stock/orçamento ou contabilidade por arrasto.

29/10/2026. COMMON-PAYABLE-SOURCE-SIM-v1, especificação e regras aprovadas. Implementado apenas em QA, sem aceitação ou checkpoint de encerramento presumidos. O exemplo executado é o aprovado mais recentemente: base 10 000 MZN, imposto documental 1 600 MZN, principal 11 600 MZN. Exemplos anteriores de 1 160 MZN na especificação são históricos; não são os valores desta entrega.

Entrada sem palavra-passe — 29/10/2026

Por pedido expresso do responsável, a demonstração admite entrada por função sem procurar credenciais: SGF http://127.0.0.1:8006/demo, Compras http://127.0.0.1:8005/demo. Escolher Preparar, Validar ou Consultar; a empresa/unidade SGF é seleccionada e revalidada no servidor. A página do percurso permite voltar à escolha de função e sair. As sessões são renovadas na troca, os perfis existentes permanecem distintos e nenhuma concessão foi acrescentada. As identidades são sintéticas e partilhadas por função, sem identificar o avaliador real. O cenário/histórico é partilhado e conservado.

Código de entrada: scripts/payables-demo-entry.php, registado exclusivamente por scripts/payables-router.php nos hosts QA já isolados. Não altera o login operacional nem disponibiliza entrada anónima na instalação pública. O motor financeiro permanece inalterado. Prova HTTP scripts/payables-demo-entry-proof.mjs / docs/proofs/payables-demo-entry.json: três funções em ambas as composições, CSRF, recusa de função arbitrária, contexto SGF, saída/reentrada e histórico conservado; sem executar comandos financeiros. Não constitui prova visual. Não é necessário novo build para esta alteração PHP/HTML; nenhuma dependência mudou.

Verificação pública: https://sgf.tempo.co.mz/ responde 200, /api/session responde sem utilizador autenticado e /demo responde 404. Não foi encontrada configuração de implantação nas pesquisas documentais/scripts dos projectos, nem ligação de gestão do alojamento disponível nesta sessão. Não foi possível identificar a base pública ou excluir dados reais por leitura pública. A publicação de uma demonstração sintética separada permanece por executar; os endereços locais não são acessíveis a avaliadores externos. Não se removeu autenticação pública nem se alterou o domínio. A preparação actual é específica do host QA local, não um pacote de implantação pronto para o servidor desconhecido. A avaliação pelo responsável permanece suspensa por falta de acesso público, conforme a mensagem posterior; nenhum encerramento/checkpoint presumido.

Diagnóstico de acesso — prioridade de 29/10/2026

Pedido: recuperar entrada sem novas contas/instâncias, preservar dados, não avançar módulos; eventual reposição de credencial/acesso exige uma confirmação concreta. Nesta passagem não se alterou credencial, concessão ou schema.

Endereço existente	Base efectiva local	Contas / entrada
http://127.0.0.1:8002/avaliar	sgf_tempo_test	Entrada de avaliação existente sem palavra-passe: preparador, validador, técnico e verificador. Também verificadas as credenciais do manifesto original para gestor@example.test, consulta@example.test e contas de oficina.
http://127.0.0.1:8003	budget_core_sgf_4abb58d1cabf	Quatro contas *-orcamento@example.test, acesso separado; não alterado.
http://127.0.0.1:8005/demo	compras_receipts_test_51bb71f4189c	Três funções sintéticas sem palavra-passe; as três credenciais existentes também aceites pelo login normal deste host.
http://127.0.0.1:8006/demo	payable_sgf_a70cf23e6cdf	Três funções sintéticas sem palavra-passe; as três credenciais existentes também aceites pelo login normal deste host.
http://sgf-tempo.test	sgf_tempo_dev	Contas reais locais existentes nala@tempo.co.mz e onala@me.com; sem tentativa de adivinhar ou repor palavras-passe.
http://compras.test	compras_dev	Conta existente nala@tempo.co.mz; verificação de email ainda não registada. As rotas Compras protegidas usam verified; isto pode ser uma segunda etapa após autenticação válida, não erro de palavra-passe nem bloqueio fiscal. Não se alterou verificação.
https://sgf.tempo.co.mz	Não identificável pela leitura pública	Responde 200; sessão anónima. O asset público agora coincide nominalmente com o local (app-CwyD-u3w.js), ao contrário da consulta anterior; isso não prova igualdade de bases/contas. Nenhuma credencial local foi enviada ao domínio público.

O diagnóstico mostra instalações com conjuntos de contas distintos. Os ficheiros payables-demo-*-access.json correspondem exclusivamente a 8005/8006, não a todas as instalações. Todas as seis credenciais desses ficheiros coincidem com os hashes locais e foram aceites via HTTP no host correcto; não se reproduziu palavra-passe inválida nesses pares. Não se conhece a combinação concreta tentada pelo responsável, pelo que não se atribui uma causa única ao erro relatado. Os cookies das demonstrações têm nomes distintos; as concessões por contexto continuam separadas.

Procedimento imediatamente utilizável: abrir http://127.0.0.1:8002/avaliar e escolher Preparar e gerir para explorar o SGF; trocar função pelo ponto de entrada existente. Para Compras, abrir http://127.0.0.1:8005/demo e escolher Preparar ou Consultar. Para o percurso SGF de obrigações, usar http://127.0.0.1:8006/demo. Não há palavra-passe a copiar nesses endereços; não se afirma que os cenários estejam reunidos numa única base. Estes endereços são locais, não links para avaliadores externos.

Verificação: scripts/access-diagnose.php lê configuração efectiva e contas em transacção PostgreSQL READ ONLY, com rollback e sem imprimir segredos/hashes. scripts/access-login-check.mjs verifica as quatro entradas existentes em /avaliar, contexto, consulta e saída, e as seis credenciais existentes de obrigações, consulta e saída; prova sanitizada em docs/proofs/access-recovery.json. Reexecutada a prova existente de entrada livre nos dois hosts e o check de módulos da demonstração integrada. Não se executou operação de negócio. Asserção inicial do teste de redireccionamento foi corrigida para comparar pathname, pois Laravel pode produzir URL raiz sem barra final; não foi necessário mudar a aplicação. Provas HTTP, sem declaração de revisão visual. Emissão fiscal e acessos de entrada mantêm verificações independentes.

Limite público: acesso administrativo a sgf.tempo.co.mz não foi estabelecido; a documentação local de avaliação já regista recusa da chave SSH numa tentativa anterior. Não se repetiu tentativa com outras chaves nem se alterou servidor. Recuperação pública permanece pendente, sem inventar base ou conta remotas. Nenhum novo módulo, conta, instância, alteração de credencial, concessão, publicação ou checkpoint foi efectuado neste diagnóstico.

Resultado e responsabilidade financeira

Uma factura criada e conferida pelos serviços existentes de Compras origina uma proposta e, por identidade distinta, uma obrigação reconhecida no núcleo comum. A origem, fotografia, captura/revisão, decisão e histórico são recuperáveis. O principal é exactamente total_minor=1160000, sem recálculo de imposto ou presunção de aplicabilidade fiscal real.

O vencimento continua nulo. A consulta apresenta «Principal reconhecido — vencimento pendente», «Atraso indeterminado» e «Dias de atraso: sem valor». A consulta com relógio em 2030 conserva estes valores: nenhuma classificação automática de vencida/não vencida ou zero dias de atraso.

Compras já tinha dívida implícita em ExternalPaymentWorkflow::outstanding (total da factura menos pagamentos confirmados). A leitura de uma origem reconhecida neste ensaio passa a obter o principal canónico de Payables, revalidando versão/eligibilidade; não mantém outro principal editável. A factura permanece original documental. Para origens fora do ensaio, o percurso anterior mantém o cálculo existente. No ambiente normal a nova capacidade fica desactivada e não consulta tabelas Payables.

Pagamentos do circuito antigo são recusados para a origem reconhecida do novo ensaio. Documentos com qualquer histórico de pagamentos associado, mesmo pendente, não entram como dívida integral nova; ficam pendentes/conflituosos. Se aparecer história/alteração incompatível após reconhecimento, o principal histórico é preservado e o saldo fica indeterminado/recusado, não recalculado ou liquidado automaticamente. A migração/reconciliação desses históricos e os novos pagamentos continuam fora do âmbito.

Fonte comum, adaptadores e interface

Localização	Responsabilidade
SGF packages/payables/src/Payables.php e bootstrap.php	Fonte única: origem estável, propostas/capturas, reconhecimento, unicidade, comandos, histórico e outbox transaccionais. Contexto/actor/pessoa e callbacks explícitos, sem sessão no motor
SGF packages/payables/src/Workspace.php, ui/page.php	Interface HTML partilhada, com preparação, validação e consulta. Escapa conteúdo, usa sessão/CSRF/contexto do host e não permite editar fornecedor, montantes, imposto ou vencimento
Compras app/Services/SupplierPayables.php	Lê factura, linhas, decisão e pagamentos reais da base QA; confere tenant/perfil/permissões sintéticas e fornece a fotografia; projecta a leitura financeira canónica
Compras app/Http/Controllers/SupplierPayablesController.php, rotas e ligação na página de facturas	Interface/JSON no host autónomo, protegidos pela autenticação/empresa existentes e direitos de função explícitos
SGF app/Modules/Purchasing/SupplierPayables.php e controlador correspondente	Revalida membership, empresa/unidade, direitos e identidade de pessoa; lê uma projecção do documento efectivamente conferido em Compras, mapeada explicitamente para o contexto SGF
SGF routes/web.php, resources/js/app.jsx, WorkspaceNavigation.jsx	Entrada no SGF por Compras → Obrigações a fornecedores — ensaio, sem habilitar a função a contas reais
Compras config/common-payables.php e providers dos dois hosts	Carregamento local do mesmo pacote. Compras aceita artefacto instalado em packages/payables/COMMON_PAYABLES_PATH; fallback para a fonte vizinha só fora de produção. Sem dependências instaladas/actualizadas

Não existe outro motor Payables em App/Services/App/Modules: os adaptadores só tratam origem, autorização e apresentação. O núcleo orçamental aceite não foi alterado. Não se reutilizou contas a receber de clientes como contas a pagar nem se exigiu facturação de vendas. As duas demonstrações são instalações isoladas da mesma capacidade, não duas aplicações a comunicar em cada operação.

Origem exacta, integridade e versões

O cenário de origem usa fixture própria em packages/payables/tests/ReceiptFixture.php para os pressupostos fixos 10 000/1 600/11 600; os comportamentos são executados por ReceiptWorkflow, BudgetWorkflow e InvoiceWorkflow::register/validate existentes, não por um novo conferidor. A factura fica validated, com actor/data e evento invoice.validated recuperáveis. A preparação dessa origem cria os efeitos normais de recepção/conferência antes do baseline da prova; a ligação Payables não os repete.

A identidade canónica combina instância de origem persistente, empresa de origem e ID estável da factura; o tipo de origem está delimitado pelo adaptador de facturas de fornecedor. A restrição comercial empresa/fornecedor/número normalizado já é assegurada pelo cadastro Compras. Não existe neste recorte outro importador público que aceite livremente esses identificadores ou monte documentos novos no browser. Importações gerais/aliases entre origens distintas exigirão validação de identidade própria antes de implantação.

source_revision é hash canónico do documento/linhas/decisão, não uma coluna de versão nativa inventada. capture_version identifica propostas/capturas imutáveis; uma versão nova não é chave para criar outra dívida. IDs locais de apresentação e contagem de pagamentos não entram no hash material, mas o histórico de pagamentos é revalidado separadamente em todas as decisões/replays. O original e todas as propostas anteriores permanecem append-only.

No SGF, o provisionamento importa privadamente uma projecção da mesma factura conferida, produzida pelo adaptador Compras e com recibo/hash de integridade. O hash não é assinatura digital nem uma nova validação de autenticidade; a proveniência desta prova é a execução local documentada dos serviços Compras. Não existe redigitação ou upload de factura no SGF. As provas de alterações de origem usam injecção adversarial em bases descartáveis, nunca nos exemplares da equipa ou em dados reais.

Atomicidade, estados e segurança

• Um preparador propõe; o validador deve ter outro ID e outra identidade de pessoa. Direitos/contexto e o mapeamento de pessoa são revalidados dentro do bloqueio da organização, inclusive após espera e em repetição.
• Origem sem fornecedor, moeda MZN, valores/linhas ou decisão sustentados fica pendente/conflituosa, sem principal zero presumido. Falta de vencimento é independente e não impede o reconhecimento aprovado do principal.
• pa_sources.source_key é único globalmente no ledger; pa_obligations.source_id é único e não inclui revisão ou chave de comando. Pedidos com chaves diferentes não duplicam a obrigação. Mesmo comando/conteúdo recupera o resultado; conteúdo divergente com a mesma chave é conflito.
• Proposta, obrigação, evento, outbox e resultado do comando são atómicos. Eventos são captura durável, sem publicar para contabilidade ou serviços externos. As tabelas de origem/histórico/obrigação/comando/outbox têm triggers append-only em QA.
• Alteração de origem ou revisão desactualizada produz conflito registado com hash observado e preserva principal/decisão originais. Não altera total, reduz dívida ou substitui original automaticamente. Não há circuito de correcção monetária/anulação nesta entrega.
• CSRF, autenticação e, no SGF, token de contexto mantêm-se activos. Os scripts de falhas/concorrência recusam as bases persistentes da equipa e só operam nas bases descartáveis de prova.

Demonstrações para a equipa

Compras autónomo: http://127.0.0.1:8005/obrigacoes-fornecedores. Entrar normalmente em /login; a página de facturas também apresenta a ligação no contexto sintético elegível.

ERP SGF: http://127.0.0.1:8006. Entrar, seleccionar Horizonte Sintética — Obrigações / Unidade de obrigações, abrir Compras → Obrigações a fornecedores — ensaio e a ligação de preparação/consulta. A página partilhada conserva autenticação e contexto; não se abre uma sessão remota no outro produto.

Função	Conta sintética nos dois hosts	Acções
Preparação	preparacao-obrigacoes@example.test	Consultar origem e preparar proposta, sem redigitar montantes
Validação	validacao-obrigacoes@example.test	Consultar e reconhecer a revisão exacta por identidade distinta
Consulta	consulta-obrigacoes@example.test	Origem, principal, pendências, decisão e histórico; sem comandos de escrita

Passwords aleatórias próprias de cada instalação estão apenas nos ficheiros locais protegidos C:\laragon\data\sgf-tempo\secrets\payables-demo-compras-access.json e payables-demo-sgf-access.json, campo accounts. Consultar localmente; não copiar para chat, capturas ou repositório. Nenhuma conta/concessão real foi alterada.

Guião: preparador selecciona FT-SIM-11600 e fundamenta; validador consulta a fotografia/captura e reconhece; consulta confirma 11 600,00 MZN, origem/versão e vencimento/dias nulos. Repetir a preparação/validação deve recuperar a mesma identidade. Não há formulário de pagamento, cobrança, data inventada, stock ou lançamento. O cenário foi preparado sem propostas/reconhecimentos pré-preenchidos; a revisão da equipa permanece por realizar.

powershell -NoProfile -ExecutionPolicy Bypass -File scripts/payables-demo.ps1 status
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/payables-demo.ps1 start
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/payables-demo.ps1 stop

As duas bases/roles são próprias e restritas (sem superuser, CREATEDB ou CREATEROLE), com sessões/caches/cookies/chaves separados. O provisionamento usa a ligação local de manutenção postgres apenas para criar essas bases/roles novas; cada host executa com a sua role QA. start retém cenários existentes e recusa portas ocupadas; stop só termina os servidores próprios e mantém os dados. O orçamento da equipa em 8003 e a demonstração anterior em 8002 não foram parados, resetados ou usados para estas provas. Tudo está limitado a loopback; não houve publicação.

Provas técnicas

powershell -NoProfile -ExecutionPolicy Bypass -File scripts/payables-demo.ps1 proof
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/payables-demo.ps1 proof -HistoryOnly

Evidências: duas composições e recusa de históricos liquidados. Bases descartáveis e roles removidas no final. Os SHA-256 do motor e da fotografia inicial coincidem entre os hosts. Não foram copiadas contas/sessões/credenciais entre as aplicações.

Percurso HTTP real nos dois hosts: login de três funções, origem conferida com base/imposto/total exactos, preparar, validar distintamente, consultar uma obrigação, repetir com a mesma/nova chave e verificar identidade/saldo únicos. HTML dos três perfis conferido por HTTP: preparação/validação onde autorizado, consulta sem formulários de escrita, principal e pendência apresentados. A origem incompleta não é reconhecida; a revisão antiga é recusada. Vencimento/dias continuam nulos com relógio em 2030.

Seis cenários PostgreSQL concorrentes, três por host, com processos/ligação independentes e dois waits de bloqueio observados por cenário: preparação simultânea com chaves diferentes, validação com direito revogado durante a espera (duas recusas), reconhecimento simultâneo (uma obrigação/um evento de reconhecimento). Não se afirma teste de carga ou de todas as ordens de escalonamento.

Falhas e integridade: falha SQL injectada antes do evento de reconhecimento reverte obrigação/outbox/comando; repetir a mesma chave após recuperação conclui uma vez. Contexto/unidade e actor de outra empresa, chave com outro conteúdo, ausência de CSRF e source hash/valor alterado são recusados ou sinalizados. Checksums das tabelas de factura/linhas/orçamento/stock/pagamentos antes/depois do percurso coincidiram em Compras. O ledger comum tem um evento durável por efeito, com outbox correspondente.

Históricos associados: uma fixture de pagamento confirmado anterior de 300 MZN, exclusivamente na base descartável, deixa o saldo legado de 11 300 MZN preservado e impede constituir uma obrigação como se os 11 600 estivessem integralmente por pagar. A representação SGF usa a projecção desse histórico. O comando novo não altera esses registos, não os confirma outra vez nem os liquida. Esta é prova de recusa/preservação, não implementação de pagamentos ou migração de históricos. Também se testou a detecção de histórico incompatível após reconhecimento, preservando o principal e deixando o saldo indeterminado.

Regressões: Compras 498 aprovados, 2 ignorados, 4 141 asserções. PHPStan sem erros e Pint dos ficheiros de produção alterados aprovado. Builds Compras e SGF aprovados, sem actualizar manifests/lockfiles. Uma primeira execução concorrente com o build teve falha transitória do ficheiro de fonte no dashboard; depois de estabilizar os assets, a bateria completa voltou a passar. Não se mudou código para ocultar essa falha. A suite destrutiva SGF não foi executada sobre as demonstrações existentes; o delta foi provado pelo host SGF isolado e pelas verificações de sintaxe/compilação.

Os dois ignorados continuam os testes MFA já documentados em COMMON_BUDGET_ACCEPTANCE.md: users with two factor enabled are redirected to two factor challenge e security page is displayed, dependentes da funcionalidade two-factor desactivada nesta configuração. Não cobrem o reconhecimento monetário deste incremento; a cobertura MFA permanece pendente. Não foi feita revisão visual em navegador nem se atribui aceitação manual à equipa: as provas de interface são HTTP/HTML e compilação. Não se contornou o bloqueio anterior de Computer Use. As pendências visuais de Compras/orçamento e MFA são preservadas.

Ficheiros e migrações

Fonte comum: packages/payables/{bootstrap.php,src/Payables.php,src/Workspace.php,ui/page.php,qa-schema.php,tests/ReceiptFixture.php,tests/seed.php}. Adaptadores/controladores e providers acima. Compras: alterações delimitadas em ExternalPaymentWorkflow.php, InvoiceController.php, resources/js/pages/invoices/index.tsx, routes/web.php, config/common-payables.php e .gitignore. SGF: montagem de menu/rotas, .gitignore e scripts payables-provision.php, payables-router.php, payables-demo.ps1, payables-http-proof.mjs, payables-probe.php, payables-status.php. Relatórios/provas/instruções documentais actualizados sem encerrar requisitos globais.

qa-schema.php não está registado nas migrações operacionais. Cria apenas em QA pa_access, pa_sources, pa_proposals, pa_obligations, pa_commands, pa_events, pa_outbox; no SGF acrescenta-se a projecção local pa_imported_sources e o direito de navegação QA. Não foram aplicadas migrações em compras_dev, sgf_tempo_dev, sgf_tempo_test ou produção; nem concedidos direitos reais.

Uma futura migração operacional terá de resolver cadastros/IDs definitivos, constraints compostas de pertença e modelo de acessos, preservar origens/comercial identity/versões, ensaiar backup/restauro e reconciliar pagamentos históricos antes da passagem de autoridade. Não se apresenta este schema de fixture como migração pronta para clientes. A distribuição autónoma terá de incluir o artefacto local versionado do pacote; não se criou instalador comercial nesta entrega.

Limites e continuação

Sem pagamentos, cobranças, afectações, devoluções, notas de crédito, redução/anulação financeira, lançamentos, efeitos adicionais de stock/orçamento ou activação real. Vencimento desconhecido é suportado; a revisão de uma data sustentada e planos de prestações ficam para recorte próprio. O importador SGF é um recibo de QA preparado pelos serviços, não um circuito geral de documentos em produção ou integração remota.

Próximo passo: a equipa testa as duas interfaces e relata função, origem/captura, passos e resultado observado; corrigir deltas sem apagar originais. Aceitação e checkpoint exclusivamente local só depois da decisão do responsável. Sem commit de encerramento, push ou publicação nesta entrega.

Retoma da interface — 30/10/2026

Retoma automática posterior: resultados consolidados SGF/Compras. Verificações adicionais aprovadas sem alterar motor, permissões existentes ou dados persistentes; revisão visual separada e pendente.

A página de obrigações passou a mostrar afectações novas e saldo por liquidar da posição canónica, preservando o principal. Percurso HTTP/HTML repetido em Compras e SGF: 11 600 MZN → pagamento confirmado sem abatimento → afectação confirmada de 4 000 → saldo 7 600; vencimento/dias nulos. Provas anteriores preservadas. Resultados, correcções de navegação e bloqueio visual no relatório de pagamentos, secção Consolidação do percurso. Sem habilitação pública, mudança de permissões ou encerramento presumido.