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 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
| Documento elaborado por |
|---|
| Versão |
|---|
| 1.0 |
| Í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 )
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.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 )
*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.
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 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.
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 automaticamente será incorporado ao Release “pai” para expedição.
- Os requisitos/chamados da versão 12 devem obedecer o Calendário do Release Incremental.
- Verifique como alterar o dicionário de dados no tópico Recursos de Desenvolvimento -> Ferramenta ATUSX.
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 |
|---|---|---|---|---|
| CAT001 | Ação 1 | Ação 1 | Ação 2 | Ação 2 |
| CAT017 | Ação 1 | Ação 1 | Ação 1 | Ação 1 |
| CAT014 | Ação 3 | Ação 3 | Ação 3 | Ação 3 |
| Ação 1 |
|---|
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.
|
| 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. |
| 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:
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. Visite Integração TOTVS x TAF e entenda como realizar os ajustes no Layout. | 0,25 hr | 0,25 hr | 0 hr | |||||
| Dicionário de dados | |||||||||
| Rotina | |||||||||
| Layout de Integração | |||||||||
| Processo de Integração | |||||||||
| Processo de Validação | |||||||||
| 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 | Gerar Obrigação |
5.2. Etapas do Desenvolvimento
5.2.1. Layout TOTVS
5.2.2. Dicionário de Dados
5.2.3. Cadastro / Movimento / Apuração
5.2.4. Processos de Integração
5.2.5. Obrigação Fiscal
5.3. Rotinas Importantes
5.3.1. TAFXFUN - Biblioteca de Funções Genéricas
5.3.2. TAFROTINAS - Fonte Centralizador de Rotinas
5.3.3. TAFAINTEG / TAFXINTEG / TAFIntegraESocial - Rotinas de Integração
5.3.4. TAFDIAG - Diagnóstico de Ambiente e Sistema
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas