Ir para o conteúdo principal

Estudo Tecnico sobre o que já existe desenvolvido dentro do Governa referente a RRA

Data de elaboração 06/04/2023
Responsável pelo estudo Rodrigo Stefano Sales
Equipe do estudo Caos
Alvo Governa -> Cálculo de Rendimento Retroativo
Origem

Projeto: GOVERNA
Objetivo Avaliar se o que tem desenvolvido no GOVERNA relacionado a Rendimento Retroativo Acumulado afeta o cálculo das verbas, como é feito este cálculo e se o cálculo atende a Instrução Normativa Nº 80/2022/SEFINCOTES, item 8.1.
Documentação correlata 
Observações Sem observações
Glossário
  • IRRF - Imposto de Renda Retido na Fonte
  • RRA - Rendimentos Recebidos Acumuladamente
  • IN - Instrução Normativa
  • NM - Número de Meses
  • DER - Diagrama de Entidade Relacional
  • CRUD - Create Read Update Delete
  • ORM - Object-Relational Mapping
1. Introdução

Este estudo tem como objetivo analisar a conformidade da implementação do cálculo de Rendimento Retroativo Acumulado (RRA) no sistema GOVERNA, com as exigências da Instrução Normativa Nº 80/2022/SEFIN-COTES. Será avaliado se o sistema trata os valores de forma adequada e quais são os impactos na folha de pagamento dos servidores.

Considerando a instrução normativa supracitada, que estabelece as regras para a retenção do Imposto de Renda Retido na Fonte (IRRF) no Estado de Rondônia, incluindo as formas de cálculo para os Rendimentos do Trabalho Assalariado e os Rendimentos Recebidos Acumuladamente (RRA), definida em seu capítulo 8, item IV, que diz: 

“O Imposto de Renda retido de rendimentos do trabalho assalariado deve ser realizado da seguinte forma: 
IV - valores pagos referentes a fato gerador de exercícios anteriores devem ser calculados como Rendimentos Recebidos Acumuladamente – RRA.”

Este item determina que o RRA se refere a rendimentos oriundos de exercícios anteriores, que não foram tributados no ano devido e que são pagos acumuladamente. A retenção do RRA sobre esses rendimentos é realizada de forma exclusiva, e a tabela de cálculo do imposto é diferente da utilizada para os rendimentos mensais.

Estes rendimentos têm tratamento tributário específico, que são conferidos quando os rendimentos são decorrentes de: 

  • Aposentadoria, pensão, transferência para a reserva remunerada ou reforma, pagos pela Previdência Social da União, dos estados, do Distrito Federal e dos municípios;
  • Rendimentos do trabalho.

Vale salientar que, aplica-se a referida tributação, inclusive, aos rendimentos decorrentes de decisões das Justiças do Trabalho, Federal, Estaduais e do Distrito Federal; devendo abranger tais rendimentos o décimo terceiro salário e quaisquer acréscimos e juros deles decorrentes.

O capítulo 8.1 da Instrução Normativa Nº 80/2022/SEFIN-COTES trata dos Rendimentos Recebidos Acumuladamente (RRA), ela nos informa que, para efetuar o cálculo de RRA, é necessário utilizar uma tabela específica apresentada no anexo IV da Instrução Normativa RFB nº 1.500/2014 conforme tabela descrita na imagem abaixo:

É importante destacar que o cálculo do RRA deve ser segregado dos demais rendimentos, ou seja, não deve ser incluído no mesmo grupo de cálculo dos rendimentos mensais. Além disso, é fundamental que todos os valores com caráter remuneratório sejam efetivamente pagos no ano em que surgir o fato gerador. Caso se refiram a fatos geradores de exercícios anteriores, será necessário utilizar o método de cálculo de RRA.

2. Desenvolvimento

2.1 Regras e Interações da tela de RRA

Caminho:

Movimentação Mensal > Folha de Pagamento > Cálculo de Rendimento Retroativo

Fonte:

