Exibir origem

CONTEÚDO

Visão Geral
Manutenção
1. Telas THF
Apoio
Apoio ao cliente
Rejeições para o atendimento
Rejeições para o desenvolvimento

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:

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

1. Configuração do BIRT(.jar)
2. Configuração do ambiente (Caminhos físicos das pastas rptdesign e datasul-framework.propiets)
3. Enviar o BAKA executado no ambiente
4. Enviar print do retorno em tela do BAKA
5. Enviar arquivo impresso em pdf
6. Executar o relatório no próprio ERP para verificar se está idêntico ao do Meu RH
7. Ocorre em todos os arquivos baixados?

1. Obrigatório captura dos erros apresentados no console do navegador (F12 - Console), e captura das chamadas dos serviços e seus respectivos retornos JSON (F12 - Network -> Headers/Response).
2. Versão do fonte backend
3. Prints dos programas relacionados no ERP(Parametrizações)

3.1 Em caso de férias, enviar os prints:

3.1.1 FP0540
3.1.2 FP1800
3.1.3 Qualquer outra tela relacionada com a situação reportada

3.2 Em caso de ponto, enviar os prints:

3.2.1 FP0580 - Print da aba Ponto
3.2.2 FP1601
3.2.3 PE5000
3.2.4 PE3000 - Em casos de hora extra

4. Logs de Appserver e Jboss ou Tomcat
5. Print da permissão do usuário no programa SEC
6. Backup do grupo de tabelas relacionadas ao reqferias(Quando for issues relacionadas a férias)
7. 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)

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

Exemplo de Capturas de tela para abertura de issue Meu RH Datasul

TELAS THF

Quando o problema for relacionado a telas THF é necessário evidencias todos os passos descritos na documentação Telas THF para aprovações/reprovações por usuário de RH

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. (alinhar atendimento)
Quando o item já foi resolvido no cliente com configurações/entendimento pode ser rejeitada sem alinhamento. (alinhar atendimento)

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>