Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Introdução

O TAF - TOTVS Automação Fiscal - é uma ferramenta desenvolvida por diversas áreas de desenvolvimento da TOTVS, processo conhecido como Descentralização.

Por este motivo, vê-se a necessidade de criar um manual de desenvolvimento visando padronizar as particularidades de desenvolvimento nesta ferramenta nos processos corporativos ( Manutenção, Inovação e Expedição ).

Objetivo

Este documento visa apoiar e dar base para os analistas que atuarão diretamente com os processos de desenvolvimento, seja inovação ou manutenção, na ferramenta TAF, bem como detalhar as etapas dentro de cada processo permitindo a padronização e qualidade na entrega das funcionalidades do módulo.

Premissas

A utilização deste documento e atuação no desenvolvimento do produto tem como premissa:

  • Conhecimento básico em programação na linguagem ADVPL
  • Conhecimento básico na estrutura da plataforma Microsiga Protheus: Metadados, TOTVS|AppServer, TOTVS|SmartClient, TOTVS|DbAccess, APSDU e Framework
  • Conhecimento básico em programação ADVPL utilizando MVC
  • Conhecimentos básicos em conceitos fiscais
  • Conhecimento básico em análise de Layouts

 

Versão atual
1.1
VersãoAlterações realizadas
1.0Inclusão do documento
1.1

Alteração nas etapas de Manutenção e Inovação onde envolve dicionário de dados.

- Novos projetos de inovação na versão 11 deverão ter as alterações de dicionário realizadas diretamente no programa de update - UPDTAF;

- Foram criados dois novos pacotes abaixo do Projeto TAF Segregado com o objetivo de controlar as entregas/incorporações por versão;

- Foi criado no TFS uma lista de pacotes de dicionário do TAF, visando a gestão de incorporações.

Índice

Índice

 

 

 

1. Conceitos do TOTVS Automação Fiscal

1.1. Modelos de Distribuição

Pode ser distribuído como módulo do sistema Microsiga Protheus ou como aplicação segregada ao ERP.

 

1.2. Arquitetura

1.2.1. Linguagem

O TAF utiliza a linguagem ADVPL e a base de dados é voltada a banco de dados relacional.

1.2.2. Estrutura

Utiliza o mesmo conceito da arquitetura Protheus ( visite TOTVS | Platform TOTVSTEC )

1.2.3. Metadados

Utiliza o conceito de metadados em sua arquitetura ( visite Dicionário de Dados )

1.2.4. Tabelas Autocontidas

São as tabelas informadas e pré-preenchidas pelo Governo. No TAF essas tabelas são carregadas automaticamente e podem ser utilizadas nos cadastros e movimentos do sistema. Exemplo: Países, Municípios, CFOP, etc...

1.2.5. Layout TOTVS

Possui um layout único de integração que 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.

Visite Layout Único Atual

1.2.6. Integração

Existem dois modelos de integração disponíveis para integração com o TAF, a integração Online e a integração Banco a Banco, conforme abaixo:

  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 quando o ERP utilizar a mesma base (Dicionário de Dados/RPO) do produto TAF. 

  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, o XML criado por sua rotina de integração. Após gravá-lo, o TAF através de suas rotinas de monitoramento, processará os XMLs disponíveis e transportará para uma tabela de controle dentro de seu ambiente de processamento (TAF).

Visite Manual de Integração do TAF - Para o ERP(Origem)

1.2.7 Normalização de Dados

"A normalização de dados é uma série de passos que se seguem no projeto de um banco de dados, que permitem um armazenamento consistente e um eficiente acesso aos dados em bancos de dados relacionais. Esses passos reduzem a redundância de dados e as chances dos dados se tornarem inconsistentes."

O TAF utiliza este conceito na construção de suas funcionalidades. Abaixo uma ilustração de como deve ser construída uma relação de entidades nos cadastros do TAF.

1.2.7.1. Criação de Sequencializadores:

