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 apos a manutenção.
• A documentacão do servico 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 simplismente sobrepor o client atual, deve-se realizar um merge incluindo as novas propriedades criadas.
• Para validação de funcionalides 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 incluido o XML diretamente na SPED400 e alterando o status do registro no TAF para 2)

Exclusão de Eventos

• 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 Transmisão de uma folha com multiplos vinculos na mesma filial 
• Validar a Integração e Transmisão de uma folha com multiplos vinculos em filiais diferentes
• Validar a Integração e Transmissão de uma folha agluitnada
• Validar a Integração e Transmissão de uma folha agluitnada 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 Transmisão de um pagamento  com multiplos vinculos na mesma filial
• Validar a Integração e Transmisão de um pagamento  com multiplos vinculos em filiais diferentes
• Validar a Integração e Transmissão de um pagamento  agluitnad
• Validar a Integração e Transmissão de uma folha agluitnada 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

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

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

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

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

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

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

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;