governa-rh-web/webapp/usuario/movimentacaoMensal/folhaPagamento:

lancarRendimentoRetroativo.xhtml

A tela de RRA constitui de uma tela onde inicialmente busca-se um servidor por meio da matrícula e, caso encontre, permite-se gerenciar rendimentos retroativos relacionados àquele servidor específico. A imagem abaixo demonstra o funcionamento desta tela: 

Para cadastrar um novo rendimento retroativo, o usuário precisa primeiro encontrar o servidor que será relacionado ao rendimento, após isso, se houver algum RRA já cadastrado para este servidor encontrado, os dados serão listados na tabela constante nesta mesma tela.

Tela: Novo Rendimento Acumulado Retroativo 

Caminho:

Movimentação Mensal > Folha de Pagamento > Cálculo de Rendimento Retroativo>novo

Fonte:

governa-rh-web/webapp/usuario/movimentacaoMensal/folhaPagamento:

lancarRendimentoRetroativo.xhtml


A tela de Novo Rendimento Acumulado Retroativo permite que o usuário cadastre os dados referentes ao objeto RendimentoRetroativo. Nela serão solicitados os seguintes parâmetros obrigatórios:
 
•    Número do Processo
•    Ano do Processo
•    Mês de Referência
•    Início do Período
•    Quantidade de Meses
•    Fim do Período
•    Rendimento Total
•    Pensão Judicial

Após o preenchimento destas informações, o usuário poderá salvar o RRA.

Para salvar o RRA, o sistema executa o método salvar() da classe RendimentoRetroativoMB.java. A chamada do método e o método de salvar podem ser verificados nas imagens abaixo:


A classe RendimentoRetroativoMB.java executa diversas validações antes de chamar o método salvar() da classe rendimentoRetroativoBO.java. Observe na imagem acima, na linha 153, que o método já passa como parâmetro o objeto rendimentoRetroativo.

Já na classe de negócio RendimentoRetroativoBO, no método salvar(), podemos observar todas as regras de negócio aplicadas ao objeto antes de persistir no banco. Identificamos que, na primeira ação deste método, na linha 65, ele chama a função:

validaCamposObrigatorio(rendimentoRetroativo)

que passa o objeto a ser persistido e valida todos os campos obrigatórios, na sequência, na linha 66 da imagem abaixo, o sistema chama a função:

validarRegraNegocioProcessoMesmoMesReferencia(rendimentoRetroativo)

que proíbe a existência de mais de um registro de RendimentoRetroativo para o mesmo servidor e mês de referência. Se o sistema passar pelas validações, ele persiste o objeto rendimentoRetroativo no banco, conforme podemos verificar na linha 67.

No diagrama de entidade relacional demonstrado na imagem abaixo, podemos constatar que o relacionamento da tabela rendimento_retroativo ocorre apenas com as tabelas servidor e pessoa_fisica:

A classe RendimentoRetroativo representa um registro de rendimento retroativo de um servidor em um determinado período. Ela é uma entidade persistente no banco de dados. Nesta classe podemos confirmar os relacionamentos que se ligam com RRA por meio das anotações (annotations) de relacionamento da framework de ORM hibernate. Na imagem abaixo podemos ver as anotações de relacionamento da classe RendimentoRetroativo e confirmar sua conexão com as entidades PessoaFísica e Servidor:

2.2 Regras desenvolvidas e interações com tela de RRA com verba

O sistema governa, no que se refere à Rendimento Retroativo Acumulado, em sua parte visual, contempla apenas as telas descritas no item anterior, por meio do menu: Movimentação Mensal > Folha de Pagamento > Cálculo de Rendimento Retroativo.

 Uma das formas de identificar relações de RRA com verba é analisando o Diagrama de Entidade Relacional da tabela verba, para verificar se ela tem algum tipo de ligação tabelas de RRA.  A imagem a seguir podemos conferir o DER para a tabela verba:

A imagem abaixo mostra o diagrama DER da entidade averbação:

Levando em consideração que não existe relação de verba com RRA no DER, não existe no código fonte, regras de negócios em verba que instanciem RRA, não existem tabelas de ligação entre estas entidades no banco, podemos entender que não há efetiva relação entre as entidades verba e RRA.

2.3 Interações com cálculo e outras telas que possam ser afetadas por RRA

No pacote governa-rh-calculo, nas suas classes de regras de negócio e em todo o seu código fonte, não foram encontradas quaisquer referências ou instâncias da classe RendimentoRetroativo, não foi encontrada também instância da entidade servidor (que possui ligação com RRA) com parâmetros de rendimento, que podem ser acessados por conta da ligação que RRA tem com a tabela servidor via chave primária. Portanto, subentende-se que cálculo não pode ser afetado por qualquer registro de RRA.

2.4 Atende a IN Cotes item 8.1 ?

Após análise cuidadosa do sistema GOVERNA em que diz respeito à RRA, podemos afirmar que nenhuma das classes de regras de negócios utilizam as informações da tabela de referência da Instrução Normativa RFB nº 1.500/2014 em seu anexo IV. Sendo assim, o sistema GOVERNA não atende as regras especificadas na norma.

2.5 Quesitos

2.5.1  Como ficam os pagamentos para servidores desligados ?

Classe:

CalculoDesligamentoServico.java

Pacote:

governa-rh-calculo/folha

Método:

processarPersistirCalculoDesligamento()

O método responsável por processar e persistir o cálculo de desligamento de um servidor é :

processarPersistirCalculoDesligamento(),

que fica na classe governa-rh-calculo/folha/CalculoDesligamentoServico. Este método é chamado sempre que há um pedido de desligamento de um servidor e precisa calcular seus direitos financeiros decorrente da rescisão. Neste método não há nenhuma referência ou instância de RRA, portanto, entende-se que não há influência alguma de RRA com o cálculo de pagamento dos servidores desligados.

2.5.2  Onde fica guardada a informação de RRA?

Banco:

governa

Esquema:

rh

Tabela:

rendimento_retroativo

As informações de RRA ficam guardadas na tabela rendimento_retroativo, que se encontra no esquema rh, que por sua vez, faz parte do banco de dados governa.

2.5.3   Como ficam os dados em contracheques, ficha funcional e cédula C?

Classe:

ContrachequeVisao.java

Pacote:

governa-rh-comum/entidade/visao

Método:

ContrachequeVisao()

Foi analisado todo o código na classe de visão do contra-cheque acima citada. Nenhum dos construtores recebe, por parâmetro, informações relacionadas à RRA e, também, não fazem instância da classe RRA para buscar alguma informação de Rendimento Retroativo. Valores como servidorMensal, irrfBase, irrfAliquota, fgtsBase, fgtsValor dentre diversos outros valores são recebidos no construtor e utilizados para gerar a visão do contra-cheque. 

Classe:

FinanceiroMensalBO.java

Pacote:

governa-rh-negocio/bo

Método:

buscarContrachequeConsultaMensal ()

A classe FinanceiroMensalBO é responsável pelas regras de negócio do financeiro mensal. Esta classe retorna uma lista de objetos do tipo ContrachequeVisao. Esta classe foi estudada para identificar qualquer relacionamento com RRA, porém na mesma também não consta nada que possa ser associado a Rendimento Retroativo.

    Também foi verificado no diagrama relacional DER da entidade financeiro_mensal se existia alguma relação com RRA, mas como podemos observar nas imagens abaixo, não há:

Com isto, observamos que é improvável que RRA venha a influenciar nos dados de contra-cheque, ficha funcional ou cédula C.

2.5.4   Onde o sistema calcula o RRA?

O sistema não calcula RRA, apenas o gerencia (CRUD). Foram feitas buscas no código fonte por qualquer instância da classe RendimentoRetroativo para verificar seu uso, e as únicas encontradas são as que se referem ao gerenciamento da mesma, como por exemplo: No seu evento de cadastrar, editar, excluir ou listar.

