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

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 ).

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.

 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

 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

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

 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

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

 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

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