Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.                                                             

Informações Gerais

Especificação

Produto

RM

Módulo

TOTVS Gestão Fiscal

Segmento Executor

Backoffice

Requisito/Story/Issue

FISCAL01-9775

Subtarefa


País

( x ) Brasil  (  ) Argentina  (  ) Mexico  (  ) Chile  (  ) Paraguai  (  ) Equador

(  ) USA  (  ) Colombia   (  ) Outro _____________.

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”.

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 “Produção” e “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.

draw.io Diagram
bordertrue
viewerToolbartrue
fitWindowfalse
diagramNameEstrutura Evento REINF
simpleViewerfalse
width
pageId501123918
diagramWidth402

Tabela Evento

Sugestão de nome: DEVENTOREINF

  • Identificador: será o Id do evento;
  • Id Evento Pai: será preenchido com o evento pai, porém pela sequencia lógica da EFD-REINF o Evento R-1000 terá este campo em branco;
  • Tipo: será preenchido com o código do evento da EFD-REINF, exemplo: R-1000, R-1070, R-2010 etc.;
  • Ambiente: será preenchido com o parâmetro cadastrado para a Filial;
  • Início do Período: deverá ser informado a data de início da vigência da EFD-REINF ou do Evento em questão;
  • Fim do Período: será preenchido com a 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;
    • Excluído: o Evento foi excluído com sucesso do ambiente da RFB.
  • Data da Última Transmissão: será preenchida com a data da última transmissão autorizada ou excluído;
  • Número do Protocolo: será preenchido com o número do ultimo protocolo retornado pela RFB para este Evento;
  • Código da Filial: código da filial no qual este registro pertence;
  • XML de envio: será preenchido com o xml do ultimo Evento enviado a RFB, contudo dependendo do status este campo poderá estar em branco;
  • XML de retorno: será preenchido com o xml do ultimo Evento retornado pela RFB, contudo dependendo do status este campo poderá estar em branco.

Tabela de Histórico

Sugestão de nome: DEVENTOREINFHIST

  • Identificador: será o Id do evento no qual este histórico pertence;
  • 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;
    • 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.

Protótipo de tela

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.