Percurso orçamental sintético no SGF

29/10/2026. SGF-BUDGET-WORKSPACE-SIM-v1. Implementação autorizada do passo seguinte à aceitação técnica do núcleo comum. Disponível para teste da equipa, sem aceitação ou checkpoint de encerramento presumidos.

Disponibilidade e preservação

Entrada local: http://127.0.0.1:8003. É o SGF existente: mesmo bootstrap, entrada por sessão, selecção de empresa/unidade, navegação e componentes React. Depois de seleccionar o contexto, abrir Compras → Controlo orçamental sintético ou o atalho da página inicial.

A instalação de demonstração tem base PostgreSQL própria budget_core_sgf_<12 hex>, uma conta técnica exclusiva sem superuser/CREATEDB/CREATEROLE, chave da aplicação, cookie, sessões e cache separados. Não usa sgf_tempo_dev, sgf_tempo_test ou compras_dev. A demonstração anterior em 8002 conserva contas/dados e não foi substituída. Esta composição demonstra o percurso orçamental no SGF; não reúne automaticamente todos os dados/módulos da demonstração anterior.

O estado inicial mantém quatro contas, centros e origens sintéticos, sem dotações, decisões ou movimentos pré-preenchidos. A prova HTTP usa outra base/role descartável em 8004; não consome o cenário que a equipa vai experimentar. A conferência da disponibilidade registou quatro utilizadores e zero dotações/movimentos/consumos/comandos antes da revisão da equipa.

powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-demo.ps1 status
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-demo.ps1 start
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-demo.ps1 stop

start recusa porta ocupada; o provisionamento repetido preserva a base, pessoas sintéticas, passwords e histórico. stop só termina o servidor próprio identificado e conserva os dados. Não há reset automático. Não executar testes destrutivos apontados para a base persistente da equipa. O servidor está limitado a loopback; não foi publicado ou disponibilizado remotamente.

Contas por função

Função	Conta sintética	Acções
Preparação	`preparacao-orcamento@example.test`	Consultar, preparar dotação, propor reforço
Validação	`validacao-orcamento@example.test`	Consultar, aprovar dotação, aprovar/recusar reforço
Operação	`operacao-orcamento@example.test`	Consultar, reserva/adjudicação/compromisso/libertação e consumo simulado
Consulta	`consulta-orcamento@example.test`	Ler saldos, referências, movimentos e histórico; sem escrita

As passwords aleatórias de cada conta estão exclusivamente no ficheiro local protegido C:\laragon\data\sgf-tempo\secrets\budget-demo-access.json, campo accounts. Consultá-lo localmente; não copiar passwords para chat, relatórios, capturas ou Git. As configurações de ligação/chave estão noutro ficheiro privado, budget-demo.json. Os ficheiros têm ACL do utilizador local/SYSTEM. Não foi alterada conta ou concessão real nem atribuída função a pessoas reais.

Empresa: Empresa Horizonte — Orçamento sintético. Unidade: Unidade Central — Orçamento sintético. Centro do guião: ORC-DEMO. A unidade reservada e a empresa sem membership não são autorizadas. Tenant, empresa, unidade e centro continuam identificadores distintos, sem equiparação automática.

Guião funcional da equipa

Usar entradas decimais com ponto. Para o exemplo sem imposto desta prova, indicar total e subtotal iguais; isto não configura uma taxa fiscal. Os valores e saldos abaixo são MZN.

Preparação: entrar, seleccionar empresa/unidade e abrir Compras. Criar dotação de 1000.00 em ORC-DEMO, exercício actual, corrente, base com imposto indicado e fundamento sintético. O estado fica pendente e o total aprovado/disponível é zero, sem autorização presumida.
Validação: sair/entrar com a conta de validação, seleccionar o contexto e aprovar. Conferir dotação aprovada 1000.00, actor e data. A preparação não pode aprovar a sua proposta.
Operação: seleccionar a dotação e a origem SIM-COMPRA-001. Reservar 300.00 (total e subtotal): reservado 300, disponível 700. Registar ajuste de adjudicação para 350.00: reservado 350, disponível 650. Registar compromisso 350.00: reserva zero, compromisso 350 e disponível 650.
Operação: em consumo simulado, usar a mesma origem, referência SIM-CONSUMO-001 e total/subtotal 100.00. Conferir compromisso 250, consumo 100 e disponível 650. Repetir a mesma referência/valores: não surge segundo consumo. Não é criada factura, obrigação, pagamento ou lançamento.
Preparação: propor reforço 200.00, referência SIM-REFORCO-001 e fundamento. Disponível continua 650 enquanto pendente. Validação: aprovar distintamente. Conferir total aprovado 1200 e disponível 850.00, com dotação inicial 1000 preservada.
Operação: na origem separada SIM-COMPRA-LIBERTAR, reservar 200 e libertar antes de compromisso. Disponível volta a 850. Repetição não duplica a libertação; compromisso posterior à libertação é recusado. Uma origem já comprometida não recebe nova libertação por este circuito.
Consulta: conferir cartões de saldo, tabela dos deltas, origem, dotação, actor, data, referência do consumo e histórico expansível. Esta conta não mostra formulários de escrita; pedidos directos sem direito também são recusados.

