Cronograma de Vencimentos e Revisões de SST (NR-01)

O que é o cronograma de revisões e validades

O cronograma de vencimentos e revisões de SST é o módulo M09 do SIGSSST. Seu objetivo é centralizar os prazos e as revisões obrigatórias da NR-01 e das normas correlatas, apresentando-os como um calendário/lista de vencimentos com dias restantes e status. Em vez de a equipe de Segurança do Trabalho acompanhar validade de treinamento em uma planilha, prazo de ação em outra e revisão de documento em uma terceira, tudo converge para uma única visão com o que está OK, o que exige atenção e o que já venceu.

O cronograma é alimentado automaticamente por eventos dos demais módulos — documentos, treinamentos, cursos EaD, simulados, requisitos legais, planos de ação, terceiros, EPIs/EPCs, entre outros — e complementado por itens cadastrados manualmente. Cada linha carrega o tipo do item (kind), a data de vencimento (due_date), o responsável e o status, e pode disparar notificações configuráveis.

Vencimentos derivados de todos os módulos

A maior parte dos itens do cronograma é derivada: cada um referencia sua origem por source_module (o código do módulo, ex.: M03, M18) e source_entity_id (o identificador da entidade que gerou o prazo). Quando uma entidade é criada em um módulo-fonte, o backend projeta automaticamente o vencimento correspondente no M09, junto com o indicador (M10) e a evidência (M11) da mesma cadeia. Os módulos que geram vencimentos automaticamente incluem M02, M03, M08, M17, M18, M19 e os módulos de rotina padronizados (acidentes, emergências, inspeções, EPC etc.).

O tipo e a data de cada item derivado vêm do próprio dado de origem:

• M02 (inventário de riscos) gera a revisão do risco do PGR na data prevista de revisão — ou, sem data explícita, em 30 dias para risco alto/crítico e 90 dias para os demais.
• M03 (plano de ação) gera o prazo da ação, a partir do prazo cadastrado na própria ação.
• M08 (terceiros e contratadas) gera o vencimento de conformidade documental da contratada.
• M17 (cursos EaD) gera a revalidação do curso na data de validade do certificado.
• M18 (matriz de requisitos legais) gera a revisão do requisito na data de próxima revisão.
• M19 (análise crítica pela direção) gera a data da próxima análise crítica.
• Módulos de rotina (acidentes, simulados, inspeções, EPC etc.) geram o prazo do próprio registro, a partir da sua data de evento.

Assim, o cronograma não fixa uma periodicidade genérica: ele lê a data pertinente de cada origem, e essa origem permanece a fonte de verdade daquele prazo.

Itens manuais com SSOT no próprio cronograma

Nem toda obrigação nasce de outro módulo. Para esses casos, é possível cadastrar itens avulsos diretamente no cronograma. Um item manual não tem source_module nem source_entity_id e é marcado explicitamente como ssot = M09 — ou seja, o próprio cronograma passa a ser o dono (SSOT) daquele registro.

O sistema mantém a coerência com duas regras de validação: source_module e source_entity_id devem ser informados sempre em conjunto (um sem o outro é rejeitado), e todo item sem origem precisa declarar ssot = M09. Isso impede que itens manuais e derivados se confundam ou colidam.

Status OK, Atenção e Vencido e cálculo de dias restantes

A lista calcula os dias restantes (data de vencimento menos a data de hoje) e traduz essa proximidade em um status visual: OK quando o prazo está confortável, Atenção quando o vencimento se aproxima e Vencido quando a data já passou. Esse status é derivado da própria data — não é digitado.

Em paralelo, cada item carrega um status operacional de fluxo: pendente, visto, concluído ou cancelado. São coisas distintas — o status visual mede a proximidade do prazo, enquanto o status operacional registra o que a equipe já fez com aquele item (por exemplo, marcá-lo como visto após tomar ciência).

Notificações configuráveis por tipo e responsável

O cronograma dispara notificações configuráveis por tipo de item e por responsável. Prazos de treinamento, por exemplo, podem alertar com antecedência escalonada (como 30, 15 e 7 dias antes do vencimento), e itens em atraso podem gerar escalonamento. Cada notificação fica registrada com trilha de auditoria, de modo que a comunicação do prazo também vira evidência de que a organização acompanhou a obrigação.

Por que itens derivados não são editáveis no cronograma

Itens derivados são projeções de um dado que pertence a outro módulo. Por isso não podem ser editados no M09: alterar a data de uma revisão de risco no cronograma, e não no inventário de riscos (M02), criaria divergência entre a projeção e a fonte. A edição acontece sempre no módulo de origem, e a única alteração permitida sobre o item derivado é o status operacional (marcar como visto).

Esse desenho preserva a cadeia SSOT e permite reprocessamento seguro: a geração derivada é idempotente, com unicidade por (source_module, source_entity_id, kind, due_date). Reprocessar o mesmo evento atualiza o item existente em vez de criar um vencimento duplicado. Alterações de prazo na origem se refletem no cronograma e geram trilha de auditoria.

Insumo para a análise crítica (M19) e os painéis (M10)

O cronograma não é um fim em si: suas pendências e vencidos alimentam as visões globais de pendência, os painéis de indicadores de SST (M10) e a home administrativa. Na análise crítica pela direção (M19), o conjunto de prazos e atrasos entra como insumo do que precisa ser revisado. E o próprio M19 fecha o ciclo agendando a próxima análise crítica de volta no M09 — a rotina de conformidade se retroalimenta.

Base normativa (periodicidades da NR-01)

O anexo regulatório do módulo é a NR-01 (Portaria MTE nº 765/2025), cujo item 1.5 (GRO e PGR) exige manter o gerenciamento de riscos e seus controles atualizados, com revisões periódicas. Documentos e obrigações correlatas têm cadências próprias — no manual de implementação da NR-01, por exemplo, a política de SST tem revisão bienal, enquanto ordem de serviço, plano de emergência, mapa de risco e programas de capacitação têm atualização anual; requisitos legais e treinamentos têm validade própria.

Como o M09 lê a periodicidade e a data de próxima revisão de cada origem (revisão prevista do risco, validade do treinamento, próxima revisão do requisito legal, prazo da ação), o calendário reflete a norma aplicável a cada item — sem hard-code de um único prazo legal para tudo.