Todas as tabelas do TAF possuem uma tupla chamada de "ID" que tem como objetivo ser a identificação única da informação na tabela, se trata de um campo com valor auto-incremental. Para realizar a configuração do sequencializador temos duas formas, conforme abaixo:

I. Função GetSx8Num:

Utilizando essa função os valores gerados são sequenciais por tabela, por exemplo "1,2,3,4...", foi muito utilizado para os primeiros cadastros do TAF, hoje somente deve ser utilizada para manutenção nos cadastros que já a utilizam.

II. Função TafGeraId:

Utilizando essa função os valores gerados são em hexadecimal, ou seja, não seguem uma sequência crescente lógica como no modelo anterior, essa função é a que deve ser utilizada para o desenvolvimento de novos cadastros no TAF, ela garante que os códigos não sejam repetidos e é muito mais performática do que a função anterior GetSx8Num.

Futuramente iremos realizar a migração de todos os cadastros que utilizam a função GetSx8Num para a TafGeraId, é possível encontrar exemplos de utilização de ambas funções nos cadastros já existentes do TAF.

1.2.7.2. Relação e hierarquia de entidades

No exemplo abaixo será ilustrado a relação entre as tabelas Cabeçalho de Documento Fiscal, Item de Documento Fiscal e Tributo do Item do Documento Fiscal, demonstrando como devem ser construídas essas relações no banco de dados/metadados.

 

1.2.7.3. Relação de chave estrangeira

No exemplo abaixo será ilustrado a relação entre as tabelas Cabeçalho de Documento Fiscal e Modelo de Documento Fiscal, demonstrando como devem ser construídas essas relações no banco de dados/metadados.

 

Na interface do cadastro, o resultado é:

 

1.3. Recursos de Desenvolvimento

1.3.1. Ferramenta TDS ( TOTVS Development Studio )

  • Ambiente de desenvolvimento

1.3.2. Ferramenta ATUSX

  • Gerenciamento de metadados padrão
  • Manutenção do Dicionário de dados
  • Gerenciamento dos projetos e pacotes de dicionário de dados
  • Compilação de pacotes de requisitos ( inovação )

O Projeto TAF SEGREGADO está separado dos projetos de dicionário de dados do Protheus padrão. O objetivo é manter sempre um dicionário segregado visando o modelo de distribuição de aplicação autônoma.

O dicionário do TAF também está no dicionário padrão do Protheus. O objetivo é manter o dicionário do TAF no padrão para atender ao modelo de distribuição como módulo do ERP.

 

O dicionário poderá ser alterado através de um requisito ( processo de inovação ) ou através de um chamado ( processo de manutenção ). Veja mais abaixo ( itens 2 e 3 deste manual ) como deve ser feita a manutenção de acordo com o seu processo de desenvolvimento e versão do produto ( versão 11 ou 12 ).

Os ajustes de dicionário realizados no ATUSX serão efetivados através do update oficial UPDDISTR ( visite Atualizador de dicionário e base de dados - UPDDISTR )


*Detalhes sobre as regras do UPDDISTR:

1.3.3. Ferramenta TFS

  • Ambiente de versionamento e gerenciamento dos fontes
  • O TAF utiliza diretórios do Protheus Padrão ( $/Protheus_Padrao ) e também possui um diretório específico ( $/TAF ) para outros controles.

 

1.3.3. Ferramenta TDN

  • Ambiente de documentação do produto e processos

Alterando o Layout TOTVS no TDN:

Publicações conforme demanda de alterações e visualização em real-time para adaptação dos extratores. Pode ser demandado por Requisitos ( Inovação ) e Chamados ( Manutenção ).

 

 Será disponibilizada uma nova versão de Layout a cada expedição de novo Release TOTVS. Exemplo:

    • Release 12.1.4  Disponibilizado Layout TAF 2.5
    • Release 12.1. Disponibilizado Layout TAF 2.6
    • Release 12.1.6  Disponibilizado Layout TAF 2.7

 

 

