Matriz Oficial de SLA

Tela documental · v1.0 · vigente desde 01/07/2026 · fonte: docs/governanca/01_MATRIZ_OFICIAL_SLA.md

Somente leitura · sem cálculo

Esta tela é apenas informativa/documental. Ela reproduz o conteúdo já publicado nos documentos de governança do domínio SMS — não consulta o BigQuery, não recalcula prazo ou status de SLA e não grava nada. Qualquer mudança de regra de negócio deve primeiro ser aprovada e refletida em docs/governanca/01_MATRIZ_OFICIAL_SLA.md, e só depois neste componente.

1. Matriz Oficial de SLA por tipo/grupo de pedido

Tipo	Grupo	Regra aplicada	Prazo
Qualquer tipo	urgente = TRUE (prevalece sobre tudo abaixo)	D+1/D+2 útil por hora de criação	D+1 útil (<12h) · D+2 útil (≥12h)
MAPA	MEDICAMENTOS	Cronograma FARMÁCIA (match por ponto)	Limite do cronograma cadastrado
MAPA	MEDICAMENTOS PORTARIA 344/98	Cronograma FARMÁCIA (match por ponto)	Limite do cronograma cadastrado
MAPA	ALMOXARIFADO	Cronograma ALMOXARIFADO (match por regional)	Limite do cronograma cadastrado
AVULSO	DOMICILIAR	Cronograma ALMOXARIFADO (match por regional) — única exceção dentro de AVULSO	Limite do cronograma cadastrado
AVULSO	JUDICIAL / INSULINAS / MEDICAMENTOS / MEDICAMENTOS PORTARIA 344/98 / MEDICAMENTOS ESTRATÉGICOS / ALMOXARIFADO / COMPLEMENTAR	D+2/D+3 útil por hora de criação	D+2 útil (<12h) · D+3 útil (≥12h)
COMUM (legado)	Qualquer — fora da Matriz Oficial	Regra fixa histórica, sem distinção de hora	D+2 útil sempre

Hierarquia de precedência (uma regra inferior nunca sobrescreve uma superior): URGENTE → MAPA → AVULSO → COMUM (legado, sempre isolado).

2. Regras de URGENTE

Aplica-se a qualquer pedido com a flag urgente = TRUE, independentemente de tipoPedido ou grupoPedido. É a regra de maior prioridade do sistema.

Condição de criação	Prazo
Criado até 11:59 (hora_base_calculo < 12)	D+1 útil
Criado a partir das 12:00 (hora_base_calculo ≥ 12)	D+2 útil

Caso especial homologado — MAPA + URGENTE: quando um pedido é MAPA e urgente = TRUE, a regra URGENTE prevalece sobre o cronograma de MAPA — o pedido usa D+1/D+2 útil, não o cronograma. Decisão de negócio formalmente encerrada na Fase 1 (15 pedidos MAPA/urgente identificados na base completa em 2026-07-01); não deve ser reaberta sem nova solicitação explícita da operação.

3. Regras de MAPA

Pedidos tipoPedido = MAPA nunca usam D+2/D+3 corrido — todos os grupos MAPA usam cronograma. Decisão de negócio deliberada (ver 03_REGRAS_DE_NEGOCIO.md).

Grupo (grupoPedido)	Cronograma utilizado
MEDICAMENTOS	FARMÁCIA
MEDICAMENTOS PORTARIA 344/98	FARMÁCIA
ALMOXARIFADO	ALMOXARIFADO

Se não houver cronograma cadastrado compatível com o destino/mês do pedido, o status resultante é Sem Cronograma — não há fallback para D+2/D+3 nesses grupos.

4. Regras de AVULSO

Grupo (grupoPedido)	Regra
DOMICILIAR	Cronograma ALMOXARIFADO (única exceção dentro de AVULSO — ver seção 5)
JUDICIAL	D+2 útil / D+3 útil
INSULINAS	D+2 útil / D+3 útil
MEDICAMENTOS	D+2 útil / D+3 útil
MEDICAMENTOS PORTARIA 344/98	D+2 útil / D+3 útil
MEDICAMENTOS ESTRATÉGICOS	D+2 útil / D+3 útil
ALMOXARIFADO	D+2 útil / D+3 útil
COMPLEMENTAR	D+2 útil / D+3 útil

