Informações Gerais

Objetivo

 Detalhar as alterações necessárias no modulo TOTVS Gestão Fiscal para a implementação dos Eventos Cadastrais R-1000 e R-1070 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.

Tabela

Evento

Sugestão de nome: DEVENTOREINF

• Identificador: será o Id do evento;
• Id Evento Pai: Deverá ser 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: Deverá ser preenchido com o parâmetro cadastrado para a Filial. 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.

(Obrigatório)

Definição da Regra de Negócio

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

Exemplo de Aplicação:

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

Tabelas Utilizadas

• SE2 – Cadastro de Contas a Pagar
• FI9 – Controle de Emissão de DARF>.

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.