RECEITAJUD
Documentações
Documentação de usuário
Contexto
O RECEITAJUD é o sistema implantado no Conselho Nacional de Justiça (CNJ) responsável por integrar o poder judiciário e a Receita Federal Brasileira.
Diante das muitas limitações existentes no INFOJUD atualmente, surgiu a necessidade de se criar um novo RECEITAJUD para substituí-lo, contemplando as funcionalidades existentes e adicionando outras novas. A nova arquitetura além de ganhar em agilidade na obtenção de informações junto à Receita Federal, uma vez que os magistrados terão acesso à base de dados de forma online, provê o uso de APIs o que a torna uma ferramenta fácil de ser integrada à outras soluções existêntes nas plataformas do poder judiciário, seguindo as diretrizes do trabalho colaborativo proposto na PDPJ (Plataforma Digital do Poder Judiciário).
Acessos
Para solicitar a inclusão ou alteração de usuários/perfis no sistema, entre em contato com o administrador regional do Corporativo no seu tribunal.
Magistrados já possuem acesso completo à ferramenta e podem delegar acesso aos servidores, os quais terão acesso completo a partir desse momento.
Serviços Disponíveis
Atualmente são disponibilizados os seguintes serviços de consulta:
- E-Financeira
- Escrituração Contábil Fiscal (ECF)
- Dados Cadastrais Pessoa Física (CPF)
- Dados Cadastrais Pessoa Jurídica (CNPJ)
- Declaração de Importação (DI´s)
- Declaração de Imposto de Renda da Pessoa Física (DIRPF)
- Declaração de Operações com Cartão de Crédito(DECRED)
- Declaração de Operaçãoes Imobiliárias (DOI)
- Declaração de Informações sobre Atividades Imobiliárias (DIMOB)
- Imposto sobre a Propriedade Territorial Rural (ITR)
Após a autenticação do usuário no Marketplace do PDPJ, é possível acessar o RECEITAJUD e suas funcionalidades disponibilizadas pelo PDPJ na página inicial da plataforma:
Interfaces do Sistema
O menu inicial do RECEITAJUD dispõe todas as funcionalidades do sistema, bastante clicar sobre uma delas para acessá-la.
Se necessário, também existe o menu lateral com a lista das funcionalidades. Para acessar o menu lateral, basta clicar sobre o botão azul no canto superior esquerdo ao lado da logo do RECEITAJUD.
Na visão do servidor, as funcionalidades tem o seguinte layout (na visão do magistrado, o campo 'Juiz' não estará presente). Todos os campos devem ser preenchidos para realizar uma nova consulta. Assim que a consulta for efetuada ela estará disponível na tabela 'Histórico de buscas' na parte inferior da página.
Particularidades nos campos das requisições
Algumas funcionalidades possuem itens diferentes das demais, como exemplo, o sub-menu da E-financeira que é uma barra de navegação dessa declaração, ramificando-a de acordo com os tipos de declarações que ela oferece. Para acessar cada um deles, basta clicar no nome, apenas serão alterados os campos necessários para se efetuar uma nova consulta e o histórico será respectivo ao item do sub-menu selecionado.
A funcionalidade para consultas de pessoas físicas (consulta CPF) também é diferente. Nela, pode-se realizar uma consulta inserindo apenas o CPF desejado ou preenchendo as informações pessoais. Para a segunda opção, é necessário (obigatório) informar o nome e o nome da mãe ou o nome e a data de nascimento. As demais informações não são obrigatórias mas auxiliarão a filtrar a resposta.
Essa funcionalidade não possui histórico, assim, a resposta será apresentada na tela logo após a consulta.
Assim como a consulta de CPFs, a consulta de CNPJs também não possui histórico e o resultado será apresentado logo após a consulta.
Histórico de consultas
Na maioria das funcionalidade do sistema será exibido o histórico de consultas realizadas pelo usuário (caso seja um magistrado, também são apresentadas as consultas feitas pelos servidores vinculados a ele). Logo após a consulta ter sido realizada, o resultado estará apresentado como na imagem a seguir, atualize a página para verificar a atualização do resultado.
O histórico após a atualização da pagina ficará da seguinte forma:
Para cada item do histórico existe um botão de 'Detalhes' na extremidade direita (coluna 'Resposta'). Esse botão abre uma janela com todos os dados referentes à consulta e a quem a realizou.
Documentação técnica
Documentação técnica do sistema RECEITAJUD com informações a respeito de tecnologias utilizadas, arquiteturas, banco de dados, classes e rotinas fundamentais e abstração de código.
Rodando o projeto localmente
Para exceutar o sistema localmente, deve-se ter as ferramentas de desenvolvimento do Java (versão 8) instaladas, o PostgreSQL e o PGAdmin. Configurar um servidor local no PGAdmin com o nome do database: receitajud. Feito isso, realizar um build do projeto com as dependências (importante), acessar a pasta .m2 na máquina local e adicionar o arquivo settings.xml (pode ser encontrado aqui). Realizar novo build com dependências e, por fim, rodar o projeto.
Arquitetura
O sistema é desenvolvido com base no projeto de Implementação de Referência da PDPJ (https://git.cnj.jus.br/pdpj/dev/referencia), seguindo assim os padrões de desenvolvimento e as boas práticas. Esse projeto base já tem as principais configurações para desenvolvimento prontas, o que facilita a implementação de funcionalidades.
As classes a serem alteradas/criadas ficarão nos pacotes de controller, services, models e repositories. O pacote controller gerencia as rotas da aplicação, de envio e chegada de dados e faz apenas algumas verificações de dados antes de enviá-los para a sua respectiva classe service. A separação das rotas nesse pacote foi feita de acordo com o tipo da requisição, e para cada tipo existem duas rotas: criação de requisição para a RFB a partir dos dados informados pelo usuário e a busca do histórico do usuário atualmente autenticado na aplicação. Nesse pacote também existe a classe que gerencia as call-backs.
O pacote services gerencia a lógica e as regras de negócio da aplicação, além de fazer a ligação com camadas internas, por exemplo, acessar o pacote repositories.
O pacote models é composto por: entities, dtos (Data Transfer Object), mappers e enums. São classes bases da aplicação usadas para o desenvolvimento e servem para tratar os dados, por meio de objetos, de forma mais fácil.
Call-Backs
Com o objetivo de manter o sistema assíncrono, as requisições feitas ao serviço da RFB devem informar o tipo da requisição, ano e CPF/CNPJ juntamente com um endereço URL da internet (chamado de call-back) e retornará no corpo da resposta um ID. Esse endereço (no caso, o endereço do RECEITAJUD) será para onde o serviço da RFB enviará a resposta da requisição assim que a tiver, identificando-a pelo ID retornado anteriormente. Ou seja, quando uma requisição é feita para o serviço da RFB ela terá duas etapas. A primeira é informar quais dados se desejam e para onde enviá-los (endereço da call-back), tendo como resposta um ID, o qual representa a requisição em questão. Enquanto a RFB processa esse pedido, o sistema está livre para fazer novas requisições e a atual é encerrada. A segunda é receber na call-back¬ indicada os dados requisitados, assim que estiverem prontos na RFB, e encerrar a requisição em questão também.
Swagger
As requisições no sistema são acompanhadas de anotações da operação, as quais servem para gerar a documentação do Swagger. Esse serviço permite que o sistema seja acessado diretamente no back-end, podendo testar e verificar padrões de envio e reposta independentemente do front-end.
- Link Swagger de desenvolvimento: https://gateway.stg.cnj.cloud/receitajud-dev/swagger-ui.html#/
- Link Swagger de homologação: https://gateway.stg.cnj.cloud/receitajud/swagger-ui.html#/
Notas finais
O sistema do RECEITAJUD está, atualmente, divido em duas branches principais: develop e master. A master é utilizada para homologação e é tida como branch principal, ou seja, deve ser a mais estável para o sistema em produção. A de develop é utilizada para testar funcionalidades e não precisa tanto cuidado quanto a estabilidade. Cada commit feito aplica as alterações à respectiva branch, o que implica também em atualizar o serviço do Swagger respectivo. Por exemplo, realizando um commit com push na branch de desenvolvimento, somente ela será alterada assim como somente o serviço de desenvolvimento do Swagger será alterado.
Para alterações no ambiente de produção, deve-se apenas criar uma nova TAG no repositório do GitLab, as configurações estão feitas para que assim que uma nova TAG seja criada, independente de qual branch, essa será a versão que estará em produção.