Documenta validacao bancaria e proxima etapa de pagamentos
This commit is contained in:
@@ -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.
|
||||
|
||||
|
||||
+11
-2
@@ -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,
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user