Sistema de Gestão de Contratações (SGC)

Aquisições, serviços e pessoas · Uma solução TEMPO.

Sistema em Laravel 13, React, TypeScript e Inertia que reúne compras, contratação de prestadores individuais e recrutamento de trabalhadores, com perfis, aprovações e histórico próprios de cada percurso.

Este é o projecto activo em C:\laragon\www\compras. Preserve a conta existente. A implementação Python criada separadamente fica apenas como referência; consulte o mapa de compatibilidade antes de adaptar funcionalidades.

O produto inclui os artefactos dos núcleos comuns em packages/, conferidos por SHA-256 com composer run runtime:check. A execução da aplicação já não exige a pasta vizinha do SGF. Actualizar esses artefactos a partir da origem comum, conforme packages/README.md. Esta distribuição não activa automaticamente capacidades financeiras nem altera dados/configuração de instalações existentes.

Executar localmente

Durante o desenvolvimento, use composer run dev e abra http://127.0.0.1:8005/. Este é o ambiente persistente com entrada directa no dashboard, os menus organizados e os processos em avaliação. /avaliar permite mudar de perfil. O arranque reutiliza a avaliação existente e inicia o Vite quando necessário, sem migrações, seeds ou alterações de contas.

Conferência dos pagamentos pendentes após importação: entrega e provas. Implementada em testes, com migração 000023 e activação ainda por aplicar; demonstração actual preservada.

Explorar a aplicação sem palavra-passe

Na demonstração local isolada, abrir http://127.0.0.1:8005/avaliar e escolher Entrar como proprietário. A página «Explorar Compras», acessível também pela ligação acima da aplicação, reúne os 21 módulos/páginas principais. Links protegidos, como /relatorios, encaminham para esta entrada quando a sessão expira e regressam ao destino após a escolha do perfil, sem pedir credenciais. Disponibiliza ainda os seis perfis operacionais sintéticos para experimentar os respectivos passos. Os dados e alterações desta demonstração persistem entre visitas.

A entrada pertence exclusivamente à base QA local existente de obrigações, com empresa e exemplos sintéticos; não altera contas/dados da instalação normal em 8015. As regras de aprovação independente e de integridade permanecem. O proprietário tem o perfil administrativo e as três acções do ensaio de obrigações; os passos reservados a Procurement, Finanças ou Armazém usam os perfis de avaliação disponíveis. Não se declara que todos os percursos já tenham exemplos completos nesta base.

Retomar a avaliação existente, sem apagar dados: composer run dev. Se já estiver activa, basta abrir a ligação. O comando não provisiona outra base nem reinicia o SGF. Verificação HTTP: scripts/evaluation-access-check.mjs; resultados em docs/proofs/evaluation-access.json (20 páginas, seis perfis, CSRF, recusa de identificadores arbitrários e saída; sem operações de negócio). A revisão visual do utilizador é separada.

Instalação habitual separada: http://127.0.0.1:8015, com autenticação e dados próprios, preservada no .env. O arranque antigo permanece disponível explicitamente como composer run dev:standard; não é a entrada de avaliação usada durante o desenvolvimento.

Preparação da instalação habitual, quando pretendida

As dependências e o .env devem estar configurados. O projecto suporta a ligação PostgreSQL existente; os testes usam SQLite em memória. Esta preparação é separada da avaliação persistente usada no desenvolvimento.

php artisan migrate
npm install
npm run build
composer run dev:standard

Abra a aplicação, registe uma conta e configure a empresa no painel. A primeira conta torna-se administradora exclusivamente da empresa que cria. Em Empresa e equipa, adicione departamentos, centros de custo e utilizadores com os perfis necessários. Contas registadas publicamente não entram automaticamente numa empresa existente.

Crie um pedido, guarde o rascunho, confira os valores e submeta. Entre com as contas de aprovação para decidir cada etapa. O solicitante não pode aprovar o próprio pedido; um administrador não substitui os aprovadores. Cada etapa exige uma pessoa diferente. Sem um aprovador elegível o pedido fica pendente.

Entrega actual

• Relatórios de compras: menu Relatórios → Relatórios de compras (/relatorios), com filtros, resumo, exportação CSV completa e ligações ao processo/relatório individual. O relatório imprimível inclui recepções e, para os perfis financeiros autorizados, facturas e registos de pagamentos. Estados preservados, sem cálculo de saldo por este relatório. Ver o inventário actualizado em docs/menus-benchmark-20261029.md.

