Este material deve ser usado pelos times de desenvolvimento do Totvs Automação Fiscal, tanto na etapa de desenvolvimento, quanto no CODE REVIEW, teste unitário e teste integrado.

 Se algum dos cenários abaixo já se encontra automatizado NÃO É NECESSÁRIO fazer o teste manual, deve-se apenas garantir que o cenário automatizado não tenha quebras e TACHAR o cenário na relação abaixo informando na frente qual o(s) casos de testes que atendem aquele escopo.

ESCOPO E-SOCIAL

Cadastro MVC

• Inclusão de todos os campos do cadastro validando gatilho e consulta padrão, inclusive para as GRIDs ( filhos, netos, etc.. ), sendo que cada GRID deve ter ao menos 3 linhas de registro incluído;

• Integração do XML gerado na linha acima pela TAFST2, validando se todas as informações foram integradas corretamente;

• Preencher ao menos um campo de cada GRID existente no cadastro, realizar a geração do XML e validar Schema transmitindo com o TSS;

Integração via WebService

• O serviço alterado deve ser validado através de um client REST utilizando, no caso do serviço de integração WSTAST2 é necessário validar os métodos GET e POST, o tempo de integração deve ser no mínimo mantido após a manutenção.

• A documentação do serviço deve ser atualizada e publicada, analisar se não acontecerá quebras e se o serviço for utilizado com a assinatura anterior.

Integração Online

• Validar a integração realizando a chamada da API tafprepInt através de uma POC, durante o processo é necessário analisar quais são os parâmetros informados pelo GPE e desta maneira "simular" a integração.

Integração com o TSS

• Na alteração de um serviço do TSS é necessário atualizar o client do mesmo, por conta das funcionalidades criadas para a tokenização o client gerado pelo IDE. Não pode simplesmente sobrepor o client atual, deve-se realizar um merge incluindo as novas propriedades criadas.

• Para validação de funcionalidades de transmissão e consulta, é necessário que o documento seja de fato integrado com o TSS, no caso da transmissão é necessário que o documento tenha seu schema validado, todos os grupos não opcionais devem ter um cenário de teste próprio considerando a regra do layout, nos processos de consulta o XML deve passar pelo TAFPROC5 (é possível simular uma consulta incluindo o XML diretamente na SPED400 e alterando o status do registro no TAF para 2)

Inclusão/Alteração de Eventos

Ao incluir ou alterar um evento, verificar os itens do link Alteração/Inclusão de Eventos para definição do escopo da manutenção.

• Realizar a exclusão através do TAFKEY
• Realizar a exclusão através da Chave de Negócio (identificação do índice através do TAFROTINAS)
• Realizar a exclusão através do Recibo

Eventos de Tabela

• Integração/Cadastro do evento com Inclusão utilizando uma vigência diferente da anterior, o sistema deve acatar a Integração e não realizar o versionamento.

• Integração/Cadastro do evento como alteração utilizando a mesma vigência, o sistema deve criar uma nova versão do evento se o mesmo estiver transmitido (status 4), caso contrario deve realizar a alteração direta.

Eventos Não Periódicos

S-2230

As validações abaixo podem ser realizadas através de um script de teste:

• Integração de Fim de afastamento informando o TAFKEY do predecessor
• Integração de retificação do fim de afastamento informando o TAFKEY do predecessor
• *Integração de retificação do inicio de  afastamento informando o TAFKEY do predecessor e alterando a data de inicio 
• *Integração de retificação de um afastamento completo informando o TAFKEY do predecessor e alterando a data de inicio
• Integração de afastamentos de inicio, fim e completo sem informar o TAFKEY

*Em Desenvolvimento

Eventos Periódicos

S-1200

As validações abaixo podem ser realizadas através de um script de teste:

• Validar a Integração e Transmissão de uma folha com múltiplos vínculos na mesma filial 
• Validar a Integração e Transmissão de uma folha com múltiplos vínculos em filiais diferentes
• Validar a Integração e Transmissão de uma folha aglutinada
• Validar a Integração e Transmissão de uma folha aglutinada após a transmissão do primeiro vinculo.
• Validar a Integração de uma folha para um trabalhador autônomo RPA (infocomplem)

S-1210

As validações abaixo podem ser realizadas através de um script de teste:

• Validar a Integração e Transmissão de um pagamento  com múltiplos vínculos na mesma filial
• Validar a Integração e Transmissão de um pagamento  com múltiplos vínculos em filiais diferentes
• Validar a Integração e Transmissão de um pagamento aglutinado
• Validar a Integração e Transmissão de uma folha aglutinada após a transmissão do primeiro vinculo.

Totalizadores 

• A gravação dos totalizadores devem obrigatoriamente passar pela rotina TAFPROC5, este processo é necessário para garantir a gravação de todas as tabelas que envolvem o processo.

Painel INSS-FGTS / Relatório INSS

• Validar o processo de gravação da tabela V3N nos processos de de integração, transmissão e consulta, não podem haver duplicidades na tabela, avaliar se o sistema está "re-gerando" a tabela corretamente para o relatório de FGTS(em excel), a performance deve ser considerada neste item, por este motivo caso a alteração tenha sido em uma rotina de persistência o tempo do processamento deve ser no mínimo mantido.

