Histórico da Página
Este documento tem por objetivo definir, especificar e explanar sobre os critérios técnicos necessários para integração entre os sistemas de controle empresarial (ou qualquer outro software desejado), e o sistema TOTVS Automação Fiscal.
Para que se torne mais efetivo o entendimento deste documento é altamente recomendável que seja acessado o link abaixo para conhecimento de todo o escopo do produto:
Índice
Índice |
---|
Contexto de negócio
O TAF ( TOTVS Automação Fiscal ) foi criado com o objetivo de consolidar dados e layouts, a fim de fornecer recursos de validação e consistências desses dados para posterior envio as às plataformas governamentais.
Este documento visa fornecer as especificações técnicas para que os softwares de gestão possam iniciar integração com o TAF.
Modelo Operacional
O software controlador dos processos empresarias gerará uma mensagem eletrônica contendo as informações fiscais, contábeis e trabalhistas, no formato pré-definido pela TOTVS, de maneira a garantir a integridade dos dados. Esta mensagem eletrônica será então submetida a processos de integração e validação de estrutura, com o intuito de consistir integridade e conteúdo da mensagem, definindo assim se esta está apta a ser importada ao sistema consolidador.
Após receber todos os dados necessários, o TAF submete as informações importadas a outros processos como validação e consistência de layout. O objetivo final é gerar os dados para importação/transmissão dos arquivos em formato pré-definido pela Secretaria de Fazenda Estadual de jurisdição do contribuinte emitente, Prefeitura ou Receita Federal.
De forma resumida existem quatro modelos de integração disponíveis para integração:
- Integração Online:
Neste cenário o ERP envia as informações em real-time para o TAF, ou seja, no momento em que o usuário confirma a operação no ERP o TAF já é atualizado automaticamente. Este cenário somente é disponível para o produto Microsiga Protheus quando o ERP utilizar a mesma base (Dicionário de Dados/RPO) do produto TAF, ou seja, utiliza o TAF como módulo do sistema. - Integração Banco a Banco:
Neste cenário utiliza-se conexão banco-a-banco para realizar a integração das informações. Este conceito utiliza a própria ferramenta DBAcces/TopConnect. Com isso, a aplicação grava em uma tabela compartilhada e sob seu domínio, ou seja, no mesmo database, a mensagem criada por sua rotina de extração. Após gravá-lo, o TAF através de suas rotinas de monitoramento, processará as mensagens disponíveis e transportará para uma tabela de controle dentro de seu ambiente de processamento (TAF). - Integração de Arquivo físico:
Neste cenário o software de origem gera a mensagem de integração em um arquivo físico (TXT ou XML, dependendo do escopo da integração) e submete este arquivo a um processo de importação no TAF. Este processo pode ser feito manualmente ou de forma automática (agendada) no próprio TAF. Integração via Web Service
:Aviso Disponível à partir da release 12.1.17
Neste cenário utiliza-se um serviço web disponibilizado pelo TAF para envio das mensagens de integração. Neste modelo o ERP deve, através do protocolo HTTP (HTTPS), enviar a mensagem ao Web Service do TAF (que deve estar previamente configurado e no ar) utilizando um método POST, e poderá utilizar de outros métodos para consulta e monitoramento das mensagens enviadas.
Sistemas Envolvidos
Qualquer ERP( Totvs e não Totvs ) é elegível de integração com o TAF, basta desenvolver a mensagem de integração baseada no Layout Único de Integração.
Para geração do E-Social o layout de integração com o TAF é o mesmo Layout disponibilizado pela Receita Federal e pode ser encontrado na página abaixo:
Arquitetura da Integração
Visão
Layout/Mensagem de Integração
O Layout Único de Integração do TAF tem como objetivo possuir a maior quantidade de informações para a geração das mais variadas obrigações acessórias, ou seja, o Layout foi elaborado de forma lógica, garantindo que de apenas uma integração diversas obrigações possam ser geradas dentro do TAF.
Além do Layout Único de Integração existe também escopos onde o TAF utiliza o próprio Layout da obrigação disponibilizada pelo Fisco para integração com os ERP´s, como por exemplo o e-Social.
Abaixo temos uma tabela demonstrando quais escopos utilizam o Layout Único do TAF e quais utilizam o próprio Layout da Receita.
Escopo | Layout Único | Layout da Receita |
---|---|---|
Informações Fiscais ( Ex: EFD ICMS/IPI, EFD Contribuições... ) | Sim | Não |
Informações Contábeis ( Ex: ECF, Apuração IRPJ/CSLL... ) | Sim | Não |
Informações Trabalhistas ( Ex: eSocial ) | Não | Sim |
API - Interfaces de Integração
API de Integração Nativa
As API's abaixo devem ser utilizadas somente para o modelo de integração nativa (online), ou seja, onde o TAF está sendo utilizado como módulo do sistema Microsiga Protheus.
TAFAPIERP
Objetivo: Serviço utilizado para invocar de forma automática os processos de integração do TOTVS Automação Fiscal.
Modo de Uso:
Exemplo de Uso:
Parâmetros de entrada:
TAFPrepInt
Objetivo: Serviço utilizado para integração de informações no Layout do eSocial
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().
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 )
Exemplo de Uso: Inicialmente deverá ser realizado o desenvolvimento de string no formato XML, exemplo:
Bloco de código | ||
---|---|---|
| ||
cXml += '<eSocial>'
cXml += '<evtTabRubrica>'
cXml += '<infoRubrica>'
If cOper == "3"
cXml += '<inclusao>'
ElseIf cOper == "4"
cXml += '<alteracao>'
Else
cXml += '<exclusao>'
Endif
cXml += '<ideRubrica>'
cXml += '<codRubr>' + cCodRubr + '</codRubr>'
If lGeraCod
cXml += '<ideTabRubr>' + (cAliasSRV)->RV_FILIAL + '</ideTabRubr>'
Else
cXml += '<ideTabRubr>' + "" + '</ideTabRubr>'
Endif
cXml += '<iniValid>' + cAnoMes + '</iniValid>'
cXml += '<fimValid>' + "" + '</fimValid>'
cXml += '</ideRubrica>'
cXml += '<dadosRubrica>'
cXml += '<dscRubr>' + cDescRub + '</dscRubr>'
cXml += '<natRubr>' + (cAliasSRV)->RV_NATUREZ + '</natRubr>'
cXml += '<tpRubr>' + cINDTRB + '</tpRubr>'
cXml += '<codIncCP>' + (cAliasSRV)->RV_INCCP + '</codIncCP>'
cXml += '<codIncIRRF>' + (cAliasSRV)->RV_INCIRF + '</codIncIRRF>'
cXml += '<codIncFGTS>' + (cAliasSRV)->RV_INCFGTS + '</codIncFGTS>'
cXml += '<codIncSIND>' + (cAliasSRV)->RV_INCSIND + '</codIncSIND>'
cXml += '<repDSR>' + cREPDSR + '</repDSR>'
cXml += '<rep13>' + cREPDTE + '</rep13>'
cXml += '<repFerias>' + cREPFER + '</repFerias>'
cXml += '<repAviso>' + cREPREC + '</repAviso>'
cXml += '<fatorRubr>' + Alltrim(Str(nFatRub)) + '</fatorRubr>'
cXml += '<observacao>' + "" + '</observacao>'
cXml += '<ideProcessoCP>'
cXml += '<tpProc>' + (cAliasSRV)->RV_TPPROCP + '</tpProc>'
cXml += '<nrProc>' + (cAliasSRV)->RV_NRPROCP + '</nrProc>'
cXml += '<extDecisao>' + (cAliasSRV)->RV_EXPROCP + '</extDecisao>'
cXml += '</ideProcessoCP>'
cXml += '<ideProcessoIRRF>'
cXml += '<nrProc>' + (cAliasSRV)->RV_NRPIRRF + '</nrProc>'
cXml += '</ideProcessoIRRF>'
cXml += '<ideProcessoFGTS>'
cXml += '<nrProc>' + (cAliasSRV)->RV_NRPFGTS + '</nrProc>'
cXml += '</ideProcessoFGTS>'
cXml += '<ideProcessoSIND>'
cXml += '<nrProc>' + (cAliasSRV)->RV_NRPSIND + '</nrProc>'
cXml += '</ideProcessoSIND>'
cXml += '</dadosRubrica>'
If cOper == "3"
cXml += '</inclusao>'
ElseIf cOper == "4"
cXml += '</alteracao>'
Else
cXml += '</exclusao>'
Endif
cXml += '</infoRubrica>'
cXml += '</evtTabRubrica>'
cXml += '</eSocial>' |
Parâmetro de entrada:
Nome | Tipo | Descrição | Obrigatório | Referência |
---|---|---|---|---|
cEmpEnv | Caracter | Empresa do registro no ERP | X | |
cFilEnv | Caracter | Filial do registro no ERP | X | |
cXml | Caracter | String contendo o XML no formato do Layout do eSocial | X | |
cKey | Caracter | Chave do registro | X | |
cTpInteg | Caracter | Tipo da integração ( "1" = Online ; "2" = Banco-a-banco ; "3" - Chamada TAFAINTEG ) | X | |
cEvento | Caracter | Código do Evento que está sendo enviado ( Exemplo: S1010, S1020, S1030, etc.. ) | X | |
cXERPAlias | Caracter | Alias da tabela TAFXERP ( log de integração do TAF ) | ||
cTicket | Caracter | Código do Ticket ( lote ) que o registro está sendo integrado | ||
cStatQueue | Caracter | Indica se o registro será considerado na fila de integração. Informe 'F' para que seja considerado. Enviar como parâmetro para que seja retornado o status de Fila. Se mantiver 'F' é porque o registro foi processado com sucesso ou permanece na fila, se retornar 'R' é porque o erro de integração foi impeditivo para manter o registro na fila. | X |
Retorno
Nome | Tipo | Descrição |
---|---|---|
aErros | Array | Array contendo os erros encontrados no processo de integração que impediram que o registro fosse importado com sucesso na base de dados do TAF. |
TAFProcLine
Objetivo: Serviço utilizado para integração de informações no Layout Único TOTVS ( dados fiscais e contábeis )
Modo de Uso:
Exemplo de Uso:
Parâmetros de entrada:
TAFGetStatus
Objetivo: Serviço utilizado para consultar o status de determinado registro na base de dados do TAF
Modo de Uso:
Exemplo de Uso:
Parâmetros de entrada:
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âmetro | Descrição | Obrigatório? | Default |
---|---|---|---|
cEvento | Evento do eSocial a que se refere o registro | Sim | |
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 ERP | Não | cEmpAnt |
cFilEnv | Filial do registro no ERP | Não | cFilAnt |
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 )
Tendo em mente a tabela acima vamos detalhar agora os modelos de integração existentes:
Integração Online:Neste modelo de integração o ERP irá utilizar uma API disponibilizada pelo TAF que será a responsável por ler o conteúdo da mensagem enviada, interpretar e gravar as informações no banco de dados retornando ao ERP caso ocorra algum problema, todas as funções disponíveis para a integração Online estão disponíveis no tópico "API de Integração Nativa".
Neste modelo de integração o ERP irá gravar a mensagem de integração em uma tabela compartilhada do seu banco de dados e o TAF irá realizar a leitura dessa informações para integração, conforme abaixo:
I. Conhecendo a tabela compartilhada:
A tabela compartilhada é criada após a execução da Wizard Inicial do TAF( Sempre executada no primeiro acesso ao TAF ), no banco do ERP seu nome será TAFST1, e ela possui os seguintes campos:
- TAFFIL (Caracter): Código da Empresa/Filial do ERP, o código informado nesse campo depois será amarrado a filial do TAF que receberá as informações na integração;
- TAFCODMSG (Caracter): Informa o tipo da mensagem que será gravada na linha, podendo ser 1 para arquivo texto ou 2 para XML;
- TAFSEQ (Caracter): Quando a mensagem enviada superar 1MB, deve ser quebrada em duas linhas na tabela, nesse cenário esse campo deve ser incrementado com um sequencializador, iniciando em '001';
- TAFTPREG (Caracter): Nome do Layout que será integrado, podendo ser tanto do Layout Totvs quando o nome do próprio registro de acordo com o Layout da Receita Federal
- TAFKEY (Caracter): Chave do registro, a ser gerada de acordo com regra gerada pelo ERP para posterior recuperação da informação;
- TAFMSG (Caracter): Mensagem a ser enviada para o TAF
- TAFSTATUS (Caracter): Status do registro na tabela, sempre que gravado pelo ERP deve ser gravado como "1", o TAF seta para "2" quando o registro já foi integrado;
- TAFTICKET (Caracter): Código de identificação do lote da integração. É opcional, e caso o ERP não informe o TAF gera um código aleatório no formato UUID.
- TAFDATA (Caracter): Data para identificação do lote da integração. É opcional, e caso o ERP não informe o TAF gera automaticamente.
- TAFHORA (Caracter): Hora para identificação do lote da integração. É opcional, e caso o ERP não informe o TAF gera automaticamente.
Os demais campos são de controle do TAF
- TAFPRIORIT (Caracter): Prioridade de processamento do registro. Mais detalhes no toóico "Recursos de integração".
- TAFSTQUEUE (Caracter): Status do registro na fila de processamento. Mais detalhes no toóico "Recursos de integração".
- R_E_C_N_O_ (Numérico): Campo de controle interno ( TOTVS|DbAccess )
- R_E_C_D_E_L_ (Numérico): Campo de controle interno ( TOTVS|DbAccess )
- D_E_L_E_T_ (Numérico): Campo de controle interno ( TOTVS|DbAccess )
II. Exemplo da tabela TAFST1 populada:
Regra de Execução da Integração para integrações que não utilizam o Layout Totvs
Quando é enviado para o TAF um XML do eSocial, por exemplo, o mesmo é submetido a uma regra que define se a operação será realizada ou não dentro do TAF, sempre que o retorno for negativo a Origem receberá um retorno com o erro, seja via gerenciador de integração ( Integração Banco a Banco ) ou um array com os erros encontrados ( Integração OnLine )
Acesse a página abaixo para mais detalhes do comportamento da integração para o E-Social:
Comportamento da Integração TAF - eSocial
Regra de Execução da Integração para integrações que utilizam o Layout Totvs
Nessa integração o TAF sempre verifica o campo TAFKEY, caso seja uma TAFKEY já enviada previamente o TAF realiza o Replace do cadastro no TAF, caso contrário realiza a inclusão da informação.
sempre que ocorrer algum problema na integração a Origem receberá um retorno com o erro, seja via gerenciador de integração ( Integração Banco a Banco ) ou um array com os erros encontrados ( Integração OnLine )
Processos automáticos de integração do TAF
Quando utilizada a integração banco a banco o TAF possui alguns JOB´s de processamento automático para realizar o processo de carga dos dados, sendo eles:
TAFAINTG0:
Descrição: Busca as informações na ST1 no ERP e integra para a ST2 (TAF). Alterando o flag desses registros na ST1 (STATUS=2 - Integrados).
TAFAINTG2:
Descrição: Realiza a integração da TAFST2 para as tabelas internas do TAF. Integra as informações mesmo com inconsistências alimentando o gerenciador de integração
TAFAINTG3:
Descrição: Rotina que varre a base de dados procurando as inconsistências para apresentá-las no monitor de integrações.
Para maiores informações de como realizar a configuração dos Jobs de Integração acesse o lonk abaixo:
API de Integração
Sistema Protheus (Online):
Outros Sistemas:
Particularidade de Integração do eSocial
Múltiplas Rúbricas
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.
1. Objetivo:
Este documento tem como objetivo demonstrar os resultados que devem ser alcançados nos cenários possíveis de manutenção com relação aos eventos do E-Social no TAF, é fundamental e obrigatório que os requisitos entregues estejam respeitando todos os cenários abaixo tanto no modelo de integração quanto manual.
2. Tabela de Resumo das operações:
Novo Registro | Evento Corrente: Incluído | Evento Corrente: Alterado | Evento Corrente: Excluído | Situação Corrente: Transmitido | Situação Corrente: Não Transmitido | |
---|---|---|---|---|---|---|
Inclusão | Executa | Operação não realizada | Operação não realizada | Analisar duas próximas colunas | Executa | Operação não realizada |
Alteração | Operação não realizada | Executa | Executa | Analisar duas próximas colunas | Operação não realizada | Executa |
Exclusão | Operação não realizada | Executa | Executa | Operação não realizada |
***Seguindo com o documento temos maiores detalhes sobre cada uma das operações citadas na tabela acima***
3. Realizando uma nova inclusão no TAF:
Registro não existe no TAF:- Deve ser realizada a inclusão do registro;
Situação do Registro igual a "I" (Incluído):
- Não deve ser realizada a integração e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
Situação do Registro igual a "A" (Alterado):
- Não deve ser realizada a integração e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF";
Estrutura da Tabela Compartilhada
A tabela compartilhada é criada após a execução da Wizard Inicial do TAF( Sempre executada no primeiro acesso ao TAF ), no banco do ERP seu nome será TAFST1, e ela possui os seguintes campos:
TAFFIL (Caracter): Código da Empresa/Filial do ERP, o código informado nesse campo depois será amarrado a filial do TAF que receberá as informações na integração;
TAFCODMSG (Caracter): Informa o tipo da mensagem que será gravada na linha, podendo ser 1 para arquivo texto ou 2 para XML;
TAFSEQ (Caracter): Quando a mensagem enviada superar 1MB, deve ser quebrada em duas linhas na tabela, nesse cenário esse campo deve ser incrementado com um sequencializador, iniciando em '001';
TAFTPREG (Caracter): Nome do Layout que será integrado, podendo ser tanto do Layout Totvs quando o nome do próprio registro de acordo com o Layout da Receita Federal
TAFKEY (Caracter): Chave do registro, a ser gerada de acordo com regra gerada pelo ERP para posterior recuperação da informação;
TAFMSG (Caracter): Mensagem a ser enviada para o TAF
TAFSTATUS (Caracter): Status do registro na tabela, sempre que gravado pelo ERP deve ser gravado como "1", o TAF seta para "2" quando o registro já foi integrado;
TAFTICKET (Caracter): Código de identificação do lote da integração. É opcional, e caso o ERP não informe o TAF gera um código aleatório no formato UUID.
TAFDATA (Caracter): Data para identificação do lote da integração. É opcional, e caso o ERP não informe o TAF gera automaticamente.
TAFHORA (Caracter): Hora para identificação do lote da integração. É opcional, e caso o ERP não informe o TAF gera automaticamente.
TAFOWNER (Caracter): Identificação do ERP dono do XML a ser integrado. É Opcional.
Os demais campos são de controle do TAF, na tabela TAFST2:
TAFPRIORIT (Caracter): Prioridade de processamento do registro. Mais detalhes no tópico "Recursos de integração".
TAFSTQUEUE (Caracter): Status do registro na fila de processamento. Mais detalhes no tópico "Recursos de integração".
R_E_C_N_O_ (Numérico): Campo de controle interno ( TOTVS|DbAccess )
R_E_C_D_E_L_ (Numérico): Campo de controle interno ( TOTVS|DbAccess )
D_E_L_E_T_ (Numérico): Campo de controle interno ( TOTVS|DbAccess )
Exemplo da tabela TAFST1 populada:
API - Interfaces de Integração
API de Integração - Microsiga Protheus
Informações | ||
---|---|---|
| ||
As API's abaixo devem ser utilizadas somente para o modelo de integração nativa (online), ou seja, onde o TAF está sendo utilizado como módulo do sistema Microsiga Protheus. |
API | Descrição | Documentação |
---|---|---|
TAFAPIERP | Serviço utilizado para invocar de forma automática os processos de integração do TOTVS Automação Fiscal. | Acesse TAFAPIERP |
TAFPrepInt | Serviço utilizado para integração de informações no Layout do eSocial. | Acesse TAFPrepInt. |
TAFProcLine | Serviço que recebe a mensagem que deve ser integrada ao TAF e realiza a cargas das tabelas de acordo com o Layout TOTVS. | Acesse TAFProcLine |
TAFGetStat | Serviço utilizado para consultar o status de determinado registro na base de dados do TAF | Acesse TAFGetStat |
TAFDelTicket | Serviço para excluir Tickets de integração com o TAF. | Acesse TAFDelTicket |
API de Integração - Outros Sistemas
API | Descrição | Documentação |
---|---|---|
WSTAFST2 | Serviço que integra os produtos na tabela compartilhada TAFST2, permite a consulta do status de integração e cadastro dos registros através do TAFKEY ou TAFTICKET, e permite a exclusão dos registros através do TAFTICKET. | Acesse Web Service REST - Integração |
WSTAFQueryElements | Serviço que permite que uma aplicação faça uma consulta generalizada na base de dados do TOTVS Automação Fiscal para obter uma série de registros/elementos através de um status pré-definido pela aplicação (de acordo com os status existentes no TAF) ou do tipo do registro (de acordo com os tipos existentes no TAF) | Acesse Web Service REST - Consulta de Elementos |
WSTAFGetXML | Serviço que permite que uma aplicação requisite ao TAF que retorne um ou mais dados dentro de uma estrutura XML, a mesma que foi (ou que será) enviada ao Governo. Caso o evento ainda não tenha sido transmitido ao Governo, será retornado o XML gerado pelo próprio TAF. Caso o evento já tenha sido transmitido e autorizado pelo Governo, será retornado o XML final (inclusive com a assinatura do TSS). | Acesse Web Service REST - Retorno de XML |
Regra de Execução da Integração para integrações que não utilizam o Layout Totvs
Quando é enviado para o TAF um XML do eSocial, por exemplo, o mesmo é submetido a uma regra que define se a operação será realizada ou não dentro do TAF, sempre que o retorno for negativo a Origem receberá um retorno com o erro, seja via gerenciador de integração ( Integração Banco a Banco ) ou um array com os erros encontrados ( Integração OnLine )
Regra de Execução da Integração para integrações que utilizam o Layout Totvs
Nessa integração o TAF sempre verifica o campo TAFKEY, caso seja uma TAFKEY já enviada previamente o TAF realiza o Replace do cadastro no TAF, caso contrário realiza a inclusão da informação.
sempre que ocorrer algum problema na integração a Origem receberá um retorno com o erro, seja via gerenciador de integração ( Integração Banco a Banco ) ou um array com os erros encontrados ( Integração OnLine )
Processos automáticos de integração e transmissão do TAF
Tabela de processos de integração e modelos operacionais aplicáveis:
Processo | Descrição | Integração Online | Banco a banco | Arquivo físico | Web Service |
---|---|---|---|---|---|
TAFProc0 | Cópia de dados da tabela TAFST1 para TAFST2 | N/A | Manual/Automático | N/A | N/A |
TAFProc1 | Limpeza da tabela TAFST1 | N/A | Manual/Automático | N/A | N/A |
TAFProc2 | Integração de dados para tabelas de negócio (base oficial) | Automático | Manual/Automático | Manual/Automático | Manual/Automático |
TAFProc3 | Validação e consistência de Layout | Manual/Automático | Manual/Automático | Manual/Automático | Manual/Automático |
TAFProc4 | Transmissão de Eventos para o TSS | Manual/Automático | Manual/Automático | Manual/Automático | Manual/Automático |
TAFProc5 | Consulta de Eventos ao TSS | Manual/Automático | Manual/Automático | Manual/Automático | Manual/Automático |
TAFProc6 | Importação de arquivo físico | N/A | Manual/Automático | Manual/Automático | N/A |
Para maiores informações de como realizar a configuração dos Jobs de Integração acesse o lonk abaixo:
Particularidade de Integração do eSocial
Comportamento das Integrações x Operação dos Eventos
Objetivo
Esta tabela tem como objetivo demonstrar os resultados que devem ser alcançados nos cenários possíveis de manutenção com relação aos eventos do eSocial no TAF.
Novo Registro | Evento Corrente: Incluído | Evento Corrente: Alterado | Evento Corrente: Excluído | Situação Corrente: Transmitido | Situação Corrente: Não Transmitido | |
---|---|---|---|---|---|---|
Inclusão | Executa | Operação não realizada | Operação não realizada | Analisar duas próximas colunas | Executa | Operação não realizada |
Alteração | Operação não realizada | Executa | Executa | Analisar duas próximas colunas | Operação não realizada | Executa |
Exclusão | Operação não realizada | Executa | Executa | Operação não realizada |
Dica | ||
---|---|---|
| ||
A lista abaixo traz mais detalhes sobre cada operação realizada na integração de eventos, conforme tabela acima. |
1. Realizando uma nova inclusão no TAF:
Registro não existe no TAF:
- Deve ser realizada a inclusão do registro;Situação do Registro igual a "I" (Incluído):
- Não deve ser realizada a integração, e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
Situação do Registro igual a "A" (Alterado):
- Não deve ser realizada a integração, e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF";
Situação do Registro igual a "E" (Excluído):
Registro já Transmitido ao RET:
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração"deste documento.
Registro não transmitido ao RET:
- Não deve ser realizada a integração, e no gerenciador deve aparecer a mensagem:"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
2. Realizando uma nova alteração no TAF:
Registro não existe no TAF:
- Não deve ser realizada a integração, e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
Situação do Registro igual a "I" (Incluído):
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração" deste documento.
Situação do Registro igual a "A" (Alterado):
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração" deste documento.Situação do Registro igual a "E" (Excluído):
Registro já Transmitido ao RET:- Não deve ser realizada a integração, e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
Registro não transmitido ao RET:
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração" deste documento.
3. Realizando uma nova exclusão no TAF:
Registro não existe no TAF:
- Não deve ser realizada a integração e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
Situação do Registro igual a "I" (Incluído):
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração" deste documento.
Situação do Registro igual a "A" (Alterado):
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração" deste documento.Situação do Registro igual a "E" (Excluído):
Registro já Transmitido ao RET:- Não deve ser realizada a integração, e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
Registro não transmitido ao RET:
- Não deve ser realizada a integração e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
4. Regras Gerais de Integração:
Quando o registro já existente no TAF não foi transmitido ao RET, ou seja, seu campo de Status é diferente de 2 ( Aguardando Retorno do Governo ), e 4 ( Autorizado pelo Governo ), a operação deve ser realizada normalmente na base de dados, caso já tenha sido enviado deve ser realizada a operação seguindo as regras abaixo:
Dica |
---|
Duplicar o registro, mantendo o atual e gerando uma nova linha na tabela com as regras abaixo |
Último Recibo ( _PROTUL ) = O novo registro gerado deve ter esse campo vazio.
Penúltimo Recibo ( _PROTPN ) = O novo registro deve ter nesse campo o valor do recibo do registro anterior com a mesma chave.
Versão ( _VERSAO ) = O novo registro deve ter uma nova versão.
Versão Anterior ( _VERANT ) = O novo registro deve ter o valor da versão do registro anterior com a mesma chave.
Evento ( _EVENTO ) = O novo registro deve ter a operação que foi realizada.
Ativo ( _ATIVO ) = O novo registro deve ter a situação igual a 1 ( Ativo ) e setar o registro anterior com a mesma chave para 2 ( Inativo ).
Nota | ||
---|---|---|
| ||
Para a integração de arquivos de alteração, com relação ao comportamento da tag <indRetif>, quando um evento exista no TAF e ainda não foi transmitido, ao enviar um evento com a mesma chave (ex.: S-2206 com a mesma data de alteração), o conteúdo da tag <indRetif> é 2, se for uma data diferente o conteúdo da tag <indRetif> é 1, a exceção são os eventos S-1200/S-1210 por conta da aglutinação (MV). |
5. Complemento de dados ( integração multi ERP )
O TAF permite que diversos sistemas de origem realizem a integração de dados ao TAF, complementando informações de determinado evento na base de dados, inclusive quando se tratar do mesmo registro.
Exemplo: No cadastro de funcionário, um sistema X deseja incluir informações cadastrais, e outro sistema Y deseja incluir informações do vínculo do empregado com o empregador. Neste caso, o sistema X deve enviar somente os campos (tags) relacionados ao conteúdo que deseja integrar ao TAF, e o sistema Y devem enviar somente os campos (tags) das informações do vínculo. Automaticamente os dados se complementam e tornam o registro na base de dados do TAF elegível para transmissão ao Governo.
Nota | ||
---|---|---|
| ||
Esse comportamento é aplicado diante de algumas regras:
|
6. Exclusão de Eventos (S-3000)
O TAF permite três modelos de integração para evento S-3000 do eSocial:
1 - Enviar o recibo do Evento na tag <nrRecEvt>
Caso o ERP possua em mãos o recibo do Evento, pode enviar ao TAF a exclusão através deste recibo.
2 - Enviar a chave do Evento na tag <nrRecEvt>
Quando a informação enviada dentro da tag <nrRecEvt> for a chave do registro ( e não o recibo ), deve existir o atributo tpOper onde deve ser informado o tipo de operação utilizado na exclusão do evento.
Opções:
U - Excluí o ultimo registro ( Apenas o Ativo )
Neste caso será excluído apenas o último registro ativo de acordo com a chave enviada.
T - Exclui todo o Histórico do Evento
Neste caso serão excluídos todos os registros relacionados a chave enviada, independente do status.
Exemplo:
<nrRecEvt tpOper = “U”> Chave_do_evento </nrRecEvt>
3 - Enviar o TAFKEY do Evento na tag <nrRecEvt>
Basta enviar nesta tag o TAFKEY enviado na integração deste registro com o TAF.
Todas as opções são voltadas ao preenchimento da tag <nrRecEvt>. Todas as demais tags do evento devem ser preenchidas normalmente conforme Layout do eSocial.
Múltiplas Rúbricas
Objetivo
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.
Fila de Integração
Objetivo
Facilitar o gerenciamento de integração de Eventos para o software de origem dos dados, tornando o TAF responsável pelo armazenamento e reprocessamento de eventos.
Funcionamento
De forma geral, o comportamento do TAF na integração de registros onde os eventos predecessores estão pendente de uma resposta do Governo, é rejeitá-los, garantindo assim a integridade dos dados dentro da base de dados.
Contudo, para facilitar o gerenciamento destes eventos, o TAF permite ao ERP que envie esses eventos com a propriedade de Eventos de Fila. Desta forma, o TAF fica responsável por manter este evento em uma fila de integração, realizando tentativas de integração até que o evento predecessor tenha uma resposta definitiva do endpoint do Governo.
Informações | ||
---|---|---|
| ||
Acesse Web Service REST - Integração e obtenha mais detalhes sobre a configuração da Fila de Integração no Serviço de Integração do TAF. |
Na prática, enquanto o evento predecessor estiver com status "Aguardando retorno", todas as tentativas de integração do registro geram um log e mantém este registro na fila de integração. Ao receber uma resposta do Governo, existem duas possibilidades:
- O Governo rejeita o evento predecessor: Neste caso o registro que está na fila de integração também é rejeitado pelo TAF para o ERP, e é removido da fila de integração;
- O Governo autoriza o evento predecessor: Neste caso o registro que está na fila de integração é removido da fila de integração, e há uma tentativa de integração no TAF. Ele pode ser aceito ou rejeitado, dependendo de sua estrutura.
Exemplo: Existe na base de dados do TAF um registro de admissão ( S-2200 ) do funcionário A pendente de retorno do Governo. Neste momento, o ERP envia ao TAF um registro de Alteração Cadastral ( S-2205 ) do mesmo funcionário A. O evento S-2205 é colocado na fila de integração até que o evento S-2200 tenha uma resposta, e quando houver esse retorno por parte do Governo, o evento S-2205 entrará em um dos dois casos acima.
Imagem do Monitor de Integração ao tentar realizar diversas importação de um evento S-2205, que está aguardando uma resposta de evento predecessor S-2200.
Registros de log gerados pela Fila de Integração, onde após 3 tentativas de integração o evento predecessor foi rejeitado pelo Governo.
Situação do Registro igual a "E" (Excluído):
Registro já Transmitido ao RET:
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração"
deste documento.
Registro não transmitido ao RET:
- Não deve ser realizada a integração e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
4. Realizando uma nova alteração no TAF:
Registro não existe no TAF:- Não deve ser realizada a integração e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
Situação do Registro igual a "I" (Incluído):
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração" deste documento.
Situação do Registro igual a "A" (Alterado):
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração" deste documento.
Situação do Registro igual a "E" (Excluído):
Registro já Transmitido ao RET:
- Não deve ser realizada a integração e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
Registro não transmitido ao RET:
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração" deste documento.
5. Realizando uma nova exclusão no TAF:
Registro não existe no TAF:- Não deve ser realizada a integração e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
Situação do Registro igual a "I" (Incluído):
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração" deste documento.
Situação do Registro igual a "A" (Alterado):
- Deve ser realizada a operação seguindo os conceitos citados em "Regras Gerais de Integração" deste documento.
Situação do Registro igual a "E" (Excluído):
Registro já Transmitido ao RET:
- Não deve ser realizada a integração e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
Registro não transmitido ao RET:
- Não deve ser realizada a integração e no gerenciador deve aparecer a mensagem:
"A operação solicitada no XML está em desacordo com o cenário do registro na base do TAF"
6. Regras Gerais de Integração:
Quando o registro já existente no TAF não foi transmitido ao RET, ou seja, seu campo de Status é diferente de 2,3 e 4 a operação
deve ser realizada normalmente na base de dados, caso já tenha sido enviado deve ser realizada a operação seguindo as regras
abaixo:
**Duplicar o registro, mantendo o atual e gerando uma nova linha na tabela com as seguintes regras:**
Protocolo = O novo registro gerado deve ter esse campo vazio
Penúltimo Protocolo = O novo registro deve ter nesse campo o valor do protocolo do registro anterior com a mesma chave
Versão = O novo registro deve ter uma nova versão
Versão Anterior = O novo registro deve ter o valor da versão do registro anterior com a mesma chave
Evento = O novo registro deve ter a operação que foi realizada
Ativo = O novo registro deve ter a situação igual a 1 ( Ativo ) e setar o registro anterior com a mesma chave para 2 ( Inativo ).