Implementa reforcos orcamentais com aprovacao independente
This commit is contained in:
+25
-16
@@ -2,27 +2,36 @@
|
||||
|
||||
Estado actualizado em 28 de Outubro de 2026. Projecto activo: C:\laragon\www\compras, Laravel + React + PostgreSQL, http://127.0.0.1:8015. Preservar conta, dados, configuração, cookie e porta. SGF Tempo e Investmoz são independentes. A implementação Python separada fica apenas como referência; não importar contas, sessões ou bases experimentais.
|
||||
|
||||
| Área | Implementado no Laravel | Pendente |
|
||||
| ------------------------ | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
|
||||
| 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, anexos privados e versões bancárias com duas validações | Múltiplas contas e verificação bancária externa |
|
||||
| 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 |
|
||||
| Ordens | Emissão única/idempotente, snapshots, consulta e impressão | Orçamento não validado; documentos de desenvolvimento |
|
||||
| Recepção | Parcial/total, qualidade, divergências, pendentes, segregação do emitente e auditoria | Substituições e anexos; rejeições não autorizam receber acima do total |
|
||||
| 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 | Facturas, consumo e registo/conferência de pagamentos externos | Estornos, 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 |
|
||||
| Área | Implementado no Laravel | Pendente |
|
||||
| ------------------------ | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
|
||||
| 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, anexos privados e versões bancárias com duas validações | Múltiplas contas e verificação bancária externa |
|
||||
| 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 |
|
||||
| Ordens | Emissão única/idempotente, snapshots, consulta e impressão | Orçamento não validado; documentos de desenvolvimento |
|
||||
| Recepção | Parcial/total, qualidade, divergências, pendentes, segregação do emitente e auditoria | Substituições e anexos; rejeições não autorizam receber acima do total |
|
||||
| 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, reforços aprovados, reservas e compromissos por empresa/centro/exercício | Revisão visual, reduções/transferências e validação operacional integral |
|
||||
| Facturas e pagamentos | Facturas, consumo e registo/conferência de pagamentos externos | Estornos, 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 |
|
||||
|
||||
Preservar enums, políticas, modelos relacionais, Brick Math e isolamento por empresa. As regras guardadas nos snapshots não são substituídas pela configuração actual. Ausência de conflito não anula conflito registado. Exemplos públicos fictícios não dão acesso aos dados de negócio.
|
||||
|
||||
## Verificação actual
|
||||
|
||||
Reforços entregues por empresa/centro/exercício, com aprovação independente e
|
||||
histórico, sem reescrever a dotação inicial. Migração 000013 no lote 14 após
|
||||
backup e restauro verificados de 45 tabelas. Três cenários concorrentes PostgreSQL
|
||||
aprovados. Suite actual: **370 aprovados, 3 ignorados, 2.704 asserções**.
|
||||
Tabela de reforços vazia na base real. Regras de investimento, reduções,
|
||||
transferências, estornos e revisão visual continuam pendentes.
|
||||
|
||||
### Histórico da entrega de pagamentos externos
|
||||
|
||||
Registo e conferência de pagamentos externos entregues, com liquidação parcial,
|
||||
independência, revalidação bancária e consumo orçamental sem duplicação.
|
||||
Suite actual: **347 aprovados, 3 ignorados e 2.630 asserções**.
|
||||
|
||||
@@ -1,5 +1,68 @@
|
||||
# Desenvolvimento do SGC
|
||||
|
||||
## Reforços orçamentais por empresa
|
||||
|
||||
Implementadas propostas de reforço em `/orcamentos`, por dotação existente de
|
||||
empresa/centro de custo/exercício. Administração ou Finanças propõe referência
|
||||
interna, montante positivo e fundamento; outra pessoa destes perfis aprova ou
|
||||
rejeita, fundamentando. Perfis do operador e do proponente são recarregados em
|
||||
transacção. O autor não aprova o próprio reforço.
|
||||
|
||||
A dotação inicial aprovada não é alterada. Dotação acumulada = valor inicial
|
||||
mais reforços aprovados. Disponível = acumulada menos reservas, compromissos
|
||||
remanescentes e consumos. Pendentes e rejeitados não aumentam o saldo; a
|
||||
aprovação permite novas reservas apenas dentro do disponível actualizado.
|
||||
Reforçar não altera consumo ou compromissos anteriores, base de IVA, moeda,
|
||||
centro, exercício ou regras de aprovação de compras. Montantes são definidos
|
||||
pela própria empresa, sem valores financeiros predefinidos para clientes.
|
||||
|
||||
Referência normalizada única por empresa, permitindo referências iguais noutras
|
||||
empresas. Repetição idêntica da proposta ou da aprovação não duplica a verba.
|
||||
Decisões finais e dados do reforço não admitem reescrita ou eliminação pelos
|
||||
modelos. Falha na auditoria reverte integralmente proposta ou decisão.
|
||||
Só dotações aprovadas do exercício actual recebem reforços. Há o mesmo limite
|
||||
técnico de representação monetária das requisições, não um limite empresarial
|
||||
ou autorização comercial. Aprovações históricas não são revogadas automaticamente
|
||||
por mudanças posteriores de perfil; correcções exigem fluxo próprio, ainda ausente.
|
||||
|
||||
### Verificação e aplicação
|
||||
|
||||
**370 testes aprovados, 3 ignorados, 2.704 asserções** na suite completa.
|
||||
Inclui **23 testes de reforços, 74 asserções**: perfis, independência, exactidão,
|
||||
idempotência, bases preservadas, isolamento, valores por empresa, ano encerrado,
|
||||
auditoria e rollback, inputs manipulados e disponibilidade para reservas.
|
||||
PHPStan, Pint, TypeScript e compilação aprovados.
|
||||
|
||||
Três cenários concorrentes PostgreSQL aprovados: mesma aprovação repetida,
|
||||
reforços distintos aprovados em simultâneo e aprovação concorrente com reserva.
|
||||
Duas ligações independentes em processos PHP observadas simultaneamente à
|
||||
espera de bloqueios por cenário. Conferidos dotação acumulada, saldo reservado,
|
||||
ausência de excesso e preservação do valor inicial. Base temporária eliminada.
|
||||
São transacções de serviço, não teste HTTP ou de carga.
|
||||
[Evidência](reforcos-concorrencia-postgresql.json).
|
||||
|
||||
Migração 000013 aplicada no **lote 14**, após backup custom PostgreSQL 17 de
|
||||
**245.514 bytes** e restauro verificado das **45 tabelas** anteriores numa base
|
||||
temporária, depois eliminada. Dump e manifesto partilharam snapshot consistente.
|
||||
Registos de negócio, restrições e `.env` preservados. Tabela de reforços vazia:
|
||||
sem seeds, verbas fictícias, contas novas ou alterações de credenciais na base
|
||||
real. Backup/manifesto privados, fora do Git.
|
||||
[Evidência sem dados privados](reforcos-migracao-000013.json).
|
||||
|
||||
`/consulta/reforcos` contém somente exemplos fictícios; não consulta dotações ou
|
||||
utilizadores e não grava dados. O navegador voltou a reportar
|
||||
`The browser access host is unavailable`: **revisão visual pública, autenticada
|
||||
e de impressão continua pendente**. Não constitui validação operacional integral.
|
||||
|
||||
### Próximo passo e limitações
|
||||
|
||||
Próximo incremento: regras de investimento configuráveis por empresa e aprovadas
|
||||
independentemente. Não inventar montantes comuns aos clientes, semântica de
|
||||
limites ou dispensa de aprovações. Enquanto não houver regra própria aprovada,
|
||||
equipamentos continuam bloqueados para adjudicação/emissão. Reduções, transferências
|
||||
de dotações, estornos de reforços e passagem de saldos entre exercícios não
|
||||
foram implementados; exigem fluxos e decisões próprios.
|
||||
|
||||
## Registo e conferência de pagamentos externos
|
||||
|
||||
Implementado `/pagamentos`, por empresa. Finanças regista pagamentos já
|
||||
|
||||
@@ -1,5 +1,15 @@
|
||||
# Continuidade do desenvolvimento do SGC
|
||||
|
||||
## Próxima etapa após reforços
|
||||
|
||||
Reforços por empresa/centro/exercício já estão implementados e migrados
|
||||
(000013, lote 14). Não repetir as orientações históricas abaixo. Prosseguir
|
||||
com regras de investimento configuráveis por empresa, com decisões e valores
|
||||
explícitos, versionamento e aprovação independente. Não presumir um valor ou
|
||||
interpretar limite ausente como autorização. Até existir regra própria aprovada,
|
||||
preservar o bloqueio de adjudicação/emissão de equipamento. Revisão visual e
|
||||
validação operacional integral continuam pendentes. Consultar o relatório actual.
|
||||
|
||||
## Próxima etapa após pagamentos externos
|
||||
|
||||
Registo e conferência independente de pagamentos externos já implementados,
|
||||
|
||||
@@ -7,7 +7,7 @@ Actualização: o utilizador autorizou avançar com a abordagem. Dotações, res
|
||||
compromissos e conferência de facturas/consumo foram implementados e migrados.
|
||||
A base de IVA é uma decisão explícita de cada empresa. As secções seguintes
|
||||
conservam a proposta original; não comprovam aprovação de limites monetários,
|
||||
tolerâncias ou regras de investimento. Reforços continuam pendentes. Registo e
|
||||
tolerâncias ou regras de investimento. Reforços positivos, com aprovação independente, foram implementados posteriormente. Registo e
|
||||
conferência de pagamentos externos foram acrescentados depois; não executam
|
||||
transferências nem substituem a confirmação humana da evidência.
|
||||
Estado actual em `docs/desenvolvimento.md`.
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
{
|
||||
"tested_at_utc": "2026-10-28T12:59:44+00:00",
|
||||
"separate_database": true,
|
||||
"transport": "Independent PHP service transactions and PostgreSQL connections",
|
||||
"scenarios": [
|
||||
{
|
||||
"name": "same_approval",
|
||||
"passed": true,
|
||||
"overlapping_lock_waits": 2,
|
||||
"approved_total_minor": 12000,
|
||||
"reserved_minor": 0,
|
||||
"original_allocation_unchanged": true
|
||||
},
|
||||
{
|
||||
"name": "distinct_reinforcements",
|
||||
"passed": true,
|
||||
"overlapping_lock_waits": 2,
|
||||
"approved_total_minor": 19000,
|
||||
"reserved_minor": 0,
|
||||
"original_allocation_unchanged": true
|
||||
},
|
||||
{
|
||||
"name": "approval_vs_reservation",
|
||||
"passed": true,
|
||||
"overlapping_lock_waits": 2,
|
||||
"approved_total_minor": 12000,
|
||||
"reserved_minor": 10000,
|
||||
"original_allocation_unchanged": true
|
||||
}
|
||||
],
|
||||
"passed": true,
|
||||
"test_database_dropped": true
|
||||
}
|
||||
@@ -0,0 +1,15 @@
|
||||
{
|
||||
"verified_at_utc": "2026-10-28T13:00:53+00:00",
|
||||
"migration": "2026_10_28_000013_create_budget_reinforcements",
|
||||
"batch": 14,
|
||||
"backup_created": true,
|
||||
"backup_bytes": 245514,
|
||||
"restore_verified": true,
|
||||
"restored_tables": 45,
|
||||
"restore_database_dropped": true,
|
||||
"business_records_unchanged": true,
|
||||
"existing_constraints_preserved": true,
|
||||
"env_unchanged": true,
|
||||
"budget_reinforcements_count": 0,
|
||||
"operational_validation": false
|
||||
}
|
||||
Reference in New Issue
Block a user