Histórico da Página
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
Objetivo
Página destinada a detalhar as particularidades do TAF nos processos corporativos ( expediçãoManutenção, manutenção Inovação e inovação Expedição ).
Introdução
Os itens abaixo são referências que devem ser adotadas no desenvolvimento, homologação e liberação do TAF para as versões 11 e 12.
| Índice | |
|---|---|
|
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
| Documento elaborado por |
|---|
| Versão atual |
|---|
| 1.1 |
| Versão | Alterações realizadas |
|---|---|
| 1.0 | Inclusã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 | |
|---|---|
|
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:
- 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. - 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. 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:
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.
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.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.
Mais abaixo nos cenários de Inovação e Manutenção será ilustrado como deve ser feito o controle de alteração e incorporação de pacotes.
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.
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
a. 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,
Branch de Inovação do TAF - versão 12 ( release incremental ): $/Protheus_Padrao/Fontes_Doc/Inovação/V12
b. As alterações de fontes, tabelas autocontidas e layout de integração deverão ser realizadas nos diretórios de Inovação
c. As alterações de dicionário deverão ser realizadas no ATUSX ( em pacote individual ) e incorporados no final do release de expedição do TAF
d. 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.
e. 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 );
f. Assim que o chamado/requisito for homologado na versão 12, este automaticamente será incorporado ao Release “pai” para expedição.
g. Os requisitos/chamados da versão 11 devem obedecer o Calendário do TAF;
h. Os requisitos/chamados da versão 12 devem obedecer o Calendário do Release Incremental.
1.2. Particularidades processo de manutenção
1. Durante o ciclo de construção, os chamados de Não Conformidade serão desenvolvidos e homologados na branch de manutenção.
2. Quando chamado na versão 11, as alterações de dicionário deverão ser realizadas no UPDTAF quando não contemplado pelo UPDDISTR*.
*Detalhes sobre as regras do UPDDISTR:
Regras para atualização do dicionário SX1 SX2 . SIX
Fluxo operacional:
Manutenção
( devido as mudanças no processo do release incremental este tópico está sendo reavaliado )
Os códigos fontes do TAF estão armazenados em um único diretório no TFS. Qualquer manutenção nas rotinas, independente da versão do TAF ( 11 ou 12 ), devem ser realizadas nesse único diretório.
Após a homologação do chamado, as alterações serão compiladas em 4 diretórios distintos:
1) D-1 Protheus Padrão - Versão 11 ( todas as línguas e bases );
2) D-1 Protheus Padrão - Versão 12 ( todas as línguas e bases );
3) D-1 TAF - Versão 11 ( todas as línguas, base TOPCONNECT );
4) D-1 TAF - Versão 12 ( todas as línguas, base TOPCONNECT ).
Todo chamado da versão 11 deverá gerar uma réplica para a versão 12. Como o fonte já foi corrigido na versão 11 e este se aplica à todas as versões, a FNC réplica da versão 12 deverá ser encerrada apenas com os fontes corrigidos amarrados como dependência no pacote. Deverá ser colocada uma observação no encerramento da FNC, indicando o chamado original que aquele erro já foi corrigido.
| Versão | 12 |
|---|---|
| 1 - Chamado envolve alteração de dicionário |
|
| 2 - Chamado não envolve alteração de dicionário |
|
| 3 - Chamado envolve alteração de tabela autocontida |
|
| 4 - Chamado envolve alteração no layout.def / dbf / dtc |
|
| Versão | 11 |
|---|---|
| 1 - Chamado envolve alteração de dicionário |
|
| 2 - Chamado não envolve alteração de dicionário |
|
| 3 - Chamado envolve alteração de tabela autocontida |
|
| 4 - Chamado envolve alteração no layout.def / dbf / dtc |
|
Alterando o dicionário
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.
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. |
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:
|
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. |
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. Atenção! O pacote somente será incorporado ao dicionário padrão quando utilizada a rotina Aprovação SQA no ATUSX. Atenção! 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.
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 | Baixa | Media | Alta | Crítica |
|---|---|---|---|---|
| Não conformidade ( CAT001 e similares ) | Ação 2 | Ação 2 | Ação 2 | Ação 2 |
| Legislações ( CAT017 e similares ) | Ação 2 | Ação 2 | Ação 2 | Ação 2 |
| Melhorias ( CAT014 ) | Ação 3 | Ação 3 | Ação 3 | Ação 3 |
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 ). |
|---|
|
| 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. |
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
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 | Descrição | Tempo gasto na implementação do campo* | Tempo gasto na Validação do Campo* | Tempo gasto na Validação do Registro** |
|---|---|---|---|---|
| Layout TOTVS | Etapa 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 hr | 0,25 hr | 0 hr |
| Dicionário de dados | Etapa 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 hr | 0,25 hr | 0 hr |
| Rotina | Etapa destinada a criação/adequação da rotina do cadastro ( 100% codificação ) | 0,25 hr | 0,25 hr | 2 hr |
| Layout de Integração | Etapa destinada a adequação do layout de integração ( fonte TAFLAYOUT ) que gera o arquivo layout.def. | 0,25 hr | 0,25 hr | 0 hr |
| Processo de Integração | Etapa destinada a teste unitário de um processo de integração ( job 2 ) da implementação que está sendo feita. | 0,25 hr | 0,25 hr | 0,25 hr |
| Processo de Validação | Etapa destinada a teste unitário de um processo de validação ( job 3 ) da implementação que está sendo feita. | 0,25 hr | 0,25 hr | 0,25 hr |
| Gerar Obrigação | Etapa destinada a criação/adequação da rotina geradora do arquivo da obrigação fiscal (TXT/XML) | 0,25 hr | 0,25 hr | 0,25 hr |
| TOTAL | Totaliza as horas para cada implementação | 1,75 hora ( 1 hora e 45 minutos ) por campo | 1,75 hora ( 1 hora e 45 minutos ) por campo | 2,75 hr ( 2 horas e 45 minutos ) por registro |
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
- TAFA062, TAFA062E, TAFA062S
- TAFA275, TAFA275VIEW
- TAFA276, TAFA276VIEW
- TAFA277, TAFA277VIEW
- TAFA280, TAFA280VIEW
- TAFAMON, TAFMONVIEW
- TAFOBRIG, TAFOBRIGA
- TAFR101, TAFRFUN
- TAFR102, TAFRFUN
- TAFR105, TAFRFUN
- TAFR106, TAFRFUN
- TAFR107, TAFRFUN
- TAFR108, TAFRFUN
- TAFR109, TAFRFUN
- TAFR110, TAFRFUN
- TAFR111, TAFRFUN
- TAFR112, TAFRFUN
- TAFR113, TAFRFUN
- TAFR114, TAFRFUN
- TAFR115, TAFRFUN
- TAFR116, TAFRFUN
- TAFXINTEG, TAFAINTEG
- TAFXVALID, TAFVLDECF
- TAFXECF, TAFECF0, TAFECFJ, TAFECFK, TAFECFL, TAFECFM, TAFECLN, TAFECLP, TAFECFT, TAFECFU, TAFECFX, TAFECFY
- TAFXGSP, TAFGS05, TAFGS07, TAFGS10, TAFGS20, TAFGS30, TAFGS31
- TAFA117, TAFXSPD0, TAFXSPD1, TAFXSPDA, TAFXSPDC, TAFXSPDD, TAFXSPDE, TAFXSPDF, TAFXSPDG, TAFXSPDH, TAFXSPDI, TAFXSPDX
- 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
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas