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-9796 | Subtarefa | FISCAL01-10185 |
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 do Evento Periódicos R-2010 à R-2070 e R-5011 da EFD-REINF
De acordo com o manual da EFD-REINF o Evento R-5011 é o totalizador do período. Após o encerramento do período no ambiente da RFB este evento pode ser consultado para retornar os totalizadores calculados no ambiente da RFB com base nos Eventos transmitidos.
No TOTVS Gestão Fiscal iremos inverter a relação dos Eventos periódico com o totalizador tornando o Evento R-5011 "pai" dos Eventos periódicos conforme abaixo.
Com esta mudança o R-5011 passa a ser utilizado como "Período dos Eventos Periódicos" e seus filhos serão os Eventos Periódicos.
Detalhes dos campos do R-5011:
Ao acessar o menu "Eventos Periódicos" devem ser apresentados todos os Eventos R-5011 e o mesmo deverá disponibilizar um anexo com todos os Eventos Periódicos. Os processos de "Transmitir", "Consultar" e "R-9000 Excluir" devem ser disponibilizados na lista de processos da visão do R-5011 e na lista de processos dos Eventos filhos permitindo a execução individual ou em lote. Ao ser acionado no R-5011 o processo será executado para todos os Eventos filhos obedecendo as regras de cada processo.
Deverá ser criado um processo de Inclusão no qual os Eventos Periódicos serão incluídos conforme sua origem deixando-os no ponto de transmissão. Este processo será executado automaticamente ao encerrar o período de apuração dos tributos envolvidos na EFD-REINF ou de forma manual através de um processo na tela de cadastro do Período de Eventos Periódicos (R-5011). Além disso o processo deve ser criado com possibilidade de agendamento através de job.
Internamente a inclusão também deverá atualizar Eventos já criados comparando a data do status do mesmo com a data do log de alteração no cadastro de origem ou novas origens relacionadas ao mesmo Evento. No caso de um Evento com status “Não Transmitido” ou "Alterado" basta atualizar os dados do mesmo sem a necessidade de registrar histórico. No caso do Evento já ter sido autorizado o Status deverá ser modificado para "Alterado" e seus dados atualizados na integra, ou seja com base em todas as origens relacionas a este Evento.
Somente os Eventos com status "Não Transmitido", "Inconsistente" e "Rejeitado" podem ser excluídos;
Os eventos periódicos serão gerados com base em cadastros do BackOffice conforme abaixo. Cada evento deverá disponibilizar através de anexo uma consulta das origens relacionadas ao evento (Exemplo: números dos lançamentos fiscais utilizados no evento).
O xml do Evento deverá ser gerado conforme abaixo.
<?xml version="1.0" encoding="utf-8"?> <Reinf> <evtTabProcesso id="???000000000000000000000000000000000"> <ideEvento>{...}</ideEvento> <ideContri>{...}</ideContri> <infoProcesso> <inclusao>{...}</inclusao> <alteracao>{...}</alteracao> <exclusao>{...}</exclusao> </infoProcesso> </evtTabProcesso> </Reinf> |
No grupo infoProcesso poderá ter apenas um dos seguinte Grupos
|
Este evento será gerado com base no Cadastro de Processo e todos os campos envolvidos precisam de controle de alteração (semelhante ao log da Filial). Sempre que estes campos forem atualizados e o Evento já estiver autorizado o status do registro R-1070 será modificado para “Alterado”.
|
As demais estruturas não destacadas irão seguir o padrão geral dos eventos
O campo Vara precisa registrar log de alteração no cadastro de processo.
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|