Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
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 _____________. |
Detalhar as alterações necessárias no módulo TOTVS Gestão Fiscal para a implementação da EFD-REINF.
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).
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.
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.
Deverá ser criado um menu EFD-REINF no Módulo 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
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.
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 Cadastral ou Evento Periódico.
Sugestão de nome: DEVENTOREINF
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
Campos Nullable: Id. Evento Pai, Id. Evento REINF, Fim do Período, Data da Última Transmissão, Número do Protocolo, XML de envio e XML de retorno.
Sugestão de nome: DEVENTOREINFHIST
Foreign key: Identificador - FK com a tabela Evento.
Campos Nullable: XML de retorno e Observação.
Os Eventos devem seguir o padrão de cadastros do ERP, contudo podem existir particularidades entre os Eventos e neste caso deve ser verificada a regra na documentação especifica do Evento.
Ao ser incluído o Evento assumira o Status de "Não transmitido".
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".
O cadastro do Evento poderá ser excluído somente quando status for Não Transmitido, Inconsistente ou Rejeitado.
Não confundir Exclusão de cadastro com o Evento de Exclusão da RFB. |
Serão demonstrados os layouts referentes à estrutura comuns entre os Evento, contudo algum Evento pode ter um comportamento diferente do descrito abaixo e neste caso deverá ser verificado a documentação do mesmo.
|
as
as
Todos os Eventos devem armazenar um histórico com todas as mudanças que provocarem alteração de Status. Este histórico deve apresentar as informações mais importantes do Evento e permitirá somente consulta. Este histórico deve ser disponibilizado em forma de anexo no Cadastro do Evento.
asdas
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|