Histórico da Página
Versões comparadas
Chave
- Esta linha foi adicionada.
- Esta linha foi removida.
- A formatação mudou.
Aviso |
---|
Não publicar esta página |
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).
AUTOCONTIDAS NOVA VERSÃO - FWBULK
- A utilização do FWBulk na inserção de novos 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).
- 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 set relation 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 e X9_CHVFOR = 1
Ex:
Relacionamento FK com autocontidas
- Relacionamento FK com autocontidas
Nesse situação a recomendação é X9_USEFIL = S, X9_VINFIL = 2 e X9_CHVFOR = 2
Já que a autocontidas não está atrelada a filial e sim ID e dificilmente é mudado o compartilhamento da autocontidas por ser compartilhada
Ex:
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
- 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 );
- 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).
- 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
- TAF ESOCIAL:
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
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;
Índice |
---|