Informações Gerais

Objetivo

Detalhar as alterações necessárias no modulo TOTVS Gestão Fiscal para a implementação da EFD-REINF.

Introdução

De acordo com o manual da escrituração fiscal digital de retenções e outras informações fiscais (EFD-REINF) versão 1.04.00 de dezembro de 2018, a EFD-REINF é uma obrigação acessória que visa basicamente reunir informações de retenção e algumas informações fiscais conforme interesse da Receita Federal do Brasil (RFB).

Exigência

Estão obrigados a EFD-REINF as pessoas jurídicas que prestaram ou contrataram serviços, que retiveram PIS/Pasep, Cofins, CSLL, CPRB, IRRF entre outros, conforme consta no manual versão 1.04.00 seção 2.4 “Pessoas Obrigadas as Declarar”.
A REINF deverá ser gerada e entregue mensalmente até o dia 15 do mês subsequente ao fato gerador, salvo especificidades previstas na legislação.
De acordo com a IN RFB 1.842/2018, de 29 de outubro de 2018 serão obrigadas a EFD-REINF a partir de 10 de julho de 2019 todas as empresas que são do Regime Especial Unificado de Arrecadação de Tributos e Contribuições devidos pelas Microempresas e Empresas de Pequeno Porte (Simples Nacional), sendo que as demais já estão obrigadas exceto órgãos públicos.

EFD-REINF

A EFD-REINF é constituída por vários arquivos magnéticos que representam eventos e devem obedecer ao layout próprio conforme o manual técnico em vigência. Cada evento deve ser assinado digitalmente conforme regras publicadas no manual técnico.
A entrega dos eventos deverá ocorrer por lotes que podem ser constituídos de 1 (um) à 100 (cem) eventos sendo estes transmitidos para a RFB através do Webservices pela internet conforme definições do manual técnico.
Os eventos devem obedecer a sequência lógica conforme abaixo.

• R-1000 e R-1070: Estes eventos são únicos e não precisam ser reenviados a RFB periodicamente, apenas quando for necessário atualizar os dados.
• R-2010, R-2020, R2030, R-2040, R-2050, R-2060 e R-2070: Estes eventos devem ser enviados até o dia 15 do mês seguinte à emissão da nota fiscal ou fatura ou antes do envio do evento R-2099 - Fechamento dos Eventos Periódicos, o que ocorrer primeiro.
• R-2099: Este evento é utilizado para informar o encerramento do período de apuração dos eventos periódicos. Deve ser transmitido até o dia 15 do mês subsequente ao do mês de referência informado no evento.
• R-2098: Este evento poderá ser utilizado após o evento R-2099 com o intuito de reabrir o período de apuração e possibilitar ajustes. Após os ajustes o encerramento do período precisa ser realizado novamente através do R-2099.
• R-3010: Este possuí um período é especifico conforme regras do manual da EFD-REINF e não é afetado pelos eventos R-2099 e R-2098.
• R-5001: Este evento será retornado como resposta de qualquer evento periódico enviado. No caso de um lote com vários eventos será retornando um R-5001 para cada evento enviado.
• R-5011: Este evento é o totalizador do período e deverá ser consultado após o encerramento do mesmo.
• R-9000: Este evento é utilizado para anular qualquer evento periódico (R-2010 à R-2070) ou não periódico (R-3010). Contudo, para os eventos periódicos o período não poderá estar encerrado.

Obrigações Acessórias

Deverá ser criado um menu EFD-REINF no modulo Fiscal Pasta Obrigações acessórias e só poderá ser acessado pela filial matriz ou SCP. Este menu terá os seguintes submenus “Eventos Cadastrais” e “Eventos Periódicos”.

Sugiro alterar o menu SPED colocando com submenus do mesmo a opção EFD-ICM IPI e EFD-REINF

Parâmetros