• Passagem explícita de pagamentos históricos para a obrigação comum: principal integral, confirmados deduzidos uma vez, pendentes/rejeitados preservados e validação distinta. Migração 000022 aplicada e activação histórica concluída em compras_dev, após backup/restauro e preservação conferida; sem incorporação automática. A demonstração em 8005 mantém o seu cenário anterior. Não executa pagamentos nem confirma pendentes após a passagem. Ver entrega, aplicação e provas.

• Regras de investimento próprias por empresa: tecto por processo, base de IVA e vigência explícitos, com duas aprovações administrativas distintas do autor. Equipamento exige também validação técnica, Finanças e reserva em dotação de investimento. Regra congelada na adjudicação/ordem; mudança de base bloqueia emissão com aprovações antigas. Migração 000014 aplicada após backup/restauro verificados. Sem regras ou limites fictícios na base real.

• Reforços de orçamento por empresa/centro/exercício, com proposta, aprovação independente e histórico imutável. A dotação inicial e a base de IVA são preservadas; apenas reforços aprovados aumentam o saldo disponível. Migração 000013 aplicada após backup/restauro verificados; três cenários concorrentes PostgreSQL aprovados. Exemplo público em /consulta/reforcos.

• Registo de pagamentos externos por empresa, com conferência independente, liquidação parcial/total de facturas e revalidação da versão bancária. Sem consumo duplicado do orçamento ou execução de transferências. Migração 000012 aplicada após backup/restauro verificados; três cenários concorrentes PostgreSQL aprovados. Interface /pagamentos; demonstração /consulta/pagamentos.

• 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 cenários concorrentes PostgreSQL aprovados. Sem facturas fictícias na base real. Interface em /facturas; exemplo público em /consulta/facturas.

• Orçamentos por empresa, centro de custo e exercício, com montante e base com/sem IVA explícitos, aprovação independente, reservas e compromissos auditados. Migração 000009 aplicada após backup e restauro verificados; cinco cenários concorrentes PostgreSQL aprovados. Sem dotações fictícias na base real. Centros sem dotação mantêm o circuito de desenvolvimento sem controlo. Estornos continuam pendentes; não constitui validação operacional integral do orçamento. Interface em /orcamentos.

• Equipamentos e peças ligados aos artigos existentes, compatibilidades, criticidade configurada, mínimos explícitos e alertas, saídas rastreáveis e validação técnica. Finanças é obrigatória para equipamento em qualquer valor; a adjudicação/emissão exige regra própria vigente e reserva em dotação de investimento. Migração 000008 aplicada no lote 9 após backup recuperável e verificação da preservação. Demonstração em /consulta/equipamentos.

• Página inicial em /, demonstração pública por módulo em /consulta e navegação autenticada agrupada por área e perfil.

• Recepções parciais/totais com qualidade, divergências, quantidades pendentes e segregação do emitente. Entradas de stock apenas para quantidades físicas aceites, sem duplicação; catálogo, armazéns, existências e histórico por empresa.

• Saídas com destino, responsável e fundamento; transferências atómicas; contagens físicas e ajustes justificados, com histórico e protecção contra saldos negativos e contagens desactualizadas. Migração 000007 aplicada na base actual, lote 8, após backup com recuperação ensaiada e confirmação da preservação dos registos; demonstração em /consulta/operacoes-stock.

• Empresas com filtragem de consultas por organização e testes de isolamento.

• Departamentos, centros de custo e criação administrativa de contas com perfis.

• Requisições com rascunho editável, linhas, categoria, quantidade, preço e IVA indicado por linha.

• Cálculos exactos no servidor com Brick Math, valores monetários em centavos e arredondamento por linha a meio para cima.

• Referências únicas baseadas na sequência de identificadores da base de dados; podem existir intervalos na numeração.

• Aprovações sequenciais com transacção e bloqueio da requisição, rejeição fundamentada e regras guardadas na submissão.

• Histórico de criação, edição, submissão e decisão. O modelo impede a edição e eliminação de entradas; protecção contra alterações por SQL ou acesso administrativo directo ainda exige permissões próprias na base de dados.

• Painel com indicadores reais, pesquisa e paginação de requisições.

• Fornecedores: cadastro com NUIT único por empresa, referências documentais, beneficiários, impedimentos, revisão e activação/suspensão por Finanças, distinta do autor.

