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 )

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. 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.2. 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 abaixo como deve ser feita a manutenção de acordo com o seu processo de desenvolvimento:

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 TAFXFUNB 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 todos os arrays com as infromaçõs 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 inrofmação que 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 as rotinas( 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

5.3.4. TAFDIAG - Diagnóstico de Ambiente e Sistema

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

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