Modelo utilizado para atualização da tabela de alterações do Layout TAF ( esboço ): A página de alterações possuirá uma tabela para inclusão de todas as alterações realizadas no Layout durante o desenvolvimento do Release Incremental.

Cada inclusão possuirá um LINK a outra página com maiores detalhes sobre aquela alteração.

 

Página com detalhes da alteração ( esboço ): No fechamento do Release Incremental, faremos um “compilado” de todas as alterações para gerar a nova versão do layout TAF.

A página de “Alterações” e as páginas “Alteração XYZ” serão de acesso interno de usuários pré-selecionados. A página “pai” da versão ( exemplo “Versão 2.5” ) será publicada com o arquivo .xls para acesso comum à planilha do Layout TAF.

 

2. Inovação

Este tópico tem como objetivo detalhar a as particularidades do TAF no processo de inovação.

2.1. Tenho um requisito do TAF que devo desenvolver na versão 11

Durante o ciclo de construção, os requisitos de Inovação ( JIRA ) serão desenvolvidos e homologados na branch de Inovação.



Fontes: Deverá ser utilizada a branch de Inovação do TAF - versão11: $/TAF/Inovação, de acordo com o release de entrega, exemplo: 11.80.13, 11.80.14, etc...


 

Dicionário de Dados: Para alteração do dicionário de dados, deverá seguir os passos abaixo:

 

As etapas ao lado deverão ser seguidas apenas para os seguintes projetos:

- Inovações realizadas até o release 11.80.15;

- eSocial Layout 2.1 - expedição 11.80.17;

- Automatização do Lalur/Lacs e Apuração IRPJ/CSLL - expedição 11.80.20.

 
  • As alterações de dicionário deverão ser realizadas no ATUSX ( em pacote individual por requisito ) e incorporados no final do release de expedição do TAF ( de acordo com o calendário de expedição da versão 11 );
  • Os pacotes do ATUSX sempre devem ser criados abaixo do Projeto do Release de entrega da versão 12, ou seja, deve-se planejar a homologação do requisito/chamado de réplica da versão 12 assim que iniciar o desenvolvimento da versão 11. O objetivo é realizar as alterações de dicionário uma única vez, garantindo a integridade do TAF em ambas as versões.
  • Assim que o chamado/requisito for homologado na versão 11, deve ser solicitado ao GCAD que faça a incorporação no pacote TAF Segregado - Versão 11;

    (aviso) Atenção! Durante a homologação do requisito na versão 11, a aprovação do dicionário de dados no ATUSX NÃO deve ser feita através da rotina de "Aprovação SQA", pois isso fará com que o pacote seja incorporado na versão 12!

    (aviso) Atenção! Não se esqueça de incluir o pacote criado para o seu requisito na lista de pacotes do TAF ( $/TAF/Documentos/Gestão de Pacotes - ATUSX/Lista de Pacotes e Incorporações - Dicionário TAF.xlsx ) 

A incorporação dos pacotes dos referidos projetos ( à esquerda ) deverá ser realizado no Pacote TAF SEGREGADO - VERSÃO 11, devido ao congelamento do PROJETO TAF SEGREGADO.

Exemplo:

Image RemovedImage Added

As etapas abaixo deverão ser seguidas para os demais projetos de inovação desenvolvidos na versão 11

 As alterações de dicionário deverão ser realizadas via update - UPDTAF.

 

(aviso) Atenção! Sempre valide as funcionalidades desenvolvidas através do tópico 5.Detalhes de Codificação


2.1. Tenho um requisito do TAF que devo desenvolver na versão 12

Durante o ciclo de construção, os requisitos de Inovação ( JIRA ) serão desenvolvidos e homologados na branch de Inovação.
Fontes: Branch de Inovação do TAF - versão 12 ( release incremental ): $/Protheus_Padrao/Fontes_Doc/Inovação/V12