2.5.5   Vai rodar no cálculo o RRA?

Caminho:

Cadastro > Parametrização > Cálculo > Evento para Cálculo

Fonte:

governa-rh-web/webapp/usuario/cadastro/parametrizacaoCalculo/manterParamEventoCalculo.xhtml

image.png

image.png

Existe no sistema GOVERNA uma área onde o usuário pode definir os parâmetros que serão rodados no evento do cálculo. Dentre os parâmetros existentes, podemos encontrar referência a RRA, porém, como podemos observar nas classes abaixo, que fazem o controle dos dados que geram a lista de parâmetros para o cálculo, que as informações referentes a RRA não são solicitadas para serem adicionadas à lista. Conclui-se então, que o sistema, neste menu específico, apresenta opção para adicionar RRA no cálculo, mas não efetua esta regra de negócio.

Classe:

ParamEventoCalculoBO.java

Pacote:

governa-rh-negocio/bo

Método:

salvar()

A classe ParamEventoCalculoBO representa um conjunto de parâmetros utilizados para calcular os eventos relacionados a verba. Em seu método salvar(), podemos observar que ela verifica a existência de verbas cadastradas e, em seguida, salva o objeto no banco de dados. Por meio do método verificarExistenciaVerba(), ela checa se existe verba cadastrada para diversos tipos de parâmetros, como percebemos na tabela abaixo:

getSaldoSalarioDesligamento()

getAdiantaFeriasRegulamentares()

getFeriasRegulamentares()

getAbonoFeriasRegulamentares()

getFeriasVencidas()

getFeriasProporcionais()

getAbonoFeriasProporcionais()

getAdiantamentoDecimoTerceiro()

getDecimoTerceiro()

getDecimoTerceiroDesligamento()

getAdiantamentoMensal()

getSalarioFamilia()

getAbonoFamilia()

getAbonoPecuniario()

getDiferencaFerias()

getComplementoSalario()

getComplementoSaldoNegativo()

getDescontoComplementoSaldoNeg()

getFalta()

getImpostoRenda()

getPensaoJudicial()

getDescontoAdiantamentoFerias()

getDescontoAdiantamentoSalario()

getDescontoAdiantamento13Sal()

getFgts()

getPrvFeriasDesligamento()

getIrrfFeriasDesligamento()

getFeriasPremio()

getAvisoIdenizadoDesligamento()

getDecimoIndenizadoDesligamento()

getPrvDecimoDesligamento()

getIrrfDecimoDesligamento()

getInssDecimoDesligamento()

getInssOutraEmpresa()

getCorteTeto()

getArredondamento()

getDescontoArredondamento()

getProLabore()

getAbonoFeriasVencidas()

getDiferencaSalarioComissionado()

getDiferencaSalarioEfetivo()

getTercoAbonoPecuniario()

getRestituicaoInss()

getInssFerias()

 

É possível notar que o método supracitado não busca parâmetros de RRA, demonstrando assim, que RRA não têm influência nenhuma sobre o cálculo.

2.5.6   Os valores determinados em cálculo são únicos?

Como pudemos identificar no item anterior deste capítulo, a classe ParamEventoCalculoBO verifica a existência de diversos tipos de verbas cadastradas. O método que verifica existência de verba é rodado uma vez para cada cenário demonstrado na tabela do item anterior, ex:verificarExistenciaVerba(getSaldoSalarioDesligamento());
e assim por diante. Se ocorrer de algum campo não ser informado, o método pai(salvar()) irá lançar uma exceção do tipo CampoObrigatorioNaoInformadoExcecao, retornando a seguinte mensagem: “Campo obrigatório não informado na entidade [%s].”  Desta forma, podemos considerar como únicos os valores determinados em cálculo.

2.5.7   Existe tabela na aplicação ou tela para informar as devidas alíquotas?