• O tempo de geração dos relatórios devem ser no mínimo mantidos após qualquer manutenção nos mesmos.

Painel Transmissão eSocial

Operações do eSocial com acesso via WebApp.

ESCOPO TAF FISCAL

Cadastro MVC

Cadastro Movimento

• Inclusão de todos os campos do cadastro validando gatilho e consulta padrão, inclusive para as GRIDs ( filhos, netos, etc.. ), sendo que cada GRID deve ter ao menos 3 linhas de registro incluído;

• Alteração do registro incluído na linha acima, colocando mais 1 registro em cada GRID e mudando 3 campos do cabeçalho do cadastro;
• Exclusão do item alterado acima;

Cadastro Espelho

• Gerar XML do evento através da opção "Gerar XML / Gerar XML em lote";

• Excluir evento não transmitido;
• Excluir evento transmitido e validar a geração do evento R-9000;

PAINEL REINF

Performance

Sempre que for realizado uma alteração em query, busca ou consulta nos eventos da EFD-REINF, anexar o logprofiler na issue após a alteração demonstrando que a rotina ganhou ou ao menos permaneceu com a mesma performance que antes da alteração. Utilizar as chaves ServerMemoryInfo e  DebugThreadUsedMemory para monitorar o consumo de memória.

Realizar testes com uma carga de ao menos 10.000 registros incluídos via execauto ou procedure. 

Eventos de Tabela

• R-1000

  • (Automatizado ? ) Validar a remoção do contribuinte no ambiente de testes da Receita 

  • Validar a inclusão e transmissão de um evento R-1000 preenchendo todos os campos da C1E.
  • Validar a inclusão e transmissão de um evento R-1000 deixando um campo obrigatório em branco (validação de erros retornados pelo RET)
  • Enviar uma alteração de evento R-1000

• R-1070

  • Validar a inclusão e transmissão de um evento de processo referenciado (R-1070)

  • Validar a inclusão e transmissão de um evento de processo referenciado com erro de transmissão pelo RET
  • Enviar uma alteração de evento R-1070

Eventos Periódicos

• R-2010

  • Validar e transmitir um evento R-2010 com processo referenciado

  • Validar e transmitir um evento R-2010 com um documento fiscal que possua CNO, deve preencher o campo T95_INDCPR = 1
  • Validar e transmitir um evento R-2010 com um documento fiscal que não possua CNO, deve preencher o campo T95_INDCPR = 0
  • Validar e transmitir um evento R-2010 que seja rejeitado pelo RET.
  • Excluir um evento R-2010 que não foi transmitido
  • Excluir um evento R-2010 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-2010

• R-2020

  • Validar e transmitir um evento R-2020 com processo referenciado

  • Validar e transmitir um evento R-2020 com retenção adicional
  • Validar e transmitir um evento R-2020 que seja rejeitado pelo RET.
  • Excluir um evento R-2020 que não foi transmitido
  • Excluir um evento R-2020 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-2020

• R-2030

  • Validar e transmitir um evento R-2030 com processo referenciado

  • Validar e transmitir um evento R-2030 configurado para apurar pela baixa
  • Validar e transmitir um evento R-2030 configurado para apurar pela emissão
  • Validar e transmitir um evento R-2030 que seja rejeitado pelo RET.
  • Excluir um evento R-2030 que não foi transmitido
  • Excluir um evento R-2030 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-2030

• R-2040

  • Validar e transmitir um evento R-2040 com processo referenciado

  • Validar e transmitir um evento R-2040 configurado para apurar pela baixa
  • Validar e transmitir um evento R-2040 configurado para apurar pela emissão
  • Validar e transmitir um evento R-2040 que seja rejeitado pelo RET.
  • Excluir um evento R-2040 que não foi transmitido
  • Excluir um evento R-2040 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-2040

• R-2050

  • Validar e transmitir um evento R-2050 com processo referenciado

  • Validar e transmitir um evento R-2050 sem processo referenciado
  • Validar e transmitir um evento R-2050 que seja rejeitado pelo RET.
  • Excluir um evento R-2050 que não foi transmitido
  • Excluir um evento R-2050 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-2050

• R-2055

  • Validar e transmitir um evento R-2055 com processo referenciado

  • Validar e transmitir um evento R-2055 sem processo referenciado
  • Validar e transmitir um evento R-2055 que seja rejeitado pelo RET.
  • Excluir um evento R-2055 que não foi transmitido
  • Excluir um evento R-2055 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-2055
  • Validar e transmitir um evento R-2055 com notas fiscais de 2 fornecedores diferentes em filiais diferentes
  • Validar e transmitir um evento R-2055 com participante optante pela folha de pagamento (o campo V5S_INDCP deve estar com 2 e o R-5001 não deverá ter valores a recolher)

• R-2060

  • Validar e transmitir um evento R-2060 com processo referenciado

  • Validar e transmitir um evento R-2060 sem processo referenciado
  • Validar e transmitir um evento R-2060 que seja rejeitado pelo RET.
  • Excluir um evento R-2060 que não foi transmitido
  • Excluir um evento R-2060 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-2060
  • Validar e transmitir eventos R-2060 com códigos de atividade diferentes (será gerado uma linha na V0T para cada código e os valores da V0S devem ser iguais a soma dos valores da V0V).