Dicionário de Dados: Para alteração do dicionário de dados, deverá seguir os passos abaixo:
    • As alterações de dicionário deverão ser realizadas no ATUSX ( em pacote individual por requisito ) e incorporados no final do release de expedição do TAF ( de acordo com o calendário de expedição da versão 12 );
    • Assim que o chamado/requisito for homologado na versão 12, este será incorporado ao Release “pai” para expedição;
    • Assim que o chamado/requisito for homologado na versão 12, deve ser solicitado ao GCAD que faça a incorporação no pacote TAF Segregado - Versão 12;
    • Os requisitos/chamados da versão 12 devem obedecer o Calendário do Release Incremental.

      (aviso) Atenção!  O pacote somente será incorporado ao dicionário padrão quando utilizada a rotina Aprovação SQA no ATUSX.

      (aviso)Image Modified Atenção!
       Não se esqueça de incluir o pacote criado para o seu requisito na lista de pacotes do TAF ( $/TAF/Documentos/Gestão de Pacotes - ATUSX/Lista de Pacotes e Incorporações - Dicionário TAF.xlsx )Após a homologação, além da incorporação no dicionário padrão, o pacote também deve ser incorporado no PACOTE TAF SEGREGADO - VERSÃO 12. 

      Image Added

(aviso) Atenção! Sempre valide as funcionalidades desenvolvidas através do tópico 5.Detalhes de Codificação

3. Manutenção

Este tópico tem como objetivo detalhar a as particularidades do TAF no processo de inovação.

 

3.1. Tenho um chamado do TAF que devo desenvolver na versão 11

Durante o ciclo de construção, os chamados de Manutenção ( SSIM ) serão desenvolvidos e homologados na branch de Manutenção ou de Inovação.

  • O chamado a ser desenvolvido não possui alteração no modelo de dados

    Deverá apenas realizar a alteração no código fonte de acordo com a versão/release da correção.

    Fontes: Deverá ser utilizada a branch de Manutenção do Protheus_Padrao ( pasta do TAF ) - versão11: $/Protheus_Padrao/Fontes_Doc/Sustentação/V11/V118/Fontes/TAF

  • O chamado a ser desenvolvido possui alteração no modelo de dados
Neste caso, deverá ser avaliado a categoria do chamado e a criticidade do mesmo:

 

Criticidade X

Categoria

BaixaMediaAltaCrítica
Não conformidade ( CAT001 e similares )Ação 2Ação 2Ação 2Ação 2
Legislações ( CAT017 e similares )Ação 2Ação 2Ação 2Ação 2
Melhorias ( CAT014 )Ação 3Ação 3Ação 3Ação 3

 

 

Ação 1

A partir do release 11.80.16 esta opção não será mais utilizada, visando disponibilizar todos os ajustes de dicionário ( do processo de manutenção ) através do update ( UPDTAF ).

Fontes: Deverá ser utilizada a branch de Manutenção do Protheus_Padrao ( pasta do TAF ) - versão11: $/Protheus_Padrao/Fontes_Doc/Sustentação/V11/V118/Fontes/TAF

Dicionário de Dados: Verificar se a alteração de dicionário é contemplada pelo UPDDISTR e, caso seja contemplada, realizar a alteração do dicionário através do ATUSX ( Tópico Recursos de Desenvolvimento -> Ferramenta ATUSX ) . Neste caso o cliente aguarda a expedição do Atualizador do TAF no final do release.

Caso a alteração de dicionário não seja contemplada pelo UPDDISTR, o ajuste é realizado no update do módulo ( UPDTAF ) que pode ser encontrado no diretório de fontes padrão.

  • As alterações de dicionário deverão ser realizadas no ATUSX ( em pacote individual por requisito ) e incorporados no final do release de expedição do TAF ( de acordo com o calendário de expedição da versão 11 );
  • Os pacotes do ATUSX sempre devem ser criados abaixo do Projeto do Release de entrega da versão 12, ou seja, deve-se planejar a homologação do requisito/chamado de réplica da versão 12 assim que iniciar o desenvolvimento da versão 11. O objetivo é realizar as alterações de dicionário uma única vez, garantindo a integridade do TAF em ambas as versões.
  • Assim que o chamado/requisito for homologado na versão 11, deve ser solicitado ao GCAD que faça a incorporação no Projeto TAF Segregado ( utilizado para atualização do TAF na versão 11 );
  • Verifique como alterar o dicionário de dados no tópico Recursos de Desenvolvimento -> Ferramenta ATUSX.
