Histórico da Página

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 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:

1. 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.
   
   
2. 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).
   
   
3. 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.
   
   
4. Integração via Web Service:
   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:

Layout Taf - eSocial

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.

API - Interfaces de Integração

API de Integração

- Microsiga Protheus

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

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

Tendo em mente a tabela acima vamos detalhar agora os modelos de integração existentes:

API de Integração - Outros Sistemas

Estrutura da Tabela Compartilhada

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:

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, na tabela TAFST2:

TAFPRIORIT (Caracter): Prioridade de processamento do registro. Mais detalhes no

toóico

tópico "Recursos de integração".

TAFSTQUEUE (Caracter): Status do registro na fila de processamento. Mais detalhes no

toóico

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 )

II.

Exemplo da tabela TAFST1 populada:

Image Modified

 

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:

06. Efetue uma integração

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:

***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";
    
    
  • 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 ).