Mudanças entre as edições de "Execução fiscal"

Edição das 13h36min de 4 de outubro de 2013

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.

Tramitar em lote

Requisito do PJe, independe da execução fiscal

Priorização: ++

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 fluxo da minuta, conforme orientações do minutar.

Melhoria para o termo de audiência

Requisito do PJe, independe da execução fiscal

Priorização: +++

Necessidade negocial

Ao finalizar uma audiência, deveria ser possível converter o termo de audiência em despacho, sentença ou decisão conforme decisã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 decisão do usuário de converter o 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 convertido o termo produzido em despacho, sentença ou decisão.
• alterar a realização de audiência para, caso o usuário opte por converter o 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 converter, 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 converter, 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

- dar nome ao grupo - fornecer o parâmetro de agrupamento (identificação da parte) - listar processos com base no parâmetro - possibilitar retirada de alguns dos processos - editar grupo posteriormente à criação - atuar nos processos agrupadamente (minutar, assinar e movimentar) - selecionar processos na atuação Priorização: +++

Agrupar processos automaticamente por valores devidos

Mediante parametrização por órgão julgador. O valor total é a soma dos valores das CDAs. A atualização das CDAs impacta reagrupamento. Atuar nos processos agrupadamento (minutar, assinar e movimentar) Priorização: +++

Melhoria no minutar/assinar em lote

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. Allan vai encaminhar o pedido mais detalhado.

"Incluir 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." Priorização: +++

Integração do Pje com V-Post

Priorização: +