Ação 2

Fontes: Deverá ser utilizada a branch de Manutenção do Protheus_Padrao ( pasta do TAF ) - versão11: $/Protheus_Padrao/Fontes_Doc/Sustentação/V11/V118/Fontes/TAF

Dicionário de Dados: O ajuste é realizado no update do módulo ( UPDTAF ) que pode ser encontrado no diretório de fontes padrão.

Após a homologação, a alteração realizada no UPDTAF deve ser replicada para o dicionário no ATUSX, através do pacote TAF SEGREGADO - VERSÃO 11:

 

 

Ação 3

Uma melhoria que envolve alteração no dicionário de dados deve ser absorvida no roadmap e tratado através do processo de Inovação.

 

(aviso) Atenção! Sempre valide as funcionalidades desenvolvidas através do tópico 5.Detalhes de Codificação

3.2. Tenho um chamado do TAF que devo desenvolver na versão 12

 

Adotar o processo padrão de manutenção do Release Incremental: Manutenção com Dicionário de Dados - Release Incremental

(aviso) Atenção! Sempre valide as funcionalidades desenvolvidas através do tópico 5.Detalhes de Codificação

4. Expedição

4.1. Fluxo operacional

 

 

 

5. Detalhes de Codificação

Este tópico aborda detalhadamente cada etapa de codificação e o que deve ser verificado e validado ao desenvolver uma funcionalidade no TAF. Para entender os sub-tópicos a seguir, é necessário ter em mente que um desenvolvimento no produto envolve as etapas abaixo:

 

5.1. Padrões pré-codificação

5.1.1 Padrão de Levantamento

Antes de qualquer ação de especificação ou desenvolvimento de funcionalidades no módulo, sugere-se um levantamento das alterações que serão realizadas, visando mapear o que realmente deve ser criado e o que pode ser utilizado do legado do produto.

Para padronizar este mapeamento, utilizar um arquivo na extensão XLS ( ou XLSX ) no formato abaixo:

TAF - Mapeamento de Campos DIEF-CE.xlsx

Documento elaborado por: David Augusto da Costa Pinto

(aviso) Etapa obrigatória no desenvolvimento de novas obrigações fiscais

5.1.2. Padrão de Estimativas

Após a fase de levantamento, sugere-se a utilização de um padrão para estimar as horas de desenvolvimento de determinada funcionalidade. Seguir conforme tabela abaixo ( tabela 1: Indica o que representa cada etapa, tabela 2: indica o tempo estimado para cada etapa ):

(aviso) Quando se tratar de uma obrigação fiscal, a estimativa refere-se ao tempo gasto para 1 ( um ) campo* ou 1 ( um ) registro** a ser implementado

EtapaDescriçãoTempo gasto na implementação do campo*Tempo gasto na Validação do Campo*Tempo gasto na Validação do Registro**
Layout TOTVSEtapa destinada a análise e adequação do arquivo do Layout TOTVS de Integração. Verifique o tópico Recursos de Desenvolvimento -> Ferramenta TDN e entenda como realizar os ajustes no Layout.0,25 hr0,25 hr0 hr
Dicionário de dadosEtapa destinada a análise e adequação do dicionário de dados ( tabelas, campos, índices, gatilhos, etc. ), tanto na aplicação quanto na ferramenta ATUSX.0,25 hr0,25 hr0 hr
RotinaEtapa destinada a criação/adequação da rotina do cadastro ( 100% codificação )0,25 hr0,25 hr2 hr
Layout de IntegraçãoEtapa destinada a adequação do layout de integração ( fonte TAFLAYOUT ) que gera o arquivo layout.def.0,25 hr0,25 hr0 hr
Processo de IntegraçãoEtapa destinada a teste unitário de um processo de integração ( job 2 ) da implementação que está sendo feita.0,25 hr0,25 hr0,25 hr
Processo de ValidaçãoEtapa destinada a teste unitário de um processo de validação ( job 3 ) da implementação que está sendo feita.0,25 hr0,25 hr0,25 hr
Gerar ObrigaçãoEtapa destinada a criação/adequação da rotina geradora do arquivo da obrigação fiscal (TXT/XML)0,25 hr0,25 hr0,25 hr
TOTALTotaliza as horas para cada implementação1,75 hora ( 1 hora e 45 minutos ) por campo1,75 hora ( 1 hora e 45 minutos ) por campo2,75 hr ( 2 horas e 45 minutos ) por registro

 