• R-4010

  • Validar e transmitir um evento R-4010 com processo referenciado e IR na emissão (Nota fiscal) (Automatizado CT_R4010_03)

  • Validar e transmitir um evento R-4010 sem processo referenciado e IR na emissão (Fatura)
  • Validar e transmitir um evento R-4010 com dependentes e deduções de dependentes e IR na baixa (Pagamento)  (Automatizado CT_R4010_08)
  • Validar e transmitir um evento R-4010 que seja rejeitado pelo RET.
  • Validar e transmitir um evento R-4010 com rendimentos isentos.  (Automatizado CT_R4010_07)
  • Validar e transmitir um evento R-4010 que não atingiu valor mínimo de IR para retenção.  (Automatizado CT_R4010_12)
  • Excluir um evento R-4010 que não foi transmitido
  • Excluir um evento R-4010 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-4010
  • Validar e transmitir eventos R-4010 com naturezas de rendimentos diferentes
  • Validar e transmitir um evento R-4010 que tenha mais de 1 residente exterior com NIF e com mais de um movimento.
  • Validar e transmitir um evento R-4010 que tenha mais de 1 residente exterior sem NIF e com mais de um movimento.

• R-4020

  • Validar e transmitir um evento R-4020 com processo referenciado e IR na emissão (Nota fiscal)

  • Validar e transmitir um evento R-4020 sem processo referenciado e IR na emissão (Fatura)
  • Validar e transmitir um evento R-4020  com PCC e IR na baixa (Pagamento)
  • Validar e transmitir um evento R-4020  com PCC e IR na emissão (Fatura)
  • Validar e transmitir um evento R-4020  com CSRF na emissão (Fatura e Nota) - Esse registro não pode ser considerado na apuração.
  • Validar e transmitir um evento R-4020  com SCP (Pagamento) e sem incidencia de imposto.
  • Validar e transmitir um evento R-4020  com SCP (Fatura) e sem incidencia de imposto - Esse registro não pode ser considerado na apuração.
  • Validar e transmitir um evento R-4020 que seja rejeitado pelo RET.
  • Validar e transmitir um evento R-4020 com rendimentos isentos.
  • Excluir um evento R-4020 que não foi transmitido
  • Excluir um evento R-4020 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-4020
  • Validar e transmitir eventos R-4020 com naturezas de rendimentos diferentes
  • Validar e transmitir um evento R-4020 que tenha mais de 1 residente exterior com NIF e com mais de um movimento.
  • Validar e transmitir um evento R-4020 que tenha mais de 1 residente exterior sem NIF e com mais de um movimento.

• Natureza de Rendimento 12001 - Lucros e dividendos - Testes válidos para R-4010/R-4020
  • Realizar testes com o parâmetro MV_TAFSTRI = .T. e .F.

          Exemplo 1: Fatura emitida em 05/11 de 12.000 reais com 2 parcelas (IR e PCC no pagamento):

• • Parcela 1 - 6.000 paga em 2x
    • Pagamento 1 Sequencial 001 - 3.000 em 05/11 - Registro 1 na V3U
    • Pagamento 2 Sequencial 002 - 3.000 em 20/11 - Registro 2 na V3U
  • Parcela 2 - 6.000 paga em 2x
    • Pagamento 1 Sequencial 001 - 3.000 em 20/12 - Registro 3 na V3U
    • Pagamento 2 Sequencial 002 - 3.000 em 05/01 - Registro 4 na V3U

No caso acima, como haverá somente o pagamento devemos apresentar em novembro, o valor de 6.000, pois temos 2 pagamentos com mesmo número, data de emissão e parcela, porém sequenciais diferentes. Em dezembro teremos apenas 3.000, pois somente um pagamento foi feito em Dezembro.

Exemplo 2: Fatura emitida em 05/11 de 12.000 reais com 2 parcelas (IR na emissão e PCC no pagamento):

• • Parcela 1 - 6.000 paga em 2x
    • Pagamento 1 Sequencial 001 - 3.000 em 05/11 - Registro 1 na V3U
    • Pagamento 2 Sequencial 002 - 3.000 em 20/11 - Registro 2 na V3U
  • Parcela 2 - 6.000 paga em 2x
    • Pagamento 1 Sequencial 001 - 3.000 em 20/12 - Registro 3 na V3U
    • Pagamento 2 Sequencial 002 - 3.000 em 05/01 - Registro 4 na V3U

No caso acima, como o IR está na emissão, somente o valor da fatura será apresentado no painel (12.000), pois o IR já está na emissão e foi    devido em cima do valor total do título. Os pagamentos do mês 11 não deverão ser considerados para soma, pois o valor total do título já foi considerado. Como houve pagamentos em Novembro, devemos manter a apresentação dos dados do pagamento, eles serão utilizados n a montagem das informações do PCC. Os valores do PCC devem ser somados para cada pagamento + sequencia + data de pagamento que acontecerem.