Deverá ser criado um parâmetro por filial para armazenar a versão e ambiente da EFD-REINF. Devido a integração com o TSS eu sugiro que seja criado um parâmetro no Totvs Gestão Fiscal para exibir as configurações de conexão com o TSS (TPARFILIAL) e que neste mesmo parâmetro sejam exibidos os campos abaixo.

• Ambiente: deverá apresentar as opções:
  1 - Produção;
  2 - Produção restrita.
• Versão: deverá apresentar um combobox com a versão 1.4.01

Estrutura de tabelas para os Eventos

Apesar das pequenas diferenças todos os eventos têm a mesma estrutura então será detalhado abaixo a estrutura que será criada para cada Evento seja ele um Evento de Cadastrado ou Evento Periódico.

Tabela Evento

Sugestão de nome: DEVENTOREINF

• Identificador: Identificador do cadastro do evento;
• Cód. Coligada: código da coligada na qual o cadastro foi realizado;
• Id. Evento Pai: deve ser preenchido com o evento pai, porém pela sequencia lógica da EFD-REINF o Evento R-1000 terá este campo em branco;
• Id. Evento REINF: ID de 36 posições definido pela EFD-REINF. Este campo será preenchido após a primeira integração com o TSS.
  • A identificação única do evento (Id) é composta por 36 caracteres, conforme o que segue:
    IDTNNNNNNNNNNNNNNAAAAMMDDHHMMSSQQQQQ
    ID - Texto Fixo "ID";
    T - Tipo de Inscrição do Empregador (1 - CNPJ; 2 - CPF);
    NNNNNNNNNNNNNN - Número do CNPJ ou CPF do empregador - Completar com zeros à direita. No caso de pessoas jurídicas, o CNPJ informado deve conter 8 ou 14 posições de acordo com o enquadramento do contribuinte para preenchimento do campo {ideEmpregador/nrInsc} do evento R-1000, completando-se com zeros à direita, se necessário.
    AAAAMMDD - Ano, mês e dia da geração do evento;
    HHMMSS - Hora, minuto e segundo da geração do evento;
    QQQQQ - Número sequencial da chave. Incrementar somente quando ocorrer geração de eventos na mesma data/hora, completando com zeros à esquerda.
    OBS.: No caso de pessoas jurídicas, o CNPJ informado deverá conter 8 ou 14 posições de acordo com o enquadramento do contribuinte para preenchimento do campo {ideEmpregador/nrInsc} do evento S-1000, completando-se com zeros à direita, se necessário.
• Tipo: deve ser preenchido com o código do evento da EFD-REINF, exemplo: R-1000, R-1070, R-2010 etc.;
• Ambiente: deve ser preenchido com o parâmetro cadastrado para a Filial;
• Início do Período: data de início da vigência da EFD-REINF ou do Evento em questão;
• Fim do Período: data final do Evento em questão
• Status: poderá assumir um dos seguintes valores:
  • Não Transmitido: o Evento foi cadastrado, mas ainda não foi integrado com o TSS para ser transmitido a RBF;
  • Pendente: o Evento foi cadastrado e já integrado com o TSS, e será necessário realizar o processo de consulta para verificar o resultado do processamento do Evento junto a RBF;
  • Inconsistente: os cadastros que dão origem ao Evento estão preenchidos incorretamente e por este motivo não foi possível montar o Evento. O motivo da inconsistência poderá ser verificado no campo observação do histórico;
  • Rejeitado: a RFB não autorizou o Evento por qualquer motivo e o mesmo foi rejeitado. O motivo da rejeição poderá ser verificado no campo observação do histórico;
  • Autorizado: a RFB validou e autorizou o Evento;
  • Alterado: Após autorização os dados de origem do Evento foram alterados e o Evento precisa ser retransmitido a RFB;
  • Excluído: o Evento foi excluído com sucesso do ambiente da RFB.
