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: 0

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

A 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 da 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 da 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 da CDA

<schema targetNamespace="http://www.cnj.jus.br/mni/cda" elementFormDefault="qualified"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:cda="http://www.cnj.jus.br/mni/cda">

<element name="dividaativa" type="cda:tipoDividaAtiva"></element>

<complexType name="tipoDividaAtiva">
 <sequence>
   <element name="certidao" type="cda:tipoCertidao" maxOccurs="unbounded" minOccurs="1"></element>
 </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="valorDivida" type="cda:valorDivida" maxOccurs="unbounded" minOccurs="1"></element>
  </sequence>
</complexType>

<complexType name="tipoDevedorPrincipal">
  <sequence>
     <element name="inscricaoMFDevedorPrincipal" type="string" maxOccurs="1" minOccurs="1"></element>
  </sequence>
</complexType>

<complexType name="tipoDevedorAlternativo">
  <sequence>
    <element name="inscricaoMFDevedorAlternativo" type="string" maxOccurs="1" minOccurs="0"></element>
    <element name="tipo" maxOccurs="1" minOccurs="0">
      <simpleType>
        <restriction base="string">
           <enumeration value="SOLIDARIO" />
           <enumeration value="SUBSIDIARIO" />
        </restriction>
      </simpleType>
     </element>
   </sequence>
 </complexType>

 <complexType name="valorDivida">
   <sequence>
      <element name="valor" type="string" maxOccurs="1" minOccurs="1"></element>
      <element name="dataApuracao" type="date" maxOccurs="1" minOccurs="1"></element>
      <element name="dataInicioIncidencia" type="date" maxOccurs="1" minOccurs="0">
        <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>
      </element>
      <element name="rubrica" maxOccurs="1" minOccurs="1">
        <simpleType>
           <restriction base="string">
              <enumeration value="PRINCIPAL" />
              <enumeration value="MULTA" />
              <enumeration value="JUROS" />
              <enumeration value="CORRECAO" />
           </restriction>
         </simpleType>
       </element>
       <element name="tipoValor" maxOccurs="1" minOccurs="1">
         <simpleType>
           <restriction base="string">
              <enumeration value="ORIGINARIO" />
              <enumeration value="ATUALIZACAO" />
           </restriction>
          </simpleType>
        </element>
    </sequence>
  </complexType>
									
</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 any 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 xmlns:cda="http://www.cnj.jus.br/mni/cda">
 <cda:certidao>
  <cda:devedorPrincipal>
   <cda:inscricaoMFDevedorPrincipal>111.111.111-11</cda:inscricaoMFDevedorPrincipal>
  </cda:devedorPrincipal>
  <cda:devedorAlternativo>
   <cda:inscricaoMFDevedorAlternativo>222.222.222-22</cda:inscricaoMFDevedorAlternativo>
   <cda:tipo>SOLIDARIO</cda:tipo>
  </cda:devedorAlternativo>
  <cda:valorDivida>
   <cda:valor>1.269,00</cda:valor>
   <cda:dataApuracao>2002-02-12</cda:dataApuracao>
   <cda:dataInicioIncidencia>2002-02-02</cda:dataInicioIncidencia>
   <cda:rubrica>MULTA</cda:rubrica>
   <cda:tipoValor>ORIGINARIO</cda:tipoValor>
  </cda:valorDivida>
 </cda:certidao>
</cda:dividaativa>

Número CDA como campo de consulta

Prioridade: 1

Necessidade negocial

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

Regras de negócio

• A pesquisa deve retornar todos os processos que tenham como informação processual complementar o registro de número da CDA disponibilizado para consulta.
• A consulta poderá ser realizada apenas pelo número completo da CDA
• O campo de consulta deverá ter seu preenchimento restrito ao máximo de 20 caracteres alfanuméricos
• 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: 0

Necessidade negocial

Permitir que, para as 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 petição interlocutória não lida para o usuário
• A tarefa deverá aparece segundo o perfil do usuário, conforme comportamento já adotado no PJe nessas situações
• Se mais de uma petição interlocutória estiver vinculada 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á adotado no PJe nessas situações
• Ao abrir a tarefa, o usuário deverá visualizar uma lista contendo as petições interlocutórias não lidas daquele processo, sendo exibido a primeiro petição automaticamente em um quadro abaixo da lista. Para o caso de uma petição apenas, a lista não deverá ser exibida.
• Para cada petição da lista, deve o usuário poder clicar em sua descrição, de forma que a petição seja exibida no quadro abaixo da lista.
• Para cada petição da lista, deve existir um campo de seleção para que o usuário marque a petição para ser retirada da lista, com possibilidade de selecionar-se todas 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 uma petição, a referida petição deverá ter sua marcação de petição não lida retirada (verificar qual o mecanismo que marca um documento como não lido atualmente).
• Para o caso de várias petições interlocutórias para o mesmo processo, as petições selecionadas devem ter sua marcação de petição não lida retirada
• Para o caso de várias petições para o mesmo processo e nenhuma petição selecionada, o sistema deve exibir uma mensagem informando que não é possível realizar a tarefa sem petições selecionadas
• Caso todas as petições tenham sido desmarcadas, 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 petições interlocutórias foram inseridas, visualizar aviso da entrada da petição, podendo retirar a marcação de petição não lida a partir do aviso e, consequentemente, quando daquela petição apenas estiver uma tarefa pendente, retirar o processo da tarefa.