(aviso) Etapa obrigatória no desenvolvimento de novas obrigações fiscais

 

5.2. Dúvidas Frequentes sobre as Etapas do Desenvolvimento

5.2.1. Layout TOTVS

  • Onde encontrar? R: 07. Conheça o Layout de Integração
  • Qual é o formato oficial? R: Arquivo XLS
  • Como devem ser feitas as manutenções do arquivo? R: Tópico Recursos de Desenvolvimento -> Ferramenta TDN.

5.2.2. Dicionário de Dados

  • Como manutenir o ATUSX? R: Tópico Recursos de Desenvolvimento -> Ferramenta ATUSX.
  • Caso a aplicação do UPDDISTR não surja efeito, o que devo fazer? R: Utilizar a rotina UPDTAF
  • Caso a alteração realizada no ATUSX não esteja de acordo, preciso montar um novo ambiente? R: Não, apenas atuar no arquivo ( tabela, campo, índice, gatilho, etc... ) onde será feito o ajuste e aplicar novamente o atualizador de dicionário de dados UPDDISTR.

5.2.3. Cadastro / Movimento / Apuração

  • O que é MVC: R: Model View Controller, um padrão de arquitetura de software utilizado em todos os cadastros do TAF. 

5.2.4. Processos de Integração

  • Quais processos devo utilizar para testar a integração? R: Jobs de Integração ( zero, um e dois ) e TAFA500.

5.2.5. Obrigação Fiscal

  • Onde devo registrar o meu levantamento e estimativa? R: No TFS, $/TAF/Documentos/Obrigações Fiscais.

 

5.3. Rotinas Importantes

5.3.1. TAFXFUN - Biblioteca de Funções Genéricas

  • Nesse fonte existem todas as funções genéricas do TAF, sempre que possível o analista deve desenvolver funcionalidades de uma forma genérica e dinâmica, pensando que outros analistas podem reutilizá-la posteriormente.

  • Quando o analista entender que uma funcionalidade desenvolvida se enquadra na característica acima a mesma deve estar nesse fonte, sempre criada como FUNCTION para que outros fontes possam utilizar a função.

  • É importante frisar que antes de desenvolver a funcionalidade é essencial analisar se já não existe alguma que atenda a necessidade ou possa vir a atender com algumas modificações pontuais (Sempre lembrando que a alteração não pode impactar no legado da função).

  • Por já estar com uma quantidade grande de linhas vamos criar o fonte TAFXFUNDIC que terá o mesmo princípio, deixaremos assim o TAFXFUN obsoleto para novas implementações, serão permitidas apenas correções e melhorias nas funções já disponíveis

  • A documentação no cabeçalho da função desenvolvida é essencial e obrigatório, informando sempre os parâmetros que a função recebe, o retorno da função, além de informações sobre o escopo da mesma.

