|
|
|
@@ -1,5 +1,61 @@
|
|
|
|
|
# Desenvolvimento do ProcuraFlow
|
|
|
|
|
|
|
|
|
|
## Incremento actual de adjudicação e ordens de compra
|
|
|
|
|
|
|
|
|
|
Implementado em 28 de Outubro de 2026 no projecto Laravel existente, segundo a secção «Próximo incremento após RF-AF-01» das orientações. O RF-AF-01, os fornecedores e os documentos privados foram reutilizados e preservados. Não foram recriadas contas, executados seeds ou alterados o SGF Tempo, o Investmoz ou a configuração local.
|
|
|
|
|
|
|
|
|
|
### Selecção e revalidação
|
|
|
|
|
|
|
|
|
|
- Procurement regista a adjudicação a partir da página de comparação de cotações. Exige justificação escrita e data/local de entrega. O solicitante não selecciona a sua própria compra; Administração consulta, sem substituir os perfis operacionais.
|
|
|
|
|
- `ProposalComparison` unifica a matriz da interface e a decisão no servidor. Recalcula preços, prazos e notas com aritmética racional; arredonda a pontuação final a duas casas decimais. Quantidades, preços e IVA são verificados em precisão decimal e centavos. Linhas devem corresponder à requisição, e os totais têm de conferir com as linhas. A entrega suporta apenas MZN.
|
|
|
|
|
- Requer três fornecedores distintos com propostas elegíveis, válidas e comparáveis; cada proposta elegível precisa de duas avaliações elegíveis. Os avaliadores têm de continuar na mesma empresa e num perfil operacional permitido, respeitar o departamento quando são chefes, ser distintos e não ser o solicitante. Uma declaração de ausência não substitui a verificação de conflitos.
|
|
|
|
|
- Escolha limitada ao topo da pontuação. Empates permitem seleccionar uma das propostas empatadas, sempre com fundamento escrito. Dispensa de cotações, escolha abaixo do topo e outros caminhos de excepção permanecem bloqueados sem política aprovada; parâmetros enviados pelo navegador não dispensam estas regras.
|
|
|
|
|
- Cada operação decisiva revalida o `ConflictGuard`, incluindo solicitante, aprovadores, autores de cotações, avaliadores e agora autor/aprovadores da adjudicação. Novas declarações continuam a bloquear operações sem apagar o histórico.
|
|
|
|
|
- A selecção fecha o registo de novas propostas e avaliações desse processo. A matriz de decisão e a sua impressão digital são guardadas. Alterações aos valores, avaliações, ponderações ou elegibilidade da matriz impedem a utilização das aprovações para emitir sobre uma base diferente.
|
|
|
|
|
|
|
|
|
|
### Escalões e ciclo de aprovação do valor final
|
|
|
|
|
|
|
|
|
|
- Os limites e a base com/sem IVA vêm do snapshot guardado na requisição; não se substituem pela configuração actual da empresa. Processos sem snapshot válido ou histórico completo de aprovação da estimativa são bloqueados.
|
|
|
|
|
- A adjudicação abre explicitamente um novo ciclo de aprovações para o valor final, mesmo quando fica no mesmo escalão. As decisões da estimativa são preservadas e não são reaproveitadas. O topo do primeiro escalão é inclusivo, tal como o segundo; ultrapassagens acrescentam Procurement e Finanças, conforme as regras guardadas.
|
|
|
|
|
- As etapas são sequenciais. Solicitante e autor da adjudicação não aprovam o ciclo; cada etapa é decidida por uma pessoa distinta. A rejeição exige fundamento. Antes de emitir, verifica-se novamente se os aprovadores finais continuam elegíveis e sem conflito.
|
|
|
|
|
- Equipamento e peças com tipos ainda não suportados são bloqueados, sem presumir aprovação técnica ou limites próprios. Não existem excepções automáticas para urgência, fornecedor único ou valores acima de limites sem política definida.
|
|
|
|
|
|
|
|
|
|
### Ordem emitida e consulta
|
|
|
|
|
|
|
|
|
|
- Ordem única por requisição e adjudicação, com referências `OC-ANO-ID`, transacção e unicidade na base de dados. Repetir a emissão devolve a ordem existente sem novas linhas, novo número, nova auditoria ou alteração dos dados congelados. Podem existir intervalos na sequência de identificadores.
|
|
|
|
|
- A ordem congela na emissão linhas, quantidades/unidades, preços, IVA, totais, moeda, fornecedor/contactos, empresa, departamento, centro de custo, referência/condições da proposta, entrega, fundamento, emitente, matriz revalidada e aprovações. A matriz guardada na adjudicação continua separada como histórico da escolha. Alterações posteriores às fichas e propostas não reescrevem a ordem.
|
|
|
|
|
- Listagem, detalhe, emitente, histórico e versão HTML para impressão ou gravação em PDF pelo navegador. A impressão escapa o conteúdo fornecido pelos utilizadores. Não há geração de PDF no servidor ou envio por email.
|
|
|
|
|
- Administração, Procurement e Finanças consultam na própria empresa; chefes apenas processos do seu departamento. Solicitantes e armazém não recebem acesso aos documentos financeiros nesta etapa.
|
|
|
|
|
- Todas as ordens exibem **Documento de desenvolvimento. Não autoriza compras reais.** O snapshot guarda `development_only=true` e `budget_checked=false`. **O orçamento ainda não é verificado**, tanto na interface como na impressão. Não foram criadas ordens reais neste incremento.
|
|
|
|
|
- Falhar a auditoria reverte a adjudicação e as suas etapas, ou a emissão e as suas linhas. Os modelos das ordens e linhas impedem edição/eliminação; a protecção contra SQL administrativo continua dependente das permissões operacionais.
|
|
|
|
|
|
|
|
|
|
### Verificação e preservação
|
|
|
|
|
|
|
|
|
|
- Suite completa Laravel: **165 passaram, 3 ignorados, 1.662 asserções**. Os 46 testes específicos de adjudicação/ordens passaram; a suite inclui também os testes anteriores de RF-AF-01/fornecedores/anexos e os três testes de pré-visualização pública acrescentados em paralelo. Os testes usam SQLite em memória, não a base de negócio.
|
|
|
|
|
- Cobertura: acesso por perfil e departamento; isolamento de empresas; valores/IVA e quantidades fraccionárias; fronteiras de 25.000 e 150.000 MZN; base com/sem IVA guardada; novo ciclo de aprovação; empates; excepções bloqueadas; conflitos/suspensão/expiração após avaliação ou selecção; elegibilidade de avaliadores/aprovadores; integridade das linhas; prevenção de repetição com unicidade/idempotência; snapshots; impressão com escape de HTML; rollback se falhar a auditoria.
|
|
|
|
|
- PHPStan aprovado, sem erros; Pint aprovado em todos os ficheiros PHP; verificação frontend sem avisos ou erros; TypeScript aprovado; compilação aprovada; `git diff --check` sem erros.
|
|
|
|
|
- Migração aditiva `2026_10_28_000005_create_purchase_awards_and_orders` aplicada no PostgreSQL local após os testes. Contagens antes/depois iguais: 1 utilizador, 1 empresa e 0 requisições, fornecedores, cotações, avaliações, documentos e declarações de conflito. Novas tabelas de adjudicações, aprovações finais, ordens e linhas vazias. Não foram criados registos sintéticos na base real.
|
|
|
|
|
- O SHA-256 do `.env` manteve-se igual antes e depois. Não houve seeds, alterações de credenciais ou configuração, nem reinicialização de dados.
|
|
|
|
|
- As rotas de ordens/adjudicação estão registadas. O acesso sem autenticação a `/ordens` redireccionou para a entrada ProcuraFlow em 8015, com HTTP 200. As páginas autenticadas e o conteúdo da impressão foram verificados em testes HTTP/Inertia, não visualmente.
|
|
|
|
|
|
|
|
|
|
Foram detectadas alterações paralelas na pré-visualização pública, na entrada e nas respectivas rotas/testes; foram preservadas e incluídas na verificação final, sem as apresentar como parte desta implementação. As alterações funcionais deste incremento permanecem limitadas à adjudicação/ordens e à integração necessária com os módulos anteriores.
|
|
|
|
|
|
|
|
|
|
### Limitações e próximo passo
|
|
|
|
|
|
|
|
|
|
**Revisão visual autenticada, revisão visual da impressão/PDF e concorrência real em PostgreSQL continuam pendentes.** Não foram realizados testes de carga. O código usa bloqueio por empresa e bloqueios dos registos de comparação/fornecedores/utilizadores dentro da transacção; isso não constitui validação de concorrência real.
|
|
|
|
|
|
|
|
|
|
Ainda não existe cancelamento/reabertura de adjudicações, alteração da data de entrega depois da selecção ou substituição de uma ordem emitida. Se a base aprovada mudar, faltar elegibilidade ou a data de entrega passar, o sistema impede a emissão; não assume uma autorização de correcção. As políticas e o fluxo de revisão/cancelamento devem ser definidos antes de ampliar esses caminhos.
|
|
|
|
|
|
|
|
|
|
Permanecem pendentes orçamento, multimoeda, dados bancários com dupla validação, aprovações técnicas de equipamentos/peças e as políticas comerciais em aberto. Próximo incremento: recepção parcial e conferência de qualidade com segregação do emitente, seguido de equipamentos, peças e stock. Não avançar para compras ou pagamentos reais.
|
|
|
|
|
|
|
|
|
|
### Ficheiros deste incremento
|
|
|
|
|
|
|
|
|
|
Migração `2026_10_28_000005`; modelos `PurchaseAward`, `PurchaseAwardApproval`, `PurchaseOrder`, `PurchaseOrderItem` e trait de imutabilidade; serviços `ProposalComparison` e `PurchaseWorkflow`; controlador `PurchaseController`; integração em `ConflictGuard` e `QuotationController`; casts decimais de `QuotationItem` e `ProposalEvaluation`; rotas autenticadas e menu; tipos `purchase.ts`, páginas `purchases/award`, `purchases/index`, `purchases/show`, ligação da comparação e vista `purchases/print.blade.php`; testes `PurchaseAwardOrderTest`; documentação.
|
|
|
|
|
|
|
|
|
|
## Entrega anterior RF-AF-01
|
|
|
|
|
|
|
|
|
|
Os registos abaixo conservam os resultados anteriores. A indicação de adjudicação e ordens como próximo passo nessas entregas fica substituída pelo incremento acima.
|
|
|
|
|
|
|
|
|
|
## Incremento actual RF-AF-01 de 28 de Outubro de 2026
|
|
|
|
|
|
|
|
|
|
### Implementado
|
|
|
|
|