Tramitar em lote

Requisito do PJe, independe da execução fiscal

Prioridade: 2

Necessidade negocial

Apesar das opções de minutar, movimentar e assinar em lote permitir que se faça tarefas repetitivas com um só procedimento, ao final de cada processo selecionado para realização dos procedimentos, o usuário precisa selecionar qual será a próxima tarefa do processo. Sendo assim, é desejável que a tarefa de saída dos processos possa ser selecionada de uma só vez para todos os processos.

Registramos, além do pedido de melhoria, um defeito na segunda tela do minutar em lote. A visualização de detalhes do processo apresentava defeito na versão 1.4.6.2.RC4 provisória. Foram feitos testes na versão definitiva e o erro não voltou a acontecer, mas o grupo de execução fiscal registrou a ocorrência no levantamento de requisitos.

Regras de negócio

Validar as restrições abaixo:

• As tarefas apresentadas para seleção devem ter sido configuradas no(s) fluxo(s) como sendo uma transição de saída da tarefa em lote selecionada.
• Existindo uma ou mais idêntica transição possível em todos os processos selecionados, o sistema deve permitir que o usuário substitua todas as transições dos processos por uma daquelas elegíveis para todos. A regra de negócio havia sido definida quando da definição da funcionalidade, mas não foi implementada.
  • Referência:
    • RN274
    • anexos da pendência PJEII-825
• A exibição das transições comuns a todos os processos deve acontecer em uma caixa de combinação vazia contida acima do cabeçalho da tabela de processos que, ao ser selecionada, exibirá a lista de transições possíveis a todos os processos daquela lista. Verificar imagem abaixo
• Ao selecionar uma das transições exibidas, as caixas de combinação referentes a cada processo deverão ter a seleção alterada para a transição selecionada.
• Ao selecionar a própria caixa de combinação vazia, o sistema carregará as caixas de combinação referente a cada processo com as previamente carregadas ao abrir a tela inicialmente.

Orientação para testes

A questão será testada na versão 1.4.6.2 RC4 pelo subgrupo de testes do Comitê dos Tribunais Estaduais e Militares.

Melhoria para o termo de audiência

Requisito do PJe, independe da execução fiscal

Priorização: 1

Necessidade negocial

Ao finalizar uma audiência, deveria ser possível utilizar o inteiro teor do termo de audiência para realização de despacho, sentença ou decisão conforme opção do usuário. Em muitos casos, o que consta no termo é o conteúdo do ato judicial, sendo de grande valia fazer com que essa necessidade seja automatizada pelo sistema.

Contextualização

A realização da audiência no PJe, assim como outros passos relacionados à audiências, são realizados através de configuração de tarefas no fluxo principal de tramitação das classes judiciais. Sendo assim, o termo de audiência, documento final produzido ao final da realização, é fruto da tarefa de realização.

Premissas de configuração

O fluxo principal, onde ocorre a realização de audiências, deve ser alterado para conter um nó de decisão que, dependendo da opção do usuário de utilizar o interior do termo em ato judicial, levará o processo para o subfluxo de preparar ato judicial, tarefa de confirmação do ato. Ao final da execução do subfluxo de preparação do ato judicial, a próxima tarefa seria a tarefa anteriormente configurada para ser posterior à de realização de audiência.

Regras de negócio

Validar as restrições abaixo:

• alterar a realização de audiência para conter opção, a ser selecionada pelo usuário através de botão, para que seja utilizado o inteiro teor do termo produzido para a conclusão de despacho, sentença ou decisão.
• alterar a realização de audiência para, caso o usuário opte por utilizar o inteiro teor do termo de audiência em ato judicial, o lançador de movimentos seja exibido para que o usuário selecione o movimento que ficará temporiamente registrado para confirmação em tarefa posterior.
• caso o usuário opte por utilizar o inteiro teor, o processo deverá ficar pendente da tarefa de confirmar ato, de acordo com configuração do fluxo.
• caso o usuário opte por não utilizar o inteiro teor (opção padrão), o processo seguirá para a tarefa posterior à realização da audiência, conforme configuração do fluxo.
• todas as regras relacionadas a realização de audiência já implementadas devem ser mantidas.

Agrupar processos pelo polo passivo

Prioridade: 1

Necessidade negocial

