194 lines
14 KiB
Markdown
194 lines
14 KiB
Markdown
# Validação técnica do SGC — 28 de Outubro de 2026
|
|
|
|
## Incremento: visão única do processo de compra
|
|
|
|
O detalhe de uma requisição inclui o acesso «Ver processo completo», em
|
|
`/requisicoes/{requisition}/processo`. A página reúne as etapas já suportadas,
|
|
os responsáveis por função, decisões com autores e datas, atalhos para os
|
|
registos e o histórico permitido ao perfil. Inclui ligação entre processos
|
|
originais e revisões quando ambos são visíveis ao utilizador. O cabeçalho e
|
|
rodapé partilhados mantêm-se neste ecrã.
|
|
|
|
Esta é uma consulta dos registos existentes. Não cria etapas obrigatórias,
|
|
aprovações, documentos, reservas ou pagamentos. Planeamento, acta de abertura,
|
|
qualificação específica do concurso e relatório por etapas aparecem apenas
|
|
como funcionalidades futuras, sem se presumirem aplicáveis a todas as compras.
|
|
Os quatro exemplos locais continuam a ser referências, não regras impostas.
|
|
|
|
O estado da requisição é separado dos restantes estados. Existência de propostas
|
|
não significa elegibilidade; histórico técnico não garante validade da base
|
|
actual; existência de lançamentos não certifica o orçamento; recepções podem
|
|
ser parciais; registo de factura não equivale a validação; pagamentos externos
|
|
confirmados não comprovam liquidação integral nem executam transferências.
|
|
|
|
A rota exige autenticação, empresa configurada e visibilidade da requisição.
|
|
Solicitantes não obtêm detalhes de propostas, adjudicações, ordens ou finanças
|
|
por esta consulta. Chefias conservam o âmbito departamental; Finanças e
|
|
Administração consultam os resumos financeiros. O Armazém não obtém acesso a
|
|
requisições de terceiros por esta nova rota. Documentos e eventos são filtrados
|
|
no servidor, sem snapshots privados, anexos ou dados bancários. A resposta usa
|
|
`private, no-store` e histórico Inertia cifrado.
|
|
|
|
Cinco testes específicos cobrem registos e estados parciais, ocultação de
|
|
compras/finanças ao solicitante, propriedade e departamento, isolamento entre
|
|
empresas e convidados, actualização da validação de factura e leitura sem
|
|
novos eventos de auditoria. Não há migração nem alteração de dados de negócio.
|
|
TypeScript, lint/formatação, build, PHPStan e Pint passaram.
|
|
|
|
Bateria completa deste incremento: **419 testes aprovados, 2 ignorados,
|
|
3180 asserções**. Os testes ignorados continuam condicionados à activação de
|
|
MFA; não são apresentados como aprovados. Os seis cenários concorrentes do
|
|
incremento anterior não foram repetidos, pois esta entrega não altera as
|
|
operações transaccionais que verificam.
|
|
|
|
O navegador voltou a devolver `The browser access host is unavailable`.
|
|
A revisão visual pública, autenticada e de impressão continua pendente;
|
|
testes HTTP e compilação não a substituem. O cancelamento de ordens emitidas
|
|
continua sujeito à proposta de regras ainda não validada.
|
|
|
|
## Incremento: navegação partilhada e revisão sem ordem emitida
|
|
|
|
O cabeçalho e rodapé do SGC são partilhados pelo acesso autenticado e pela
|
|
consulta pública, incluindo a proposta `/proposta/principal`. Os dropdowns
|
|
agrupam Compras, Finanças, Armazém e Gestão; preservam os acessos anteriores,
|
|
o menu da conta e a localização do ecrã. As opções autenticadas respeitam o
|
|
perfil; a autorização continua a ser verificada no servidor. A referência
|
|
visual foi consultada apenas em leitura no InvesteMoz: preto `#090909`,
|
|
vermelho `#ed1c24`, menus brancos. O projecto InvesteMoz não foi alterado.
|
|
|
|
Em `/revisao-compras`, cada empresa pode propor uma política datada para
|
|
cancelar adjudicações sem ordem emitida. Não existe activação por defeito.
|
|
A implementação usa duas assinaturas administrativas distintas do proponente
|
|
para publicar a regra e uma decisão Financeira independente para cada
|
|
cancelamento pedido por Compras. Estas são opções deste circuito implementado;
|
|
não constituem valores financeiros predefinidos para as empresas.
|
|
|
|
Um cancelamento pendente bloqueia novas decisões finais e emissão. Aprovação
|
|
encerra a adjudicação e requisição originais, mantendo cotações e decisões;
|
|
liberta apenas reserva não comprometida. Repetições idênticas não duplicam
|
|
lançamentos. Rejeição mantém a compra original. Uma decisão é imutável e,
|
|
neste primeiro âmbito, existe no máximo um pedido de cancelamento por
|
|
adjudicação, incluindo pedidos rejeitados. Uma alteração da política bloqueia
|
|
a aprovação de pedidos antigos; a rejeição continua disponível para retomar
|
|
o processo. Ordens emitidas e compromissos financeiros impedem este circuito.
|
|
|
|
Só o solicitante original, ainda no mesmo departamento, pode preparar um
|
|
único novo rascunho ligado ao cancelamento aprovado, com nova data e
|
|
justificação. Copiam-se artigos e estimativas, sem decisões, cotações,
|
|
validações técnicas ou reserva automática. O novo pedido segue o circuito
|
|
normal, incluindo validação técnica quando aplicável. As restrições únicas
|
|
de adjudicação e ordem por requisição foram conservadas.
|
|
|
|
A migração aditiva 000015 foi aplicada no batch 16 após backup privado de
|
|
259925 bytes e restauro verificado de 48 tabelas numa base temporária.
|
|
Dados de negócio anteriores, restrições e `.env` foram preservados; não foram
|
|
criadas políticas ou operações fictícias na base real. Ver relatório
|
|
`revisao-migracao-000015.json`. O backup e o manifesto ficam fora do Git.
|
|
|
|
Sete cenários novos verificam política obrigatória, bloqueio pendente,
|
|
rejeição e retoma, histórico e rascunho único, recusa após emissão,
|
|
segregação após mudança de perfil, libertação única da reserva e rollback
|
|
conjunto quando falha a auditoria. A validação concorrente deste circuito
|
|
foi acrescentada numa base PostgreSQL temporária: **6 cenários aprovados**,
|
|
cada um com duas ligações independentes e duas esperas de bloqueio simultâneas.
|
|
Abrange decisão repetida, decisões opostas, revisão repetida, emissão com
|
|
cancelamento pendente, emissão repetida e emissão em disputa com um pedido
|
|
de cancelamento. Nos três cenários de emissão, a adjudicação é seleccionada
|
|
e aprovada pelos serviços reais da aplicação. O controlo positivo emite uma
|
|
única ordem e um único compromisso; na disputa, apenas uma operação avança.
|
|
Os quatro primeiros cenários verificam também reserva e revisão únicas.
|
|
O relatório é `revisao-concorrencia-postgresql.json`; a base exclusiva de
|
|
testes foi eliminada no fim. Não houve alterações à base de negócio.
|
|
|
|
Resultado do incremento: **414 testes aprovados, 2 ignorados, 3099 asserções**.
|
|
PHPStan e Pint passaram; TypeScript, lint/formatação e build passaram.
|
|
As quatro verificações HTTP da proposta, requisições públicas, reforços e
|
|
aparência responderam 200. Estes pedidos HTTP não constituem revisão visual.
|
|
|
|
A revisão visual pública, autenticada e de impressão continua pendente:
|
|
o acesso ao navegador permanece indisponível. Compilação e testes não a
|
|
substituem. Ordens emitidas, estornos, notas de crédito, devoluções e
|
|
validação operacional das regras de cada empresa continuam fora deste âmbito.
|
|
|
|
Esta revisão cobre os módulos implementados e as pendências documentadas no
|
|
repositório. Não equivale a validação operacional integral ou certificação de
|
|
todos os requisitos do sistema. Valores e políticas reais continuam a pertencer
|
|
a cada empresa; nenhum foi criado nesta revisão.
|
|
|
|
## Correcções verificadas
|
|
|
|
- Operações que verificavam o perfil antes de esperar pelo bloqueio da empresa
|
|
passam a recarregar e bloquear o utilizador dentro da transacção. Abrange
|
|
facturas, dados bancários, stock, recepções, requisições, adjudicação, emissão,
|
|
validação técnica e dotação inicial. Mudança de perfil ou de empresa durante
|
|
a espera não é autorizada pelo perfil antigo em memória.
|
|
- Requisição volta a verificar departamento e centro de custo ao guardar e o
|
|
departamento do solicitante ao submeter. Decisões departamentais usam o perfil
|
|
actual; revisão técnica e aprovadores finais são bloqueados durante as
|
|
verificações transaccionais.
|
|
- Dotação pendente mostra **zero disponível e zero aprovado**, preservando o
|
|
valor proposto e o histórico. O servidor já bloqueava a reserva; a interface
|
|
deixou de apresentar verba proposta como disponível.
|
|
- Teste da página de segurança com MFA desligado deixou de ser indevidamente
|
|
ignorado. Textos dessa página e confirmação de alteração de palavra-passe
|
|
traduzidos para português. Nenhuma palavra-passe real foi alterada.
|
|
- Configuração de fontes passou a declarar desactivada a optimização opcional
|
|
que já não era gerada por ausência de `fontaine`. Mantém Instrument Sans e
|
|
elimina o aviso de dependência opcional sem instalar pacotes novos.
|
|
|
|
## Resultados
|
|
|
|
**407 testes aprovados, 2 ignorados, 2.964 asserções** na suite completa SQLite
|
|
em memória. Os dois ignorados dependem de MFA activado, actualmente desligado;
|
|
não são apresentados como funcionalidades validadas. PHPStan, Pint, TypeScript,
|
|
compilação e formatação/lint frontend verificados no fecho.
|
|
|
|
**32 cenários concorrentes PostgreSQL aprovados**, todos em bases exclusivas
|
|
de teste, eliminadas no final:
|
|
|
|
| Área | Cenários | Evidência |
|
|
| ------------------------------ | -------: | ------------------------------------------------------ |
|
|
| Recepções | 4 | [Relatório](recepcao-concorrencia-postgresql.json) |
|
|
| Stock e peças | 7 | [Relatório](stock-concorrencia-postgresql.json) |
|
|
| Reservas e compromissos | 5 | [Relatório](orcamento-concorrencia-postgresql.json) |
|
|
| Facturas e consumo | 3 | [Relatório](facturas-concorrencia-postgresql.json) |
|
|
| Dados bancários | 3 | [Relatório](bancos-concorrencia-postgresql.json) |
|
|
| Pagamentos externos | 3 | [Relatório](pagamentos-concorrencia-postgresql.json) |
|
|
| Reforços | 3 | [Relatório](reforcos-concorrencia-postgresql.json) |
|
|
| Regras de investimento | 3 | [Relatório](investimento-concorrencia-postgresql.json) |
|
|
| Perfil revogado durante espera | 1 | [Relatório](autorizacao-concorrencia-postgresql.json) |
|
|
|
|
O último ensaio bloqueia a empresa, observa duas ligações simultaneamente à
|
|
espera e revoga os dois perfis de Armazém antes de libertar o bloqueio. Os dois
|
|
pedidos pelo kernel HTTP retornam **403**; não criam recepções nem movimentos.
|
|
Os restantes ensaios verificam saldos, duplicações e integridade conforme os
|
|
respectivos relatórios. Não são testes de carga ou uma validação de todos os
|
|
possíveis cruzamentos concorrentes do sistema.
|
|
|
|
Sem migrações, seeds, criação de contas, alteração de configuração de ambiente
|
|
ou escritas de negócio na base real nesta revisão. Acesso HTTP pode actualizar
|
|
sessões. Nenhuma autorização de compra ou transferência bancária foi emitida.
|
|
|
|
## O que permanece por tratar
|
|
|
|
| Pendência | Situação |
|
|
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
| Revisão visual pública, autenticada e impressão | Bloqueada pelo acesso ao navegador; testes HTTP não a substituem. |
|
|
| MFA obrigatório e ciclo completo de acessos | Não implementados/activados; dois testes condicionais continuam ignorados. |
|
|
| Revisão/cancelamento de adjudicações e ordens | Cancelamento de adjudicações sem ordem implementado no incremento abaixo; cancelamento de ordens emitidas continua ausente. |
|
|
| Reversões, estornos, notas de crédito e devoluções | Funcionalidades ainda não implementadas; não se apagam lançamentos existentes. |
|
|
| Regras empresariais | Escalões provisórios, regras fiscais, validade/levantamento de conflitos e excepções exigem decisão da empresa. |
|
|
| Investimento agregado e fraccionamento | Apenas tecto por processo suportado; sem agregação/detecção automática. |
|
|
| Outras etapas do roteiro | Multimoeda, reposição, tolerâncias/investigação de inventários, manutenção/activos e requisitos de subscrição/hosting continuam no roteiro. |
|
|
| Controlos operacionais | Carga, permissões contra SQL administrativo, retenção e recuperação por empresa ainda exigem validação própria. |
|
|
|
|
Estas pendências não foram marcadas como concluídas por compilação ou testes
|
|
funcionais. O próximo incremento de revisão/cancelamento deve definir e guardar
|
|
uma política explícita por empresa, conservar o passado e exigir novas decisões
|
|
para processos revistos; não pode autorizar por omissão a alteração de ordens
|
|
emitidas ou a libertação de compromissos já consumidos.
|
|
|
|
Verificação HTTP local no fecho: **18 páginas públicas responderam 200** e
|
|
**13 rotas protegidas responderam 302 sem sessão**. O navegador voltou a devolver
|
|
`The browser access host is unavailable`; a revisão visual continua pendente.
|