Inserir no quadro ao lado apenas os anexos necessários para a ocorrência. (Para inserir Anexo: Posicione o cursos no quadro ao lado Ctrl + M, depois clicar no menu "Anexo à está pagina" em seguida clicar em "Enviar Arquivo").
Informar a descrição do erro, e ao abrir a issue utilizar a mesma descrição para o Summary ( Resumo / Titulo) da issue na integração do zendesk com o Jira
AO RODAR A PONAPI01 ESTÃO SENDO CARREGADAS MARCAÇÕES NA TABELA RR1 COM CÓDIGO NSR NO CAMPO RR1_CODNSR= '0' E SUBINDO SEM NUMERAÇÃO NO CAMPO RR1_CODPIS
Detalhamento / Observações
(espaço para detalhar o cenário que o erro ocorre e observações analisadas, observações de legislação, etc)
Ambiente totalmente atualizado com o RPO D-1 em 11/05/2023 - Não reproduz o problema, pois com o PONAPI01 está com data em 10/05/2023
Ambiente com a expedição continua do RH reproduz o problema com data da PONAPIA01 em
Qual o entendimento do que seria correto / Sugestão de Ajuste
(espaço para detalhar a sugestão de ajuste ou o entendimento do que seria correto.
Ao rodar a PONAPI01 com data em 17/04/2023 , disponivel no pacote da expedição continua até o momento(13/05) , algumas marcações estão subindo para RR1 com o RR1_CODNSR=0 e sem PIS. Este problema na RR1 estava impactando nas tabelas RFE e SP8, subindo as marcações indevidamente com os campos respectivos RFE_IDORG e P8_IDORG com conteúdo '0' e consequentemente gerando impactos como multiplicidade de marcações e diversas marcações rejeitadas na SP8, inclusive impactando na performance do processo das próximas leituras das marcações, pois as tabelas estavam sendo populadas com resquicios devido à este incidente;
Caso utilizado o D-1 com a rotina na versão 10/05/2023, que foi ajustado na ISSUE DRHJORNPRT-4836, o problema não ocorre. As marcações mesmo sem PIS são carregadas com seus devidos NSRs no campo RR1_CODNSR e preenchido com base no RR1_CODCPF.
Existe link com legislação
Se existir link com legislação ou embasamento legal informar
Link:
Em caso de Melhoria de Performance anexar o Log Profile:
Verificar se as analises foram realizadas de acordo com o comitê de performance. E utilizar no zendesk a Macro Performance Modelo: Abertura de Issue
Zendesk
Antes da Abertura avaliar Criticidade, Causa e Tipo da Issue;
Avaliar catalogo;
Aplicar Macro internaTransferência Manutenção
Na abertura da issue utilizar a mesma descrição para o Summary ( Resumo / Titulo) da issue na integração do zendesk com o Jira, porque o titulo da issue tem que ser coerente com o problema.
Após abrir a issue informar para o cliente o código da issue aberta Macro:Comunicar ao Cliente sobre ISSUE
TDN
Passo a passo com print de telas. Não utilizar videos ou gifs na evidência, vídeos são permitidos apenas com alinhamento;
Analisar se os prints estão legíveis.
Descrever osparâmetros e em caso de duvidas verifique no fonte, e compare com os parâmetros do cliente;
Sempre colocar telasTurno, Regra de apontamento (todas as abas) e Tabela de horário padrão;
Se for relatório encaminhar o print com todas as perguntas preenchidas;
Encaminhar Totvs Replay - (inserir no tópico de anexos ↑);
Se for legislação verificar antes de abrir a issue se existe o embasamento da consultoria e se foi feito alinhamento.
Dica
Testar alterando parâmetros e mnemônicos para ter certeza que é erro ou configuração. As orientações acima são para fazer check list da issue, entretanto mais informações podem ser adicionadas de acordo com a necessidade.
Insira abaixo a evidência de erro: Passo a passo print de telas, a cada etapa detalhar o que foi feito.
Inserir anexos apenas no quadro tópico de anexo
1. Passo
-Parâmetros MV_APICLO do cliente:
-Se rodar a PONAPI01 com a versão 17/04/2023 do pacote publicado da expedição continua do RH com data em 09/05, as marcações sobem na RR1 com o RR1_CODNSR=0, veja exemplos abaixo:
Da forma que fica a RR1 se rodar a leitura e apontamento as marcações sobem de forma errada com NSR nos campos RFE_IDORG e P8_IDORG de forma errada
-Em algum momento ao rodar mais vezes a PONAPI01 as mesmas marcações passam a subir novamente, porém com NSR para o mesmo CPF, assim ao rodar a leitura-PONM010, o sistema grava as marcações com NSR e rejeita as marcações na SP8 que possuem NSR, com isso gerando rejeições indevidas na tabela e populando a tabela RFE desnecessariamente, veja:
-Caso utilizamos o PONAPI01 para rodar com data na versão de 10/05/2023, referente a manutenção feita pela ISSUE DRHJORNPRT-4836. O problema não é mais apresentado e as marcações sobem corretamente na RR1 com as numerações de PIS no primeiro processamento, veja:
-Ao rodar a PONAPI01 com data em 10/05/2023 as marcações sobem com RR1_CODNSR corretamente:
Ao executar a leitura neste cenário as marcações sobem corretamente, veja:
