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.
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;
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.
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.
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.
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.
Exclusão de EventosIntegraçã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.
As validações abaixo podem ser realizadas através de um script de teste:
*Em Desenvolvimento
As validações abaixo podem ser realizadas através de um script de teste:
As validações abaixo podem ser realizadas através de um script de teste:
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.
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.
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;
Gerar XML do evento através da opção "Gerar XML / Gerar XML em lote";
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.
(Automatizado ? ) Validar a remoção do contribuinte no ambiente de testes da Receita
Validar a inclusão e transmissão de um evento de processo referenciado (R-1070)
Validar e transmitir um evento R-2010 com processo referenciado
Validar e transmitir um evento R-2020 com processo referenciado
Validar e transmitir um evento R-2030 com processo referenciado
Validar e transmitir um evento R-2040 com processo referenciado
Validar e transmitir um evento R-2050 com processo referenciado
Validar e transmitir um evento R-2055 com processo referenciado
Validar e transmitir um evento R-2060 com processo referenciado
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-4020 com processo referenciado e IR na emissão (Nota fiscal)
Exemplo 1: Fatura emitida em 05/11 de 12.000 reais com 2 parcelas (IR e PCC no pagamento):
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):
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):
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):
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.
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
Gerar o relatório de todos os eventos transmitidos e comparar com o valor apresentado na tabela espelho
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:
ORIGEM | NUMERO | SERIE | PARTICIPANTE | SEQUENCIAL | VALOR BRUTO | IR | PIS/COFINS/CSLL |
---|---|---|---|---|---|---|---|
FAT | 0001001-1 | A | F4020001 | - | R$ 1000,00 | R$ 15,00 | R$ 0,00 |
PGT | 0001001-1 | A | F4020001 | 001 | R$ 600,00 | R$ 0,00 | R$ 27,90 |
PGT | 0001001-1 | A | F4020001 | 002 | R$ 400,00 | R$ 0,00 | R$ 18,60 |
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:
FORNECEDOR | TOTAL DOCS. | VALOR BRUTO | IR | PIS/COFINS/CSLL |
---|---|---|---|---|
F4020001 | 1 | R$ 1000,00 | R$ 15,00 | R$ 46,50 |
2) R-4020 Fatura com IR e PCC no pagamento, com 2 baixas parciais:
ORIGEM | NUMERO | SERIE | PARTICIPANTE | SEQUENCIAL | VALOR BRUTO | IR | PIS/COFINS/CSLL |
---|---|---|---|---|---|---|---|
PGT | 0002001-1 | B | F4020001 | 001 | R$ 600,00 | R$ 9,00 | R$ 27,90 |
PGT | 0002001-1 | B | F4020001 | 002 | R$ 400,00 | R$ 6,00 | R$ 18,60 |
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:
FORNECEDOR | TOTAL DOCS. | VALOR BRUTO | IR | PIS/COFINS/CSLL |
---|---|---|---|---|
F4020001 | 1 | R$ 1000,00 | R$ 15,00 | R$ 46,50 |
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.
A utilização do FWBulk na inserção de registros nas tabelas autocontidas, somente ocorre para tabelas vazias.
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:
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 é:Relacionamento FK com autocontidas
Nesse situação a recomendação é X9_USEFIL = S, X9_VINFIL = 2-Não e X9_CHVFOR = 2-NãoRelacionamento com tabelas de cadastros
Nesse situação a recomendação é X9_USEFIL = S, X9_VINFIL = 2-Não e X9_CHVFOR = 2-NãoJá 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-SimExistem 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.
Grupo de Campos | Tamanho | Tam Min | Tam Max |
---|---|---|---|
061-IDs TAF sem FWUUID | 10 | 10 | 15 |
062-CHVNF | 15 | 15 | 20 |
078-VERSÃO E VERANT | 14 | 14 | 100 |
079-STATUS | 1 | 1 | 10 |
080-PROTUL e PROTPN | 44 | 1 | 100 |
081-EVENTO | 1 | 1 | 10 |
082-ATIVO | 1 | 1 | 10 |
085-ID TAF (TAFGeraID) | 36 | 36 | 40 |
088-NUMPRO Processo Referenciado | 10 | 10 | 30 |
156-CODCUS CENTRO DE CUSTO TAF | 6 | 6 | 20 |
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".
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 );
TAFA266 - Desligamento Celetista
TAFA280 - Desligamento TSV
TAFA269 - Exclusão de Eventos
Resolver os WARNINGS que ocorrem em tempo de compilação, mantendo sempre o fonte atualizado.
Proteger a utilização de acesso a parâmetro SX6 de sistema utilizando parâmetro de valor default em funções como GetMV(), SuperGetMv().
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.
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.
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.
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.
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):
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/**/*" |