Exibir origem

01. VISÃO GERAL

O objetivo deste documento é criar um modelo de abertura de issues com o detalhamento necessário para uma atuação mais efetiva do desenvolvimento.

Documentações bases de datasul: https://tdn.totvs.com/x/6dEWHg | https://tdn.totvs.com/x/H0xYGw

02. MANUTENÇÃO

Todos os passos devem ser evidenciados e anexados na issue:

Descritivo do erro/solução detalhado e não genérico (evidência via texto, imagem ou vídeo).
Base simulada (se possível em ambiente não corporativo, para não perder a simulação).
Base simulada na versão mais atual disponível no mercado.

Abaixo estão validações e questionamentos, mínimos, que devem ser enviados na issue:

Geral (deve ter em todas as issues)

Login

Arquivos PDF

Telas THF

1. Ambiente JBOSS ou TOMCAT?
2. Ocorre em aparelhos android e/ou iOS?
3. Qual versão do APP ocorre a situação?
4. Ocorre no Browser?
5. Ocorre em ambiente de produção e/ou homologação?
6. Cliente utilizando ambiente em quarentena ou libesp? Caso positivo, realizar teste sem o ambiente em libesp.
7. Qual banco de dados?
8. Versão do frontend?
9. Ocorre para todos os funcionários?
10. Logs de Appserver e JBOSS ou Tomcat.
11. Print da permissão do usuário no programa SEC.
12. Tipo de estrutura de report (Unidade de lotação, exceção unidade de lotação, time de trabalho ou time de trabalho com exceção de unidade de lotação).
13. Qual console?
14. Versões superiores a 12.1.34 deve anexar o extrato de versões DFWKTOOLS-4329 DT Implementação do Extrato de versão para o appserver

Não temos como garantir que os redirecionamentos internos, proxy reversos, balanceamento dos clientes estão corretos. Portanto, é requisito que o cliente faça um teste com ambiente interno e sem redirecionamentos.

Teste sem HTTPS.

No Arquitetura Mobile, aba Datasul checar a as requisições necessárias e anexar print para descartamos alguns problemas relacionados as APIs de frame.

Print para do CORS funcionando, para verificar consulte o Arquitetura Mobile aba Cors.

Link externo com QR Code, usuário e senha, caso o cliente não queira passar a senha por questões da LGPD, utilizar o TOTVS Minha Senha

Se utilizar o login por AD, fazer um teste com um usuário sem AD.

Configuração e ambiente, verificar todo o material de apoio:

Relatório para Testes na rotina BIRT (esse link é do frame, é essencial que tudo esteja funcionando antes de continuar a análise pelo RH)

Download de PDF - Datasul JBOSS

Download de PDF - Datasul Tomcat

Enviar o BAKA executado no ambiente.

Enviar print do retorno em tela do BAKA.

Enviar arquivo impresso em pdf.

Executar o relatório no próprio ERP e enviar para comparação.

Ocorre em todos os arquivos baixados?

Evidenciar todos os passos descritos na documentação Telas THF para aprovações/reprovações por usuário de RH

Problema somente no app

Executar o procedimento descrito em Script do Postman para validar ambientes Datasul com Meu RH - Ionic 5

Testar no browser do aparelho.

Versão do android/iOS utilizado.

Férias

Ponto

FP0540

FP1800

Qualquer outra tela relacionada com a situação reportada

Backup do grupo de tabelas relacionadas ao reqferias

FP0580 - Print da aba Ponto

FP1601

PE5000

PE3000 - Em casos de hora extra

Obs.: As associadas devem possuir a mesma documentação do item "Para todas as issues".

03. APOIO

O apoio deve ser aberto quando todos os passos da manutenção já foram realizados, evidenciados e anexados na issue, porém o atendimento precisa de algum apoio.

Situação estressada internamente na equipe antes de gerar a issue (enviar a base quando houver).
Descrição dos passos realizados até o momento da criação da issue (histórico).

04. APOIO AO CLIENTE

O Apoio - Cliente deve ser aberto quando todos os passos da manutenção já foram realizados, evidenciados e anexados na issue, porém a partir da análise de todas as evidência o desenvolvimento precisa analisar diretamente a base do cliente.

Situação estressada internamente na equipe antes de gerar a issue (enviar a base quando houver).
Descrição dos passos realizados até o momento da criação da issue (histórico).

05. REJEIÇÕES PARA O ATENDIMENTO

Acordos:

O desenvolvimento tem até 30 dias para fazer o grooming inicial das issues e verificar se a situação é pertinente.
Quando alguma dessas informações estiverem faltando nas issues o analista do atendimento deve ser acionado para envia-las em até 2 dias.
Todas as rejeições devem alinhadas com o analista e a líder ([email protected] ou prime [email protected]) e aguardaremos resposta em até 2 dias para prosseguir com a rejeição.
Quando a issue é aberta no mesmo dia pode ser rejeitada sem alinhamento.
Quando o item já foi resolvido no cliente com configurações/entendimento pode ser rejeitada sem alinhamento.

06. REJEIÇÕES PARA O DESENVOLVIMENTO

Quando o cliente retornar que a correção não foi efetiva:

O atendimento deverá conferir se o aplicou as correções corretamente.
Caso o problema ainda ocorra no ambiente do cliente, as correções enviadas deve ser aplicada em ambiente atualizado. Sendo o problema simulado deverá abrir uma issue do tipo Rejeição - Manutenção.
Todos os passos da manutenção devem ser realizados, evidenciados e anexados na issue.

<!-- esconder o menu --> 


<style>
div.theme-default .ia-splitter #main {
    margin-left: 0px;
}
.ia-fixed-sidebar, .ia-splitter-left {
    display: none;
}
#main {
    padding-left: 10px;
    padding-right: 10px;
    overflow-x: hidden;
}

.aui-header-primary .aui-nav,  .aui-page-panel {
    margin-left: 0px !important;
}
.aui-header-primary .aui-nav {
    margin-left: 0px !important;
}
</style>