@@ -0,0 +1,29 @@
|
||||
# Conferência dos pagamentos pendentes importados
|
||||
|
||||
29/10/2026. Continuação solicitada pelo proprietário: desenvolver a ligação seguinte entre pagamentos originais e obrigação comum. Identificador: `PAYABLE-IMPORTED-DECISION-v1`.
|
||||
|
||||
O circuito existente de conferência pode confirmar ou rejeitar pagamentos que estavam pendentes na passagem de histórico. A confirmação reduz o saldo uma única vez; a rejeição conserva o saldo. Não cria pagamentos nem executa transferências.
|
||||
|
||||
## Preservação e saldo
|
||||
|
||||
A importação original e os seus pagamentos permanecem imutáveis. Cada decisão posterior acrescenta um facto em `pa_payment_decisions`, ligado ao pagamento importado, com sequência por obrigação, fotografia mínima, interveniente e hashes anterior/seguinte. O núcleo comum valida a cadeia e confronta-a com o histórico original actual antes de fornecer o saldo. Alterações estranhas à decisão deixam o saldo indisponível.
|
||||
|
||||
O pagamento original e a sua auditoria são actualizados pelo serviço de conferência já existente. A escrita do facto comum e do evento pertence à mesma transacção: uma falha reverte todos os efeitos. Bloqueios de empresa e origem serializam operações; unicidade por pagamento e sequência impede segunda decisão. Repetir a mesma decisão não gera novo abatimento; uma decisão contrária é recusada.
|
||||
|
||||
Mantêm-se revalidação do perfil Financeiro, separação do autor, direito explícito `validate`, banco actual com duas validações elegíveis, exercício actual para confirmação, conflito de interesses e limite do saldo actualizado. A importação não concede direitos adicionais. Novos registos de pagamento sobre obrigações reconhecidas continuam recusados.
|
||||
|
||||
## Instalação
|
||||
|
||||
Migração aditiva preparada: `2026_10_29_000023_create_payable_payment_decisions.php`, uma tabela com protecção contra actualização/eliminação em PostgreSQL e SQLite. Não foi aplicada em `compras_dev` nem na demonstração 8005 nesta entrega.
|
||||
|
||||
Capacidade desactivada por defeito: `COMMON_PAYABLES_HISTORY_DECISIONS_ENABLED=false`. Depende da importação histórica activa, do esquema novo e dos direitos existentes. Não se alteraram configurações, contas, concessões ou dados da instalação local/demonstração. A leitura de decisões já registadas conserva o saldo mesmo quando esta nova capacidade de escrita é desactivada; desactivar o núcleo/histórico completo continua a exigir transição explícita.
|
||||
|
||||
## Verificação
|
||||
|
||||
Regressão geral: 526 testes aprovados, 2 ignorados, 4 383 asserções. PHPStan sem erros e Pint aprovados. Após o último ajuste de tratamento de conflitos/indicação da capacidade, 20 testes específicos passaram com 109 asserções; PHPStan repetido sem erros. Interface PHP com sintaxe válida; nenhuma alteração de recursos React exige novo build nesta entrega.
|
||||
|
||||
- Testes de confirmação/rejeição, repetição, decisão contrária, independência, concessão retirada, capacidade desactivada, falha intermédia, histórico adulterado, saldo zero, limite de saldo e proibição de novos pagamentos.
|
||||
- PostgreSQL descartável: principal 11 600 MZN; confirmados originais 3 000, pendente 1 000, rejeitado 500 → saldo inicial 8 600. Dois processos confirmam o mesmo pendente: uma decisão/evento, confirmado total 4 000, saldo 7 600. Importação original preservada, trigger de imutabilidade verificado e falha injectada com reversão completa.
|
||||
- Prova: `docs/proofs/payable-payment-decisions-pg.json`. Bases e utilizadores temporários removidos no final. Revisão visual desta capacidade não realizada.
|
||||
|
||||
Para disponibilizar esta conferência na instalação local, o passo seguinte é aplicar/verificar a migração com cópia de recuperação e activar a opção. A demonstração 8005 conserva o cenário que o proprietário está a avaliar.
|
||||
@@ -1,5 +1,26 @@
|
||||
# Desenvolvimento do SGC
|
||||
|
||||
## Reforço da integração de obrigações — 29 de Outubro de 2026
|
||||
|
||||
Continuação do ensaio `COMMON-PAYABLE-SOURCE-SIM-v1`, descrito em
|
||||
[entrega comum](../../sgf-tempo/docs/SUPPLIER_PAYABLE_DELIVERY.md).
|
||||
`ExternalPaymentWorkflow` passa a revalidar o principal canónico dentro das
|
||||
transacções de registo e conferência, depois dos bloqueios da empresa e da
|
||||
factura, antes de aceitar repetições ou gravar decisões. Evita confiar apenas
|
||||
na consulta anterior à espera pelo bloqueio. Preserva as alterações existentes.
|
||||
|
||||
Acrescentado teste em `ExternalPaymentTest.php`: mesmo com instância de origem
|
||||
configurada, as quatro rotas de consulta/preparação/validação recusam acesso
|
||||
fora da base isolada e o pagamento legado continua funcional. Testes de
|
||||
pagamentos: **34 aprovados, 113 asserções**. PHPStan sem erros e Pint dos dois
|
||||
ficheiros alterados aprovado. Este teste não simula concorrência PostgreSQL.
|
||||
Regressão completa executada: **499 aprovados, 2 ignorados, 4 147 asserções**.
|
||||
Os dois ignorados correspondem à cobertura MFA já pendente na configuração.
|
||||
|
||||
Sem migrações, seeds, alterações de contas ou dados reais, novos pagamentos
|
||||
operacionais, commit, push ou publicação. Revisão visual e aceitação do ensaio
|
||||
continuam pendentes; este reforço não activa obrigações em produção.
|
||||
|
||||
## Estado consolidado após abertura e actas — 28 de Outubro de 2026
|
||||
|
||||
Referência: commit `07e775c` e [validação técnica](validacao-tecnica.md).
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
{
|
||||
"activated_at_utc": "2026-10-29T19:34:42+00:00",
|
||||
"database": "compras_dev",
|
||||
"migration": "000022",
|
||||
"history_enabled": true,
|
||||
"existing_tables_verified": 72,
|
||||
"existing_records_unchanged_except_new_audit": true,
|
||||
"accounts_and_grants_unchanged": true,
|
||||
"source_identity_unchanged": true,
|
||||
"activation_audit_id": 3,
|
||||
"history_imports": 0,
|
||||
"payment_links": 0,
|
||||
"automatic_import": false,
|
||||
"backup_restore_verified": true,
|
||||
"backup_bytes": 367910,
|
||||
"backup_sha256": "1f29bdaf0ea0379475c26e78f07cffe2ca31401ab216031b499c2562bafad7dc",
|
||||
"environment_sha256_after": "6014bcf47860188fcbba612715fce95ce9cbbd25e62f399f7b2ac03614a2d8ec",
|
||||
"public_deployment": false
|
||||
}
|
||||
@@ -0,0 +1,22 @@
|
||||
{
|
||||
"applied_at_utc": "2026-10-29T19:33:27+00:00",
|
||||
"database": "compras_dev",
|
||||
"migration": {
|
||||
"migration": "2026_10_29_000022_create_payable_history_imports",
|
||||
"batch": 23
|
||||
},
|
||||
"existing_tables_verified": 72,
|
||||
"existing_records_unchanged": true,
|
||||
"existing_constraints_preserved": true,
|
||||
"env_unchanged": true,
|
||||
"new_table_counts": {
|
||||
"pa_history_imports": 0,
|
||||
"pa_imported_payments": 0
|
||||
},
|
||||
"append_only_triggers": 2,
|
||||
"activation_enabled": false,
|
||||
"accounts_or_grants_created": false,
|
||||
"restore_verified": true,
|
||||
"backup_bytes": 367910,
|
||||
"backup_sha256": "1f29bdaf0ea0379475c26e78f07cffe2ca31401ab216031b499c2562bafad7dc"
|
||||
}
|
||||
@@ -0,0 +1,67 @@
|
||||
# Factura → obrigação: navegação integrada e próxima ligação
|
||||
|
||||
29/10/2026. Continuação local durante a avaliação do proprietário.
|
||||
|
||||
## Activação local posterior
|
||||
|
||||
Após a orientação para prosseguir, o percurso foi activado em `compras_dev`, no ambiente local. Conferida a única conta existente, #1, administrativa, empresa #1; concedidas explicitamente consulta/preparação/validação em `pa_access`, com pessoa estável `local-user-1` e auditoria `supplier_payables.local_activated`. Nome, palavra-passe, perfil e dados anteriores da conta foram preservados. Não se criou nova conta nem se dispensa revisor distinto do preparador.
|
||||
|
||||
`COMMON_PAYABLES_ENABLED=true` e identidade persistente própria foram guardados apenas no `.env` local, depois de novo backup privado de 367 719 bytes, restaurado e comparado nas 72 tabelas. O servidor público e as configurações das demonstrações não foram alterados. A aplicação tem zero facturas, zero pagamentos e zero obrigações; não houve importação, reconhecimento ou operação financeira automática. Evidência sem segredos: `obrigacoes-activacao-local.json`.
|
||||
|
||||
Acrescentada ligação «Obrigações a fornecedores» no menu Finanças quando a consulta está autorizada pelo servidor. A navegação usa carregamento de página completo, porque a página comum não é uma resposta Inertia. A revogação de consulta retira o menu e mantém a recusa no servidor. Testes de integração/navegação e pagamentos: 39 aprovados, 152 asserções; build, TypeScript e PHPStan do middleware aprovados. O PHPUnit fixa a desactivação e identidade vazia por omissão, para não herdar a activação de `.env` nos restantes testes.
|
||||
|
||||
O arranque adicional do servidor em 8015 foi recusado pela revisão automática (`blocked by policy`, sem motivo específico devolvido); não se contornou essa recusa. A configuração activada foi verificada num processo novo. A demonstração em 8005 continua disponível, com a nova ligação de menu após actualizar a página.
|
||||
|
||||
Para desactivar esta configuração enquanto não houver obrigações, definir somente `COMMON_PAYABLES_ENABLED=false`; conservar a identidade da instalação e a auditoria. Não alterar identidade ou apagar direitos/histórico como mecanismo de reversão. Havendo obrigações, preparar a transição da responsabilidade pelo saldo antes de qualquer desactivação. A activação local não conclui a migração dos pagamentos históricos nem autoriza uso financeiro real.
|
||||
|
||||
## Aplicação autorizada à instalação local
|
||||
|
||||
Após pedido expresso «aplique», 000021 foi aplicada em `compras_dev`, lote **22**, em 29/10/2026. Backup privado de 346 030 bytes, SHA-256 `481a4d2a7430e0a43c0a7ba4c190f22e5a2520a5423587f90579bcfb917d373a`, restaurado e comparado numa base separada antes da aplicação; base de restauro removida. As 65 tabelas anteriores, os seus registos, restrições e `.env` ficaram preservados. Sete tabelas novas vazias e seis triggers append-only conferidos. Aplicação e verificação feitas em transacção, com limites de bloqueio/execução, sem seeds.
|
||||
|
||||
Evidência sanitizada: `obrigacoes-migracao-000021.json`. Backup e manifesto privados em `storage/app/private/backups/supplier-payables-000021-20261029-185002-93c089/`. A activação continua desligada e nenhum acesso/conta foi criado. As demonstrações persistentes e o servidor público não foram alterados. A aplicação do esquema não incorpora facturas nem constitui obrigações automaticamente.
|
||||
|
||||
## Continuação: instalação do esquema e ativação explícita
|
||||
|
||||
Preparada a migração `2026_10_29_000021_create_supplier_payables.php`, utilizando `PayablesSchema` do pacote comum. O instalador QA usa a mesma definição: não existe uma segunda cópia do esquema. PostgreSQL e SQLite têm protecção append-only para origens, propostas, obrigações, comandos, eventos e outbox. Instalação sobre tabelas existentes ou parciais recusa reconciliação implícita. O instalador QA pode reconhecer a instalação completa da migração e confere os seis triggers PostgreSQL.
|
||||
|
||||
`COMMON_PAYABLES_ENABLED=false` é o estado inicial. A activação explícita exige `PAYABLE_SOURCE_INSTANCE` persistente e esquema instalado; não concede qualquer direito. As entradas QA existentes mantêm o reconhecimento isolado anterior. O saldo passa a conferir também a identidade canónica da origem; mudar a identidade de instalação com obrigações existentes provoca conflito em vez de cair no saldo antigo.
|
||||
|
||||
Estado anterior à autorização de aplicação: migração apenas preparada. A aplicação posterior em `compras_dev` está registada acima; as demonstrações persistentes, `.env`, contas, concessões e facturas reais continuam inalterados. A interface mantém identificação de ensaio, sem activação financeira real.
|
||||
|
||||
Facturas com pagamentos anteriores mantêm o saldo do percurso existente. A incorporação automática continua recusada; a transição com transporte explícito de histórico fica para incremento próprio. Nesta passagem não se regista ou executa nenhum novo pagamento real, nem se desbloqueiam pagamentos posteriores sobre uma obrigação incorporada.
|
||||
|
||||
Novos testes `SupplierPayableIntegrationTest.php`: activação no esquema de aplicação, reconhecimento único, principal de 6 000 centavos e vencimento nulo, saldo preservado de 2 000 após pagamento confirmado de 4 000 sobre factura de 6 000, recusa de segunda dívida, controlo de acesso/empresa, mudança de identidade e imutabilidade. Com facturas/pagamentos: 60 testes aprovados, 215 asserções. Todas as operações destes testes são em SQLite em memória, não na demonstração.
|
||||
|
||||
Prova PostgreSQL `payables-demo.ps1 proof` aprovada nos dois hosts, com instalação da nova migração em Compras e instalação QA comum em SGF: obrigação única de 11 600 MZN, vencimento desconhecido, concorrência, falhas/recuperação, versões e isolamento; orçamento/stock/pagamentos conservados. Bases e roles descartáveis removidas. PHPStan do adaptador/controlador aprovado e formatação Pint dos ficheiros deste incremento aplicada. A primeira execução PHPStan com 128 MB tinha esgotado memória; repetição com limite de 512 MB aprovada, sem configuração global.
|
||||
|
||||
Regressão completa após este incremento: **503 aprovados, 2 ignorados, 4 167 asserções** (505 testes). Mantêm-se dois testes anteriormente ignorados; não foram apresentados como executados. Sem novo build necessário neste incremento exclusivamente PHP/configuração/migração; o build do incremento anterior mantém-se aprovado.
|
||||
|
||||
## Alteração entregue
|
||||
|
||||
Cada factura apresenta uma ligação para `/obrigacoes-fornecedores?invoice={id}` quando o utilizador tem consulta do núcleo comum na instalação sintética. A página mostra apenas o documento seleccionado, as propostas, a obrigação e os eventos da respectiva identidade canónica. O regresso leva a `/facturas`. O endpoint de consulta aceita o mesmo filtro; a consulta geral mantém-se.
|
||||
|
||||
O filtro usa empresa do utilizador e `Payables::identity`, não apenas o número visível ou o identificador local. Parâmetros inválidos recebem 422; facturas inexistentes ou fora da empresa não são adoptadas. Sem filtro, o comportamento anterior é preservado. Não há reconhecimento, pagamento, consumo de stock/orçamento ou alteração de histórico por navegação.
|
||||
|
||||
## Conferência da integração existente
|
||||
|
||||
- Compras já fornece factura, fornecedor, ordem, moeda, valores/linhas e a referência da auditoria de conferência ao núcleo único. Não se redigitam esses dados no reconhecimento.
|
||||
- O núcleo conserva uma identidade por instância/empresa/documento e uma revisão da origem. A conferência documental e a validação da obrigação são decisões separadas.
|
||||
- O principal comum já é consultado pelo saldo de Compras quando a origem está incorporada e compatível. Origem alterada ou pagamentos associados provocam conflito; não se presume outro saldo.
|
||||
- A incorporação continua limitada às bases QA reconhecidas. A consulta integrada não publica nem instala o esquema na base habitual de Compras.
|
||||
- Vencimento desconhecido permanece pendência visível; não impede por si só reconhecer o principal, não é uma data inventada e não produz atraso igual a zero.
|
||||
|
||||
## Próximo incremento funcional a delimitar
|
||||
|
||||
Integrar a incorporação no percurso normal exige transportar o esquema QA para migrações de aplicação, configurar a identidade persistente da instalação e os direitos por empresa, e definir a transição das facturas já existentes. A configuração será verificável antes de aplicação; não executar migrações reais por consequência deste relatório.
|
||||
|
||||
Facturas sem pagamentos podem seguir a origem conferida e o reconhecimento existente. Para facturas com pagamentos, o plano deve preservar separadamente principal original, pagamentos confirmados e pendentes, e atribuir uma só responsabilidade pelo saldo. Nunca importar o saldo líquido como principal e deduzir pagamentos novamente. O caminho de pagamentos existente é conservado até essa transição estar implementada e verificada.
|
||||
|
||||
Revisão documental de vencimento é outro incremento: evidência, autor, versão anterior e histórico, sobre a mesma obrigação. Não inferir data a partir de texto livre nem transformar revisão documental em nova dívida. Não incluir cancelamento de ordens, estornos, notas de crédito ou operações bancárias neste delta de navegação.
|
||||
|
||||
## Verificação
|
||||
|
||||
- `scripts/invoice-payable-link-check.mjs`: consulta da factura presente na demonstração, filtro, regresso, identificadores inválidos/inexistentes e igualdade integral da consulta/histórico antes e depois. Resultado em `proofs/invoice-payable-link.json`. A demonstração tem uma factura: esta prova HTTP não declara teste de duas origens distintas ou de concorrência.
|
||||
- Regressão dirigida: `InvoiceTest.php` e `ExternalPaymentTest.php`, 56 aprovados, 195 asserções, SQLite em memória. A primeira tentativa não executou os testes por falta do driver; repetição com `-d extension=pdo_sqlite -d extension=sqlite3` aprovada, sem alteração global do PHP.
|
||||
- Build frontend aprovado, sem novas dependências. Sintaxe PHP e `git diff --check` aprovados.
|
||||
- PHPStan dos dois ficheiros PHP alterados aprovado, sem erros, com limite de memória de 512 MB por comando; a tentativa inicial com 128 MB esgotou memória, sem alterar configuração global.
|
||||
- Sem declaração de revisão visual, aceitação, publicação ou checkpoint. Dados e acessos de avaliação conservados.
|
||||
@@ -0,0 +1,48 @@
|
||||
# Menus de Compras — primeira aplicação do benchmark
|
||||
|
||||
29/10/2026. Pedido do proprietário: renovar os menus antes de retomar o trabalho funcional pendente. Referência fornecida: `referencias/benchmark-menus-20261029.txt`. Este incremento aplica a organização da navegação; não declara implementado todo o benchmark.
|
||||
|
||||
## Entregue
|
||||
|
||||
A aplicação autenticada usa agora um menu lateral por tarefas e uma barra superior com pesquisa do menu, atalho de nova requisição e conta. As secções podem ser expandidas, a área actual abre automaticamente e a ligação corrente fica destacada. Pesquisa sem distinção de acentos/maiúsculas, limpeza e mensagem de ausência de resultados. Não é uma pesquisa global de documentos.
|
||||
|
||||
| Secção | Percursos existentes reunidos |
|
||||
| --- | --- |
|
||||
| Painel inicial | Visão geral e indicadores existentes |
|
||||
| Requisições | Nova, minhas, meus rascunhos, todas as autorizadas e planeamento |
|
||||
| Aprovações | Próxima decisão elegível para o utilizador e histórico das suas decisões de requisições |
|
||||
| Consultas e adjudicações | Cotações/comparação, adjudicações/ordens e revisão/cancelamento existente |
|
||||
| Fornecedores | Cadastro e documentos |
|
||||
| Recepções e armazém | Recepções/divergências, artigos/stock, saídas/inventários, equipamentos/peças |
|
||||
| Finanças | Facturas, obrigações autorizadas, pagamentos externos, orçamentos/reforços e investimento |
|
||||
| Administração e controlo | Empresa/equipa/centros, políticas de admissão/recomendação e conflitos |
|
||||
|
||||
O layout real é `SgcShell`, usado por `AppLayout`; o componente antigo `AppSidebar` não é a navegação activa. A renovação foi feita no layout efectivamente utilizado. As consultas públicas mantêm o seu layout próprio e as ligações anteriores. O núcleo comum de obrigações continua com o seu ecrã próprio e regresso às facturas; a sua ligação usa carregamento completo para não receber uma página HTML como modal Inertia.
|
||||
|
||||
## Listas ligadas ao servidor
|
||||
|
||||
`/requisicoes?view=mine` limita ao autor da sessão. `view=approvals` reutiliza `canDecide`, incluindo empresa, departamento, próxima etapa, autor distinto, decisões anteriores e conflitos. `view=decided` filtra decisões efectivamente registadas pelo utilizador. Todos os conjuntos partem da consulta autorizada existente. Filtros de estado/referência e paginação mantêm o conjunto escolhido. `status=draft&view=mine` abre os rascunhos pessoais; não altera as regras actuais para guardar rascunhos.
|
||||
|
||||
Menu filtrado pelos perfis existentes; obrigações só aparece quando o servidor confirma consulta. Não foram criadas contas ou concessões, alterados limites, regras fiscais, processos de aprovação ou dados de negócio. Não há migração nova neste incremento.
|
||||
|
||||
## Verificação
|
||||
|
||||
- 44 testes aprovados, 539 asserções: requisições, vistas pessoais, elegibilidade, isolamento entre empresas, decisões, entrada pública e demonstrações.
|
||||
- Build, TypeScript, lint do âmbito, Pint e PHPStan do controlador aprovados; `git diff --check` sem erros.
|
||||
- Navegador local: inspecção visual a 1280 × 900 e 390 × 844; menu, expansão, pesquisa «obrigacoes» sem acentos, ausência/limpeza de resultados, destaque único da ligação visível, vistas de rascunhos/aprovações e navegação para obrigações/regresso às facturas. Sem deslocamento horizontal nos modos verificados. Dimensão temporária reposta no final.
|
||||
- Drawer móvel com foco contido e botão de fecho; ligações fecham o drawer. Sem operações de negócio durante a prova visual.
|
||||
- Capturas em `proofs/screenshots/menu-desktop.png` e `menu-mobile.png`. Esta é verificação técnica visual, não aceitação atribuída ao proprietário.
|
||||
|
||||
## Trabalho preservado para continuação
|
||||
|
||||
### Conferência das ligações após renovação
|
||||
|
||||
`scripts/menu-links-check.mjs` verifica a própria definição do menu contra a instalação local: **94 entradas somadas nos seis perfis**, páginas de conta/aparência, recusas no servidor para empresa/finanças sem direito, vistas pessoais, ordenação dos parâmetros e opção activa. No processo de exemplo, conferidas 12 ligações internas, incluindo requisição, orçamento, cotações, adjudicação, ordem, recepção, facturas, pagamentos, relatório, admissão e recomendação. Factura → obrigação → facturas e igualdade do histórico antes/depois também aprovadas. Evidência em `proofs/menu-links.json`; sem comandos de negócio.
|
||||
|
||||
Encontrados e corrigidos dois destaques de navegação: `/requisicoes/{id}/relatorio` pertence a cotações/comparação e `/requisicoes/{id}/adjudicacao` pertence a adjudicações/ordens. Antes abriam a página correcta, mas o menu destacava requisições. Os casos têm agora asserções de regressão na conferência. Build actualizado aprovado.
|
||||
|
||||
Esta conferência é HTTP e de correspondência das rotas do menu. A nova inspecção visual não pôde ser repetida porque o controlo do navegador devolveu `browser.user is unavailable`, incluindo ao recuperar o separador existente; não se apresenta a prova visual do incremento anterior como nova verificação. As capturas anteriores permanecem referências da entrega inicial.
|
||||
|
||||
Retomar o transporte do histórico de pagamentos na integração factura → obrigação, preservando principal, confirmações/pendências e responsabilidade única pelo saldo. A aplicação do esquema e a activação local anteriores ficam preservadas.
|
||||
|
||||
O formulário proposto no benchmark continua a ser evolução funcional própria: guardar dados incompletos, revisão antes de submeter, aviso de alterações não guardadas, anexos e campos/validações adicionais. Contratos/acordos, catálogo unificado, multimoeda, pesquisa global e novos relatórios ainda exigem implementação. Os menus desta entrega conduzem a capacidades existentes; não representam essas capacidades futuras como concluídas.
|
||||
@@ -0,0 +1,22 @@
|
||||
{
|
||||
"activated_at_utc": "2026-10-29T18:53:31+00:00",
|
||||
"database": "compras_dev",
|
||||
"user_id": 1,
|
||||
"tenant_id": 1,
|
||||
"actions": [
|
||||
"view",
|
||||
"prepare",
|
||||
"validate"
|
||||
],
|
||||
"enabled": true,
|
||||
"source_instance": "compras-local-aa0dbeec75b98ca65246756541f75363",
|
||||
"backup_restore_verified": true,
|
||||
"backup_bytes": 367719,
|
||||
"backup_sha256": "f6df149cd91fae24dbe233952e04064b0325e8d968182c7e76e624cb7b3d93cd",
|
||||
"existing_account_preserved": true,
|
||||
"invoice_count_unchanged": true,
|
||||
"payment_count_unchanged": true,
|
||||
"obligations": 0,
|
||||
"automatic_import": false,
|
||||
"public_deployment": false
|
||||
}
|
||||
@@ -0,0 +1,27 @@
|
||||
{
|
||||
"applied_at_utc": "2026-10-29T18:50:28+00:00",
|
||||
"database": "compras_dev",
|
||||
"migration": {
|
||||
"migration": "2026_10_29_000021_create_supplier_payables",
|
||||
"batch": 22
|
||||
},
|
||||
"existing_tables_verified": 65,
|
||||
"existing_records_unchanged": true,
|
||||
"existing_constraints_preserved": true,
|
||||
"env_unchanged": true,
|
||||
"new_table_counts": {
|
||||
"pa_access": 0,
|
||||
"pa_sources": 0,
|
||||
"pa_proposals": 0,
|
||||
"pa_obligations": 0,
|
||||
"pa_commands": 0,
|
||||
"pa_events": 0,
|
||||
"pa_outbox": 0
|
||||
},
|
||||
"append_only_triggers": 6,
|
||||
"activation_enabled": false,
|
||||
"accounts_or_grants_created": false,
|
||||
"restore_verified": true,
|
||||
"backup_bytes": 346030,
|
||||
"backup_sha256": "481a4d2a7430e0a43c0a7ba4c190f22e5a2520a5423587f90579bcfb917d373a"
|
||||
}
|
||||
@@ -1,5 +1,37 @@
|
||||
# Continuidade do desenvolvimento do SGC
|
||||
|
||||
**Conferência posterior dos pendentes implementada, 29/10/2026:** confirmação/rejeição ligada ao núcleo comum com decisão imutável, saldo único e escrita original atómica. Provas SQLite e PostgreSQL descartável, incluindo dois pedidos simultâneos e reversão de falha, aprovadas. Ver [entrega](conferencia-pendentes-importados.md). Migração 000023 e opção de conferência preparadas, ainda não aplicadas/activadas em `compras_dev` ou 8005; importação local anterior preservada. Substitui a pendência de desenvolver esta conferência, sem novos pagamentos/transferências.
|
||||
|
||||
**Aplicação/activação histórica local concluída, 29/10/2026:** após «continue», 000022 aplicada em `compras_dev`, lote 23, e flag histórica activada, após backup/restauro das 72 tabelas. Registos/restrições preservados, duas tabelas novas vazias e dois triggers verificados. Activação auditada sem novas contas/concessões ou alteração de identidade; zero facturas/pagamentos/obrigações e nenhuma incorporação automática. Ver `historico-migracao-000022.json`, `historico-activacao-local.json` e [relatório](passagem-historico-pagamentos.md). Demo 8005 permanece sem esta migração/activação, confirmada em leitura; restantes demos e público preservados. Substitui apenas as indicações históricas de aplicação/activação pendentes abaixo. Novos pagamentos e decisão de pendentes depois da passagem continuam incremento próprio.
|
||||
|
||||
**Verificação final do histórico:** regressão geral com 517 aprovados, 2 ignorados e 4 337 asserções; últimos reforços de identidade cobertos por 11 testes específicos/64 asserções. PHPStan/Pint aprovados. PostgreSQL histórico (concorrência, falha/retoma, imutabilidade) e regressão anterior nas duas composições aprovados; bases descartáveis removidas. 000022/flag histórica permanecem por aplicar/activar na base local. Conta, três concessões anteriores e dados locais preservados. Ver [entrega do histórico](passagem-historico-pagamentos.md).
|
||||
|
||||
**Passagem de pagamentos históricos implementada em testes, 29/10/2026:** [âmbito, arquitectura e provas](passagem-historico-pagamentos.md), `PAYABLE-HISTORY-IMPORT-v1`. Principal bruto preservado, confirmados deduzidos uma vez, pendentes/rejeitados conservados sem abatimento; fotografia preparada e validada por pessoa distinta, conflito em alterações e responsabilidade única do saldo. Fonte comum; migração 000022 preparada, flag histórica desligada por omissão, sem aplicação às bases habituais/demos ou novas concessões. Prova PostgreSQL com concorrência, falha/retoma, imutabilidade e originais preservados aprovada (`proofs/payable-history-pg.json`). Novos pagamentos/confirmação de pendentes após passagem, reconciliação e contabilidade continuam separados.
|
||||
|
||||
**Ligações conferidas após o novo menu:** 94 entradas em seis perfis e 12 ligações internas do processo, filtro pessoal/estado, factura → obrigação/regresso e histórico conservado. Prova em `proofs/menu-links.json`, repetível por `scripts/menu-links-check.mjs`. Corrigido o destaque do relatório (cotações) e adjudicação (ordens); ambas as páginas já abriam correctamente. Build actualizado aprovado. Inspecção visual nova indisponível por falha da ligação de controlo do navegador; não declarar nova revisão visual. Sem alterações de negócio, migração ou concessões. Retomar depois a transição dos pagamentos históricos.
|
||||
|
||||
**Menus renovados a partir do benchmark, 29/10/2026:** [entrega e continuação](menus-benchmark-20261029.md). Layout autenticado real `SgcShell` com menu lateral, pesquisa, secções por tarefa e adaptação móvel; consultas públicas preservadas. Novos conjuntos de requisições pessoais, aprovações elegíveis e decisões efectivas, sem alargar direitos. 44 testes/539 asserções, build, TypeScript, lint, PHPStan e verificação visual desktop/móvel aprovados. Sem novas migrações, concessões ou operações de negócio. Próximo trabalho: retomar transição do histórico de pagamentos factura → obrigação. Formulário completo do benchmark, contratos, catálogo, moedas e relatórios continuam incrementos próprios; não os declarar entregues por aparecerem no benchmark.
|
||||
|
||||
**Activação local posterior, 29/10/2026:** `compras_dev` activada com identidade persistente e três direitos auditados para a conta administrativa existente #1/empresa #1, após novo backup/restauro das 72 tabelas. Sem nova conta, mudança de palavra-passe/perfil, facturas/pagamentos/obrigações ou importação automática. Ver `obrigacoes-activacao-local.json` e [relatório](integracao-factura-obrigacao.md). Menu Finanças com ligação condicional pelo servidor; build/TypeScript/PHPStan e 39 testes dirigidos/152 asserções aprovados. Arranque extra de 8015 recusado pela revisão automática; demonstração 8005 preservada e disponível. Substitui a indicação histórica de activação desligada abaixo. Pagamentos históricos e utilização real continuam fora desta activação.
|
||||
|
||||
**Aplicação expressamente autorizada e concluída, 29/10/2026:** pedido «aplique» executado apenas para 000021 em `compras_dev`, lote 22. Backup privado/restauro comparado antes da aplicação; preservadas as 65 tabelas anteriores, registos, restrições e `.env`. Sete tabelas novas vazias e seis triggers append-only verificados. Ver `obrigacoes-migracao-000021.json` e [relatório](integracao-factura-obrigacao.md). A activação permanece desligada; nenhuma conta/concessão, incorporação de facturas ou obrigação automática. Demos e servidor público preservados. Este registo substitui apenas a indicação histórica de 000021 por aplicar, abaixo.
|
||||
|
||||
**Verificação final deste incremento:** regressão completa com 503 aprovados, 2 ignorados e 4 167 asserções; prova PostgreSQL nos dois hosts aprovada e ambientes descartáveis removidos; PHPStan aprovado. Não aplicar 000021 à instalação habitual por inferência, nem importar facturas com liquidações anteriores sem transição própria. A avaliação local continua disponível e preservada.
|
||||
|
||||
**Esquema de aplicação preparado, 29/10/2026:** migração 000021 usa `PayablesSchema` único no pacote comum (QA e aplicação), com histórico append-only; opt-in `COMMON_PAYABLES_ENABLED` desligado por omissão e identidade persistente da instalação. Não aplicada às bases habituais ou demos persistentes; sem novas concessões reais. Facturas com pagamentos preservam percurso/saldo anterior e recusam incorporação automática. Reconhecimento único, saldo, permissões, identidade e imutabilidade: 60 testes dirigidos/215 asserções aprovados. Ver [relatório](integracao-factura-obrigacao.md). A interface continua ensaio; transporte do histórico de pagamentos continua pendente.
|
||||
|
||||
**Continuação durante avaliação, 29/10/2026:** [ligação por factura e conferência da integração](integracao-factura-obrigacao.md). Cada factura elegível abre a sua origem/propostas/obrigação/histórico no núcleo comum, com regresso às facturas; filtro por empresa e identidade canónica. Sem reconhecimento ou pagamentos por navegação. Build e 56 testes dirigidos/195 asserções aprovados; prova HTTP da factura existente conserva histórico. A integração na instalação habitual e a transição de facturas com pagamentos continuam delimitadas no relatório, sem aplicação real automática.
|
||||
|
||||
**Acesso local de avaliação, 29/10/2026:** pedido do proprietário para retomar Compras e disponibilizar acesso semelhante ao SGF. Entrada http://127.0.0.1:8005/avaliar, proprietário administrativo e seis perfis sintéticos sem palavra-passe, ligação persistente acima da aplicação e directório de 20 páginas. Implementação em `routes/evaluation.php`, apenas no host QA local e base/role verificadas; contas reais/porta 8015 preservadas. Resultado HTTP em `proofs/evaluation-access.json`. Não remove segregação dos processos nem declara aceitação visual ou demonstração completa de todos os percursos. SSH e publicação adiados. Incremento funcional mais recente continua a obrigação comum de fornecedor abaixo; não avançar automaticamente para pagamentos/cancelamento de ordens sem delimitar o respectivo âmbito.
|
||||
|
||||
**Implementação sintética de obrigações, 29/10/2026:** [entrega nas duas composições](../../sgf-tempo/docs/SUPPLIER_PAYABLE_DELIVERY.md). Reutiliza `InvoiceWorkflow`/origem conferida; principal comum de 11 600 MZN com vencimento/dias nulos. `outstanding()` delega para o principal canónico apenas na origem QA reconhecida e recusa história/versão incompatível; pagamentos desse cenário ficam bloqueados. Fora do ensaio mantém-se o percurso anterior. Sem migração ou concessão real, novos pagamentos, stock/orçamento adicional ou lançamentos. Preservar avaliação orçamental em paralelo; aceitação/visual/checkpoint continuam separados.
|
||||
|
||||
**Regras comuns de produto, 29/10/2026:** referência nas [oito regras SGF/Compras](../../sgf-tempo/docs/SUPPLIER_PAYABLE_SCOPE.md#14-orientação-comum-de-produto-da-tempo--29102026). Documento, obrigação, liquidação, confirmação, reconciliação e contabilidade são factos distintos; núcleo único preserva origem, idempotência e histórico. Vencimento desconhecido gera pendência sem inventar data/apagar principal. Afectações parciais, excessos não afectados, correcções e cobrança configurada orientam a evolução, mas o incremento actual é apenas obrigação a fornecedor. Sem implementação ou alargamento a pagamentos/cobranças nesta actualização documental.
|
||||
|
||||
**Especificação completada em 29/10/2026, apenas documental:** [matriz e proposta de obrigações](../../sgf-tempo/docs/SUPPLIER_PAYABLE_SCOPE.md), secções 9–13. Inclui estados/funções, vencimento desconhecido, unicidade por origem independentemente da chave de pedido, transição preservando pagamentos confirmados/pendentes e exemplo 1 160,00 MZN para confirmação. Sem implementação, migração, alteração de pagamentos ou avaliação orçamental. A dívida implícita existente não desaparece por falta de vencimento; nenhum segundo saldo será tratado como autoridade.
|
||||
|
||||
**Ligação seguinte, 29/10/2026 — delimitação:** [factura conferida → obrigação a pagar](../../sgf-tempo/docs/SUPPLIER_PAYABLE_SCOPE.md). Reutilizar factura/fornecedor/valores/decisão existentes e preservar o saldo implícito de `ExternalPaymentWorkflow::outstanding`, sem segunda base de dívida. Falta vencimento estruturado e referência explícita da revisão de origem; não inventar versão nativa ou interpretar condições textuais como data. Apenas conferência/desenho nesta passagem; sem novo pagamento, stock, lançamento ou alterações às bases reais. Orçamento entregue e avaliação da equipa continuam independentes.
|
||||
|
||||
**Aceitação técnica de 29/10/2026:** a Tempo aceitou a extracção `COMMON-BUDGET-SYNTHETIC-v1` e autorizou checkpoint exclusivamente local nos dois repositórios, sem uso real/push/publicação. Ver [aceitação](../../sgf-tempo/docs/COMMON_BUDGET_ACCEPTANCE.md). Revisão visual Compras pendente; SGF apenas adaptador QA sem interface deste percurso; dois testes MFA ignorados continuam pendentes. Esta aceitação substitui apenas a pendência de encerramento técnico abaixo. Próximo passo: percurso sintético integrado SGF, sem bloquear desenvolvimento pela automação do navegador.
|
||||
|
||||
**Execução posterior em 29/10/2026:** `COMMON-BUDGET-SYNTHETIC-v1` implementado, com fonte única no pacote SGF, adaptadores locais e duas bases descartáveis. Ver [relatório técnico](../../sgf-tempo/docs/COMMON_BUDGET_DELIVERY.md). Conservar as alterações e os percursos; sem aceitação presumida, checkpoint de encerramento, migração/concessões/dados reais, publicação ou push. Não avançar para obrigações/pagamentos/contabilidade por arrasto.
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
# Passagem de histórico de pagamentos para obrigações
|
||||
|
||||
29/10/2026. Continuação autorizada pelo proprietário após a conferência do novo menu. Identificador técnico: `PAYABLE-HISTORY-IMPORT-v1`.
|
||||
|
||||
## Resultado e limites
|
||||
|
||||
Implementada uma passagem explícita em duas etapas: preparar a fotografia dos pagamentos existentes e validá-la por pessoa distinta. A factura conferida mantém o principal integral. A obrigação comum passa a fornecer o saldo, deduzindo uma única vez apenas os pagamentos anteriormente confirmados. Pendentes e rejeitados conservam montantes/estados e não são deduzidos.
|
||||
|
||||
Não é um novo pagamento, afectação arbitrária ou reconciliação bancária. Não executa transferências, confirma pendentes, cria stock, consome novamente orçamento ou produz lançamentos contabilísticos. O circuito normal continua a recusar incorporar pagamentos implicitamente; o percurso novo tem acções e activação próprias.
|
||||
|
||||
Exemplo de referência: principal 1 160,00 MZN, confirmado 300,00 e pendente 100,00 → saldo 860,00. Prova PostgreSQL integrada: principal 11 600,00, confirmado 3 000,00, pendente 1 000,00 e rejeitado 500,00 → saldo 8 600,00; pendente/rejeitado não reduzem o saldo. Vencimento e dias de atraso mantêm-se nulos.
|
||||
|
||||
## Responsabilidade e preservação
|
||||
|
||||
- Fonte única em `sgf-tempo/packages/payables`: `HistoricalPayments`, `HistorySchema` e extensão opcional de `Payables`; sem segundo motor de saldo no adaptador Compras.
|
||||
- `principal()` conserva o principal documental; `balance()` consulta a posição do núcleo. `ExternalPaymentWorkflow::outstanding()` recebe o saldo comum já líquido, sem voltar a subtrair os mesmos pagamentos.
|
||||
- A fotografia guarda IDs, empresa/documento/moeda, valor, estado, autor/data e referências das auditorias de registo/decisão. Não copia referências externas cifradas, comprovativos, contas bancárias ou instruções de pagamento.
|
||||
- O adaptador confere que a auditoria corresponde ao pagamento, factura, valor, estado e interveniente. Confirmações/rejeições exigem decisão independente; a importação não reescreve decisões históricas em função dos perfis actuais desses antigos intervenientes.
|
||||
- Identidade canónica por instância/empresa/documento, chave única por pagamento original e uma importação por obrigação/origem. Mudança de identidade não pode criar uma segunda obrigação para a mesma factura local.
|
||||
- Mudança de pagamentos entre preparação e validação produz conflito e exige nova fotografia. Leitura posterior detecta origem/histórico divergente e deixa o saldo indisponível, conservando principal/originais. Desactivar a integração com obrigação incorporada não autoriza cair silenciosamente no saldo antigo.
|
||||
- A gravação do principal, passagem, ligações, eventos e idempotência é transaccional. Falha intermédia não deixa incorporação parcial. A importação não altera as tabelas originais de factura, pagamentos, orçamento ou stock.
|
||||
|
||||
## Esquema, acesso e interface
|
||||
|
||||
Migração aditiva `2026_10_29_000022_create_payable_history_imports.php`, com duas tabelas append-only: `pa_history_imports` e `pa_imported_payments`. Reutiliza os direitos explícitos de preparação/validação existentes; a validação própria permanece recusada. Não cria contas nem concessões.
|
||||
|
||||
Activação separada `COMMON_PAYABLES_HISTORY_ENABLED=false` por omissão. Exige integração anterior activa, esquema completo e adaptador com fornecedor de histórico. O SGF mantém o percurso anterior sem pagamentos; esta entrega não configura automaticamente um fornecedor de pagamentos históricos no adaptador SGF.
|
||||
|
||||
Na página comum, quando activado e existindo pagamentos na factura, surge «Incorporar factura com pagamentos anteriores». A proposta apresenta confirmados/pendentes/rejeitados. A obrigação apresenta principal e saldo por liquidar separadamente. As fotografias antigas continuam consultáveis. Depois da passagem, novos pagamentos e confirmação de pendentes ficam para o incremento do circuito comum; não continuar a escrever pelo percurso antigo após transferir a responsabilidade.
|
||||
|
||||
## Estado de aplicação
|
||||
|
||||
Após orientação posterior «continue», **000022 aplicada em `compras_dev`, lote 23**, e `COMMON_PAYABLES_HISTORY_ENABLED=true` guardado no `.env` local. Novo backup privado de 367 910 bytes, SHA-256 `1f29bdaf0ea0379475c26e78f07cffe2ca31401ab216031b499c2562bafad7dc`, restaurado e comparado nas 72 tabelas antes da aplicação; base de restauro removida. Registos/restrições anteriores preservados na aplicação transaccional; duas tabelas novas vazias e dois triggers append-only conferidos.
|
||||
|
||||
Activação registada em `supplier_payables.history_local_activated`, sem criar conta ou alterar concessões. Projecções dos registos das 72 tabelas anteriores conferidas novamente, descontando apenas o registo da nova migração e a nova entrada de auditoria. Identidade da instalação e permissões anteriores preservadas. A configuração foi confirmada num processo novo: activação histórica verdadeira, uma conta, três direitos anteriores e zero facturas/pagamentos/obrigações. Nenhuma incorporação automática.
|
||||
|
||||
Evidências sanitizadas: `historico-migracao-000022.json` e `historico-activacao-local.json`. Backup/manifesto privados em `storage/app/private/backups/payable-history-000022-20261029-193307-f5d793/`.
|
||||
|
||||
As demonstrações persistentes e o servidor público não foram migrados/configurados nesta aplicação. Conferência só de leitura em 8005 confirmou activação histórica falsa e ausência das tabelas novas nesse ambiente. A demonstração não passa a ter histórico sintético por consequência da activação de `compras_dev`. Migração/activação anteriores 000021, menus e acessos do proprietário preservados. A interface nova foi conferida por resposta HTML nas provas PostgreSQL, sem uma nova prova visual no navegador.
|
||||
|
||||
## Provas
|
||||
|
||||
`PayableHistoryImportTest.php`: principal bruto/saldo, decisão independente, repetição da mesma chave e de chaves distintas, pagamentos pendentes/rejeitados, total liquidado, alteração entre proposta/validação, ausência de auditoria, falha/recuperação, imutabilidade, configuração desactivada, duplicações/omissões/incompatibilidades, mudança de identidade e exemplo 1 160−300=860.
|
||||
|
||||
`scripts/payable-history-proof.mjs`: cria bases/roles QA exclusivas, regista/conferencia os pagamentos sintéticos pelo circuito existente, injecta uma falha e valida simultaneamente em dois processos. Confere uma obrigação, uma importação, três ligações, saldo correcto, original de negócio intacto, protecções SQL e recusa de alteração histórica; elimina as bases/roles no final. Relatório sanitizado: `proofs/payable-history-pg.json`.
|
||||
|
||||
Regressão geral: **517 aprovados, 2 ignorados, 4 337 asserções** (519 testes). Após o reforço final da consulta de identidade, repetida a bateria específica: **11 aprovados, 64 asserções**. PHPStan dos adaptadores/controlador e Pint do âmbito aprovados. A prova antiga de obrigações sem pagamentos também passou em Compras e SGF, com concorrência/recuperação e efeitos de orçamento/stock/pagamentos preservados. As bases e roles de ambas as provas PostgreSQL foram removidas.
|
||||
|
||||
Leitura anterior à aplicação: 000022 não aplicada e importação histórica desactivada. A aplicação/activação posteriores estão registadas acima. Não há build novo neste incremento PHP/esquema; o frontend e os menus anteriores não foram alterados. As verificações técnicas e a activação local não constituem aceitação visual ou publicação, nem executam pagamentos.
|
||||
@@ -0,0 +1,42 @@
|
||||
{
|
||||
"checked_at": "2026-10-29T18:55:02.410Z",
|
||||
"base": "http://127.0.0.1:8005",
|
||||
"owner_modules": [
|
||||
"/dashboard",
|
||||
"/empresa",
|
||||
"/requisicoes",
|
||||
"/planeamento",
|
||||
"/fornecedores",
|
||||
"/cotacoes",
|
||||
"/ordens",
|
||||
"/recepcoes",
|
||||
"/stock",
|
||||
"/stock/operacoes",
|
||||
"/equipamentos",
|
||||
"/orcamentos",
|
||||
"/regras-investimento",
|
||||
"/facturas",
|
||||
"/pagamentos",
|
||||
"/obrigacoes-fornecedores",
|
||||
"/conflitos",
|
||||
"/revisao-compras",
|
||||
"/politica-admissao",
|
||||
"/politica-recomendacao"
|
||||
],
|
||||
"roles": [
|
||||
"requester",
|
||||
"department_head",
|
||||
"procurement",
|
||||
"finance",
|
||||
"warehouse",
|
||||
"admin"
|
||||
],
|
||||
"csrf_enforced": true,
|
||||
"arbitrary_role_refused": true,
|
||||
"arbitrary_user_refused": true,
|
||||
"logout": true,
|
||||
"business_commands": 0,
|
||||
"real_accounts_changed": false,
|
||||
"operational_entry_status": "not running",
|
||||
"visual_review": false
|
||||
}
|
||||
@@ -0,0 +1,11 @@
|
||||
{
|
||||
"checked_at": "2026-10-29T18:41:52.592Z",
|
||||
"documents_checked": 1,
|
||||
"per_invoice_entry": true,
|
||||
"return_to_invoices": true,
|
||||
"invalid_identifiers_refused": true,
|
||||
"unknown_invoice_refused": true,
|
||||
"full_listing_unchanged": true,
|
||||
"business_commands": 0,
|
||||
"visual_review": false
|
||||
}
|
||||
@@ -0,0 +1,155 @@
|
||||
{
|
||||
"checked_at": "2026-10-29T19:14:17.130Z",
|
||||
"results": [
|
||||
{
|
||||
"role": "admin",
|
||||
"checked_entries": 24,
|
||||
"paths": [
|
||||
"/requisicoes/criar",
|
||||
"/requisicoes?view=mine",
|
||||
"/requisicoes?view=mine&status=draft",
|
||||
"/requisicoes?view=all",
|
||||
"/planeamento",
|
||||
"/requisicoes?view=approvals",
|
||||
"/requisicoes?view=decided",
|
||||
"/cotacoes",
|
||||
"/ordens",
|
||||
"/revisao-compras",
|
||||
"/fornecedores",
|
||||
"/recepcoes",
|
||||
"/stock",
|
||||
"/stock/operacoes",
|
||||
"/equipamentos",
|
||||
"/facturas",
|
||||
"/obrigacoes-fornecedores",
|
||||
"/pagamentos",
|
||||
"/orcamentos",
|
||||
"/regras-investimento",
|
||||
"/empresa",
|
||||
"/politica-admissao",
|
||||
"/politica-recomendacao",
|
||||
"/conflitos"
|
||||
]
|
||||
},
|
||||
{
|
||||
"role": "procurement",
|
||||
"checked_entries": 17,
|
||||
"paths": [
|
||||
"/requisicoes/criar",
|
||||
"/requisicoes?view=mine",
|
||||
"/requisicoes?view=mine&status=draft",
|
||||
"/requisicoes?view=all",
|
||||
"/planeamento",
|
||||
"/requisicoes?view=approvals",
|
||||
"/requisicoes?view=decided",
|
||||
"/cotacoes",
|
||||
"/ordens",
|
||||
"/revisao-compras",
|
||||
"/fornecedores",
|
||||
"/recepcoes",
|
||||
"/stock",
|
||||
"/stock/operacoes",
|
||||
"/equipamentos",
|
||||
"/regras-investimento",
|
||||
"/conflitos"
|
||||
]
|
||||
},
|
||||
{
|
||||
"role": "finance",
|
||||
"checked_entries": 21,
|
||||
"paths": [
|
||||
"/requisicoes/criar",
|
||||
"/requisicoes?view=mine",
|
||||
"/requisicoes?view=mine&status=draft",
|
||||
"/requisicoes?view=all",
|
||||
"/planeamento",
|
||||
"/requisicoes?view=approvals",
|
||||
"/requisicoes?view=decided",
|
||||
"/cotacoes",
|
||||
"/ordens",
|
||||
"/revisao-compras",
|
||||
"/fornecedores",
|
||||
"/recepcoes",
|
||||
"/stock",
|
||||
"/stock/operacoes",
|
||||
"/equipamentos",
|
||||
"/facturas",
|
||||
"/obrigacoes-fornecedores",
|
||||
"/pagamentos",
|
||||
"/orcamentos",
|
||||
"/regras-investimento",
|
||||
"/conflitos"
|
||||
]
|
||||
},
|
||||
{
|
||||
"role": "department_head",
|
||||
"checked_entries": 14,
|
||||
"paths": [
|
||||
"/requisicoes/criar",
|
||||
"/requisicoes?view=mine",
|
||||
"/requisicoes?view=mine&status=draft",
|
||||
"/requisicoes?view=all",
|
||||
"/planeamento",
|
||||
"/requisicoes?view=approvals",
|
||||
"/requisicoes?view=decided",
|
||||
"/cotacoes",
|
||||
"/ordens",
|
||||
"/revisao-compras",
|
||||
"/fornecedores",
|
||||
"/recepcoes",
|
||||
"/equipamentos",
|
||||
"/conflitos"
|
||||
]
|
||||
},
|
||||
{
|
||||
"role": "warehouse",
|
||||
"checked_entries": 11,
|
||||
"paths": [
|
||||
"/requisicoes/criar",
|
||||
"/requisicoes?view=mine",
|
||||
"/requisicoes?view=mine&status=draft",
|
||||
"/requisicoes?view=all",
|
||||
"/planeamento",
|
||||
"/revisao-compras",
|
||||
"/recepcoes",
|
||||
"/stock",
|
||||
"/stock/operacoes",
|
||||
"/equipamentos",
|
||||
"/conflitos"
|
||||
]
|
||||
},
|
||||
{
|
||||
"role": "requester",
|
||||
"checked_entries": 7,
|
||||
"paths": [
|
||||
"/requisicoes/criar",
|
||||
"/requisicoes?view=mine",
|
||||
"/requisicoes?view=mine&status=draft",
|
||||
"/requisicoes?view=all",
|
||||
"/planeamento",
|
||||
"/revisao-compras",
|
||||
"/conflitos"
|
||||
]
|
||||
}
|
||||
],
|
||||
"request_detail_checked": true,
|
||||
"invoice_count": 1,
|
||||
"process_links_checked": [
|
||||
"/requisicoes/1",
|
||||
"/orcamentos",
|
||||
"/requisicoes/1/cotacoes",
|
||||
"/requisicoes/1/adjudicacao",
|
||||
"/ordens/1",
|
||||
"/ordens/1/recepcoes",
|
||||
"/facturas",
|
||||
"/pagamentos",
|
||||
"/requisicoes/1/relatorio",
|
||||
"/requisicoes/1/admissao",
|
||||
"/requisicoes/1/recomendacao",
|
||||
"/recepcoes/1"
|
||||
],
|
||||
"canonical_query_order": true,
|
||||
"active_subroutes": true,
|
||||
"business_history_unchanged": true,
|
||||
"business_commands": 0
|
||||
}
|
||||
@@ -0,0 +1,28 @@
|
||||
{
|
||||
"checked_at": "2026-10-29T19:41:38.688Z",
|
||||
"passed": true,
|
||||
"fault_recovery": true,
|
||||
"concurrent_recognition": true,
|
||||
"original_business_history_unchanged": true,
|
||||
"new_transfers_executed": false,
|
||||
"scenario": {
|
||||
"principal_minor": 1160000,
|
||||
"balance_minor": 860000,
|
||||
"confirmed_minor": 300000,
|
||||
"pending_minor": 100000,
|
||||
"rejected_minor": 50000,
|
||||
"obligations": 1,
|
||||
"imports": 1,
|
||||
"payment_links": 3,
|
||||
"business_fingerprint": "fb66326abf7968aa818b0c6a214c2a1f59966fa11d3692e748fa0fa1aaa3cf1f",
|
||||
"ui_balance_correct": true,
|
||||
"due_on": null,
|
||||
"days_overdue": null,
|
||||
"append_only_tables": [
|
||||
"pa_history_imports",
|
||||
"pa_imported_payments"
|
||||
],
|
||||
"changed_history_refused": true
|
||||
},
|
||||
"visual_review": false
|
||||
}
|
||||
@@ -0,0 +1,19 @@
|
||||
{
|
||||
"checked_at": "2026-10-29T19:41:38.669Z",
|
||||
"passed": true,
|
||||
"atomic_rollback": true,
|
||||
"concurrent_decision_once": true,
|
||||
"original_import_preserved": true,
|
||||
"new_transfers_executed": false,
|
||||
"scenario": {
|
||||
"balance_minor": 760000,
|
||||
"confirmed_minor": 400000,
|
||||
"pending_minor": 0,
|
||||
"decisions": 1,
|
||||
"events": 1,
|
||||
"original_status": "confirmed",
|
||||
"append_only": true,
|
||||
"frozen": "4b5aa40f964c0709661449b4ab5bfd7cd8295eac9c4d186822d0a1e10aa63534"
|
||||
},
|
||||
"visual_review": false
|
||||
}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
@@ -0,0 +1,131 @@
|
||||
Compras: ecrãs e proposta de menu
|
||||
Referências funcionais, estrutura de navegação e inspiração visual
|
||||
|
||||
Explorar os ecrãs do Oracle Purchasing
|
||||
Referência: Oracle E-Business Suite 12.2, com foco no Procurement Command Center. Esta análise descreve funções documentadas; não é uma demonstração interactiva nem uma reprodução de capturas de ecrã.
|
||||
Consultar o guia oficial do Procurement Command Center. Na página, procurar os títulos em inglês abaixo para localizar cada painel.
|
||||
Ecrã Função documentada
|
||||
Summary — Resumo Visão global das actividades e dos indicadores de procurement.
|
||||
Requisitions — Requisições Priorizar requisições conforme as necessidades e apoiar a criação de encomendas.
|
||||
Orders — Encomendas Acompanhar encomendas e o tempo de processamento do ciclo de compra.
|
||||
Order Details — Detalhes da encomenda Painel de detalhe incluído no capítulo de operações de procurement.
|
||||
Agreements — Acordos Rever acordos e identificar problemas que possam afectar as compras.
|
||||
Strategic Sourcing — Compras estratégicas Analisar negociações, poupanças e negociações ainda não adjudicadas.
|
||||
Indirect Procurement — Compras indirectas Identificar oportunidades de utilização de contratos e analisar compras fora de contrato.
|
||||
Supplier Analysis — Análise de fornecedores Analisar entregas pontuais, qualidade e cumprimento dos preços.
|
||||
Item Analysis — Análise de artigos Apoiar a selecção de artigos com base no histórico e em critérios de desempenho.
|
||||
Employee Shopping Tracker — Pesquisa no catálogo Analisar pesquisas de artigos ou serviços para melhorar o catálogo.
|
||||
Fonte das funções acima: guia oficial Oracle. Os painéis permitem pesquisa, filtros laterais, combinação de critérios e pesquisas guardadas. A disponibilidade depende da instalação e configuração do Command Center.
|
||||
Percurso de exploração sugerido
|
||||
1. Começar em Summary para compreender a visão global.
|
||||
2. Passar a Requisitions e Orders para seguir o ciclo operacional.
|
||||
3. Consultar Agreements e Strategic Sourcing para explorar contratos e negociações.
|
||||
4. Terminar em Supplier Analysis e Item Analysis para analisar fornecedores e artigos.
|
||||
Este percurso é uma recomendação de leitura, não uma sequência obrigatória
|
||||
Propor um menu de procurement
|
||||
Proposta conceptual para um software próprio. Os módulos, campos e acções seguintes são recomendações de desenho, não o menu oficial do Oracle.
|
||||
Menu principal Submenus e acções propostas
|
||||
Painel inicial Minhas tarefas; requisições pendentes; encomendas em aberto; alertas de entrega; contratos a expirar.
|
||||
Requisições Nova requisição; minhas requisições; todas as requisições autorizadas; acompanhamento do estado.
|
||||
Aprovações Pendentes; histórico; devolver para correcção; aprovar ou rejeitar com justificação.
|
||||
Consultas e concursos Pedidos de cotação; concursos; propostas recebidas; mapa comparativo; adjudicações.
|
||||
Ordens de compra Criar ordem; rascunhos; ordens aprovadas; alterações; acompanhamento de entregas.
|
||||
Fornecedores Cadastro; documentos; categorias de fornecimento; qualificação; histórico de compras.
|
||||
Contratos Contratos activos; acordos de preços; renovações; adendas; alertas de validade.
|
||||
Recepções Receber bens; confirmar serviços; recepções parciais; divergências; devoluções.
|
||||
Facturas Registo; conferência com ordem e recepção; divergências; envio à contabilidade; consulta do estado de pagamento.
|
||||
Catálogo Artigos e serviços; categorias; unidades de medida; preços acordados.
|
||||
Relatórios Despesa por fornecedor e categoria; tempos de aprovação; entregas em atraso; compras fora de contrato.
|
||||
Administração Utilizadores e perfis; limites de aprovação; centros de custo; moedas; integrações; registo de auditoria.
|
||||
Organização dos ecrãs
|
||||
• Navegação: menu lateral por módulo e barra superior com pesquisa, notificações e perfil.
|
||||
• Listagens: filtros por estado, período e fornecedor; tabela central; acção principal claramente identificada.
|
||||
• Detalhe: separadores para dados gerais, linhas, anexos, aprovações e histórico.
|
||||
• Requisição: departamento, centro de custo, descrição, artigo ou serviço, quantidade, unidade, data necessária e anexos.
|
||||
• Comparação de propostas: fornecedor, preço, moeda, impostos, prazo de entrega, condições de pagamento e critérios de selecção.
|
||||
• Ordem de compra: fornecedor, referência à requisição, linhas, entrega, condições comerciais e estado de aprovação.
|
||||
Perfis e controlos propostos
|
||||
Requisitante: cria e acompanha pedidos. Aprovador: decide sobre pedidos atribuídos. Comprador: gere consultas e ordens. Recepção: confirma entregas. Financeiro: confere facturas. Administrador: configura acessos e regras.
|
||||
Recomenda-se separar criação, aprovação e recepção, restringir dados por perfil e registar alterações. O módulo Facturas deve integrar-se com a contabilidade, evitando duplicar a execução de pagamentos.
|
||||
Fluxo de referência proposto: requisição → aprovação → consulta ou concurso, quando aplicável → adjudicação → ordem de compra → recepção → conferência da factura → processamento financeiro.
|
||||
Especificação do ecrã Nova requisição
|
||||
Proposta funcional para desenvolvimento do software próprio; não descreve um ecrã oficial do Oracle. As regras deverão ser confirmadas com a organização antes da implementação.
|
||||
Objectivo e acesso
|
||||
Permitir ao requisitante registar uma necessidade de bens ou serviços, guardar um rascunho e submetê-lo para aprovação. Acesso proposto: Requisições → Nova requisição. O utilizador só pode seleccionar departamentos e centros de custo para os quais tenha autorização.
|
||||
Campos do cabeçalho
|
||||
Campo Obrigatoriedade e comportamento Validação na submissão
|
||||
Número da requisição Automático e só de leitura, atribuído ao guardar. Identificador único; não editável pelo requisitante.
|
||||
Requisitante e data de criação Automáticos, a partir da sessão e do sistema. Utilizador autenticado; data e hora registadas pelo sistema.
|
||||
Departamento Obrigatório; selecção da lista autorizada. Departamento activo e acessível ao utilizador.
|
||||
Centro de custo Obrigatório; lista dependente do departamento. Activo, autorizado e compatível com o departamento.
|
||||
Título e descrição da necessidade Obrigatórios; título breve e descrição do objectivo. Não aceitar campos vazios ou apenas espaços.
|
||||
Tipo de pedido Obrigatório: bens, serviços ou misto. As linhas devem ser coerentes com o tipo seleccionado.
|
||||
Data necessária Obrigatória; data pretendida para entrega ou início do serviço. Não anterior à data local de submissão. Avisar quando o prazo for inferior ao prazo de compra configurado.
|
||||
Local de entrega ou execução Obrigatório; local autorizado e instruções complementares opcionais. Local activo; instruções não substituem a selecção do local.
|
||||
Prioridade e justificação de urgência Prioridade normal por defeito; justificação obrigatória se urgente. Urgência não dispensa aprovação nem autoriza contornar o processo.
|
||||
Moeda Obrigatória; única para toda a requisição. Moeda activa. Para comparação com orçamento noutra moeda, exigir taxa e data de conversão válidas.
|
||||
Projecto ou actividade Opcional, salvo exigência do centro de custo. Quando indicado, deve estar activo e associado ao centro de custo.
|
||||
Estado Só de leitura; rascunho ou submetido neste ecrã. Alterado exclusivamente pelas acções autorizadas.
|
||||
Campos das linhas
|
||||
Campo Obrigatoriedade e comportamento Validação na submissão
|
||||
Artigo ou serviço e categoria Obrigatórios; escolher do catálogo ou introduzir descrição livre quando permitido. Entrada de catálogo activa. Fora do catálogo: descrição, categoria e justificação obrigatórias.
|
||||
Especificação técnica Obrigatória para pedidos fora do catálogo; opcional se o catálogo já definir a necessidade. Indicar características necessárias; para serviços, âmbito e resultado esperado.
|
||||
Quantidade Obrigatória; valor numérico positivo. Superior a zero; precisão compatível com a unidade de medida.
|
||||
Unidade de medida Obrigatória; proveniente do catálogo ou da lista configurada. Unidade activa e compatível com o artigo ou serviço.
|
||||
Preço unitário estimado Obrigatório na moeda do cabeçalho; não representa preço adjudicado. Superior a zero. Sem estimativa, permitir guardar rascunho, mas bloquear submissão até completar.
|
||||
Tratamento fiscal e taxa estimada Obrigatórios; opções configuradas, incluindo isenção ou não aplicável. Taxa válida para o tratamento escolhido. Não assumir automaticamente uma taxa fiscal.
|
||||
Subtotal, imposto e total estimado Calculados e só de leitura. Preço unitário proposto sem imposto. Subtotal = quantidade × preço unitário; imposto calculado pelo tratamento configurado; total = subtotal + imposto. Arredondamento conforme a moeda.
|
||||
Fornecedor sugerido Opcional; selecção do cadastro e motivo da sugestão. Fornecedor activo. A sugestão não constitui adjudicação nem obriga à contratação.
|
||||
Anexos e resumo
|
||||
Permitir anexar especificações, fotografias ou documentos de suporte, sujeitos às extensões e ao tamanho máximo configurados. Verificar ficheiros no servidor, incluindo conteúdo potencialmente perigoso, e aplicar os mesmos acessos da requisição. Exigir anexos apenas nas categorias ou situações definidas pelas regras internas; mostrar essa exigência antes da submissão.
|
||||
Apresentar o total estimado na moeda do pedido, a indicação de que não é um compromisso de compra e o percurso de aprovação previsto. Se houver controlo orçamental integrado, mostrar a disponibilidade e a data da consulta; sem integração, indicar “Orçamento não verificado”, sem simular disponibilidade.
|
||||
Acções do ecrã
|
||||
Acção Comportamento proposto
|
||||
Adicionar linha Inserir artigo ou serviço mantendo a moeda e os dados do cabeçalho.
|
||||
Remover linha Disponível em rascunho; pedir confirmação se a linha tiver dados e recalcular o resumo.
|
||||
Anexar ou remover documento Disponível em rascunho; validar ficheiro e confirmar remoção.
|
||||
Guardar rascunho Permitir dados incompletos; validar os valores já preenchidos e manter a requisição fora da fila de aprovação. Confirmar a gravação com número e data.
|
||||
Pré-visualizar Mostrar cabeçalho, linhas, anexos e totais antes de submeter, sem alterar o estado.
|
||||
Submeter para aprovação Validar o pedido completo, apresentar confirmação com total e percurso previsto, gravar e encaminhar uma única vez. Mostrar número e estado após sucesso.
|
||||
Voltar à lista Se houver alterações não guardadas, oferecer guardar rascunho, descartar alterações ou continuar a editar.
|
||||
Regras de submissão e mensagens
|
||||
• Exigir pelo menos uma linha válida, todos os campos obrigatórios e os anexos condicionais.
|
||||
• Confirmar no servidor os acessos, os dados activos, os cálculos e a regra de aprovação. Bloquear se não existir um percurso de aprovação aplicável.
|
||||
• Quando o controlo orçamental for obrigatório, bloquear se não for possível verificá-lo. Insuficiência de orçamento deve seguir a regra de bloqueio ou excepção aprovada pela organização, nunca uma dispensa automática.
|
||||
• Bloquear a auto-aprovação do requisitante; encaminhar para aprovador autorizado alternativo quando necessário.
|
||||
• Detectar possíveis pedidos duplicados e apresentar aviso para revisão. Evitar submissões repetidas por duplo clique ou repetição da ligação.
|
||||
• Destacar cada erro junto ao campo e apresentar um resumo navegável, por exemplo: “Seleccione um centro de custo” ou “A quantidade deve ser superior a zero”. Preservar os dados introduzidos.
|
||||
• Após submissão, tornar os dados submetidos só de leitura. Correcções posteriores devem seguir um processo controlado de devolução ou revisão, com histórico.
|
||||
• Registar autor, data, alterações e transições de estado. Detectar edição concorrente para não substituir silenciosamente alterações de outro utilizador.
|
||||
• Em falha de gravação ou ligação, não apresentar sucesso. Preservar os dados no ecrã e permitir verificar o estado antes de tentar novamente.
|
||||
Critérios de aceitação
|
||||
1. Um pedido incompleto pode ser guardado em rascunho, mas não pode ser submetido.
|
||||
2. Campos obrigatórios em falta, quantidade inválida ou preço sem estimativa impedem a submissão e mostram mensagens específicas.
|
||||
3. Alterar quantidade, preço ou tratamento fiscal actualiza os totais segundo as regras configuradas.
|
||||
4. Um pedido válido é gravado e encaminhado uma única vez, com número identificável e estado submetido.
|
||||
5. O utilizador não consegue seleccionar centros de custo não autorizados nem editar dados de um pedido já submetido.
|
||||
6. Ao abandonar alterações não guardadas, é apresentada uma confirmação; nenhuma perda de dados ocorre sem escolha explícita.
|
||||
Decisões a confirmar antes do desenvolvimento: limites de aprovação, política orçamental, moedas e taxas de conversão, tratamentos fiscais, categorias com anexos obrigatórios, limites dos ficheiros e regras de urgência. Não foram assumidos limiares ou valores específicos da organização.
|
||||
Comparar as referências visuais
|
||||
A comparação distingue documentação de um sistema real de projectos de design. As recomendações de utilização são uma apreciação para este trabalho; não resultam de testes de usabilidade.
|
||||
Referência Conteúdo disponível Utilização recomendada e limite
|
||||
Oracle Purchasing
|
||||
Documentação oficial de painéis operacionais e analíticos do Procurement Command Center. Validar funções e processos. A documentação não substitui uma demonstração da instalação concreta.
|
||||
Figma — Purchase Management Dashboard
|
||||
Projecto com ordens de compra, fornecedores, comparação de cotações, orçamento, entregas e aprovações hierárquicas. Explorar a estrutura de um projecto de interface. Um desenho não comprova funcionamento, integrações ou segurança de um sistema.
|
||||
Dribbble — Procurement UI
|
||||
Galeria de interfaces de procurement, painéis, fornecedores e concursos. Comparar rapidamente abordagens visuais. As imagens isoladas podem não mostrar o fluxo completo ou os estados de erro.
|
||||
Behance — Procurement Dashboard
|
||||
Galeria de projectos de painéis e plataformas de procurement. Procurar projectos que expliquem várias páginas e decisões de design. A profundidade e o carácter funcional variam por projecto.
|
||||
Fontes consultadas: as referências ligadas em cada linha. Consulta realizada em 29 de Outubro de 2026. A comparação baseia-se nas descrições públicas disponíveis; não foi feita uma inspecção visual detalhada de cada ecrã nem um teste dos protótipos.
|
||||
Recomendação para avançar
|
||||
Usar o Oracle como referência funcional, o projecto Figma como ponto de partida para organização de interface e as galerias Dribbble e Behance para procurar alternativas visuais. Não copiar uma aparência sem confirmar que suporta o processo de compra pretendido.
|
||||
Critérios para escolher uma interface
|
||||
• Clareza dos estados: rascunho, submetido, aprovado, rejeitado e concluído.
|
||||
• Facilidade de executar tarefas: criar uma requisição, comparar propostas e acompanhar uma encomenda.
|
||||
• Visibilidade de prazos, responsáveis e próximos passos.
|
||||
• Tratamento de anexos, comentários, divergências e histórico.
|
||||
• Legibilidade, contraste e navegação por teclado.
|
||||
• Adaptação à língua portuguesa e às moedas utilizadas pela organização.
|
||||
Estes critérios são recomendações para avaliação futura; não representam resultados medidos nas referências.
|
||||
|
||||
Reference in New Issue
Block a user