5.3.2. TAFROTINAS - Fonte Centralizador de Rotinas

  • Nesse fonte mantemos um Arrays com as informações dos cadastros do TAF, ou seja, sempre que precisar saber, por exemplo, quais são as tabelas auto-contidas do TAF? Quais são os cadastros do TAF criados para a ECF ?  etc... deve-se utilizar esse fonte para consulta, quando o array não possuir uma informação que o analista necessita ele pode ser complementado.

  • O principal objetivo desse fonte é mantermos em um único lugar todas as informações de cadastros do TAF, assim, quando criada uma nova obrigação o analista deve apenas incluir nesse fonte para que todas as rotinas já passem a contemplar os novos cadastros( Integração, Validação, Geração, etc... )

  • Em alguns casos temos arrays criados fora desse fonte, caso o analista se depare com essa situação fica de sua responsabilidade adequar a rotina e passar a utilizar esse fonte para consulta.

5.3.3. TAFAINTEG / TAFXINTEG / TAFIntegraESocial - Rotinas de Integração

  • Os fontes TAFAINTEG, TAFXINTEG e TAFIntegraESocial tem como característica principal realizar a integração dos dados do ERP para o TAF(Integração Banco a Banco) e em alguns casos enviar as informações do TAF para o TSS (Por exemplo o envio dos eventos do e-Social), abaixo irei detalhar o papel de cada um deles no processo de integração:

  • TAFAINTEG: É o fonte referente ao motor de integração, responsável por realizar a execução dos Job´s do TAF e a leitura das tabelas TAFST1 e TAFST2 para todos os tratamentos efetivados durante o processo de integração, manutenções nesse fonte devem ser tratadas com muito critério, pelo processo não será necessária nenhuma manutenção quando realizada novas implementações de obrigações no TAF.

  • TAFXINTEG: É o fonte que possui todas as funções genéricas utilizadas pelo motor de integração(TAFAINTEG), ou seja, é um fonte auxiliar ao motor, segue o mesmo princípio citado no TAFAINTEG, pelo processo não será necessária nenhuma manutenção para a implementação de novas obrigações, não devemos utilizá-la para subir funções genéricas que não tenham relação com o motor.

  • TAFIntegraESocial: Esse fonte foi criado para a integração exclusiva do ERP Protheus com o TAF no escopo do E-Social, através das funções disponibilizadas é possível utilizar o conceito da integração OnLine, onde ao imputar uma informação no Protheus a mesma já é enviada ao TAF de forma automática sem a necessidade de executar os Jobs de integração. Todas as funções genéricas criadas para esse escopo devem ser desenvolvidas nesse fonte. 

  • Importante mencionar que todo o motor de integração banco a banco se baseia no TAFLAYOUT para realizar o De/Para de informações, ou seja, identificar a origem da informação e onde a mesma deve ser gravada no TAF.

5.3.4. TAFDIAG - Diagnóstico de Ambiente e Sistema

  • Esse fonte realiza a criação do diagnóstico do TAF que auxilia o nosso atendimento a verificar se o cliente possui a base do TAF atualizada para uso, através dessa funcionalidade fazemos diversas validações na base para verificar se o dicionário está atualizado, Binário, LIB, Auto-Contidas, Layout.def, etc... 

  • Sempre que realizada a criação/alteração de uma auto-contida ou do Layout.Def deve-se alterar esse fonte para que não apareça ao cliente que o seu ambiente está desatualizado quando executado o diagnóstico.

  • Após o término do desenvolvimento de novas obrigações é muito importante que o analista abra o diagnóstico no ambiente de homologação para verificar se nenhuma alteração deve ser realizada no Diagnóstico após as suas implementações.

5.3.4. TAFLAYOUT - Layout de Integração - Layout Único

  • Esse fonte foi criado para construção do Layout.def, ou seja, sempre que o cliente realizar a integração, por exemplo, esse fonte é acionado, gera o arquivo Layout.def na StartPath do ambiente, ao final da integração o arquivo é deletado.

  • O arquivo Layout.def é utilizado pelo motor de integração para realizar a carga dos dados no TAF, ou seja, sempre deve ser incrementado com os novos layouts criados para atender as obrigações acessórias desenvolvidas.

  • O analista sempre deve se atentar ao legado, ou seja, tratar com ColumnPos() e AliasIndic() a criação de novos campos e tabelas para evitar que ocorram problemas com clientes que estejam com o ambiente desatualizado(Releases anteriores a entrega da obrigação).

