Documento de Requisitos e Regras de Negócio

Sistema de Gestão de Infrações - SPU (Secretaria do Patrimônio da União)


1. Visão Geral

O sistema tem como objetivo principal gerenciar autos de infração aplicados a ocupações irregulares em áreas públicas federais (ex: terrenos de marinha). A aplicação centraliza o controle de infratores, cálculo de multas mensais contínuas (DARFs), acompanhamento do status de cobrança e geração de relatórios gerenciais, com forte base legal (Decreto-Lei nº 2.398/1987 e Lei nº 13.139/2015).


2. Regras de Negócio (RN)

ID Regra Descrição
RN01 Cálculo do Valor da Multa (Metragem) O valor da multa mensal baseia-se na multiplicação da metragem da área pelo valor do metro quadrado vigente na época.
RN02 Transição de Legislação (Marco Legal) Para infrações com “Data da Ciência” anterior a 26/10/2015, aplica-se a regra do Decreto-Lei 2.398/1987 (multa cobrada em dobro). A partir de 26/10/2015, aplica-se a Lei 13.139/2015 (multa simples fixa cumulativa). O sistema deve inferir a área corretamente a partir do valor principal baseado nessas datas, quando a área não for informada.
RN03 Geração Contínua de DARFs (Mêsversário) Os lançamentos de DARF são gerados mês a mês de forma cumulativa. A data base é o “mêsversário” da Data de Ciência Inquestionável.
RN04 Impacto do Status de Cobrança Se o status de cobrança estiver SUSPENSA ou PARALISADA, mas o status da infração for ATIVA/EM ANDAMENTO, os lançamentos devem continuar sendo gerados. A suspensão neste caso só pausa a ação de cobrança, mas a dívida continua rolando.
RN05 Interrupção de Lançamentos Os lançamentos de DARFs só devem parar de ser gerados automaticamente se: (1) O status da infração for ENCERRADA; ou (2) A cobrança for marcada como QUITADA ou CESSADA. Nesse cenário, os DARFs são gerados apenas até a data da movimentação do status ou a data de encerramento da infração.
RN06 Tabela de Valor Histórico do m² O sistema deve manter um histórico com a validade das Portarias que reajustam o valor do m² da União, servindo como base imutável para os cálculos passados.
RN07 Inconsistências Cadastrais O sistema não deve barrar o cadastro por falta de informações estruturais na importação (ex: área vazia ou sem CPF), mas deve colocar a infração em estado de “Inconsistência” alertando o operador.

3. Requisitos Funcionais (RF)

  • RF01 - Gestão de Infratores: O sistema deve permitir cadastrar, editar e visualizar Infratores (Pessoa Física - CPF, e Pessoa Jurídica - CNPJ), incluindo dados de endereço e contatos.
  • RF02 - Gestão de Autos de Infração: O sistema deve permitir o registro completo de infrações, vinculando-as a um infrator, com informações como Superintendência, Município, Tipo de Infração, Origem, Metragem e Data da Ciência Inquestionável.
  • RF03 - Importação de Planilhas em Lote: O sistema deve possuir módulo para importar dados em massa através de planilhas Excel (.xls, .xlsx) ou CSV, mapeando as colunas automaticamente e processando regras de negócio durante a carga (incluindo cálculo reverso da área, se estiver em branco).
  • RF04 - Agendador de Tarefas Automático: O sistema deve conter um “Agendador” (Scheduler) capaz de rodar tarefas diárias/periódicas em background, encarregado de gerar novos DARFs no mêsversário de cada infração ativa.
  • RF05 - Controle do Status da Cobrança: O formulário da infração deve permitir adicionar um histórico de “Controle de Cobranças” com datas e motivos (ex: CESSADA, SUSPENSA, LIMINAR JUDICIAL), permitindo auditoria das fases da dívida.
  • RF06 - Simulação de Acréscimos Legais (SELIC): O sistema deve oferecer uma calculadora (API) que calcule os acréscimos moratórios (Juros SELIC e Multa de Mora) de acordo com a regra vigente para Dívida Ativa da União sobre qualquer lançamento atrasado.
  • RF07 - Relatórios e Dashboards: O sistema deve gerar visões agregadas em relatórios gerenciais e dashboards (ex: “Resumo por Motivo da Cobrança”, “Status de Lançamento”, “Inscritos em DAU”), permitindo expansão (detalhamento analítico) das tabelas e download das informações.
  • RF08 - Tratamento de Débitos Quitados: O usuário deve ter um controle flag (“Débitos quitados: SIM/NÃO”) e, ao Encerrar a infração, o sistema deve sugerir a geração automática de um histórico de cobrança tipo “QUITADA”.
  • RF09 - Painel de Configurações Administrativas: O sistema deve oferecer painéis para gerenciar o Histórico do Valor do Metro Quadrado, realizar ações destrutivas seguras (limpeza de superintendência) e ajustes de base de dados.

4. Requisitos Não Funcionais (RNF)

  • RNF01 - Arquitetura Web / Linguagem: O backend deve ser desenvolvido em Python utilizando o microframework Flask, devido à sua leveza, velocidade e ótimo ecossistema para aplicações de dados.
  • RNF02 - Banco de Dados Relacional: Os dados devem ser persistidos via ORM (SQLAlchemy), suportando SQLite para ambientes de fácil instalação ou bancos maiores (como PostgreSQL) com a mesma base de código.
  • RNF03 - Estética e Padrão Visual: A interface de usuário (UI) deve adotar um padrão de usabilidade moderno (preferencialmente inspirado no Design System do GOV.BR), com cores institucionais (Azul Escuro #1351B4, tons de cinza), botões padronizados, fontes legíveis e painéis organizados por abas (Tabs).
  • RNF04 - Interatividade Frontend: O dinamismo da aplicação (como abertura de modais, recálculos imediatos, navegação e expansão de tabelas em relatórios) deve ser realizado com Vanilla JavaScript (JS puro) associado ao sistema de templates Jinja2, visando evitar sobrecarga com bibliotecas pesadas de terceiros (SPA).
  • RNF05 - Processamento Assíncrono para Relatórios e Importações: Rotinas pesadas (ex: leitura de planilhas imensas utilizando pandas ou geração de relatórios extensos para exportação utilizando xlsxwriter) não devem travar a thread principal da aplicação de forma permanente, exibindo logs ou rodando no Agendador.
  • RNF06 - Segurança e Acesso: Rotas sensíveis (como configurações globais, exclusão de dados e manipulação de multas) devem ser protegidas exigindo autenticação do usuário operador.
  • RNF07 - Responsividade Parcial: Embora seja um sistema tipicamente de desktop/escritório, elementos centrais (formulários laterais, tabelas flexíveis) devem utilizar Flexbox (CSS) para se adaptarem razoavelmente a larguras e resoluções diferentes de monitores.