Árvore de páginas

 

1) Processo de Inovação - TAF

a. Especificação

    • Cadastro ( ATUSX , MVC , Estrutura de acordo com o Layout )
      Incluir no documento quais os campos que deverão ser incluídos / alterados / excluídos, conforme o levantamento do eSocial ( TFS );
      Novas tabelas ( solicitar ao Rodrigo que fará o controle de uso de tabelas );
      Avaliar necessidade de alterar descrição das tabelas ( por conta das alterações nos nomes de eventos).

    • Regra de Validação
      Utilizar levantamento dos layouts ( TFS );
      Incluir no documentos quais regras deverão ser excluídas, incluídas e alteradas;
      Validações complexas, vamos alinhar caso a caso, e se necessário incluir na planilha de validações não desenvolvidas ( TFS ).

    • Geração do XML
      Incluir no documento todos os modelos possíveis de XML de cada Evento ( Inclusão, alteração e exclusão ( retificação ) ) conforme o layout. O desenvolvedor utilizará esses modelos para gerar o XML.

    • Integração
      Elaborar o de/para das tags do evento com os campos do TAF.
      Modelo:

      TagCampo TAFTamanhoDecimalTipoObrigatório?
      iniValidC1E_XXX60CS
            

b. Codificação

    • Cadastro ( ATUSX , MVC , Estrutura de acordo com o Layout )
      ATUSX ( um pacote por Evento / Requisito );
      Utilizar UPDDISTR obrigatoriamente;
       Não excluir campos/índices/etc, colocar como não usado;
       NÃO ALTERAR NOME DE CAMPO;
      Validar inclusão, alteração e exclusão ( SaveModel ).

    • Regras de Validação
      Funções TAF???Vld();
      Utilizar o padrão já estabelecido!!! ( TAFA???, TAFXFUN e TAFXVALID );
      Funções desconhecidas PERGUNTEM;
      Caso encontre validações não especificadas ( inclusão e exclusão ) alinhar com analista que especificou, se necessário alinhamento da equipe.

    • Geração do XML
      Funções TAF???Xml();
      Incluir / Excluir / Alterar as tags conforme especificação ( atenção para CASE SENSITIVE );
      Gerar o XML.

    • Evidência de Testes

    • Outros ajustes
      Caso encontre problemas do desenvolvimento que evidenciam uma especificação errada, ajustar o código + documento de especificação;
      Todo dia: Subir os fontes alterados;
      Fontes concorrentes - compatibilizar no outro dia de manhã e subir;
      Fazer o merge com a manutenção todo dia de manhã.

    • Integração
      Remodelar o formato atual de integração - Rodrigo.

 

2) Detalhes do desenvolvimento do E-Social - TAF

Para o desenvolvimento do E-Social no TAF foram criadas algumas definições, como existem novos analistas e até afim de tirar possíveis dúvidas vou detalhar o processo abaixo:

 

Por essa obrigação acessória se basear no envio de XMLs ao RET não podemos simplesmente manutenir o cadastro, precisamos de um controle de alterações quando a informação já foi previamente enviada ao RET.

 

No documento anexo temos mais detalhes sobre os processos que devem ocorrer nas operações de alteração e exclusão, para que esse controle seja completo foram necessárias a criação de alguns campos de controle que irei explicar abaixo:

 

CAMPO

DESCRIÇÃO

OBJETIVO

_VERSAO

Código da Versão, é sempre gerado com a Data e hora no   momento da gravação.

Como dito acima um cadastro pode ser duplicado afim de se   manter o histórico de envios ao RET, sendo assim esse campo é o que   diferencia a chave única da tabela por sempre é gerado no momento da   gravação.

_VERANT

Código da versão anterior, é sempre gravado no registro   copiado trazendo o valor do campo _VERSAO do seu registro origem.

É necessário para que tenhamos o rastro das informações,   ou seja, sabemos qual foi a versão do registro anterior que deu origem a esse   novo registro.

_STATUS

“ ” = Registro integrado

Ocorre quando o cadastro acabou de ser incluído.

 

0=Reg.Valido

Registro já foi integrado e validado pelo JOB 3.

 

1=Reg.Invalido

Registro já foi integrado e o JOB 3 encontrou   inconsistências.

 

2=Reg.Transmitido

Registro já foi integrado, validado  e seu XML já foi   enviado ao RET.

 

3=Reg.Transmitido com inconsistência

Registro já foi integrado, validado  e seu XML já foi   enviado ao RET e teve retorno de inconsistências.

 

 

4=Reg.Transmitido valido

Registro já foi integrado, validado  e seu XML já foi   enviado ao RET e teve seu conteúdo validado.

 

 

9=Em Processamento 

(Não será Utilizado)

Este campo tem como objetivo identificar o status corrente   do registro, á través dele que podemos identificar se a informação está   válida no TAF ou se já foi enviada ao RET por exemplo.

_PROTUL

Número do último protocolo de envio retornado pelo RET

Neste campo gravamos o número do protocolo enviado pelo   RET quando transmitido o XML, no caso de uma retificação precisamos desta   informação, por exemplo.

_PROTPN

Número do penúltimo protocolo de envio retornado pelo RET

Número do penúltimo registro gerado pelo RET no envio do   XML, no caso de uma retificação precisamos desta informação, por exemplo.

_EVENTO

Indica a operação que foi realizada para geração do   registro (I,A,E)

Indica a operação que deu origem ao registro, é   fundamental para se saber como tratar os campos internos de controle de   acordo com a operação realizada.

_ATIVO

Indica se o registro está ativo, ou seja, se deve ser   visualizado no cadastro (1=Ativo, 2=Inativo).

Indica se o registro deve ser visualizado no cadastro ou   se apenas será considerado como base histórica.

 