5.3.4. TAFA500 - Rotina de integração de arquivo txt

  • Esse fonte tem como objetivo realizar a carga para o TAF do arquivo texto gerado pelo ERP, ou seja, conforme mencionado acima o fonte TAFAINTEG é o motor de integração para o modelo Banco a Banco, da mesma forma o fonte TAFA500 é o motor de integração quando integrado arquivo texto.

  • Importante mencionar que todo o motor de integração de arquivo texto se baseia no TAFLAYOUT para realizar o De/Para de informações, ou seja, identificar a origem da informação e onde a mesma deve ser gravada no TAF.

  • A nível de desenvolvimento, atualizando o TAFLAYOUT tanto o modelo de integração banco a banco quanto o modelo de integração de arquivo texto funcionarão sem a necessidade de manutenção

5.3.5. TAFXVALID - Validação de Rotinas 

  • Nesse fonte incluímos todas as validações genéricas do JOB 3, ou seja, quando existe uma validação que pode ser compartilhada entre mais de um cadastro realizamos a inclusão nesse fonte, evitando assim que os analistas dupliquem as validações.

  • É importante que antes de criar uma nova validação verificar se a mesa já não existe nesse fonte.

 

6. Dependência de Fontes

Existem alguns fontes que possuem dependência, ou seja, sempre que um requisito utilizá-lo o analista deve incluir manualmente no pacote todos os fontes que possuem a dependência, abaixo segue todas as relações conhecidas do TAF:

É fundamental que os analista atualizem essa relação conforme as novas dependências forem surgindo

    1. TAFA062, TAFA062E, TAFA062S
    2. TAFA275, TAFA275VIEW
    3. TAFA276, TAFA276VIEW
    4. TAFA277, TAFA277VIEW
    5. TAFA280, TAFA280VIEW
    6. TAFAMON, TAFMONVIEW
    7. TAFOBRIG, TAFOBRIGA
    8. TAFR101, TAFRFUN
    9. TAFR102, TAFRFUN
    10. TAFR105, TAFRFUN
    11. TAFR106, TAFRFUN
    12. TAFR107, TAFRFUN
    13. TAFR108, TAFRFUN
    14. TAFR109, TAFRFUN
    15. TAFR110, TAFRFUN
    16. TAFR111, TAFRFUN
    17. TAFR112, TAFRFUN
    18. TAFR113, TAFRFUN
    19. TAFR114, TAFRFUN
    20. TAFR115, TAFRFUN
    21. TAFR116, TAFRFUN
    22. TAFXINTEG, TAFAINTEG
    23. TAFXVALID, TAFVLDECF
    24. TAFXECF, TAFECF0, TAFECFJ, TAFECFK, TAFECFL, TAFECFM, TAFECLN, TAFECLP, TAFECFT, TAFECFU, TAFECFX, TAFECFY
    25. TAFXGSP, TAFGS05, TAFGS07, TAFGS10, TAFGS20, TAFGS30, TAFGS31
    26. TAFA117, TAFXSPD0, TAFXSPD1, TAFXSPDA, TAFXSPDC, TAFXSPDD, TAFXSPDE, TAFXSPDF, TAFXSPDG, TAFXSPDH, TAFXSPDI, TAFXSPDX
    27. TAFA118, TAFXSPD0, TAFXSPD1, TAFXSPDA, TAFXSPDC, TAFXSPDD, TAFXSPDE, TAFXSPDF, TAFXSPDH, TAFXSPDI, TAFXSPDM, TAFXSPDP, TAFXSPDX

 

7. Lista de Pacotes e Incorporações de Dicionário

No TFS está disponível uma listagem de todos os pacotes de dicionário do TAF, incluindo descrição, datas de incorporação e o destino da incorporação de cada pacote.

Acessar em: $/TAF/Documentos/Gestão de Pacotes - ATUSX/Lista de Pacotes e Incorporações - Dicionário TAF.xlsx