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 (WS) 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 TOTVS Service Soa (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 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. Processo,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.
Utilizar o mesmo ID que será enviado ao TSS com 100 posições. Exemplo: Coligada + Tipo do Evento + o Identificador do cadastro do Evento |
Sugestão de nome: DEVENTOREINFHIST
Foreign key: Identificador - FK com a tabela Evento.
Campos Nullable: XML de Envio, 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 R-9000 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.
|
A integração com a RFB será realizada através dos WS do TSS no qual o TOTVS Gestão fiscal irá enviar os Eventos e o TSS se encarregará da assinatura dos XML, montagem dos lotes e comunicação com a RFB. Basicamente toda a integração com o TSS ocorrerá através dos processos "Transmitir" e "Consultar". Ambos os processos devem ser disponibilizados na lista de processos de cada Evento e, também, na lista de processos da visão dos menus "Eventos Cadastrais" e "Eventos Periódicos" podendo ser executados para um ou vários Eventos simultaneamente.
Os detalhes dos serviços do TSS devem ser consultados na especificação de integração com o TSS. |
Este processo irá transmitir o Evento do ERP para a RFB através do TSS. O processo deverá permitir a execução por agendamento de Job de forma que seja capaz de identificar Eventos com status "Não transmitido" e "Alterado" enviando-os ao TSS de forma autônoma.
Deverá ser montado um xml para cada Evento conforme o layout e origem de dados do mesmo. No caso de erros ao montar o xml dos Eventos os mesmos devem ser gravados com Status de "Inconsistente", registrado histórico com os detalhes e apresentado no log para o usuário.
Para fins de geração do XML observar o comportamento do process "Gerar Eventos Periódicos" no documento de especificação de Eventos Periódicos e se possível implementar da mesma forma. |
A configuração será realizada somente se existirem xmls gerados para enviar ao TSS. O TSS deverá ser configurado conforme consta na especificação de integração com o TSS.
Com o xml gerado deverá ser realizada uma validação de schema através do serviço VALIDARSCHEMA do TSS.
Os Eventos que apresentarem erros devem ser gravados com Status de "Inconsistente", registrado histórico com os detalhes e apresentado no log para o usuário.
Somente os Eventos que forem validados com sucesso podem ser enviados ao TSS através do serviço ENVIAREVENTOS.
Os Eventos que apresentarem erros devem ser gravados com Status de "Inconsistente" e os Eventos enviados com sucesso devem ser gravados com Status "Pendente". Ambos devem registrar histórico com os detalhes e apresentar no log para o usuário.
Este processo irá consultar no TSS o resultado da transmissão realizada para a RFB. O processo deverá permitir a execução por agendamento de Job de forma que seja capaz de identificar Eventos com status "Pendente" consultando-os no TSS de forma autônoma.
O TSS deverá ser configurado conforme consta na especificação de integração com o TSS.
Consultar os Eventos no TSS através do serviço CONSULTAREVENTOS. Se for identificado que os Eventos ainda não possuem uma resposta da RFB o usuário deve ser informado e um registro no histórico deve ser gravado, mas os Status dos Eventos não devem sofrer alterações. No caso da consulta ser realizada com sucesso o Status do Evento será alterado conforme o resultado obtido podendo ser "Autorizado" ou "Rejeitado", em ambos os casos um histórico deve ser gravado e no caso da rejeição ainda será necessário informar ao usuário o motivo da rejeição através de log.
Todos os Eventos devem armazenar um histórico com todas as mudanças que provocarem alteração de Status ou Erro nos processos, registrando as informações mais importantes do Evento somente para consulta. O histórico deve ser disponibilizado em forma de anexo no Cadastro do Evento.
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|