Não foi identificada referência no sistema ou tabela no banco, que se relacione com RRA e que possua ou permita informar as alíquotas da IN RFB nº 1.500/2014. 

Um exemplo de tabela de referência que permite a inclusão de alíquotas em caso semelhante é o da tabela índice_irrf, conforme demonstrado no diagrama DER abaixo:

2.5.8   Existe aplicação desenvolvida em carta remessa?

Existe uma pasta no governa-rh-web que contempla carta remessa, onde identificamos telas que possibilitam o gerenciamento de carta remessa, conforme pode ser observado abaixo:

Pacote:

governa-rh-web/usuario/movimentacaoMensal/controleBancario

Arquivos:

·                 consultarCartaRemessa.xhtml

·                 consultarCartaRemessaPorMatricula.xhtml

·                 excluirCartaRemessa.xhtml

·                 gerarCartaRemessa.xhtml

·                 manterVerbaExclusaoCartaRemessa.xhtml

Juntamente com as telas, identificamos também classes de Managed Beans que fazem a interação das telas de carta remessa com a camada de negócios como pode observar abaixo: 

Pacote:

governa-rh-web/managedbean

Arquivos:

·                 AbstractCartaRemessaMB.java

·                 CartaRemessaMB.java

·                 ConsultarCartaRemessa.java

·                 EscluirCartaRemessa.java

·                 VerbaExclusaoCartaRemessaMB.java

Estas classes, por sua vez, se conectam com as classes da camada de regras de negócios para assim, passarem os dados para a camada de persistência.

Pacote:

governa-rh-negocio/interfaces

Arquivos:

·                 ICartaRemessaServico.java

·                 ICartaRemessaServicoFabrica.java

Pacote:

governa-rh-negocio/bo

Arquivos:

·                 CartaRemessaBO.java

Pacote:

governa-rh-comum/negocio/interfaces

Arquivos:

·                 ICartaRemessaBO.java

Pacote:

governa-rh-comum/entidade

Arquivos:

·                 CartaRemessa.java

·                 CartaRemessaDetalhe.java

·                 CartaRemessaDetalheConsignacao.java

Considerando toda a implementação de carta remessa nos arquivos do código fonte do sistema GOVERNA, podemos concluir que existe sim, aplicação desenvolvida em carta remessa porém, não foram identificadas em nenhuma das classes acima citadas, referências ou conexões à RRA. 

2.5.9   O valor foi pago após o cálculo?

Considerando que, baseado neste estudo, o RRA que foi implementado no sistema GOVERNA não influencia em nada no cálculo da folha, podemos concluir que os valores continuam sendo gerados da forma usual e que, se são já pagos, continuam sendo.

3. Conclusão

Com base nas avaliações realizadas no presente estudo técnico, foi possível concluir que o sistema GOVERNA não atende às regras definidas na IN Cotes item 8.1, uma vez que o sistema não permite inclusão de tabela referencial de alíquotas para o cálculo dos Rendimentos Recebidos Acumuladamente, conforme determina esta mesma instrução normativa, que também o código implementado no sistema referente a RRA é apenas um cadastro e listagem simples, não possuindo qualquer ligação com verba, averbação, ou nenhuma outra tabela que não seja a tabela servidor e pessoa_fisica. 

Dessa forma, não há impacto nas tabelas de verba, contracheque, ficha funcional ou cédula C, tendo em vista que não existem cálculos segregados de RRA em relação aos demais rendimentos. Também não modifica nada nos pagamentos a servidores desligados.

É necessário, portanto, um estudo mais aprofundado e o desenvolvimento das funcionalidades referentes ao RRA no sistema, de forma que possa atender às exigências da IN Cotes item 8.1, e garantir que os cálculos sejam realizados corretamente, de forma segura e organizada. Somente com a implementação adequada de tais funcionalidades será possível assegurar a integridade das informações e o cumprimento das obrigações fiscais, de acordo com a legislação vigente.

Nenhum comentário
Voltar ao topo