Exemplo 3: Fatura emitida em 05/11 de 12.000 reais com 2 parcelas (IR e PCC no pagamento):

• • Parcela 1 - 6.000 paga em 2x
    • Pagamento 1 Sequencial 001 - 3.000 em 05/11 - Registro 1 na V3U
    • Pagamento 2 Sequencial 002 - 3.000 em 20/11 - Registro 2 na V3U
  • Parcela 2 - 6.000 paga em 2x
    • Pagamento 1 Sequencial 001 - 3.000 em 28/11 - Registro 3 na V3U
    • Pagamento 2 Sequencial 002 - 3.000 em 05/01 - Registro 4 na V3U

No caso acima, como haverá somente o pagamento devemos apresentar em novembro, o valor de 9.000, pois temos 2 pagamentos com esmo número, data de emissão, porém sequenciais e parcelas diferentes e datas de pagamentos diferentes. Em Janeiro teremos apenas 3.000, pois somente um pagamento foi feito neste mês.

          Exemplo 4: Fatura emitida em 05/11 de 12.000 reais com 2 parcelas (IR e PCC no pagamento):

• • Parcela 1 - 6.000 paga em 1x
    • Pagamento 1 Sequencial 001 - 6.000 em 05/11 - Registro 1 na V3U
  • Parcela 2 - 6.000 paga em 2x
    • Pagamento 1 Sequencial 001 - 3.000 em 28/11 - Registro 2 na V3U
    • Pagamento 2 Sequencial 002 - 3.000 em 05/01 - Registro 3 na V3U

No caso acima, como haverá somente o pagamento devemos apresentar em novembro, o valor de 9.000, pois temos 2 pagamentos com mesmo número, data de emissão, porém parcelas diferentes. Em Janeiro teremos apenas 3.000, pois somente um pagamento foi feito neste mês.

• Garantir os seguintes pontos na importação de XML de lucros e dividendos dos eventos R-4010/R-4020
  • Sempre que for criado um novo campo na Wizard da rotina TAFA618 (Importação de XML), devemos criar o novo campo também na rotina de agendamento da importação do XML.
  • Sempre que utilizada a rotina de importação do XML para lucros e dividendos, devemos validar o preenchimento dos campos V5C_ORIGEM e V4Q_ORIGEM com valor 'I'. 
  • Realizar testes de importação com 2 fornecedores exterior com NIF diferentes.
  • Realizar testes de importação com 2 fornecedores exterior sem NIF, com nomes diferentes.

• R-4040

  • Validar e transmitir 2 eventos R-4040 de filiais diferentes  (Automatizado CT_R4040_05)
  • Validar e transmitir um evento R-4040 que seja rejeitado pelo RET.
  • Excluir um evento R-4040 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-4040
  • Validar e transmitir eventos R-4040 com naturezas de rendimentos diferentes

• R-4080

  • Validar e transmitir 2 eventos R-4080 de filiais diferentes (Automatizado CT_R4080_05)
  • Validar e transmitir um evento R-4080 que seja rejeitado pelo RET.
  • Excluir um evento R-4080 que já foi transmitido (Gerar e transmitir R-9000).
  • Enviar uma retificação de um evento R-4080
  • Validar e transmitir eventos R-4080 com naturezas de rendimentos diferentes

Eventos de fechamento

• Realizar o fechamento (R-2099), a reabertura (R-2098) e um novo fechamento (R-2099). Avaliar a gravação do totalizador R-5011, para identificar se apenas o ultimo fechamento fica como válido nas tabelas de retorno

• Realizar o fechamento (R-4099), a reabertura  e um novo fechamento. Avaliar a gravação do totalizador R-9011, para identificar se apenas o ultimo fechamento fica como válido nas tabelas de retorno
• Realizar o fechamento de um período que já se encontra fechado no RET (Simular via APSDU como se o fechamento tivesse sido efetuado pelo eCac). Avaliar se as mensagens de erro de transmissão são apresentadas no PO UI.

Relatórios

• Gerar o relatório de todos os eventos transmitidos e comparar com o valor apresentado na tabela espelho

• Gerar o relatório dos totalizadores.
• Gerar relatório de lucros e dividendos, disponíveis em outras ações da tabela espelho dos eventos R-4010/R-4020

Contadores dos documentos dos cards e pendentes de apuração R-4010/R-4020

Para contagem da quantidade de documentos, será considerado a fatura e pagamentos com a mesma chave: NUMERO + SERIE + PARTICIPANTE como sendo 1 único documento, porém nos casos de pagamentos, para exibição dos valor bruto e os valores dos impostos será considerado a chave NUMERO + SERIE + PARCELA + SEQUENCIAL + PARTICIPANTE, para sumarizar os valores. 

No caso do R-4020, quando houver IR na emissão e PCC nos pagamentos, irá considerar o valor bruto somente o valor da fatura, pois o valor total do movimento já está sendo considerado na fatura.

Exemplo: 

1) R-4020 Fatura com IR na emissão e PCC no pagamento, com 2 baixas parciais:

Como a FAT e PGT possuem o mesmo NUMERO + SERIE + PARTICIPANTE, deverá ser exibido no card do evento como sendo apenas 1 documento.

