# 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.