SGF/docs/SGF_PURCHASING_DOSSIER_DELIVERY.md

Dossiê de leitura do processo de Compras

03/11/2026. SGF-PURCHASING-DOSSIER-QA-v1. Consulta conjunta dos registos efectivos da requisição, propostas, adjudicação, ordens, recepções, facturas, obrigação e histórico autorizado. Não prepara decisões nem replica os motores financeiros.

Experimentar em8074

Solicitante, chefia, Compras e Finanças encontram Dossiês e evidência no mapa e na navegação comum. A entrada exige o direito existente de consulta da requisição; ter apenas recepções ou facturas não concede este dossiê.

A demonstração nova conserva o percurso integrado, começando sem operações principais. Depois de preparar uma requisição e avançar nas etapas autorizadas, o dossiê encontra os mesmos documentos e respectivos IDs. Três fornecedores e orçamento QA1000MZN são preparação explícita; nenhuma localização atribuída.8073 e anteriores não foram actualizadas. A pesquisa paginada de fornecedores continua disponível, com os três fornecedores desta nova fixture; o directório ampliado de125admissíveis permanece na demo8073.

Implementação

• /purchasing/dossiers e /api/purchasing-dossiers: lista paginada25, com filtro de estado e pesquisa literal pelo número da requisição. A origem usa RequisitionAccess e a visibilidade nativa actual, no contexto exacto da empresa/unidade.
• O detalhe confere separadamente o direito de consulta de cada etapa e a função nativa, mantendo as concessões consultadas bloqueadas durante a leitura. A consulta financeira da obrigação passa também pelo adaptador original. Não foram criados novos direitos.
• Etapas sem acesso devolvem apenas accessible:false: sem linhas, contagens, IDs ou montantes escondidos no JSON. A interface distingue restrito de sem registos nesta página. O histórico filtra as acções das etapas autorizadas e projecta apenas ID, autor, tipo e data, sem fotografias anteriores/posteriores de outros domínios.
• Propostas, adjudicações, ordens, recepções, facturas e histórico têm páginas independentes25 no servidor. Para obrigações, a janela é de25facturas de origem; posições/saldos vêm do mesmo núcleo. A paginação financeira está identificada como janela de origens, sem inventar uma contagem global de dívidas.
• A impressão da vista cobre somente os dados/páginas visíveis e o contexto. Não é uma aprovação da operação seguinte, uma revisão de todo o universo ou substituto das prévias existentes. Cada etapa mantém a sua conferência e histórico próprio.
• O dossiê tem apenas endpoints GET. Não cria reservas, compromissos, movimentos, documentos, obrigações, pagamentos ou lançamentos. A navegação remete para as etapas existentes; nenhuma etapa é confirmada automaticamente.

Provas e reutilização

Consolidação:49verificações — leitura30, guardas4, demonstração12 e build/assets3. As provas de leitura reutilizam a base de regressão, não a demo, que já continha o percurso completo100MZN. Foi criada outra aplicação e outras sessões privadas, preservando a aplicação, configuração, ligações e dados da prova anterior. Não se repetiu qualquer comando financeiro.

Foram comparadas as142tabelas das duas bases e as suas sequências antes/depois: a impressão permaneceu exactamente igual. O dossiê encontrou os IDs originais da ordem, factura e obrigação, principal/saldo100MZN e vencimento desconhecido. Verificou páginas distintas de evidência/histórico, filtros, contexto desactualizado, unidade/módulo indevidos, origem estrangeira e recusa de POST.

Compras não recebeu dados de facturas/obrigações sem os direitos próprios; o solicitante recebeu apenas a requisição e o seu histórico autorizado, sem linhas ou contagens posteriores. Perfis apenas de Armazém ou revisão de facturas não herdaram consulta de requisições.

Na demonstração nova e vazia, os testes conferem os perfis e a revogação/restauro de uma concessão QA existente, deixando os dados e concessões exactamente iguais ao início. Esse ensaio de revogação não alterou a base de regressão reutilizada ou qualquer acesso real. Guardas de capacidade desligada/ambiente real recusaram antes de SQL.

As provas anteriores do percurso integrado, pesquisa de fornecedores e obrigação permanecem preservadas, sem repetição das suites de escrita, concorrência, recuperação ou contabilidade.

A matriz actualizada conserva seis módulos,13estágios e112critérios documentados. A inspecção estática encontra74fontes e nenhum ciclo obrigatório, sem ligações a bases. Passaram9verificações de sintaxe PHP,7de JavaScript e git diff --check; estas verificações não constituem prova visual ou de implantação.

Limitações e preservação

Este é um dossiê de leitura com permissões por etapa; não é fila universal de tarefas, aprovação transversal ou motor de previsão da próxima decisão. Sem registos numa página não prova que o processo esteja pronto para avançar; as regras e prévias de cada etapa continuam a decidir essa possibilidade.

A nova demonstração começa vazia; o percurso completo já realizado é utilizado somente pela prova de leitura na base de regressão. Não se copiaram decisões para a demo da equipa. Revisão visual, carga sustentada e capacidade de implantação continuam pendentes, sem repetir o navegador bloqueado ou inferir produção a partir destes ensaios.

Configuração desligada por omissão. Nenhuma migração/concessão no destino, alteração dos seis registos protegidos, limpeza da cache bloqueada, activação de Compras, publicação, aceitação ou checkpoint. Pagamentos/contabilização da nova origem, anexos/correcções e reunião dos restantes módulos conservam âmbitos próprios.