Condição de criação (7 grupos D+2/D+3)	Prazo
Criado até 11:59 (hora_base_calculo < 12)	D+2 útil
Criado a partir das 12:00 (hora_base_calculo ≥ 12)	D+3 útil

5. Regras de DOMICILIAR

AVULSO/DOMICILIAR é a única exceção dentro da categoria AVULSO: em vez de D+2/D+3 útil, usa o Cronograma ALMOXARIFADO — o mesmo cronograma usado por MAPA/ALMOXARIFADO, casando pela regional do pedido. Ver regra de aceite completa na seção 7.

6. Regras de cronograma FARMÁCIA

tipo_cronograma = 'FARMACIA', origem_cronograma = 'PONTO'.

Casa pelo ponto de atendimento (pontoAtendimentoNome) do pedido, comparado (após normalização) contra destino_cronograma.
Só pode casar com pedidos MAPA/MEDICAMENTOS ou MAPA/MEDICAMENTOS PORTARIA 344/98 (guarda de grupo, Fase 1).

Regra de aceite (comum aos dois tipos de cronograma)

O mês de referência do cronograma deve coincidir com o mês da data_base_sla do pedido, ou com o mês seguinte (fallback).
dt_entrega_ini e dt_entrega_fim não podem ser nulos.
A data_base_sla do pedido deve ser anterior ao corte do cronograma (dt_separacao_ini, com fallback para dt_entrega_fim).
Fallback de mês seguinte: sem cronograma válido no mês atual mas com cronograma válido no mês seguinte, usa o limite do mês seguinte.
Sem match em nenhuma das condições acima: status final Sem Cronograma.

7. Regras de cronograma ALMOXARIFADO

tipo_cronograma = 'ALMOXARIFADO', origem_cronograma = 'REGIONAL'.

Casa pela regional do pedido, comparada (após normalização) contra o mesmo campo de destino do cronograma.
Só pode casar com pedidos MAPA/ALMOXARIFADO ou AVULSO/DOMICILIAR (guarda de grupo, Fase 1).

Regra de aceite (comum aos dois tipos de cronograma)

O mês de referência do cronograma deve coincidir com o mês da data_base_sla do pedido, ou com o mês seguinte (fallback).
dt_entrega_ini e dt_entrega_fim não podem ser nulos.
A data_base_sla do pedido deve ser anterior ao corte do cronograma (dt_separacao_ini, com fallback para dt_entrega_fim).
Fallback de mês seguinte: sem cronograma válido no mês atual mas com cronograma válido no mês seguinte, usa o limite do mês seguinte.
Sem match em nenhuma das condições acima: status final Sem Cronograma.

8. Casos legados — COMUM

tipoPedido = COMUM é uma categoria legada, anterior à criação dos grupos operacionais atuais (MAPA/AVULSO).
A operação não utiliza mais COMUM como opção válida para novos pedidos; não é convertido automaticamente para AVULSO.
Não entra na conformidade da Matriz Oficial — nenhuma auditoria de aderência deve considerar pedidos COMUM como conformes ou não conformes.
Regra histórica fixa preservada apenas para fins de consulta: D+2 útil sempre, sem distinção de hora, sem D+3.

9. Fluxo View → Snapshot → API → UI

