Files
SGF/docs/SGC_PREPARATION_20261110.md
2026-11-11 09:00:17 +02:00

38 lines
5.5 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Preparação SGC — 10/11/2026
Continuação posterior do mesmo dia: [endpoint de facturas implementado e provado](SGC_INVOICE_ENDPOINT.md),78 verificações, motor nativo e autenticação/contexto/idempotência. A rota está agora registada especificamente, mas permanece desligada por omissão. Os bloqueios descritos abaixo registam o estado **anterior** desta preparação; as classes/serviços legados não são usados como writer alternativo.
Pedido: aplicar migrations, implementar/popular dimensão temporal de dez anos, limpar configuração/rotas e experimentar o POST de facturas. Não constitui activação do conector ou autorização de pagamentos/concessões novas.
## Executado
- PostgreSQL existente em127.0.0.1:55432 retomado, sem criar cluster/base/porta. Destino confirmado pela configuração: `sgf_tempo_dev`. A instalação8085 não foi copiada, actualizada ou substituída nesta preparação.
- Backup privado anterior à aplicação: `C:/laragon/data/sgf-tempo/backups/sgc-preparation-20261110/before.dump`. Não se executou restauro; não se declara recuperação ensaiada.
- Migrations explícitas `2026_11_09_000001_create_sgc_integration_tables` e `2026_11_09_000002_create_sgc_analytics_tables` aplicadas por proprietário de manutenção existente, lotes18/19. Não se executou migrate global: `2026_10_28_130000_create_workshop_billing_corrections` continua pendente e não pertence ao pedido SGC.
- Corrigidas três falhas da migration analítica: importação de `DB`, referência de departamento para `analytics_dim_organizacao.id` e alias reservado PostgreSQL `do` substituído por `org`. A primeira tentativa analítica falhou pelo alias e reverteu transaccionalmente; a segunda concluiu. A primeira migration não foi repetida nem revertida.
- O comando `PopulateDimTempo` já existia como esqueleto vazio com nome `app:populate-dim-tempo`; foi implementado como `sgc:populate-dim-tempo`. Não se executou `make:command` sobre esse ficheiro existente.
- População explícita de01/01/2026 a31/12/2035:3652 dias. Segunda execução:0 inserções. Usa gerador, lotes250 e transacção única; `insertOrIgnore` preserva datas e classificações existentes, sem truncate/update.
- `eh_dia_util` representa segunda a sexta; os feriados oficiais não foram fornecidos/validados e não são inferidos. `eh_feriado=false` é o valor preparatório da migration, não uma certificação de calendário laboral.
- `config:clear` e `route:clear` executados com PHP8.4.27 do projecto. Não se executaram `cache:clear`, `optimize:clear` ou remoções da cache de dados protegida.
## Verificação
Quatro testes unitários/17 asserções: intervalo, unicidade, ano bissexto, campos de calendário, simulação sem ligação à base e recusa de argumentos inválidos. Apenas este ficheiro de testes foi executado. O harness inicial de dois testes não fornecia o container mínimo exigido pelo comando Laravel; corrigido sem ligar a bases ou executar suites alheias.
Conferência SQL de3652 linhas, limites2026–2035 e existência da vista materializada. Fotografia anterior/posterior de todas as86 tabelas públicas preexistentes, excepto a tabela de controlo `migrations`: contagens e MD5 de todas as linhas ordenadas idênticos. Inclui dados e concessões/cache anteriores, não apenas as suas contagens. Fotografias ficam privadas; não foram impressos dados/credenciais. As tabelas novas de facturas/log SGC permanecem vazias. Nenhuma concessão explícita nova; SELECT/INSERT da conta de aplicação sobre o calendário estão disponíveis pelas permissões existentes.
```powershell
& 'C:/laragon/tools/sgf-tempo/php-8.4.27/php.exe' artisan sgc:populate-dim-tempo --start-year=2026 --years=10
& 'C:/laragon/tools/sgf-tempo/php-8.4.27/php.exe' artisan sgc:populate-dim-tempo --start-year=2026 --years=10 --dry-run
```
## POST: resultado e bloqueios
O POST de diagnóstico para `http://sgf-tempo.test/api/v1/integration/sgc/invoices`, com JSON vazio e Accept JSON, devolveu **404**. Não é o teste positivo pedido, nem uma factura aceite. O ficheiro `tests/payloads/invoice_test.json` não existe. A chave de idempotência deve ser gerada com `[guid]::NewGuid().ToString()` no PowerShell quando houver um contrato/payload válido; `uuidgen` não é pressuposto neste Windows.
`artisan route:list --path=api/v1/integration/sgc` confirma ausência da rota registada: `bootstrap/app.php` não inclui `routes/api.php`. Esse ficheiro novo também oferece pagamentos/analytics e não declara autenticação/isolamento. Não se registou todo o ficheiro para contornar o404.
Classes referenciadas e ausentes: `StoreInvoiceRequest`, `StorePaymentRequest`, modelos `Fornecedor` e `Recebimento`. A integração proposta sincroniza fornecedor automaticamente, não demonstra isolamento por empresa/unidade e grava o recibo de idempotência depois do commit de negócio. O serviço orçamental contém uma resposta de saldo simulado fixa. Não equivale ao percurso nativo já validado em8085 e não deve ser activado como alternativa por consequência das migrations.
Próxima entrega necessária para um teste positivo: contrato/payload sintético, autenticação e contexto explícitos, reutilização do motor existente em vez de espelho autónomo, idempotência atómica com comparação do payload e classes/validações completas. Pagamentos não são necessários para testar facturas. Sem publicação, activação de candidatas, alteração dos seis registos, cache de dados ou provas anteriores. Não se declara capacidade de implantação.