TOTVS Automação Fiscal

Árvore de páginas

Versões comparadas

Versão antiga 10

changes.mady.by.user Luccas Brandino Curcio

Gravado em

comparado com

Nova versão 11

changes.mady.by.user Luccas Brandino Curcio

Gravado em

Chave

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

Objetivo

Página destinada a detalhar as particularidades do TAF nos processos corporativos ( expedição, manutenção e inovação )

 

Introdução

Os itens abaixo são referências que devem ser adotadas no desenvolvimento, homologação e liberação do TAF na versão 11.Para a versão 12, deve ser adotado o processo corporativo do Release Incrementalpara as versões 11 e 12.

 

Índice
Índice

1

. Expedição

. Conceitos do TOTVS Automação Fiscal

Modelos de Distribuição

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

Image Added

 

Arquitetura

2. Inovação

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

1.1.

Particularidades no processo de inovação

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

a. Durante o ciclo de construção, os chamados de Legislação ( SSIM ) e os requisitos de Inovação ( JIRA ) serão desenvolvidos e homologados na branch de Inovação.
Fontes: Deverá ser utilizada a branch 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:

 

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ão12
1 - Chamado envolve alteração de dicionário
  • Fonte: Alterar na branch de Inovação do Release Corrente
  • Dicionário: Alterar apenas no ATUSX - Pacote MANUTENÇÃO do Release corrente
2 - Chamado não envolve alteração de dicionário
  • Fonte: Alterar na branch de Manutenção
3 - Chamado envolve alteração de tabela autocontida
  • Tabela Autocontida: Alterar na branch de Inovação do release corrente
  • Regra: A tabela autocontida sofrerá manutenção através de uma legislação, e consequentemente entrará no processo de inovação ( item 1 ).
  • Exceções ( apenas em casos críticos ): Alterar na branch de manutenção com uma sub-versão, exemplo: autocontidasv100301.taf.
  • Devem ser alterada a versão apenas dos .dbf que sofreram manutenção. Os demais mantem a versão.
4 - Chamado envolve alteração no layout.def / dbf / dtc
  • Layout: Alterar na branch de Inovação do release corrente
  • Regra: O Layout sofrerá manutenção através de uma legislação, e consequentemente entrará no 
    processo de inovação ( item 1 ).
  • Exceções ( erros ): Criar uma sub-versão na seção de "build" do layout dentro do layout.def
  • Observação: Criar uma seção de versão dentro do layout.def ( formato: versão + sub-versão + data ) exemplo: 2.600120150626
  • Criptografar arquivo layout.def ( + interface que descriptografa o arquivo para visualização )
Versão11
1 - Chamado envolve alteração de dicionário
  • Fonte: Alterar na branch de manutenção
  • Dicionário: Alterar o UPDTAF ( UPDDISTR não executa o RUP_ na versão 11 )
  • Observação: Alterar o manual de atualização orientando a execução do UPDTAF que primeiro executa o UPDDISTR (automático) e depois o UPDTAF.
  • Documentar todas as alterações no boletim ( TDN ).
  • Criar uma trava no UPDATE, só pode ser executado na versão 11 ( quando o diretório único estiver em produção ) verificar o nome da função genérica.
2 - Chamado não envolve alteração de dicionário
  • Fonte: Alterar na branch de Manutenção
3 - Chamado envolve alteração de tabela autocontida
  • Tabela Autocontida: Alterar na branch de Inovação do release corrente
  • Regra: A tabela autocontida sofrerá manutenção através de uma legislação, e consequentemente entrará no processo 
    de inovação ( item 1 ).
  • Exceções ( apenas em casos críticos ): Alterar na branch de manutenção com uma sub-versão, exemplo: autocontidasv100301.taf.
  • Devem ser alterada a versão apenas dos .dbf que sofreram manutenção. Os demais mantem a versão.
4 - Chamado envolve alteração no layout.def / dbf / dtc
  • Layout: Alterar na branch de Inovação do release corrente
  • Regra: O Layout sofrerá manutenção através de uma legislação, e consequentemente entrará no 
    processo de inovação ( item 1 ).
  • Exceções ( erros ): Criar uma sub-versão na seção de "build" do layout dentro do layout.def
  • Observação: Criar uma seção de versão dentro do layout.def ( formato: versão + sub-versão + data ) exemplo: 2.600120150626
  • Criptografar arquivo layout.def ( + interface que descriptografa o arquivo para visualização )

 

Alterando o dicionário