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.80.68\taf_wr\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.80.68\taf_wr\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:

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 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.1

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:

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 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;

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;
  •  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 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); 

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

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).

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 em dois servidores distintos ("appserver.ini"), 1 servidor dedicado ao TAFCFGJOB e no servidor de aplicação configurar a 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 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;
  •  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); 

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

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.0 (Simplificado);

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 SMART - 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.