• Manutenção de fornecedores por Procurement: edição, renovação da próxima revisão e controlo de versões. Alterações efectivas e novos documentos exigem nova validação independente por Finanças.

• Documentos privados de fornecedores (PDF, JPEG e PNG, de 1 KB a 2 MB): envio por Procurement e download autenticado por Administração, Procurement ou Finanças da mesma empresa, com auditoria. Chefes consultam a ficha sem acesso aos documentos.

• Cotações para requisições aprovadas: uma proposta por fornecedor, linhas completas, IVA herdado e cálculo exacto em centavos.

• Matriz comparativa com três fornecedores elegíveis e duas avaliações por proposta; preço e prazo automáticos, notas de qualidade, histórico e pagamento, declaração de ausência de conflito e auditoria.

• RF-AF-01: declarações pessoais por fornecedor/processo, correcções com histórico, consultas por perfil/empresa e impedimentos no servidor. A associação de fornecedores volta a verificar os intervenientes anteriores; declarações de ausência não anulam conflitos registados.

• Adjudicação fundamentada da proposta de maior pontuação, com escolha entre empates, revalidação de conflitos/propostas/avaliadores e excepções bloqueadas sem política aprovada.

• Novo ciclo explícito de aprovação do valor final, segundo os escalões e a base de IVA guardados no processo. As decisões da estimativa não são reutilizadas.

• Ordens únicas por processo, com valores e condições congelados, emissão idempotente, listagem, detalhe, histórico e impressão/gravação em PDF pelo navegador. São documentos de desenvolvimento, sem autorização para compras reais e sem validação orçamental.

Os menus Fornecedores e Cotações estão disponíveis para Administração, Procurement, Finanças e chefes de departamento. Procurement regista; Finanças valida os fornecedores; chefes apenas consultam/avaliam processos do seu departamento. O administrador não substitui os perfis operacionais: pode criar a equipa em Empresa e equipa. As contas existentes não foram alteradas.

Regras provisórias

Os limites iniciais são 25.000 e 150.000 MZN, inclusive, com base no total com IVA. São parâmetros por empresa na tabela tenants, guardados em centavos. Estes valores e a base com IVA são hipóteses de desenvolvimento, ainda sem validação de Finanças. A edição das regras pela interface e a dupla validação administrativa não estão implementadas.

O IVA é informado pelo utilizador e calculado no servidor. A taxa inicial de 0% no formulário não representa uma decisão fiscal; ainda falta o catálogo de taxas com vigência, dedutibilidade e validação por Finanças. A prioridade urgente não dispensa aprovações.

Próximas etapas

Revisão visual dos módulos entregues; reposição de stock; conciliação de pagamentos externos; revisão/cancelamento de processos, correcções de facturas e estornos; 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; cada empresa deve configurar e aprovar a sua regra e dotação de investimento antes de adjudicar equipamento. 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.

Esta base não implementa ainda os onze controlos anti-fraude nem todos os requisitos não funcionais do documento. MFA obrigatório, gestão completa do ciclo de vida dos acessos, delegações, política de levantamento de conflitos, alteração de regras com dupla aprovação, retenção, cópias de segurança e restauro por empresa serão tratados nas etapas correspondentes. Não usar para compras reais antes da validação destas regras e controlos.

As declarações pessoais abrem no menu Conflitos de interesses. Só o autor pode corrigir os próprios fundamentos/datas, acrescentando histórico; Administração e Finanças podem consultar as declarações da empresa. Não existe caducidade automática nem retirada de conflitos. A revisão visual continua pendente. Estão documentados quatro cenários reais de concorrência de recepção e sete de stock aprovados em PostgreSQL isolado; isto não valida a concorrência de todos os módulos nem a carga. Consulte o relatório de desenvolvimento.

Verificação

php artisan test --compact
php vendor/bin/phpstan analyse --no-progress
php vendor/bin/pint --test
npm run check
npm run types:check
npm run build

Os testes cobrem cálculos, entradas manipuladas, limites de aprovação, separação de funções, ordem das decisões, rejeição, recepção, stock, navegação e acesso entre empresas. SQLite em memória não demonstra os bloqueios PostgreSQL. Para os quatro cenários simultâneos de recepção, execute php tests/Concurrency/run-receipts.php: exige permissão de criar bases, cria uma base exclusiva compras_receipts_test_*, verifica o isolamento antes de migrar e elimina-a no final. Não altera o .env nem executa fixtures na base real. O orçamento ainda não é validado.