Execução fiscal

Especificações das adequações que devem ser feitas no PJe para permitir a tramitação de processos de execução fiscal

Fluxo de execução fiscal

As classes processuais no PJe têm a elas associados fluxos definidos no sistema que especificam a maneira como os processos daquelas classes irão tramitar. Para muitas classes processuais, o fluxo pode ser compartilhado, mas para processos de execução fiscal, que têm uma natureza bem peculiar, há a necessidade de se definir um fluxo específico. As instruções para criação do fluxo para esses processos estão disponíveis aqui. Essas instruções contemplam um fluxo básico, que pode ser alterado de acordo com as necessidades de cada instalação.

Receber informações do cadastro de dívida ativa

Prioridade: ++++

Necessidade Negocial

O processo de execução fiscal, via de regra, inicia-se com o cadastro da pessoa que será réu do processo por parte da parte autora, em geral uma procuradoria de um ente da federação, na sua dívida ativa. Esse cadastro envolve uma série de informações que são utilizadas ao longo da tramitação do processo. Sendo assim, o PJe precisa receber as informações da dívida ativa, daqui por diante chamada de CDA (cadastro da dívida ativa) e armazená-las de forma a poder recuperá-las e utilizá-las ao longo do trâmite processual.

Regras de negócio

Regras a serem detalhadas

Opção de solução - contextualização

O CDA, assim como outros exemplos de informações processuais complementares relevantes para a tramitação processual, pertence a um conjunto de dados que são pertinentes a grupos de processos específicos. O PJe trabalha com o objetivo de atender a todos os ramos do judiciário em todas as suas possibilidades. Alguns ramos, classes processuais, agrupamentos de classes, entre outras características determinam especificidades que devem ser tratadas, preferencialmente, com configurações realizadas nas instalações onde elas ocorrem. Partindo dessa premissa, é desejável que não se construa telas e opções de menu fixas para funcionalidades que não estarão presentes em todas as instalações, como é o caso do cadastro da CDA. Essa necessidade visa também a redução de impactos para o caso de evolução da funcionalidade em questão, sendo desejável que a solução se torne mais flexível quanto às mudanças futuras.

Descrição de solução anterior

O PJe, em sua versão ainda em construção 1.6.0, prevê o cadastro de informações processuais complementares, demanda que está sendo tratada pela pendência do Jira PJEII-7782. Tomando como base o paradigma inaugurado pela referida pendência, o cadastro da CDA no PJe deve ser feito através de uma tela no fluxo de execução fiscal que referenciará o frame Processo/Fluxo/ip/ip.xhtml de informação processual complementar que está a ser construído. O frame carregará os campos para preenchimento de acordo com um arquivo XSD específico para CDA, que contém as definições dos campos. Ao preencher os campos, o usuário submete o formulário, e o sistema grava as informações no seguinte formato:

1. um conjunto de metadados, pertinente a qualquer informações processual complementar;
2. um xml contendo as informações fornecidas pelo usuário

Da mesma forma, ao exibir dados armazenados, o sistema deve recuperar o mesmo XSD para montagem da tela, utilizando o XML gravado anteriormente para povoar os dados nos respectivos campos.

Para que o fluxo de execução fiscal notifique o sistema qual XSD será utilizado, o XSD do CDA deve ser vinculado ao fluxo desenhado para aquele fim.

As especificações do mecanismo que permitirá esse funcionamento estão disponíveis em: aqui

Descrição dos campos

Os campos que serão contemplados no XSD do CDA e, consequentemente, na tela do fluxo onde serão informados os dados da CDA, são os seguintes:

1. Certidão, obrigatório, podendo serem enviadas várias de uma só vez no caso de uso de XML, contendo:
   1. Dados da dívida
      1. Inscrição no ministério da fazenda do devedor principal, obrigatório
      2. Devedor alternativo, opcional, contendo:
         1. Inscrição no ministério da fazenda, obrigatório
         2. Tipo, obrigatório, podendo ser:
            1. Solidário
            2. Subsidiário
      3. valor, obrigatório, contendo:
         1. valor, obrigatório
         2. data de apuração, obrigatório
         3. data de início da incidência, opcional (Campo destinado a armazenar a data de início de incidência de juros ou correção monetária, quando for este o tipo de valor) - originário ou atualização?
         4. Rubrica, obrigatório, podendo ser:
            1. Principal
            2. Multa
            3. Juros
            4. Correção
         5. Tipo do valor, obrigatório, podendo ser:
            1. Originário
            2. Atualização
   2. CNPJ do credor, obrigatório
   3. Número da certidão, obrigatório
   4. Procedimento administrativo, obrigatório
   5. Código do tributo, obrigatório
   6. Agrupamento tributário, opcional

Abaixo, listagem dos campos disponibilizada pelo grupo de levantamento de requisitos do comitê dos estados: (bater com os campos do XSD)