Na tela de pendentes de apuração, deverá considerar também como sendo somente 1 documento em Total docs. e como o valor bruto já está totalizado na FATURA, não deve somar os valores brutos dos pagamentos, somente deve sumarizar os tributos dos pagamentos:

2) R-4020 Fatura com IR e PCC no pagamento, com 2 baixas parciais:

Como os PGTs possuem o mesmo NUMERO + SERIE + PARTICIPANTE, deverá ser exibido no card do evento como sendo apenas 1 documento.

Na tela de pendentes de apuração, deverá considerar também como sendo somente 1 documento em Total docs. e como não existe a fatura, deve somar os valores brutos e tributos dos pagamentos:

ECF

Apuração LALUR/LACS

GIA

• Integrar documentos fiscais de entrada e saída com cálculo de ICMS Próprio, ICMS ST, notas fiscais de transporte com código de DIPAM B (SPDIPAM23), Notas fiscais de transferência de crédito/débito e notas fiscais de venda para zona franca de Manaus. A integração destes documentos deverá ser realizada via TSI.

• Integrar apurações de ICMS com códigos de ajustes (subitem) necessários para gerar os registros CR=20, CR=25 e CR=28. Realizar a integração via TSI.
• Gerar arquivo da GIA e validá-lo no programa de validação da GIA-SP. Devem ser gerados os registros CR=05, CR=10, CR=14, CR=18, CR=20, CR=25, CR=28 e CR=30. Apenas o CR=28 pode apresentar erro de validação (numero do protocolo de autenticação inválido).
• Integrar documentos fiscais de entrada e saída com cálculo de ICMS Próprio, ICMS ST, notas fiscais de transporte com código de DIPAM B (SPDIPAM23), Notas fiscais de transferência de crédito/débito e notas fiscais de venda para zona franca de Manaus. A integração destes documentos deverá ser realizada via extrator fiscal (banco a banco e via txt).
• Integrar apurações de ICMS com códigos de ajustes (subitem) necessários para gerar os registros CR=20, CR=25 e CR=28. Realizar a integração via Extrator fiscal (banco a banco e txt).
• Gerar arquivo da GIA e validá-lo no programa de validação da GIA-SP. Devem ser gerados os registros CR=05, CR=10, CR=14, CR=18, CR=20, CR=25, CR=28 e CR=30. Apenas o CR=28 pode apresentar erro de validação (número do protocolo de autenticação inválido).
• Validar arquivo da GIA-SP com notas de serviço de entrada e saída com os CFOPs: 5933/6933/1933/2933. Utilizar notas fiscais de modelo 55 (SPED) e 01 (NFS). Apenas os valores das notas de modelo 55 devem compor o arquivo.

Apuração de IPI

Integração 

AUTOCONTIDAS NOVA VERSÃO - FWBULK

• A utilização do FWBulk na inserção de registros nas tabelas autocontidas, somente ocorre para tabelas vazias.

• Não utilizar campos virtuais na construção do aHeader da autocontidas.
• O retorno de aBody deve conter a mesma quantidade de colunas de aHeader.
• Ao zerar o parâmetro MV_VAUTCON, as tabelas autocontidas terão seus registros deletados para ser incluídos pelo FwBulk, exceto as tabelas que são abertas para inclusão/alteração (C0A, C1A, C3Z, C6U, C0Y, T71, C8A, CUF, CMM, C9V, V6Z).
• Sempre que atualizarmos uma autocontidas, precisaremos atualizar os baselines da base da automação.
• ALTCON: Ao atualizar/incluir um novo registro em uma autocontida já existente, seguir o passo a passo:

1) Mudar a versão da autocontida no fonte TAFACONT.prw. Exemplo: 

2) Mudar a versão da autocontida no fonte da Autocontida. Exemplo TAFA001.prw: 

3) Incluir no aHeader, o campo fake Alias+"_ALTCON", no fonte da Autocontida. Exemplo no TAFA001.prw será incluído o campo C01_ALTCON (obs: colocar sempre esta coluna na última posição) : 

4) Incluir no aBody que será incluído ou alterado a versão, na posição do campo fake "_ALTCON". Exemplo no TAFA001.prw: 

• ALTCON: A TAFACONT irá verificar se existe o campo "ALTCON" no aHeader de cada autocontida, caso existir, somente irá atualizar o registro onde existir a versão no aBody, e esta versão for superior a versão do ambiente. Caso não exista o campo fake "ALTCON", e a versão da autocontida for superior a versão do ambiente, ocorrerá a atualização de todos os registros de aBody.
• A versão da autocontida com o FwBulk e a atualização pontual através do controle do campo "ALTCON" será a partir da 1032.
• Observação 1 : Como a nova implementação utiliza a classe FWBulk, para a sua utilização é necessário possuir DBAccess com versão maior ou igual a 20181212 e versão de lib maior ou igual a 20201009 (FWBulk).
• Observação 2 : Conteúdo de campos numéricos agora são aceitos no aBody, tanto como caracter (entre aspas) ou numéricos (sem aspas): 

SX9

Débito Técnico ( ausência SX9 / AtuSx / SetRelation MVC )

