Histórico da Página
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.
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 | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|