Algumas pessoas do PJe, principalmente pessoas jurídicas e entidades públicas, têm a elas vinculados vários processos, que precisam ser tratados de forma agrupada, principalmente levando-se em consideração confecção de atos processuais e a tramitação dos processos no fluxo. Sendo assim, é necessário atuar em processos agrupadamente de acordo com o polo passivo cadastrado.

Regras de negócio

• Permitir o cadastramento de agrupamentos de pessoas através de um submenu do menu de pessoa
• Ao agrupamento deverá ser atribuído um nome, de até caracteres alfanuméricos
• Após criado, deve ser possível, através de uma nova aba, o cadastramento de pessoas vinculadas ao agrupamento, de modo que a pesquisa das pessoas para entrada na vinculação seja realizada por CPF ou CNPJ, tornando o CPF ou CNPJ da pessoa considerado como parâmetro de agrupamento. A vinculação será realizada com cada pessoa relacionada ao agrupamento ou o agrupamento conterá o parâmetro de vinculação cadastrado para recuperação das pessoas em cada situação de pesquisa no PJe?
• Nas opções de pesquisa de processo, um dos parâmetros deverá ser a pesquisa pelo agrupamento (dependendo do item anterior, pesquisa poderá ser realizada pelo parâmetro de agrupamento ou pelo nome do agrupamento)
• O agrupamento poderá ser editado após sua criação
• Ao executar tarefas em lote (minutar, assinar e movimentar), deve haver a possibilidade de se atuar nos processos do agrupamento em lote, dependendo da configuração das tarefas
• O comportamento das tarefas em lote no agrupamento deve ser similar ao comportamento das tarefas em lote, especialmente quanto às opções de seleção de processos para atuação

Requisitos a serem revisados para serem integrados às regras de negócio acima:

• Buscar todos os processos em trâmite pelo CNPJ ou CPF
• Todos os processos são apresentados já selecionados e com as seguintes opções:
  • ícone para apresentar os detalhes do processo
  • opção de desmarcar o processo

Agrupar processos automaticamente por valores devidos

Prioridade: 1

Necessidade negocial

Desenvolver funcionalidade para separar os processos dos grandes devedores por órgão julgador

Direcionamento da solução

A solução deve ser dada através da utilização da EL

#{processoTrfHome.instance.valorCausaStr > 4000 ? 'Triagem de grandes devedores' : 'Tarefa padrão'} 

O valor 4000 poderia ser substituído pelo que fosse adequado à instalação, com a possibilidade de criação de um parâmetro para mapeá-lo. "Triagem de grandes devedores" seria o nome da tarefa onde seriam agrupados os processos dos grandes devedores e "Tarefa padrão" seria a tarefa do fluxo responsável pela execução padrão da tramitação processual.

Melhoria no minutar/assinar em lote

Prioridade: 2

Desenvolver um minutar em lote específico para o executivo fiscal ou alterar o minutar em lote atual. A mudança deve acontecer por causa do uso de variáveis.

Criação de um frame que permita a assinatura de um ou mais documentos existentes previamente preparados e cujos identificadores estejam armazenados na variável pje:fluxo:documento:minutas. Este frame deve estar preparado para realizar assinaturas em lote, ou seja, na situação em que houver mais de um documento para o mesmo processo e na situação em que houver documentos de processos diversos, este frame deverá ser capaz de tolerar a assinatura em lote. Utilizaremos esse frame no “Preparar ato de cartório” (PRATCART). Provisoriamente esse fluxo está usando o frame de minuta do magistrado, mas não atende à solução proposta.

Integração do Pje com V-Post

Prioridade: 3

Necessidade negocial

Nas comunicações com os jurisdicionados, o Judiciário utiliza os serviço dos Correios com frequência. Os Correios têm uma possibilidade de automatizar essa comunicação através de seu serviço V-Post, onde arquivos eletrônicos são recebidos por meio seguro, sendo transformados em objetos postais físicos com sua entrega e digitalização dos ARs (avisos de recebimento) que são enviados como comprovantes da entrega. É necessário fazer uso desse serviço no PJe. O V-Post foi desenvolvido com vistas a atender tribunais e hoje já está integrado a outros sistemas de tramitação processual eletrônica.

Outras melhorias

Melhorias solicitadas por email e registradas para debate posterior:

• Definir melhoria para que o editor possa receber um tipo de documento como padrão e um modelo padrão dentre os possíveis: hoje não é possível “abrir” o editor com um tipo de documento “default” e para esse tipo um modelo também “default”. Gostaríamos de poder fazer isso em diversos pontos do fluxo, um deles, por exemplo, seria na minuta do deferimento da inicial em que o tipo de documento é “Despacho” e o modelo seria “deferimento da inicial”. (inicialmente avaliada como necessária)

• A pendência PJEII-11281 atende ao pedido de melhoria solicitado pelo Comitê dos Estados em relação ao upload de documentos, que solicitava melhoria para ajustar o editor visando permitir que se parametrizasse a obrigatoriedade ou não do uso do editor associado ao upload.