• Relacionamento pai e filho no MVC

  Débito Técnico: Criar um MVC com setRelation e não existir no atusx o relacionamento com pai e filho, nesse cenário o proposto é:
  Utilizar a chave composta no domínio e contra domínio (sem a filial antes), pois o campo X9_USEFIL já é S(im);
  Vincular filial e chave forte ambos com 1(-Sim);
  Pois a chave já está completa e se mudar o compartilhamento do pai/filho, todos devem seguir o mesmo compartilhamento.
  Nesse situação a recomendação é X9_USEFIL = S, X9_VINFIL = 1-Sim e X9_CHVFOR = 1-Sim
  Ex:
  

Relacionamento FK com autocontidas e outras tabelas

• Relacionamento FK com autocontidas

  Nesse situação a recomendação é X9_USEFIL = S, X9_VINFIL = 2-Não e X9_CHVFOR = 2-Não
  Já que a autocontidas não está atrelada a filial e sim ID e dificilmente é mudado o compartilhamento da autocontidas por ser compartilhada
  Ex:
  

• Relacionamento com tabelas de cadastros

  Nesse situação a recomendação é X9_USEFIL = S, X9_VINFIL = 2-Não e X9_CHVFOR = 2-Não

Já que o compartilhamento da tabela de cadastro não está atrelado a filial do cadastro de movimentos, somente deve-se utilizar Usar Filial = Sim, mas o Vinc. Filial e Chave Forte deve ser igual a Não, pois por exemplo, a tabela C1H-Participantes não deve, obrigatoriamente, ter o mesmo compartilhamento da C20-Notas Fiscais.

• Relacionamento entre tabelas de movimentos dependentes

  Nesse situação a recomendação é X9_USEFIL = S, X9_VINFIL = 1-Sim e X9_CHVFOR = 1-Sim

Existem tabelas de movimentos que não fazem parte do mesmo MVC, porém devem possuir o mesmo compartilhamento, por exemplo, a tabela LEM-Faturas deve ter o mesmo compartilhamento da V3U-Pagamentos. Outro exemplo, a tabela C0T-Dispositivo AIDF deve ter o mesmo compartilhamento da C20-Notas fiscais.

• Autorrelacionamento de tabelas (tabela se relaciona com ela mesma por outra chave)
  Não é necessário o uso de 'Vinc. Filial' (X9_VINFIL) como 'Sim'. Neste caso, configure o 'Vinc. Filial' (X9_VINFIL) para 'Não', para que as validações de integridade usando o SX9, sejam feitas corretamente.
  
  
• Relacionamnto entre tabelas que utilizam os campo _ID e _ID+ATIVO
  Devemos manter ativo apenas o campo _ID+ATIVO, deixando o campo "Habilitar" com o valor "Não" para o campo _ID. Por exemplo:
  No relacionamento entre as tabelas CA4 e C1G, temos os campos C1G_ID e C1G_ID+C1G_ATIVO. Nesse caso, o campo C1G_ID deve receber o conteúdo do campo "Habilitar" com o valor "Não".
                                                                                                                                                                                                                            
• Observação: o uso do campo X9_USEFIL = N ocorre somente se o campo a ser comparado não for _FILIAL. Exemplo, algumas tabelas, como a SE2 possui o campo FILORIG, caso precise usar este campo para saber a filial, então deve-se criar o relacionamento como X9_USEFIL = N. Outro exemplo, é nosso campo T0O_FILITE, caso necessite utilizar o relacionamento com este campo ao invés do campo _FILIAL, devemos utilizar como X9_USEFIL = N.

Grupo de campos

• Ao criar novos campos no dicionário de dados, atentar se estes não devem pertencer ao grupo de campos abaixo. Se sim, enviar um email para o GCAD informando o número do pacote, o campo e em qual grupo este deve pertencer:

• Observação: Se o campo utilizava um Template e passou a pertencer a um grupo de campos, não utilizar mais o Template, pois o UPDDISTR não atualiza para o grupo de campos.

Diagnóstico

Lista de Fontes

Ao criar um novo fonte, avaliar se ele é apresentado na opção de Lista de Fontes do Diagnóstico do TAF. Fontes de nossa propriedade e que não possuem "TAF" em sua composição, devem ser inseridos de forma manual, como por exemplo "WSTSSSETUP.PRW".

VALIDAÇÕES OBRIGATÓRIAS

