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 modulo 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 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
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 Cadastrado 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.
|
<idePeriodo> <iniValid>str1234</iniValid> <fimValid>str1234</fimValid> </idePeriodo> |
Elemento do XML | Origem |
---|---|
iniValid | Campo "Início do Período" do Cadastro do Evento |
fimValid | Campo "Fim do Período" do Cadastro do Evento |
<ideEvento> <tpAmb>123</tpAmb> <procEmi>123</procEmi> <verProc>str1234</verProc> </ideEvento> |
Elemento do XML | Origem |
---|---|
tpAmb | Será gerado conforme o campo Ambiente do Cadastro do Evento |
procEmi | Valor fixo 1 - Aplicativo do contribuinte |
verProc | Será gerado conforme o campo Versão do parâmetro da EFD-REINF |
<ideContri> <tpInsc>5</tpInsc> <nrInsc>str1234</nrInsc> </ideContri> |
Elemento do XML | Origem |
---|---|
tpInsc | Gerar conforme o cadastro da Filial 1- CNPJ 2- CPF |
nrInsc | CNPJ/CPF da Filial |
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. |
---|