1
View BigQuery
view_vendas_detalhada_operacional — única fonte de verdade. Calcula normalização, prioridade, engine SLA, cronograma, prazo final e status em um único `CASE` sequencial.
2
Snapshot
operational_snapshot — tabela materializada via Scheduled Query a cada 30 min. Apenas replica o resultado da view, sem lógica própria.
3
API (Next.js)
Rotas em app/api/dashboard/** leem o snapshot e retornam JSON — não recalculam nenhuma parte da regra de SLA.
4
UI (React)
Componentes do dashboard (KPIs, popups de cronograma, painéis de pedidos críticos, exportações) apenas renderizam os campos já calculados.

Ponto de atenção arquitetural: qualquer camada posterior à view deve ler o resultado já calculado, nunca recalculá-lo com lógica própria. Divergências desse princípio (ex.: rota de export) estão registradas em 06_CHECKLIST_AUDITORIA.md. Detalhamento completo em 04_ARQUITETURA_SLA.md.

10. Status de conformidade da regra

Conteúdo documental — reflete o último veredito de auditoria registrado, não uma verificação em tempo real da view/snapshot.

Item	Status
Fonte única de verdade (View) para SLA/prazo/cronograma	✅ Conforme — Fase 1/2C
Snapshot apenas replica, sem lógica própria	✅ Conforme — Fase 1/2C
APIs leem, não recalculam	✅ Conforme — Fase 2C
Front-end apenas renderiza	✅ Conforme — Fase 2C
Endpoint de escrita protegido por autenticação	✅ Conforme — Fase 2E (corrigido; era achado CRÍTICO na Fase 2D)
Veredito de homologação funcional (Fase 2D)	⚠️ Aprovado com ressalvas — 7,4/10

Detalhamento completo em docs/governanca/18_RELATORIO_FINAL_SMS.md e RELATORIO_FASE2E_PRODUCTION_READINESS_SMS.md.

11. Última atualização da matriz

Versão	Data de vigência	Descrição
1.0	01/07/2026	Primeira versão oficial pós-Fase 1: consolida a homologação funcional completa e a correção publicada em produção.

Histórico completo de mudanças em docs/governanca/05_CHANGELOG_SLA.md.

12. Documentos de governança

Todos os documentos abaixo vivem em docs/governanca/ no repositório do projeto. Esta tela não expõe um servidor de arquivos — abra os arquivos diretamente no repositório para o texto completo.

docs/governanca/01_MATRIZ_OFICIAL_SLA.md
Fonte oficial (SSOT) desta tela — hierarquia de regras, prazos, cronogramas.
docs/governanca/02_DICIONARIO_OPERACIONAL.md
Dicionário de campos e estados finais de SLA.
docs/governanca/03_REGRAS_DE_NEGOCIO.md
Justificativa de negócio por trás de cada regra (por que MAPA nunca usa D+2, guarda de grupo, etc.).
docs/governanca/04_ARQUITETURA_SLA.md
Camadas View → Snapshot → API → UI, detalhamento de cada etapa.
docs/governanca/05_CHANGELOG_SLA.md
Histórico oficial de mudanças de regra, homologação e publicação da Fase 1.
docs/governanca/06_CHECKLIST_AUDITORIA.md
Itens fora do escopo da Matriz Oficial e pendências de auditoria.
docs/governanca/07_AUDITORIA_TECNICA_SLA.md
Auditoria técnica read-only da implementação da view.
docs/governanca/08_SINGLE_SOURCE_OF_TRUTH.md
Definição do princípio SSOT aplicado ao domínio SMS.
docs/governanca/09_PLANO_MIGRACAO_FASE2B.md
Plano de eliminação de duplicidades de regra de negócio.
docs/governanca/10_RELATORIO_CONSOLIDACAO_SMS.md
Consolidação da Fase 2B.
docs/governanca/11_MAPA_FINAL_SMS.md
Mapa final de arquivos do domínio SMS pós-consolidação.
docs/governanca/12_VALIDACAO_SINGLE_SOURCE_SMS.md
Validação de que só existe uma fonte de cálculo de SLA.
docs/governanca/13_HARDENING_SMS.md
Hardening de robustez do domínio SMS (Fase 2D).
docs/governanca/14_CHECKLIST_PRODUCAO_SMS.md
Checklist de prontidão de produção — atualizado na Fase 2E.
docs/governanca/15_PERFORMANCE_SMS.md
Auditoria de performance do domínio SMS.
docs/governanca/16_MONITORAMENTO_SMS.md
Achados de observabilidade — origem do health-check e da idade do snapshot implementados na Fase 2E.
docs/governanca/17_SEGURANCA_SMS.md
Auditoria de segurança — origem da autenticação do endpoint de importação implementada na Fase 2E.
docs/governanca/18_RELATORIO_FINAL_SMS.md
Relatório final de encerramento da Fase 2D.

Carregando dashboard…