• SONARQUBE - Obrigatório utilizar o PLUG IN do link a seguir para expedição da issue ( https://code.engpro.totvs.com.br/engpro/vscode-engpro-extension/wiki/Sonar-%28PT-BR%29 );

• QueryAnalyzer - Quando existir query submeter a mesma e corrigir os erros encontrados ( https://esp.engpro.totvs.com.br/menu/query-analyzer );
• QueryAnalyzer com IA - Quando existir query submeter a mesma onde será enviado um e-mail para equipe de DBA que irá retornar com as correções e corrigir os erros encontrados ( https://esp.engpro.totvs.com.br/menu/query-analyzer );
• Robô de Automação - Obrigatório executar o robô de automação para a rotina que foi alterada e corrigir as quebras que forem apresentadas ( mesmo quando já for um erro pré-existente);
• Issues x Cobertura - Obrigatório garantir que as linhas alteradas tiveram cobertura de teste
• Ao realizar expedição de alteração de dicionário (UPDDISTR), rodar UPDTAF para garantir que não sobreponha as alterações realizadas via ATUSX. 
• Jira - Caso a issue seja crítica, analisar a causa raiz e documentar no campo "Causa Ocorrência" localizado dentro da opção EDIT/EDITAR do jira.
• Proteção de chamada de função externa quando utilizada ( Não seja de domínio do TAF, como por exemplo - LIB, outros módulos, etc.. );
• Proteção de dicionário de dados quando criado campo, índice, gatilho, consulta padrão, tabela;
• Atualização da documentação da rotina em questão com o novo incremento que foi feito ( deve ser aplicado quando não for apenas ajuste/correção de erro );
• Criação de documento de referência para novos parâmetros ou novas funcionalidades;
• Atualização da documentação para Expedição Continua ou a War Room incluir os dicionários liberados, após expedição do pacote (Atualização de Dicionário - TAF);
• Atualização da planilha de Release Notes (https://docs.google.com/spreadsheets/d/1yh9Ptyw9qV_p3BqdJuOCl72Hd5wMA3N4HEHgPKXZGCk/edit#gid=0);
• Atualização da documentação do TAF a lista de parâmetros, quando criar um novo parâmetro (TOTVS Automação Fiscal - TAF 12);
• Não esquecer de incluir no DT, no item Assuntos Relacionados, os links das centralizadas como EFD-Reinf, Painel REINF, TSI - TAF Service Integration, Obrigação ECF - Escrituração Contábil Fiscal - ECF;
• Quando for alterar o nome de alguma pasta no TFS, abrir uma issue somente para realizar a alteração, sem commit de fonte;
• Quando for criada a automação de uma API, devemos solicitar a inclusão das suites REST no servidor de automação.
• Quando as seguintes rotinas forem alteradas é necessário que seja implementada ao menos uma automação de teste com o TIR:
  • TAF ESOCIAL:
    • TAFA250 - Folha
    • TAFA421 - Trabalhador 
    • TAFA407 - Pagamentos 
    • TAFA403 - Admissão Preliminar 
    • TAFA257 -  CAT 
    • TAFA258 - Monitor Saúde do Trabalhador
    • TAFA264 - Condições Ambientais de Trabalho 
    • TAFA261 - Afastamento 

    • TAFA266 - Desligamento Celetista 

    • TAFA280 - Desligamento TSV

    • TAFA269 - Exclusão de Eventos

PONTOS DE ATENÇÃO NA CODIFICAÇÃO / CODE REVIEW - ADVPL

• Resolver os WARNINGS que ocorrem em tempo de compilação, mantendo sempre o fonte atualizado.

• Eliminar variáveis que não estão sendo utilizadas.
• Utilizar tipagem na declaração de variáveis, e logo após atribuir valor default aquela variável.
• Quando trabalhar com acesso a tabela e campos, utilizar ponteiro indicando o alias referente a este acesso para evitar erros de ambiguidade.
• Quando criado um laço de repetição que alimenta uma string ( por exemplo ao montar o IN de uma query )  deve-se avaliar o tamanho máximo que aquela string pode chegar, evitando assim erros "String size overflow", "Query greater than", etc...
• Proteger o acesso direto a um índice do array/objeto, pois pode ocorrer daquela posição não existir naquele contexto, ocasionando o famoso erro "Array out of bounds".
• Proteger acesso a função/método de outros módulos ou mesmo de Tecnologia/Framework, pois os mesmos não estão contidos no pacote de Expedição Contínua do TAF.
• Quando utilizado uma nova função/método de Tecnologia/Framework, proteger o uso de acordo com a data de liberação documentada, e manter manutenção do legado até que seja descontinuado.
• Proteger acesso a novo dicionário, avaliando se deve ser bloqueado acesso a rotina/processo ou se é possível manter uma jornada de uso pelo cliente. Para garantir que a proteção foi efetiva executar a rotina de verificação de relacionamento no diagnostico, a mesma carrega todos os modelos através de chamadas externas.

• Proteger a utilização de acesso a parâmetro SX6 de sistema utilizando parâmetro de valor default em funções como GetMV(), SuperGetMv().

• Ao criar uma tabela temporária, sempre encerrá-la ao término de uso da mesma (dbCloseArea, a exclusão da tabela é feita automaticamente no encerramento da thread).
• Ao criar um novo parâmetro em uma função já existente, avaliar a necessidade de atribuição de valor Default a esta variável.
• Utilizar a função RetSqlName para consulta a tabelas no banco de dados.

• Não realizar acesso a dicionário em declaração de variável Static, inclusive funções como GetMV(), SuperGetMV() entre outras que acessam parâmetro SX6 do sistema . Variáveis deste tipo são inicializadas sempre que qualquer função/método deste fonte é executado, e pode ser que em algumas situações o ambiente não esteja preparado, causando error.log.

• Principalmente em fontes Web Services e REST, apenas acessar dicionário após garantir que o ambiente está preparado.
• Preferir utilizar DBSeek() e MSSeek() a abertura de tabela temporária quando existir índice para esta consulta.
• Quando utilizado tabela temporária para busca de informações no banco de dados, preferir ordenar a cláusula WHERE de sua query com alguma ordenação mais próxima já existente nos índices da tabela.
• Toda nova implementação deve possuir ao menos 70% de cobertura de linhas de automação;
• Caso a query possua a instrução ORDER BY contendo nomes de campos com alias, é obrigatório utilizar o alias também no SELECT
• A query precisa ser compatível com os bancos de dados DB2, Postgres, Oracle (Versões 11G e posteriores), SQL (versões 2008 e posteriores) e Informix. 
• Realizar a execução do ADVPR nos fontes afetados pela implementação da issue em questão e, caso ocorram quebras, informar ao desenvolvedor e solicitar correção.
• Validar query na ferramenta Query Analyzer para possíveis melhorias de performance da query. 

Dicas para os bancos não homologados

Bancos não homologados para o Protheus mas que são utilizados pelos clientes de outras marcas: Oracle versão 11x e inferiores, SQL 2008 ou inferior, DB2 e Informix.

Foi criado a função TafBdVers() que retorna .T. se a versão do banco for algumas das citadas acima. Avaliar a função TafBdVers() para verificar a versão do banco de dados antes de utilizar FETCH, ChangeQuery e Subqueries em SELECT.

• Não utilizar ChangeQuery para bancos DB2 quando possui subquery, pois o mesmo acrescenta a clausula READ FOR ONLY que gera erro de query quando usado em SELECT em subquery.
• Para substituir a paginação utilizando o FETCH, pode-se utilizar a função ROW_NUMBER que é aceita em todas as versões não homologadas, porém mais lento.
• Não utilizar subqueries em SELECT que faça JOIN com as tabelas que estão no FROM da query principal, pois gera erro de query que não encontrou o Alias.
• Temos a VM com as bases Oracle 11g e SQL 2008 para testes: IP 10.171.80.176, usuário local\Master, senha: Taf2023. Validar as queries no Oracle11, pois se rodar neste banco provavelmente rode também nos outros.
• A versão 11.70 do Informix não aceita a função "Coalesce". A sugestão é usar NVL para bancos de dados Informix.

Variável Global

• Utilizar de maneira que o seu contexto considere o Grupo de Empresas ( cEmpAnt ), e caso utilizar "Gestão de Empresas", também considere a Empresa + Unidade de Negócio ( cFilAnt ) e dependendo da situação, considere até a própria Filial Matriz.

• Pensando em performance na utilização de variável global, deve ser homologado com pelo menos com dois Grupos de Empresas. Realizar a troca de Grupos e verificar se o funcionamento ocorre como esperado em todos os Grupos. Neste ponto, é importante também homologar acessando via SIGAADV ( SIGATAF ) e SIGAMDI, pois ambos possuem comportamento diferente de inicialização e carregamento de ambiente, tabelas e variáveis.

PONTOS DE ATENÇÃO NA CODIFICAÇÃO / CODE REVIEW - ANGULAR

• Evitar a injeção de dependências na sessionStorage quando a informação puder ser tratada pela protheus-lib-core, como por exemplo contexto de Grupo de Empresas, Usuários.

• Proteger acesso a sessionStorage quando contexto de uso estiver apontando para Datasul.
• Ordenar importação de bibliotecas na sequência: Nativas do Angular, outras bibliotecas externas, PO UI, componentes internos compartilhados, componentes internos específicos.
• Utilizar tipagem na declaração de variáveis.
• Avaliar obrigatoriamente se a implementação/ajuste realizado impacta o Middleware, se sim validar também esse contexto, caso contrário realizar todas as tratativas para garantir que a implementação seja visível apenas ao TAF FULL e não gere impacto no Middleware.
• Toda nova implementação deve possuir ao menos 70% de cobertura de linhas de automação;
• É importante que o responsável pelo codereview, baixe a branch e execute o comando: ng test --source-map --code-coverage --no-watch

Projetos de Inovação

Mesmo se o fonte constar no repositório interno D-1, não significa que o mesmo irá para a expedição contínua, portanto é necessário fazer o procedimento abaixo (principalmente para novos diretórios):

• Para garantirmos que as inovações descidas para a master, irão entra na expedição contínua, será necessário baixar protheus_ci(https://code.engpro.totvs.com.br/engpro/Protheus-ci),
  fazer fork, alterar a lista com o novo caminho e extensão e depois fazer o commit, push e pull request.
  
  
• Para garantir que os fontes irão constar na expedição contínua conferir a data dos fontes no arquivo taf.yaml, verificar se atualizou no seguinte caminho:
  https://arte.engpro.totvs.com.br/engenharia/expedicao_continua/config/results_master/
  
  

• Exemplo na descida do projeto de inovação do smartview ( https://code.engpro.totvs.com.br/engpro/protheus-ci/src/branch/master/Config/taf.yaml ):

  "Protheus_Padrao/Fontes_Doc/Master/Fontes/TAF/SmartView/**/*"

  "Protheus_Padrao/Fontes_Doc/Master/Fontes/treports/taf/**/*"