A dotação seleccionada determina os centros/origens apresentados nos formulários; campos de operação só aparecem para dotação aprovada do exercício actual e com origem no mesmo centro. Se o cenário já estiver usado, conservar o histórico: não se reabre ou apaga uma origem para repetir a demonstração. A equipa pode rever/repetir os comandos idempotentes; cenários adicionais devem ser acrescentados explicitamente em QA, sem reset do trabalho anterior.

As alterações de contexto limpam os formulários e não aplicam respostas tardias de outro contexto aos dados apresentados. Em erro de rede, repetir o mesmo conteúdo recupera a mesma chave de comando do formulário; o servidor mantém chaves por actor/contexto/acção e recusa conteúdo divergente.

Implementação e fronteira do núcleo

resources/js/PurchasingBudgetWorkspace.jsx: interface; recebe saldos do servidor, formata centavos com BigInt e não calcula disponibilidade/impostos. Preparação, operação, validação e consulta filtradas por direitos.
resources/js/app.jsx, WorkspaceNavigation.jsx, WorkspaceHome.jsx: montagem incremental nos componentes existentes e atalhos por função/unidade.
app/Modules/Purchasing/BudgetController.php: GET e POST do percurso, sob sessão, auth_version, CSRF e token de contexto existentes.
BudgetWorkspace.php: valida/normaliza entradas monetárias exactas, referências, sequência do cenário e comandos idempotentes; apresenta movimentos e auditoria. Não calcula deltas ou saldos financeiros.
BudgetAdapter.php e packages/budget-control: reutilizados sem alteração. O hash do núcleo coincide com as provas da extracção aceite em f77900e. Reserva/compromisso/consumo/reforço/libertação continuam com um único motor financeiro.
Novas tabelas exclusivamente QA: cb_ui_commands (recuperação/idempotência de pedidos) e cb_consumption_sources (referências de consumo simulado). A coluna histórica invoice_id do núcleo aponta, neste ensaio, para a referência sintética; não representa factura emitida ou contas a pagar implementadas.
scripts/budget-demo-*: provisionamento, servidor, acesso e estado. O provisionador usa a ferramenta PostgreSQL local já disponível em Compras para criar base/role novas, através da base de manutenção postgres; a aplicação SGF usa depois apenas a sua role QA restrita. Não existe dependência de um SGF remoto nem comunicação entre aplicações para executar os movimentos.

Provas técnicas e limites da revisão visual

Prova reproduzível:

powershell -NoProfile -ExecutionPolicy Bypass -File scripts/budget-workspace-proof.ps1

Prova HTTP: quatro sessões reais, login/logout, contexto e funções; dotação/aprovação, sequência 300→350→compromisso→consumo100→reforço200, valores exactos 650/850 disponíveis; referência/consumo únicos; insuficiência de saldo; precisão não representável recusada sem arredondar; falha por consumo excessivo com rollback da referência e recuperação; replay igual e conflito de conteúdo; libertação única sem reabertura; proibição de escrita por consulta; origem de outro âmbito, unidade reservada e contexto antigo recusados; CSRF activo. Base/role da prova removidas no final e sem alterações ao cenário da equipa.

scripts/budget-workspace-render-check.mjs: formatação exacta dos valores, deltas negativos, maior valor suportado, desconhecido como indisponível e navegação por unidade. O teste de início/menu existente também passou. Build SGF e sintaxe PHP/PowerShell passaram. Não se instalaram nem actualizaram dependências. A regressão destrutiva SGF não foi apontada para sgf_tempo_test; preservou-se a demonstração existente. As provas aceites de concorrência do núcleo mantêm-se; não se atribui concorrência de browsers a esta bateria HTTP sequencial.

A interface existe agora e está disponível para a equipa. A validação foi técnica por HTTP, verificação de componentes/formatação e compilação; não foi realizada nova revisão visual no navegador nem se presume aceitação da equipa. O bloqueio anterior da automação não foi usado como dependência para implementar ou disponibilizar este percurso. A revisão visual de Compras e os dois testes MFA ignorados continuam pendências da entrega anterior; este incremento não os encerra.

Limites de implantação e continuação

Sem migração em bases existentes, sem concessões reais, sem utilização real habilitada, sem novo motor e sem alterações ao orçamento industrial. O adaptador continua bloqueado fora do ambiente/base QA. O schema é preparado por scripts sintéticos, não por migrações registadas para aplicar em desenvolvimento/produção. Migração operacional, regras fiscais/contabilísticas e instalação completa de Compras permanecem fora desta entrega.

Próximo passo: a equipa percorre o guião e regista função, referência sintética, passos e resultado observado/esperado. Corrigir dificuldades concretas preservando origens e histórico; decidir aceitação separadamente. Não houve novo commit/checkpoint de encerramento, push ou publicação.

11 KiB Raw Blame History