Nosso Objetivo: Expedir a melhor versão do produto Automação Fiscal, assumindo a responsabilidade de todas as etapas, realizando, acompanhando ou validando os pontos citados no documento.

"Responsabilidade significa responder pelos seus atos e/ou de outras pessoas envolvidas na realização de uma determinada tarefa, todos acertam e erram juntos ! "

Este material deve ser utilizado como um CHECK LIST para a montagem e execução do processo de WR do produto Automação Fiscal.

TODAS as etapas citadas neste documento são OBRIGATÓRIAS e não podem ser desconsideradas nas respectivas etapas do WR.

1. Pré-Validação dos Artefatos:

Nesta fase devem ser executadas as etapas abaixo para garantir que os artefatos gerados estão de fato corretos e atualizados, apenas após GARANTIR que o item esta correto deve-se marcar o CHECK BOX como concluído. 

A cada nova geração do pacote e/ou atualizador todas as etapas abaixo devem ser novamente realizadas, obrigatoriamente!

•  Obter a confirmação com os POs envolvidos no WR  sobre o término de todas as entregas (fonte e dicionário) que devam estar no ambiente do WR. (Seguindo cronograma destacado mais abaixo);
  •  RM ([email protected]);
  •  DTS ([email protected]); 
  •  GPE  ( [email protected] );
  •  MDT ([email protected] );
  •  TAF eSocial ([email protected] );
  •  TAF REINF ([email protected] );
  •  TSS ([email protected] );