• Inscrição do credor (*)
• Número da cda – tamanho do campo (até 14 alfanumérico) (*)
• Valor da cda – tamanho do campo. Pode ser o mesmo do campo valor da causa (*)
• Data da cda – tamanho do campo ( 8 numérico) (*)
• Código do tributo – tamanho do campo (até 3 alfanumérico)
• Data da constituição do crédito – tamanho do campo ( 8 numérico)
• Valor original da dívida – tamanho do campo. Pode ser o mesmo do campo valor da causa (*)
• Número da certidão – tamanho do campo até 20 alfanumérico
• Valor da certidão – tamanho do campo. Pode ser o mesmo do campo valor da causa.
• Data da última atualização do crédito
• Número do processo na Procuradoria (processo administrativo) – tamanho do campo (até 20 alfanumérico)
• Agrupador tributário (grande devedor)
• Multa
• Juros
• Data da apuração
• Data da rubrica

• CPF ou CNPJ do réu(s) (*)
• Nome do réu(s) (*)
• CEP do réu(s) (*)
• Endereço do réu(s) (*)
• Bairro do réu(s) (*)
• Logradouro do réu(s) (*)
• Cidade do réu(s) (*)
• Estado do réu(s) (*)

• CPF ou CNPJ do co-responsável(s)
• Nome do co-responsável (s)
• CEP do co-responsável (s)
• Endereço do co-responsável (s)
• Bairro do co-responsável (s)
• Logradouro do co-responsável (s)
• Cidade do co-responsável (s)
• Estado do co-responsável (s)

(*) Identifica que a informação será obrigatória.

OBS: 
 O co-responsável será cadastrado no pólo passivo.
 Os dados acima serão disponibilizados pelas Procuradorias do Estado e da Prefeitura através do Modelo Nacional de Interoperabilidade	

XSD do CDA

<schema targetNamespace="http://www.cnj.jus.br/mni/cda" elementFormDefault="qualified">
 <complexType name="tipoDividaAtiva">
  <sequence>
   <element name="certidao" type="cda:tipoCertidao" maxOccurs="unbounded" minOccurs="1"/>
  </sequence>
 </complexType>
 <complexType name="tipoCertidao">
  <sequence>
   <element name="devedorPrincipal" type="cda:tipoDevedorPrincipal" maxOccurs="unbounded" minOccurs="1"></element>
   <element name="devedorAlternativo" type="cda:tipoDevedorAlternativo" maxOccurs="unbounded" minOccurs="0"></element>
   <element name="valor" type="cda:valorDivida" minOccurs="1" maxOccurs="unbounded"></element>
  </sequence>
 </complexType>
 <complexType name="valorDivida">
  <attribute name="valor" type="string" use="required"/>
  <attribute name="dataApuracao" type="date" use="required"/>
  <attribute name="dataInicioIncidencia" type="date">
   <annotation>
    <documentation>Campo destinado a armazenar a data de início de incidência de juros ou correção monetária, quando for este o tipo de valor.
    </documentation>
   </annotation>
  </attribute>
  <attribute name="rubrica" use="required">
   <simpleType>
    <restriction base="string">
     <enumeration value="PRINCIPAL"/>
     <enumeration value="MULTA"/>
     <enumeration value="JUROS"/>
     <enumeration value="CORRECAO"/>
    </restriction>
   </simpleType>
  </attribute>
  <attribute name="tipoValor" use="required">
   <simpleType>
    <restriction base="string">
     <enumeration value="ORIGINARIO"/>
     <enumeration value="ATUALIZACAO"/>
    </restriction>
   </simpleType>
  </attribute>
 </complexType>
 <complexType name="tipoDevedorPrincipal">
  <attribute name="inscricaoMF" type="string" use="required"/>
 </complexType>
 <complexType name="tipoDevedorAlternativo">
  <attribute name="inscricaoMF" type="string" use="required"/>
  <attribute name="tipo" use="required">
   <simpleType>
    <restriction base="string">
     <enumeration value="SOLIDARIO"/>
     <enumeration value="SUBSIDIARIO"/>
    </restriction>
   </simpleType>
  </attribute>
 </complexType>
 <element name="dividaativa" type="cda:tipoDividaAtiva"/>
</schema>

Solução emergencial para 1.4.6.x

O recebimento das informações da dívida ativa, ainda que não sejam tratadas de forma estruturada no PJe, é impeditivo para que o fluxo de execução fiscal seja colocado em produção. Sendo assim, optou-se por permitir que o arquivo seja enviado, no padrão MNI, através do método entregarManifestacaoProcessual, utilizando o campo do tipo n para inserção do arquivo. Sendo assim, o PJe receberá o arquivo e o armazenará, de forma que o usuário possa consultá-lo posteriormente ao longo da tramitação do processo. O arquivo enviado obedecerá a descrição do XSD especificado acima. As especificações da implementação MNI estão disponíveis aqui. Abaixo, exemplo de um arquivo XML que obedece ao esquema definido no XSD referenciado.

XML de exemplo para envio do CDA

