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 que devem ser enviados na issue:

Geral (deve ter em todas as issues)

Login

Arquivos PDF

Telas THF

Férias

Ponto

1. Ocorre em aparelhos android ou IOS?
2. Qual versão do APP ocorre a situação?
3. Ocorre no Browser?
4. Versão do WAR.
5. Ocorre em ambiente de produção ou homologação?
6. Cliente utilizando ambiente em quarentena ou libesp? Caso positivo, realizar teste sem o ambiente em libesp.
7. Link externo com QR Code, usuário e senha(Quando issues relacionadas ao Login)
8. Ambiente JBOSS ou TOMCAT?
9. Banco de dados
10. Versão do frontend?
11. Ocorre para todos os funcionários?

12. Logs de Appserver e Jboss ou Tomcat
13. Print da permissão do usuário no programa SEC

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

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.

Testar no browser do aparelho.

No Arquitetura Mobile, aba Datasul checar a as requisições necessárias e anexar print.

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

Configuração do BIRT(.jar)

Configuração do ambiente (Caminhos físicos das pastas rptdesign e datasul-framework.propiets)

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 para verificar se está idêntico ao do Meu RH

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

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>