•  Validar com o PO do TAF([email protected]) se a versão atual do instalador está com todos os testes concluídos para que se inicie o processo do WR;
•  Disponibilizar no Drive os release notes da ultima WR para que sejam atualizados pelas equipes ( https://drive.google.com/drive/folders/1g4YVi00UUifn4-hi-EHvD9WV7LVvbHF8?usp=share_link ).
•  

  Garantir que todos os artefatos (Menus, Release Notes e qualquer outro artefato que precise ser incorporado no Pacote) estão atualizados no diretório: \\10.171.212.9\Compartilhada_Pre_Pacote Se não estiver atualizado conversar com os responsáveis solicitando a atualização antes de seguir com as próximas etapas;

•  Validar se o sistema operacional do servidor (IP: 10.171.80.58) é compatível com o binário Lobo Guará e Harpia ( Application Server 19.3.0.x e superiores - Sistemas operacionais );
•  Validar se os certificados a serem utilizados nos testes forma enviados pelas linhas de produto;
•  Solicitar a engenharia a geração do artefato do WR ( instalador e pacote pontual ), são os artefatos que serão utilizados durante todos os testes do WR. (Seguindo cronograma destacado mais abaixo);
•  Confirmar se os bancos de dados estão no ar com o time do Ronaldo no GCAD ([email protected] ), em casos onde a base for criada do zero solicitar ao mesmo time a criação dos bancos de dados (para saber qual banco de dados será necessário, consultar a seção "Montagem de Ambientes" mais abaixo neste material);
•   Pedir aos TLs do time do TAF eSocial e Fiscal (E-social = [email protected] e TAF-Fiscal = [email protected] ) todos os pacotes de dicionário que foram incorporados nos últimos 5 meses, validar manualmente e pontualmente se todos constam tanto no dicionário do atualizador quanto no dicionário do ".zip" gerados pela engenharia no item anterior;
•  Avaliar todas as quebras da automação na versão 12.1.27, 12.1.33 e 12.1.2210 sobre a execução que foi gerada nos artefatos gerados pela engenharia ( ATENÇÃO: Não são as quebras do D-1 mas sim as quebras da execução que foi feita pela engenharia sobre os artefatos do WR). Direcionar todas as quebras para as TLs do TAF (E-social = [email protected] e TAF-Fiscal = [email protected] ) avaliarem com seus times se são de fato problemas de produto ou alguma outra situação mapeada, somente seguir após o "ok" de ambos times, no caso de algum problema ser encontrado deve-se conversar com o PO para definir se vamos regerar ou não o pacote;
•  Validar se tanto no atualizador quanto no arquivo ".zip" gerado pela engenharia a LIB é a última disponível no portal do cliente;
•  Validar se tanto no atualizador quanto no arquivo ".zip" gerado pela engenharia o BINÁRIO é o último disponível no portal do cliente;
•  Validar se tanto no atualizador quanto no arquivo ".zip" gerado pela engenharia o DBACCESS é o último disponível no portal do cliente;
•  Validar se tanto no atualizador quanto no arquivo ".zip" gerado pela engenharia os artefatos TAFA552.APP e TAFA552.PRW estão com a última versão expedida;
•  Validar se o release notes de todos os produtos estão contemplando as últimas entregas do produto;
•  Prosseguir com a criação/atualização das bases seguindo o cronograma destacado mais abaixo, a forma como as bases devem ser criadas estão destacadas no tópico "Montagem de Ambiente";
•  Converter para PDF e salvar os releases notes na pasta \\10.171.212.9\Compartilhada_Pre_Pacote
•  Criar usuários para os ambientes e colocar eles no grupo Admin, devido a necessidade de acessar o SIGACFG e APSDU.

Itens para o futuro ( Desconsiderar por hora ):

• Avaliar com Evandro se foi montada uma base local simulando o Smart eSocial com SO em Linux para validar possíveis problemas que ocorram no ambiente durante os testes;

2. Informações Técnicas Adicionais ( Anotações do Maestro WR ):

Atenção, muitas das informações abaixo SE TORNAM DESNECESSÁRIAS com a nova estrutura de bases proposta neste documento, logo utilize apenas como base histórica de consulta e não como uma diretriz de como realizar a atualização:

1. WR - Informações de Geração do Pacote:
   1. Gerador de pacotes (Solicitar autorização):
      1. https://james.engpro.totvs.com.br/job/engpro-expedicao/job/taf-wr/job/homologacao/build?delay=0sec
      2. Produto: todos
      3. Dicionario: Com Dicionário
      4. DicHelp: Com-Help
      5. Automação: Não
   2. Local onde o pacote é gerado: 
      1. Link: \\10.171.80.68\taf_wr\Compartilhada_Pacote
      2. Pacote é gerado com tudo que foi encerrado até 3 horas atrás.
   3. Pré - Pacote:
      1. Link: \\10.171.80.68\taf_wr\Compartilhada_Pre_Pacote
      2. Local onde serão colocados os arquivos de MENU e RELEASE NOTES para serem incorporados ao pacote.
   4. Se der erro na geração do pacote, enviar e-mail para a engenharia validar.
2. VM WR:
   1. Link: 10.171.80.58
      1. Usuário e Senha da Rede
      2. Middleware envia REST para o TSS;
      3. As marcas usam instalador porque é assim que o cliente realiza a atualização do produto no mercado para facilitar a gestão de ambiente do cliente;
3. Atualização do WR:
   1. Atualização Diária (Fazer no dia anterior ao final do expediente)
      1. RPO: \\10.171.66.229\d-1\P12.1.33\TAF_X64
      2. Aplicar a LIB PUBLISHED https://arte.engpro.totvs.com.br/framework/libs/lib/published/harpia/
   2. Dicionário se for solicitado:
      1. TAF - 009711
      2. RH - 009675
      3. MDT - 009668
   3. Atualização de Menu:
      1. Se dicionário no banco (colocar arquivos na system e atualizar o menu);
      2. Se CTREE apenas colocar os arquivos na SYSTEM;
   4. GPE/PROTHEUS:
      1. Substituir RPO D-1;
      2. Aplicar LIB pacote via vscode;
      3. Replicar RPO atualizado para as pastas apo_dbg apo_rest, apo_rnf e Protheus_Mid_DB2
      4. Se não houver dicionário replicar também para RM e DTS;
   5. RM e DTS via atualizador;
   6. Middleware apenas RPO;
   7. Se houver dicionário TAF, incluir RPO e dicionário e atualizar via instalador.

3. Cronograma WR - Março/Abril de 2022:

1. Entrega de todos os artefatos de desenvolvimento para os produtos TAF, GPE e MDT:
   1. Entrega de todos os fontes, dicionários e release note atualizados e finalizados para a entrega do WR;
   2. Prazo: 18/11/2022  
   3. Responsável: Product Owner TAF, GPE e MDT
2. Entrega final dos demais produtos que integram com o TAF e serão expedidos juntos com o WR:
   1. Entrega do produto e release note atualizado e finalizado para a entrega do WR;
   2. Prazo: 30/11/2022 
   3. Responsável: DTS, RM e QUIRONS
3. Solicitar a geração dos pacotes que serão validados durante o WR a engenharia Protheus e também a execução dos testes automatizados sobre estes artefatos gerados para todas as releases vigentes(12.1.27, 12.1.33 e 12.1.2210):
   1. Prazo: Do dia 21/11/2022 até o dia  21/11/2022
   2. Responsável: Maestro do WR
4. Montagem dos Ambientes de Teste:
   1. Prazo: Do dia 23/11/2022 até o dia  29/11/2022
   2. Responsável: Maestro do WR
5. Envio dos certificados Digitais que serão utilizados pelo TAF e TSS nos testes:
   1. Prazo: Até 18/11/2022 
   2. Responsável: DTS, RM ,Protheus, Quirons, MDT
6. Execução do WR:
   1. Teste de conexão no dia 30/11/2022
   2. Prazo: Do dia 01/12/2022 até o dia 16/12/2022 
7. Período de Margem para desvios:
   1. Prazo: Do dia 19/12/2022 até o dia 20/12/2022
8. Expedição ao mercado prevista para o dia 21/12/2022 

4. Montagem/Atualização de Ambientes:

O processo de montagem e/ou atualização dos ambientes tem como objetivo realizar a validação do maior número de cenários de configuração possíveis em ambientes de cliente, pela diversidade que o Protheus permite é totalmente inviável validar todos os cenários mas aqui vamos buscar cobrir a maior quantidade de cenários.

TODAS as etapas abaixo devem OBRIGATORIAMENTE ser realizadas para a montagem e atualização dos ambientes:

I. Ambiente JAPÃO - Validação do Instalador do TAF/TSS:

O objetivo deste primeiro ambiente é simplesmente validar se ao executar o instalador do TAF/TSS a base é criada corretamente sem nenhuma ocorrência de erro, para validar isso é necessário executar o instalador 1 vez no início da montagem do ambiente (com o artefato gerado pela engenharia) e uma outra vez no início do segundo ciclo de testes (com o novo artefato gerado pela engenharia ).

Este ambiente não será usado pelos times para testes, sendo assim pode ser montado em base local justamente visando validar o instalador !

Local da Base: Ambiente Local do analista.

----------------------------------------------------------------------------------------------------------------------------------

II. Ambiente ALEMANHA - Atualizar Via Migrador de Versão e atualizar via UPDDISTR do TAF/TSS:

Este ambiente deve ser criado uma única vez (no WR de Março/22) e sempre ser apenas atualizado com o atualizador buildado para expedição no WR que esta sendo homologado, o objetivo é validar se o cliente que está com a última versão do pacote acumulado terá problemas na atualização de seu produto.

Este ambiente será utilizado especificamente pelo time do TAF(Suporte e Desenvolvimento) para os testes de seus cenários, tanto no eSocial quanto no Fiscal:

Local da Base: VM do WR;

Versão Layout eSocial: 1.2

Versão Layout REINF: Última Vigente 

Release: 12.1.2210

Banco de Dados: ORACLE;

Dicionário: No Banco de Dados;

Integração WS / PO UI: Utilizar serviço TAFCFGJOB SEM uso da porta MPP;

Usuário(s) x Acessos: Para cada usuário listado abaixo criar um respectivo no configurador ( Ex.. Fiscal_Desenv_1, Fiscal_Desenv_2, eSocial_Desenv_1, eSocial_Suporte_1, etc.. ), deixar esses usuários com acesso FULL apenas ao módulo SIGATAF, definir uma senha padrão e solicitar que seja alterada no primeiro acesso ao produto;

Qtde Grupo de Empresas / Filiais : Realizar a criação conforme quadro abaixo:

• •  Abrir a interface de diagnóstico no ambiente e validar se as informações estão todas corretas (data do dicionário, data do repositório e informações gerais da tela);
  •  Realizar neste momento um "BKP" de toda a estrutura do produto (Binário, LIB, Dicionário, RPO, etc.. ), esta estrutura deve ficar apenas como uma base de consulta para caso ocorra algum problema durante os testes e seja necessário validar como estava a versão inicial dos testes;
  •  Validar em todos os grupos de empresas existentes os parâmetros abaixo:
    •  MV_VAUTCON - Precisa estar na última versão das tabelas autocontidas expedidas;
    •  MV_BACKEND - Precisa estar configurado nas bases onde não existe porta MPP;
    •  MV_GCTPURL - Precisa estar configurado nas bases onde não existe porta MPP;
    •  MV_TAFAMBR - Precisa esta configurado como ambiente de pré-produção;
    •  MV_TAFAMBE - Precisa esta configurado como ambiente de pré-produção;
    •  MV_TAFVLRE - Precisa estar configurado com a última versão do layout da EFD REINF;
    •  MV_TAFVLES - Precisa estar configurado ou com a versão 2.5 ou 1.0 do eSocial conforme definido no detalhe de cada ambiente mais abaixo;
    •  

      MV_TAFTALI - Precisar estar com o TOP ALIAS de cada ambiente.

    •  

      MV_TAFTDB - Precisa estar com o tipo de TOP DATABASE de cada ambiente.

  •  Configurar o Security = 1 no appserver.ini - Vamos realizar os testes com a segurança habilitada;
  •  Validar se o serviço TSI está no ar no ambiente que será utilizado pelo time TAF-Fiscal;
  •  Realizar a integração de um evento do eSocial e um evento da EFD REINF pela TAFST2 para garantir que o ambiente está funcional;
  •  Abrir rotinas em PO UI (eSocial e EFD REINF ) e validar se estão funcionando conforme o esperado;
  •  Retirar do menu (apenas no ambiente, NÃO editar arquivo XNU a ser expedido) as rotinas de monitoramento da EFD REINF(TAFXREINF) e eSocial(TAFMONTES); 

----------------------------------------------------------------------------------------------------------------------------------

III. Ambiente BRASIL - Atualização do TAF/TSS via atualizador do TAF:

No início de cada WR este ambiente será criado OBRIGATORIAMENTE através do instalador do TAF buildado em Maio/21 e atualizado com o atualizador buildado para entrega nesta WR que está sendo homologada, o objetivo é garantir que clientes que estejam nas versões antigas do produto não terão dificuldades na atualização do ambiente.

Este ambiente será utilizado especificamente por todos os times de RH que fazem integração WS com o produto TAF:

Local da Base: VM do WR;

Versão Layout eSocial: 1.1 

Versão Layout REINF: Última Vigente;

Release: Inicial 12.1.17, Atualizar para 12.1.27 e Final 12.1.33 (após o término da atualização);

Banco de Dados: MICROSOFT SQL;

Dicionário: CTREE;

Integração WS / PO UI: Utilizar serviço TAFCFGJOB COM uso da porta MPP, outro AppServer exclusívo para Middleware;

Usuário(s) x Acessos: Para cada usuário listado abaixo criar um respectivo no configurador (Ex.. Folha_RM_1, Folha_RM_2, Folha_RM_3, etc.. ), deixar esses usuários com acesso FULL apenas ao módulo SIGATAF, definir uma senha padrão e solicitar que seja alterada no primeiro acesso ao produto.

Qtde Grupo de Empresas / Filiais : Realizar a criação conforme quadro abaixo:

• •  Abrir a interface de diagnóstico no ambiente e validar se as informações estão todas corretas (data do dicionário, data do repositório e informações gerais da tela);
  •  Realizar neste momento um "BKP" de toda a estrutura do produto (Binário, LIB, Dicionário, RPO, etc.. ), esta estrutura deve ficar apenas como uma base de consulta para caso ocorra algum problema durante os testes e seja necessário validar como estava a versão inicial dos testes;
  •  Criar os usuários do ambiente
  •  Validar em todos os grupos de empresas existentes os parâmetros abaixo:
    •  MV_VAUTCON - Precisa estar na última versão das tabelas autocontidas expedidas;
    •  MV_BACKEND - Precisa estar configurado nas bases onde não existe porta MPP;
    •  MV_GCTPURL - Precisa estar configurado nas bases onde não existe porta MPP;
    •  MV_TAFAMBR - Precisa esta configurado como ambiente de pré-produção;
    •  MV_TAFAMBE - Precisa esta configurado como ambiente de pré-produção;
    •  MV_TAFVLRE - Precisa estar configurado com a última versão do layout da EFD REINF;
    •  MV_TAFVLES - Precisa estar configurado ou com a versão 2.5 ou 1.0 do eSocial conforme definido no detalhe de cada ambiente mais abaixo;
    •  

      MV_TAFTALI - Precisar estar com o TOP ALIAS de cada ambiente.

    •  

      MV_TAFTDB - Precisa estar com o tipo de TOP DATABASE de cada ambiente.

  •  Configurar o Security = 1 no appserver.ini para as filiais que não usam Middleware (Vamos realizar os testes com a segurança habilitada;), para as filial com Middleware o Security deverá ser 0. (Deverá ser criado dois Rest dentro do .ini)
  •  Realizar a integração de um evento do eSocial  e um do EFD REINF pela TAFST2 para garantir que o ambiente está funcional;
  •  Abrir rotinas em PO UI (eSocial e EFD REINF ) e validar se estão funcionando conforme o esperado;
  •  Retirar do menu (apenas no ambiente, NÃO editar arquivo XNU a ser expedido) as rotinas de monitoramento da EFD REINF(TAFXREINF) e eSocial(TAFMONTES); 

----------------------------------------------------------------------------------------------------------------------------------

IV. Ambiente EGITO - Atualização do TAF/TSS via arquivo ".zip" gerado para o GPE:

Este ambiente será utilizado pelos produtos que integram de forma "nativa" com o TAF (GPE/MDT).

A instalação deste ambiente deve ser manual, utilizando os últimos artefatos expedidos (lib, binário etc..), o RPO deve ser o expedido no portal para a release 12.1.33, o mesmo deve ser atualizado com os pacotes das equipes + lib.

Local da Base: VM do WR;

Versão Layout eSocial: 1.1

Versão Layout REINF: Última Vigente;

Release: 12.1.33;

Banco de Dados: POSTGREE;

Dicionário: No Banco de Dados;

Integração WS / PO UI: Utilizar serviço TAFCFGJOB COM uso da porta MPP;

Usuário(s) x Acessos: Para cada usuário listado abaixo criar um respectivo no configurador (Ex.. GPE_1, GPE_2, etc..), deixar esses usuários com acesso FULL apenas para os módulos SIGATAF, SIGAMDT e SIGAGPE, definir uma senha padrão e solicitar que seja alterada no primeiro acesso ao produto.

Qtde Grupo de Empresas / Filiais : Realizar a criação conforme quadro abaixo:

• •  Abrir a interface de diagnóstico no ambiente e validar se as informações estão todas corretas (data do dicionário, data do repositório e informações gerais da tela);
  •  Realizar neste momento um "BKP" de toda a estrutura do produto (Binário, LIB, Dicionário, RPO, etc.. ), esta estrutura deve ficar apenas como uma base de consulta para caso ocorra algum problema durante os testes e seja necessário validar como estava a versão inicial dos testes;
  •  Validar em todos os grupos de empresas existentes os parâmetros abaixo:
    •  MV_VAUTCON - Precisa estar na última versão das tabelas autocontidas expedidas;
    •  MV_BACKEND - Precisa estar configurado nas bases onde não existe porta MPP;
    •  MV_GCTPURL - Precisa estar configurado nas bases onde não existe porta MPP;
    •  MV_TAFAMBR - Precisa esta configurado como ambiente de pré-produção;
    •  MV_TAFAMBE - Precisa esta configurado como ambiente de pré-produção;
    •  MV_TAFVLES - Precisa estar configurado ou com a versão 2.5 ou 1.0 do eSocial conforme definido no detalhe de cada ambiente mais abaixo;
    •  

      MV_TAFTALI - Precisar estar com o TOP ALIAS de cada ambiente.

    •  

      MV_TAFTDB - Precisa estar com o tipo de TOP DATABASE de cada ambiente.

  •  Configurar o Security = 1 no appserver.ini - Vamos realizar os testes com a segurança habilitada;
  •  Realizar a integração de um evento do eSocial pela TAFST2 para garantir que o ambiente está funcional;
  •  Abrir rotinas em PO UI e validar se estão funcionando conforme o esperado;
  •  Retirar do menu (apenas no ambiente, NÃO editar arquivo XNU a ser expedido) as rotinas de monitoramento da EFD REINF(TAFXREINF) e eSocial(TAFMONTES); 

----------------------------------------------------------------------------------------------------------------------------------

V. Ambiente SUECIA - Validação da Integração via QUIRONS

Este ambiente já existe e está configurado, basta que seja atualizado com o pacote ".zip" gerado pela engenharia para expedição no WR.

Este ambiente será utilizado especificamente pelo time Quirons para validar a integração do produto com o TAF, atenção, não mudar as portas configuradas no ambiente pois elas são liberadas para integração externa a rede TOTVS onde esta localizado o produto QUIRONS(nuvem pública).

Local da Base: 20.206.92.160;

Versão Layout eSocial: 1.1 

Versão Layout REINF: N/A

Release: 12.1.33;

Banco de Dados: SQLSERVER;

Dicionário: CTREE;

Integração WS / PO UI: Utilizar serviço TAFCFGJOB COM uso da porta MPP no mesmo "appserver.ini";

Usuário(s) x Acessos: Pode ser utilizado o usuário admin, não é necessária a criação de usuários específicos;

Qtde Grupo de Empresas / Filiais : Manter a estrutura de grupo de empresas e filiais já existentes;

• •  Abrir a interface de diagnóstico no ambiente e validar se as informações estão todas corretas (data do dicionário, data do repositório e informações gerais da tela);
  •  Realizar neste momento um "BKP" de toda a estrutura do produto (Binário, LIB, Dicionário, RPO, etc.. ), esta estrutura deve ficar apenas como uma base de consulta para caso ocorra algum problema durante os testes e seja necessário validar como estava a versão inicial dos testes;
  •  Validar em todos os grupos de empresas existentes os parâmetros abaixo:
    •  MV_VAUTCON - Precisa estar na última versão das tabelas autocontidas expedidas;
    •  MV_BACKEND - Precisa estar configurado nas bases onde não existe porta MPP;
    •  MV_GCTPURL - Precisa estar configurado nas bases onde não existe porta MPP;
    •  MV_TAFAMBR - Precisa esta configurado como ambiente de pré-produção;
    •  MV_TAFAMBE - Precisa esta configurado como ambiente de pré-produção;
    •  MV_TAFVLRE - Precisa estar configurado com a última versão do layout da EFD REINF;
    •  MV_TAFVLES - Precisa estar configurado ou com a versão 2.5 ou 1.0 do eSocial conforme definido no detalhe de cada ambiente mais abaixo;
    •  

      MV_TAFTALI - Precisar estar com o TOP ALIAS de cada ambiente.

    •  

      MV_TAFTDB - Precisa estar com o tipo de TOP DATABASE de cada ambiente.

  •  Configurar o Security = 1 no appserver.ini - Vamos realizar os testes com a segurança habilitada;
  •  Realizar a integração de um evento do eSocial e um evento da EFD REINF pela TAFST2 para garantir que o ambiente está funcional;
  •  Abrir rotinas em PO UI (eSocial e EFD REINF ) e validar se estão funcionando conforme o esperado;
  •  Retirar do menu (apenas no ambiente, NÃO editar arquivo XNU a ser expedido) as rotinas de monitoramento da EFD REINF(TAFXREINF) e eSocial(TAFMONTES); 

----------------------------------------------------------------------------------------------------------------------------------

VI. Ambiente Mexico - Atualização do Smart eSocial

Incluir os artefatos onde é necessário e garantir junto ao Renato Campos ([email protected] ) que o ambiente esta atualizado com os artefatos a serem liberados no WR;

OBS: O ambiente SMART é atualizado todos os dias as 07h pelo robô com o D-1 mais Lib.

• •  Abrir a interface de diagnóstico no ambiente e validar se as informações estão todas corretas (data do dicionário, data do repositório e informações gerais da tela);
  •  Validar em todos os grupos de empresas existentes os parâmetros abaixo:
    •  MV_VAUTCON - Precisa estar na última versão das tabelas autocontidas expedidas;
    •  MV_BACKEND - Precisa estar configurado nas bases onde não existe porta MPP;
    •  MV_GCTPURL - Precisa estar configurado nas bases onde não existe porta MPP;
    •  MV_TAFAMBR - Precisa esta configurado como ambiente de pré-produção;
    •  MV_TAFAMBE - Precisa esta configurado como ambiente de pré-produção;
    •  MV_TAFVLRE - Precisa estar configurado com a última versão do layout da EFD REINF;
    •  MV_TAFVLES - Precisa estar configurado ou com a versão 2.5 ou 1.0 do eSocial conforme definido no detalhe de cada ambiente mais abaixo;
    •  

      MV_TAFTALI - Precisar estar com o TOP ALIAS de cada ambiente.

    •  

      MV_TAFTDB - Precisa estar com o tipo de TOP DATABASE de cada ambiente.

  •  Configurar o Security = 1 no appserver.ini - Vamos realizar os testes com a segurança habilitada;
  •  Realizar a integração de um evento do eSocial e um evento da EFD REINF pela TAFST2 para garantir que o ambiente está funcional;
  •  Abrir rotinas em PO UI (eSocial e EFD REINF ) e validar se estão funcionando conforme o esperado;
  •  Retirar do menu (apenas no ambiente, NÃO editar arquivo XNU a ser expedido) as rotinas de monitoramento da EFD REINF(TAFXREINF) e eSocial(TAFMONTES); 
  •  Ajustar o Menu do Smart, pois o mesmo não tem todos os menus que existem no TAF.

OBS: Quando os testes neste ambiente são realizados pelo time do RM, podem ser apresentados erros de integração. Para estes casos já existe um precedente onde a solução é a que foi utilizada na Issue

----------------------------------------------------------------------------------------------------------------------------------

5. Atividades Durante o Primeiro Ciclo do WR:

As atividades abaixo devem ser realizadas TODOS OS DIAS durante o processo de testes do WR:

•  Atualizar o D-1 (apenas fonte) todo dia de manhã antes do início dos testes e aplicar a última LIB EXPEDIDA no portal do cliente (com aplicação do D-1 a tela do diagnóstico apresenta que o TAF não esta atualizado);
•  Validar se existe necessidade de alteração de dicionário, se sim, deve-se aplicar o pacote pontualmente e anotar esse ajuste de dicionário para validar no se na geração do artefato final ele esta contemplado;
•  Anotar todas as manutenções que foram expedidas durante o WR para os projetos DSERTAF1 e DSERTAF2, independente se foram efetivadas alterações de fonte ou dicionário, no artefato final precisa validar se todas essas issues foram contempladas para expedição;
•  Validar se o ambiente do Smart eSocial foi atualizado corretamente com D-1 + LIB;
•  Validar diariamente junto aos PROXYS do TAF (E-Social = [email protected] e TAF-Fiscal = [email protected] ), se eles endossam todas as expedições (fonte e dicionário) do dia anterior que vão entrar no ambiente (PROXY precisa fazer query no JIRA de todas as issues expedidas no dia anterior e os impactos, o objetivo é evitar que algo que não deveria subir durante o WR tenha sido feito por alguém);

6. Atividades Durante o Segundo Ciclo do WR:

•  Solicitar ao GCAD a geração dos artefatos para os segundo ciclo do WR especificando quais artefatos tiveram alteração para o segundo ciclo, colocando em cópia todos os envolvidos (TLs, Proxys, POs, Ernani, Alexandre Gimenez, Wganer Souza e Mauricio Santos);
•  Solicitar ao Wagner Souza a execução dos testes automatizados;
•  Solicitar ao Renato Campos a atualização do Smart com os novos artefatos.
•  Avaliar todas as quebras da automação na versão 12.1.27, 12.1.33 e 12.1.2210 sobre a execução que foi gerada nos artefatos gerados pela engenharia ( ATENÇÃO: Não são as quebras do D-1 mas sim as quebras da execução que foi feita pela engenharia sobre os artefatos do WR). Direcionar todas as quebras para as TLs do TAF (E-social = [email protected] e TAF-Fiscal = [email protected] ) avaliarem com seus times se são de fato problemas de produto ou alguma outra situação mapeada, somente seguir após o "ok" de ambos times, no caso de algum problema ser encontrado deve-se conversar com o PO para definir se vamos regerar ou não o pacote;
•  Validar se todas as issues solucionadas durante o primeiro ciclo estão contempladas no pacote final (dicionário, fonte) - tanto no atualizador quanto no arquivo ".zip";
•  Validar se tanto no atualizador quanto no arquivo ".zip" gerado pela engenharia a LIB é a última disponível no portal do cliente;
•  Validar se tanto no atualizador quanto no arquivo ".zip" gerado pela engenharia o BINÁRIO é o último disponível no portal do cliente;
•  Validar se tanto no atualizador quanto no arquivo ".zip" gerado pela engenharia o DBACCESS é o último disponível no portal do cliente;
•  Atualizar as bases do TAF e TSS com o novo artefato final gerado pela engenharia;
•  Avaliar os fluxos de montagem de ambiente para verificar como realizar a validação destes novos artefatos gerados;
•  Atualizar a DT referente ao a Expedição do WR que se encontra no link Abril/2022 - Versão mais atualizada do produto
•  Pedir aprovação das alterações realizadas na DT para o PO do TAF.

7. Finalizando o WR:

•  Solicitar ao GCAD a publicação da expedição do WR especificando o link da DT na abertura do ticket, colocando em cópia todos os envolvidos (TLs, Proxys, POs, Ernani, Alexandre Gimenez, Wganer Souza e Mauricio Santos);

8. O que fazer no caso de erros encontrados durante os testes ?

• Os times envolvidos nos testes que identificarem erros devem direcioná-lo ao PO para entender se o mesmo é crítico ou não, sendo crítico o mesmo deve ser corrigido e entrar na próxima janela de atualização do ambiente;
• Em hipótese alguma um pacote pontual será aplicado no ambiente, ocorrerá apenas uma atualização por dia com o D-1 + Lib conforme já citado no documento;
• Se existir erro de dicionário crítico deve-se executar o upddistr pontualmente nos ambientes com o pacote e anotar o que foi alterado no dicionário, quando o pacote for regerado para o segundo ciclo de teste precisa validar se esse ajuste entrou no ambiente corretamente;
• Durante o segundo ciclo de teste NENHUMA alteração deve ser incluída no ambiente, a idéia é que durante essa fase de teste o pacote seja validado na integra sem mudanças.