# Processos jurídicos e prazos ## Objetivo O módulo reúne cadastro de estrutura judiciária, processos, partes, clientes, advogados, documentos, lançamentos financeiros e prazos processuais. Todos os registros são isolados por escritório. ## Estrutura judiciária O catálogo é mantido pelo próprio escritório: - `courts`: tribunal, segmento, sigla, código CNJ e UF; - `judicial_districts`: comarca ou circunscrição, município e UF; - `judicial_units`: vara, câmara, turma, seção ou unidade equivalente; - `court_calendar_events`: feriados e suspensões nacionais, estaduais, municipais ou específicas de tribunal. Catálogos com histórico não podem ser apagados. Devem ser desativados. ## Número CNJ O processo usa o padrão nacional `NNNNNNN-DD.AAAA.J.TR.OOOO`. A API: 1. remove máscara e caracteres não numéricos; 2. exige exatamente 20 dígitos; 3. valida os dígitos verificadores pelo módulo 97 base 10; 4. armazena a versão normalizada e devolve a versão formatada; 5. garante unicidade por escritório. ## Processo Um processo possui: - tribunal obrigatório; - comarca e unidade opcionais, mas hierarquicamente coerentes; - um ou mais clientes vinculados; - um ou mais advogados vinculados; - partes externas opcionais; - assunto, tipo de ação, posição do escritório, sigilo e valor da causa em centavos; - documentos privados do GED; - lançamentos financeiros opcionais; - prazos processuais. Somente um cliente pode ser principal e somente um advogado pode ser responsável. Quando nenhum é indicado, o primeiro item da coleção assume essa função. No `PUT`, as coleções `clients`, `lawyers` e `parties` representam a coleção completa. Campo ausente mantém a relação atual. A API impede remover um cliente que ainda possua documento ou lançamento financeiro vinculado ao processo. ## Cálculo de prazos O cálculo operacional segue estas regras: - contagem somente em dias úteis; - exclusão do dia inicial; - inclusão do dia do vencimento; - exclusão de sábados e domingos; - exclusão do recesso forense de 20 de dezembro a 20 de janeiro, inclusive; - exclusão dos feriados e suspensões ativos que se apliquem ao tribunal, estado ou cidade do processo. A base normativa registrada no snapshot é CPC, arts. 219, 220 e 224. A manutenção do calendário oficial do tribunal continua sendo responsabilidade operacional do escritório; o sistema não substitui a conferência da publicação, da intimação ou de regras específicas do órgão julgador. Cada prazo grava `calculation_snapshot` com: - data inicial; - quantidade de dias úteis; - vencimento calculado; - datas excluídas e seus motivos; - tribunal, estado e cidade usados; - regras aplicadas. Isso preserva auditoria mesmo quando o calendário for alterado depois. ## Estados do prazo - `pending`: aberto e ainda não vencido; - `overdue`: aberto e com vencimento anterior à data atual; - `completed`: concluído, com usuário, data e observação; - `canceled`: cancelado e removido logicamente. Prazos concluídos ou cancelados são imutáveis. Um processo com prazo aberto não pode ser excluído. ## Alertas O comando abaixo atualiza vencimentos e envia alertas aos responsáveis: ```bash php artisan legal-deadlines:process ``` O scheduler executa o comando diariamente às 08:00. Os dias de antecedência são configurados em `.env`: ```dotenv LEGAL_DEADLINE_ALERT_DAYS=7,3,1,0 LEGAL_MAX_DEADLINE_DAYS=3650 ``` A tabela `legal_deadline_alerts` impede envio duplicado para o mesmo prazo, vencimento, antecedência e destinatário. ## Endpoints ```http GET /api/v1/courts POST /api/v1/courts PUT /api/v1/courts/{court} DELETE /api/v1/courts/{court} GET /api/v1/judicial-districts POST /api/v1/judicial-districts PUT /api/v1/judicial-districts/{district} DELETE /api/v1/judicial-districts/{district} GET /api/v1/judicial-units POST /api/v1/judicial-units PUT /api/v1/judicial-units/{unit} DELETE /api/v1/judicial-units/{unit} GET /api/v1/court-calendar-events POST /api/v1/court-calendar-events PUT /api/v1/court-calendar-events/{event} DELETE /api/v1/court-calendar-events/{event} GET /api/v1/legal-cases POST /api/v1/legal-cases GET /api/v1/legal-cases/{legalCase} PUT /api/v1/legal-cases/{legalCase} DELETE /api/v1/legal-cases/{legalCase} POST /api/v1/legal-cases/{legalCase}/documents/{document} DELETE /api/v1/legal-cases/{legalCase}/documents/{document} GET /api/v1/legal-deadlines POST /api/v1/legal-cases/{legalCase}/deadlines/calculate POST /api/v1/legal-cases/{legalCase}/deadlines GET /api/v1/legal-deadlines/{deadline} PUT /api/v1/legal-deadlines/{deadline} POST /api/v1/legal-deadlines/{deadline}/complete DELETE /api/v1/legal-deadlines/{deadline} ``` Os parâmetros de rota usam UUID público. IDs internos são usados apenas em payloads relacionais, como `court_id`, `client_id`, `user_id` e `legal_case_id`. ## Permissões ```text judicial_catalog.view judicial_catalog.manage court_calendar.view court_calendar.manage legal_cases.view legal_cases.create legal_cases.update legal_cases.delete deadlines.view deadlines.create deadlines.update deadlines.complete deadlines.delete ``` ## Integração financeira `financial_entries.legal_case_id` é opcional. Quando informado: - processo e lançamento devem pertencer ao mesmo escritório; - o cliente do lançamento precisa estar vinculado ao processo; - o processo fica disponível no Resource financeiro e nos filtros; - o vínculo não pode ser alterado depois do primeiro pagamento ativo; - a exclusão lógica do processo não apaga o lançamento; a chave é anulada somente em exclusão física. ## Exclusão e histórico - processos, partes, prazos, catálogos e eventos usam soft delete quando aplicável; - documentos permanecem no GED; - snapshots de cálculo não são recalculados retroativamente; - alterações de localização recalculam apenas prazos ainda abertos; - exclusão de evento do calendário não modifica snapshots já gravados.