• Data da Última Transmissão: data da última transmissão autorizada ou excluída;
• Número do Protocolo: número do ultimo protocolo retornado pela RFB para este Evento;
• Cód. da Filial: código da filial no qual este registro pertence;
• XML de envio: xml do ultimo Evento enviado a RFB, contudo dependendo do status este campo poderá estar em branco;
• XML de retorno: xml do ultimo Evento retornado pela RFB, contudo dependendo do status este campo poderá estar em branco.

Primary key: Identificador
Foreign key: Cód. Coligada - FK com a tabela de coligada, Id. Evento Pai - FK com a própria tabela de Evento (auto relacionamento), Cód Filial - FK com a tabela de Filiais.
Unique key: Identificador, Cód. Coligada

Tabela de Histórico

Sugestão de nome: DEVENTOREINFHIST

• Identificador: será o Id do evento no qual este histórico pertence;
• Id Evento REINF: será preenchido com o ID de 36 posições definido pela EFD-REINF;
• Status: poderá assumir um dos seguintes valores:
  • Não Transmitido: o Evento foi cadastrado, mas ainda não foi integrado com o TSS para ser transmitido a RBF;
  • Pendente: o Evento foi cadastrado e já integrado com o TSS, e será necessário realizar o processo de consulta para verificar o resultado do processamento do Evento junto a RBF;
  • Inconsistente: os cadastros que dão origem ao Evento estão preenchidos incorretamente e por este motivo não foi possível montar o Evento. O motivo da inconsistência poderá ser verificado no campo observação do histórico;
  • Rejeitado: a RFB não autorizou o Evento por qualquer motivo e o mesmo foi rejeitado. O motivo da rejeição poderá ser verificado no campo observação do histórico;
  • Autorizado: a RFB validou e autorizou o Evento;
  • Alterado: Após autorização os dados de origem do Evento foram alterados e o Evento precisa ser retransmitido a RFB;
  • Excluído: o Evento foi excluído com sucesso do ambiente da RFB.
• Data do status: será gravada a data na qual aquele status foi gerado para o 
• XML de envio: será preenchido com o xml do evento enviado a RFB, contudo dependendo do status este campo poderá estar em branco;
• XML de retorno: será preenchido com o xml retornado pela RFB, contudo dependendo do status este campo poderá estar em 
• Número do Protocolo: será preenchido com o número do protocolo retornado pela RFB para este status;
• Observação: quando necessário será preenchido com os detalhes do status.

Foreign key: Identificador - FK com a tabela Evento.

Cadastro

Os Eventos podem ser cadastrados conforme padrão do ERP para os demais cadastros, contudo podem existir particularidades entre os Eventos e neste caso deve ser verificada a regra na documentação especifica do Evento.

Inclusão

Ao ser incluído o Evento assumira o Status de "Não transmitido".

Edição

Quando o Evento estiver com Status de "Não Transmitido" o status não será alterado, quando o Evento estiver com o Status "Inconsistente" ou "Rejeitado" o Status será alterado para "Não Transmitido". Qualquer outro status o Evento assumirá o Status de "Alterado".

Exclusão

O cadastro do Evento poderá ser excluído somente quando status for Não Transmitido, Inconsistente ou Rejeitado. 

Regras

• Quando o Evento estiver com status de pendente todos os campos precisão permanecer boqueados para Edição inclusive os campos nos cadastros de origem do Evento;
• Quando o Evento estiver com status de Excluído o mesmo deverá ser bloqueado para Edição, mas os campos de origem não serão bloqueados;
• O campo Cód. Coligada não deve ficar visível para o usuário;
• Nenhum histórico pode ser alterado, excluído ou incluído;
• Os campos Status, Tipo não devem ser editáveis;

Processos

Transmitir

as

Consultar

as

Anexos

Histórico

Todos os Eventos devem armazenar um histórico com todos as mudanças que ocorrerem. Este histórico deve apresentar as informações mais importantes do Evento e permitirá somente consulta.

Origem

as