From f0f7b8ce9d810b5f3487071d1f4e38040160c460 Mon Sep 17 00:00:00 2001 From: nala Date: Wed, 28 Oct 2026 14:37:38 +0200 Subject: [PATCH] Documenta validacao bancaria e proxima etapa de pagamentos --- README.md | 8 +++- docs/compatibilidade.md | 13 +++++- docs/desenvolvimento.md | 71 ++++++++++++++++++++++++++++++++ docs/orientacoes-continuidade.md | 11 +++++ 4 files changed, 100 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 76e50ea..f3ae4a6 100644 --- a/README.md +++ b/README.md @@ -23,6 +23,12 @@ Crie um pedido, guarde o rascunho, confira os valores e submeta. Entre com as co ## Entrega actual +- Dados bancários por fornecedor/empresa: versões propostas por Procurement, + duas validações distintas por Finanças, dados sensíveis cifrados, consultas + restritas e auditoria sem números de conta. Alterações exigem duas novas + decisões. Migração 000011 aplicada após backup/restauro verificados; três + cenários concorrentes PostgreSQL aprovados. Não executa pagamentos. + - Facturas por empresa/fornecedor/ordem, conferência exacta com recepções aceites, facturação parcial, validação independente por Finanças e conversão de compromisso em consumo. Migração 000010 aplicada após backup/restauro verificados; três @@ -69,7 +75,7 @@ O IVA é informado pelo utilizador e calculado no servidor. A taxa inicial de 0% ## Próximas etapas -Revisão visual dos módulos entregues; reposição de stock; dados bancários com dupla validação; reforços orçamentais, correcções de facturas e pagamentos; moedas e câmbio; subscrições, licenças e Docker. Equipamentos, peças, validação técnica e alertas de mínimo já estão implementados; a adjudicação de equipamento aguarda a definição da regra de investimento. Periodicidade dos inventários, tolerâncias e investigação de divergências exigem decisão da empresa. A política de periodicidade, validade e levantamento de conflitos e os procedimentos de revisão/cancelamento de adjudicações continuam por definir. +Revisão visual dos módulos entregues; reposição de stock; registo de pagamentos externos; reforços orçamentais, correcções de facturas e pagamentos; moedas e câmbio; subscrições, licenças e Docker. Equipamentos, peças, validação técnica e alertas de mínimo já estão implementados; a adjudicação de equipamento aguarda a definição da regra de investimento. Periodicidade dos inventários, tolerâncias e investigação de divergências exigem decisão da empresa. A política de periodicidade, validade e levantamento de conflitos e os procedimentos de revisão/cancelamento de adjudicações continuam por definir. O cadastro guarda referências e ficheiros anexos no disco privado `supplier_documents`, em `storage/app/supplier-documents`, fora da pasta pública e sem URLs públicas. As fichas abrem pelo directório **Fornecedores → Ver ficha → Abrir ficha, edição e documentos**. As versões antigas e documentos existentes são preservados na auditoria e no armazenamento; nesta entrega não há eliminação de documentos, antivírus, quotas acumuladas ou política de retenção. A validação do NUIT é de formato e unicidade, sem consulta a uma autoridade fiscal. Além das declarações por operação, existem declarações pessoais por fornecedor e processo; a periodicidade anual e a política de validade/levantamento ainda não foram definidas. As propostas e avaliações registadas não são editáveis nesta etapa. Os pesos 40/20/15/15/10 são provisórios e ficam guardados por proposta. A comparação liga à fase de adjudicação e emissão. A ordem exige novas aprovações do valor final e revalidação no servidor. As propostas usam MZN; a multimoeda fica para a fase correspondente. diff --git a/docs/compatibilidade.md b/docs/compatibilidade.md index 1791810..2b354fe 100644 --- a/docs/compatibilidade.md +++ b/docs/compatibilidade.md @@ -6,7 +6,7 @@ Estado actualizado em 28 de Outubro de 2026. Projecto activo: C:\laragon\www\com | ------------------------ | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | Acesso e organização | Fortify, conta, empresa, equipa, departamentos e centros de custo | MFA obrigatório e ciclo completo de acessos | | Requisições e aprovações | Rascunhos, cálculos exactos, etapas, segregação e snapshots | Validação empresarial das regras provisórias | -| Fornecedores | Cadastro, edição, renovação, validação independente e anexos privados | Dados bancários com dupla validação | +| Fornecedores | Cadastro, anexos privados e versões bancárias com duas validações | Integração futura com pagamentos | | Cotações | Propostas, avaliações e matriz comparativa | Multimoeda e revisão das propostas | | RF-AF-01 | Declarações pessoais, histórico e ConflictGuard no servidor | Política de periodicidade, validade e levantamento | | Adjudicação | Escolha fundamentada, revalidação e aprovação do valor final | Excepções, revisão e cancelamento sem política ficam bloqueados | @@ -15,7 +15,7 @@ Estado actualizado em 28 de Outubro de 2026. Projecto activo: C:\laragon\www\com | Stock | Artigos, armazéns, entradas, saídas fundamentadas, transferências atómicas, contagens e ajustes auditados por empresa | Revisão visual, reposição e conversões | | Equipamentos e peças | Cadastro, compatibilidade, mínimos, alertas, validação técnica e rastreabilidade | Regra de investimento; adjudicação/emissão de equipamento bloqueadas | | Orçamento | Dotação por empresa/centro/exercício, aprovação independente, reservas e compromissos | Revisão visual, reforços e validação operacional integral | -| Facturas e pagamentos | Registo por empresa, conferência, validação independente e consumo orçamental | Dados bancários, pagamentos, notas de crédito e anexos | +| Facturas e pagamentos | Registo por empresa, conferência, validação independente e consumo orçamental | Pagamentos, notas de crédito e anexos | | Início e navegação | Página inicial própria, menus por área/perfil e consulta pública por módulo | Revisão visual | | Auditoria | Histórico das operações implementadas | Exportações, retenção e protecção contra SQL administrativo | @@ -23,6 +23,15 @@ Preservar enums, políticas, modelos relacionais, Brick Math e isolamento por em ## Verificação actual +Dados bancários entregues: versões por empresa/fornecedor, duas decisões +independentes de Finanças, campos sensíveis cifrados e consultas restritas. +Migração 000011 no lote 12 após backup e restauro verificados de 42 tabelas. +Três cenários concorrentes PostgreSQL aprovados. Suite actual: **314 aprovados, +3 ignorados, 2.523 asserções**; 16 casos bancários. Tabelas bancárias vazias na +base real. Pagamentos e revisão visual continuam pendentes. + +### Histórico da entrega de facturas + Facturas e consumo entregues: migração 000010 aplicada no lote 11 após backup e restauro verificados de 39 tabelas. Três cenários concorrentes PostgreSQL e 22 testes de facturas aprovados. Suite completa actual: **298 aprovados, diff --git a/docs/desenvolvimento.md b/docs/desenvolvimento.md index f10ce37..841ad97 100644 --- a/docs/desenvolvimento.md +++ b/docs/desenvolvimento.md @@ -1,5 +1,76 @@ # Desenvolvimento do SGC +## Dados bancários de fornecedores com dupla validação + +Implementado no mesmo projecto, com dados isolados por empresa/fornecedor. +Procurement propõe uma versão completa; **duas pessoas distintas de Finanças**, +ambas diferentes do autor, conferem e aprovam. Uma aprovação mantém o estado +pendente; repetir a mesma decisão não conta outra vez. Rejeição impede novas +aprovações nessa versão. Correcções exigem nova versão, sem reescrever o passado. + +A versão mais recente substitui a anterior para disponibilidade futura, mesmo +quando pendente ou rejeitada. Propostas com referência anterior desactualizada +e decisões sobre versões substituídas são recusadas. Reavaliação do estado +considera fornecedor activo/revisão válida/impedimentos, perfil actual dos +validadores e conflitos de interesses. Mudança de perfil do autor não permite +auto-aprovação. Futuro pagamento deve revalidar tudo na própria transacção, +sem confiar no estado mostrado anteriormente no ecrã. + +Identificador da conta, titular, referência de evidência e fundamentos são +cifrados com a chave Laravel existente. Modelos ocultam esses campos na +serialização geral. Procurement e Finanças acedem aos dados actuais com +auditoria de leitura; Administração recebe apenas estado e metadados. Outros +perfis não acedem. A auditoria contém referências/versões, não números ou +titulares de conta. Resposta privada sem armazenamento em cache e histórico +Inertia cifrado. Campos sensíveis não são guardados em input antigo da sessão; +o campo `reason` é também excluído globalmente para impedir cópias de fundamentos +bancários em validações falhadas. Preservar a chave de aplicação nas operações +de recuperação: um backup de dados cifrados não substitui a guarda dessa chave. + +Ficha: `/fornecedores/{supplier}/dados-bancarios`, ligada à ficha existente. +Exemplo público: `/consulta/dados-bancarios`, sem contas ou consultas de negócio. +Banco, titular, conta, país e moeda são fornecidos pela própria empresa. +Não existem contas, bancos ou valores financeiros predefinidos por cliente. + +### Verificação, concorrência e migração + +Suite completa: **314 testes aprovados, 3 ignorados e 2.523 asserções**. +Inclui **16 testes bancários e 74 asserções**: independência, duas pessoas, +versões, rejeição, conflitos posteriores, mudanças de perfil, isolamento, +cifragem, resposta restrita, cache, auditoria, rollback e input sensível não +guardado na sessão. PHPStan, Pint, TypeScript, compilação e frontend aprovados. + +Três cenários concorrentes PostgreSQL aprovados: duas aprovações distintas, +mesma aprovação repetida e versões concorrentes. Duas ligações independentes +em processos PHP, observadas simultaneamente à espera de bloqueios por cenário. +Conferidos estados, versões e contagens de decisões; base temporária eliminada. +São testes de serviço, não de carga ou HTTP. +[Evidência](bancos-concorrencia-postgresql.json). + +Migração 000011 aplicada no **lote 12** após backup custom PostgreSQL 17 de +**230.372 bytes** e restauro verificado das **42 tabelas** anteriores numa base +temporária, depois eliminada. Dump e manifesto partilharam snapshot consistente. +Dados de negócio, restrições e `.env` preservados; novas tabelas vazias. Sem +contas bancárias fictícias na base real, seeds, recriação de utilizadores ou +alteração de credenciais. Backup e manifesto privados, fora do Git. +[Evidência sem dados privados](bancos-migracao-000011.json). + +### Limitações e roteiro + +O identificador é texto normalizado com validação genérica de formato; não há +consulta bancária, verificação de titularidade, validação nacional de IBAN/NIB +ou confirmação automática da evidência. A declaração de conferência é humana. +Uma conta actual por fornecedor; múltiplas contas simultâneas, cancelamento +e levantamento de rejeição não foram implementados. Não existem pagamentos, +transferências, ficheiros de remessa, integração bancária ou envio externo. + +Nova tentativa de navegador devolveu `The browser access host is unavailable`. +**Revisão visual pública, autenticada e de impressão continua pendente.** +Validação operacional integral do orçamento também permanece pendente. +Próxima etapa: registo e conferência de pagamentos externos sobre facturas +validadas, com revalidação da versão bancária no momento da operação; não +confundir esse futuro registo com execução de transferências bancárias. + ## Facturas, conferência e consumo orçamental Implementado `/facturas`: Administração consulta; Finanças regista e outra pessoa diff --git a/docs/orientacoes-continuidade.md b/docs/orientacoes-continuidade.md index 20d508c..2f0d7f5 100644 --- a/docs/orientacoes-continuidade.md +++ b/docs/orientacoes-continuidade.md @@ -1,5 +1,16 @@ # Continuidade do desenvolvimento do SGC +## Próxima etapa após dados bancários + +Versões bancárias por empresa/fornecedor, cifragem e duas validações distintas +de Finanças já estão implementadas; migração 000011 aplicada. Não repetir as +orientações históricas abaixo. Prosseguir com registo de pagamentos externos +sobre facturas validadas, revalidando a versão bancária actual, os dois +validadores, elegibilidade, conflitos, empresa e saldo em transacção. +Não executar transferências bancárias. Sem valores financeiros comuns aos +clientes. Revisão visual e validação operacional integral continuam pendentes. +Consultar `docs/desenvolvimento.md` para resultados e limitações actuais. + ## Próximo incremento após facturas Orçamento e facturas já foram implementados e migrados, incluindo conferência