Conforme conversamos hoje eu desenvolvi um motor de gravação que deverá atender a TODOS os eventos do E-Social no TAF, abaixo vou detalhar como deve ser desenvolvida a função SaveModel() dos  cadastros:                    

 

No Array aModels devem ser informados os nomes dos models que o cadastro contém e o tipo de model ( 1=Field, 2=Grid ).

 

Na chamada da função IntESocial manda-se como parâmetro o oModel, o Array citado acima e o índice referente a chave (FILIAL + ID + STATUS) do registro PAI.

 

Realizando o desenvolvimento conforme acima todos os processos citados no documento anexo devem ser realizados, caso alguém encontre algum problema por favor me avise para que possamos evoluir o motor juntos.

 

O nome do fonte é “IntegraESocial” e já está no diretório  V12.1.6 do TFS, podem compilar no ambiente de vocês e utilizar normalmente.

 

ATENÇÃO: Muito importante lembrar que no final do desenvolvimento do requisito precisamos anexar esse fonte no nosso pacote para que o SQA consiga validar.

 

3) API de Integração - Protheus x TAF

Introdução

Para realizar a integração nativa eSocial do Protheus com o TAF, deverá ser utilizada uma API onde o principal objetivo é fornecer uma integração online entre as aplicações

 

Modo de Uso

Deverá ser chamada após a validação completa do modelo de dados do ERP. Em termos técnicos, poderá ser chamada após a efetivação da função TudoOk().

 

Exemplo de Uso

Inicialmente deverá ser realizado o desenvolvimento de string no formato XML, exemplo:

A chamada efetiva da API deverá ser efetuada conforme abaixo, e tem como retorno um array de erros ( caso ocorram ):

aErros := TAFPrepInt( cEmpEnv , cFilEnv , cXml , cKey , cTpInteg, cEvento )

 

ParâmetroDescriçãoObrigatório?Default
cEmpEnv Empresa do registro no ERPNãocFilAnt
cFilEnv Filial do registro no ERPNãocEmpAnt
cXml String contendo o XML no formato do Layout do eSocialSim 
cKey Chave do registroSim 
cTpInteg Tipo da integração ( 1 = Online ; 2 = Banco-a-banco )Sim 
cEvento Código do Evento que está sendo enviado ( Exemplo: S1010, S1020, S1030, etc.. )Sim 
cXERPAliasAlias da tabela TAFXERP ( log de integração do TAF )Sim, quando cTpInteg = 2branco
cTicketCódigo do Ticket ( lote ) que o registro está sendo integradoSim, quando cTpInteg = 2branco

Após isso basta verificar se o Array “aErros “ está vazio, se sim sabemos que a informação foi incluída no TAF com sucesso, caso contrário possui o(s) erro(s) que impediu(ram) a operação.

4) Funcionalidades relativas à integração ERP x TAF

   4.1) Função para consultar status de registro no TAF

Introdução

Foi disponibilizada a função TAFGetStat() que possibilita consultar o status de um determinado registro no TAF.

Sintaxe

TafGetStat( cEvento , cChave , cEmpEnv , cFilEnv )

Parâmetros
ParâmetroDescriçãoObrigatório?Default
cEvento Evento do eSocial a que se refere o registroSim 
cChave Chave de busca do registro. No caso onde a chave do registro é composta por mais de um campo, os valores devem ser informados separados por ";" (ponto e vírgula).Sim 
cEmpEnv Empresa do registro no ERPNãocEmpAnt
cFilEnvFilial do registro no ERPNãocFilAnt

 

Modo de Uso

Local cStatus := ""

Local cEvento := "S-1010"

Local cChave := "RUB_001"

cStatus := TAFGetStat( cEvento, cChave )

 

Os retornos possíveis são:

  • "-1": Registro não encontrado na base do TAF
  • " ": Registro encontrado no TAF - não submetido ao processo de validação
  • "0": Registro encontrado no TAF - válido
  • "1": Registro encontrado no TAF - inválido
  • "2": Registro encontrado no TAF - transmitido e aguardando retorno do Governo
  • "3": Registro encontrado no TAF - transmitido e não autorizado ( retornado com erro )
  • "4": Registro encontrado no TAF - transmitido e autorizado
  • "6": Registro encontrado no TAF - pendente de exclusão no Governo ( S-3000 )
  • "7": Registro encontrado no TAF - exclusão validada pelo Governo ( S-3000 )

   4.2) Integração de múltiplas rubricas

Introdução

Integração do evento S-1010 (Rubricas) considerando o código identificador da tabela de rubricas no ERP origem.

Funcionamento 

Foi criado o cadastro Atualizações -> Cadastros eSocial -> Identificadores de Rubrica, onde é armazenado o código identificador da tabela enviado pelo ERP e gerado um código único e sequencial (ID). Esse código sequencial será utilizado pelo TAF na tag <ideTabRubr> do XML a ser transmitido ao RET .

Isso possibilita a integração de rubricas onde o código identificador da tabela no ERP é maior que 8 caracteres, como previsto no manual do eSocial. 

5) Preenchimento específico de Eventos

Evento S-1000 - Dados da Software House: Clientes TOTVS devem adotar o preenchimento abaixo.

Reg.

Descrição

Conteúdo a ser Informado

cnpjSoftHouse

CNPJ da empresa desenvolvedora do software.

53.113.791/0001-22

nmRazao

Informar o nome do contribuinte, no caso de pessoa física, ou a razão social, no caso de pessoa jurídica.

TOTVS S/A

nmCont

Nome do contato na empresa.

Gilsinei Hansen

telefone

Informar o número do telefone, com DDD.

011 2099 7373

email

Endereço eletrônico

[email protected]

 

 

  • Sem rótulos