<cda:dividaativa xsi:schemaLocation="http://www.cnj.jus.br/mni/cda cda-1.0.xsd ">
 <cda:certidao CNPJCredor="" agrupamentoTributario="" codigoTributo="" dataConstituicao="2001-01-01" dataInscricao="2001-01-01" 
   identificador="" procedimentoAdministrativo="">
  <cda:devedorPrincipal inscricaoMF=""/>
  <cda:devedorAlternativo inscricaoMF="" tipo="SOLIDARIO"/>
  <cda:valor dataApuracao="2001-01-01" dataInicioIncidencia="2001-01-01" rubrica="PRINCIPAL" tipoValor="ORIGINARIO" valor=""/>
 </cda:certidao>
</cda:dividaativa>

Número CDA como campo de consulta

Prioridade: +

Necessidade negocial

Disponibilizar, para usuários externos e internos, a possibilidade de se realizar consulta de processos pelo número do CDA.

Regras de negócio

Validar as restrições abaixo:

• A pesquisa deve retornar todos os processos que tenham como informação processual complementar o registro de número do CDA disponibilizado para consulta.
• A consulta poderá ser realizada apenas pelo número completo da CDA
• O campo de consulta deverá ter seu preenchimento facilitado através de máscara de preenchimento (definir máscara)
• O campo de consulta deverá validar dígito verificador do número (definir regra de cálculo do dígito)
• O resultado da consulta deve levar em consideração as permissões já implementadas na consulta de processos já existente no PJe

Sugestão de implementação

Acrescentar campo não obrigatório na tela de pesquisa de processos (Processo/ConsultaProcesso/listView.seam).

Detalhar como será a recuperação dos dados das informações processuais complementares e avaliar impacto de performance na pesquisa já existente - verificar viabilidade da demanda com esse foco, buscando solução alternativa em caso de impossibilidade performática

Dependência

A funcionalidade de recepção dos dados estruturados da CDA deve estar disponível.

Inserir tarefa no fluxo para tratar documentos não lidos

Requisito do PJe, independe da execução fiscal

Prioridade: ++++

Necessidade negocial

Permitir que, ao petições interlocutórias, dependendo da configuração do trâmite processual de cada vara, seja possível que uma tarefa fique pendente para o servidor, de forma que, ao abrir a tarefa, ele registre a leitura do documento, retirando aquela tarefa da pendência. A tarefa pode ter o nome de "Apreciar petições intermediárias".

• Justificativa: Petições interlocutórias ou intermediárias (quando o processo já está em curso) hoje são tratadas no agrupador "Processos com documentos não lidos", mas o agrupador não é funcional, é de difícil manuseio, já que são listados os processos, e não os documentos, e quando há vários documentos vinculados ao mesmo processo, há a repetição do processo para cada documento não lido existente. Além disso, o agrupador não atende ao requisito desejável de direcionar pendências em processos para tarefas no fluxo. O ideal seria existir uma tarefa no fluxo, assim como uma notificação na visualização do processo, vinculada à permissão.

Soluções em andamento

Há uma melhoria do agrupador citado prevista através da pendência PJEII-10444. Deve ser verificado como ficará o agrupador com a melhoria da referida pendência e com a melhoria sugerida pelo grupo de requisitos - execução fiscal..

Regras de negócio

Validar as restrições abaixo:

• Na árvore de tarefas, deve aparecer uma tarefa que exibirá uma lista de processos que têm pendência de documento não lido para o usuário
• A tarefa deverá aparece sgundo o perfil do usuário, conforme comportamento já adotado no PJe nessas situações
• Se mais de um documento estiver vinculado a um mesmo processo, o processo só deve aparecer uma vez na lista do usuário
• Os processos deverão aparecer segundo o perfil e localização configurados na tarefa para aquele usuário, conforme comportamento já adotando no PJe nessas situações
• Ao abrir a tarefa, o usuário deverá visualizar uma lista contendo os documentos não lidos daquele processo, sendo exibido o primeiro documento automaticamente em um quadro abaixo da lista. Para o caso de um documento apenas, a lista não deverá ser exibida.
• Para cada documento da lista, deve o usuário poder clicar em sua descrição, de forma que o documento seja exibido no quadro abaixo da lista.
• Para cada documento da lista, deve existir um campo de seleção para que o usuário marque o documento para ser retirado da lista, com possibilidade de se selecionar todos em uma marcação apenas.
• Deve estar disponível um botão para tramitação para a próxima tarefa do fluxo
• Ao clicar no botão, para o caso de existir apenas um documento, o referido deverá ter sua marcação de documento não lido retirada (verificar qual o mecanismo que marca um documento como não lido atualmente).
• Para o caso de vários documentos para o mesmo processo, os documentos selecionados devem ter sua marcação de documento não lido retirada
• Para o caso de vários documentos para o mesmo processo e nenhum documento selecionado, o sistema deve exibir uma mensagem informando que não é possível realizar a tarefa sem documentos selecionados
• Caso todos os documentos tenham sido desmarcados, o processo não mais deve aparecer como pendente dessa tarefa na lista do usuário.
• O usuário vinculado à tarefa (verificar como viabilizar isso) deverá poder, ao movimentar o processo ou consultar o processo onde documentos foram inseridos, visualizar aviso da entrada da petição, podendo retirar a marcação de documento não lido a partir do aviso e, consequentemente, quando daquele documento apenas estiver uma tarefa pendente, retirar o processo da tarefa.