Gestão de Pessoas | HCM - 6.10.3.85

Problema: ao efetuar o fechamento do SST para colaboradores que já tinham o fechamento concluído, o sistema gerava novamente todos esses colaboradores desnecessariamente.

Correção efetuada: ajustamos o sistema para efetuar o fechamento do SST apenas para colaboradores que ainda não possuem o fechamento ou que foram excluídos.

Problema: ao transferir um colaborador para uma empresa com filial empregadora, o leiaute S-1210 da competência anterior à transferência, mesmo com pagamento na competência atual da transferência, não estava sendo emitido para a empresa de origem.

Correção efetuada: ajustamos a geração do leiaute S-1210 para gerar corretamente o pagamento referente à empresa de origem.

Problema: quando o envio do leiaute S-1200 estava definido para o modo Manual, ao enviar os eventos periódicos, havia um S-1200 com recibo retornado. Ao gerar o leiaute S-3000 para a exclusão desse S-1200, o S-3000 ficava no aguardo para o envio manual pelo usuário. Com isso, antes de enviar o S-3000, um novo S-1200 era gerado. Esse novo S-1200 era enviado ao eSocial, retornando com recibo para que, somente em seguida, fosse enviado o S-3000. Porém, o leiaute S-3000 retornava com erro, pois o recibo que deveria ser excluído foi retificado pelo novo S-1200.

Correção efetuada: otimizamos a geração dos leiautes periódicos (S-1200, S-1210, S-1202 e S-1207), corrigindo o envio desses leiautes para que o erro mencionado anteriormente não ocorra. Após essa correção, ao tentar gerar um leiaute periódico que tenha um evento S-3000 pendente, ocorrerá o seguinte processo:

• Caso o S-3000 esteja com a situação 1 - Erro Retornado, a situação será alterada para 11 - Erro tratado (Evento excluído) e o S-1200 será processado normalmente;
• Caso o S-3000 ainda esteja pendente (sem recibo), a geração do leiaute S-1200 será bloqueada. Nesse caso, a seguinte mensagem será exibida no log de processamento:

Problema: nas Definições do eSocial, ao alterar o campo Gerar eventos da opção 5 - Eventos da folha e Reclamatória para uma opção com SST (1 - Eventos de folha e de SST, 3 - Somente Eventos de SST ou 4 - Eventos da folha, SST e Reclamatória), o sistema não preenchia o campo Início SST com a data sugerida.

Correção efetuada: ajustamos o sistema para sempre preencher a data sugerida de início do SST quando selecionada uma opção que contenha eventos de SST no campo Gerar eventos.

Problema: o sistema não permitia gerar uma retificação do envio do leiaute S-2190 para um colaborador que ainda não tinha vínculo com eSocial (S-2200 ou S-2300 enviados), apresentando a seguinte mensagem de bloqueio Data de Admissão deve ser posterior à data de hoje.

Correção efetuada: ajustamos a consistência da tela para, quando o colaborador ainda não possuir o envio do leiaute, permitir retificar o leiaute S-2190.

Problema: quando um candidato que já tinha sido efetivado através do Recrutamento e Seleção era posteriormente importado via Admissão Digital, o sistema não atualizava o status do candidato para Admissão Concluída na plataforma de Admissão Digital, devido à ordem de retorno dos registros no banco de dados.

Correção efetuada: ajustamos a busca da informação do candidato para integração com a Admissão Digital, modificando-a para buscar pelo código do candidato junto ao código da requisição. Além disso, ajustamos a rotina para enviar corretamente a informação para a Admissão Digital, solicitando a atualização do status para Admissão Concluída.

Adicionamos uma nota à documentação de reestruturação postos de trabalho para esclarecer que essa é um das telas do sistema que utilizam abrangências, logo, alguns usuários podem não conseguir visualizar todos os postos gerados. Além disso, adicionamos um exemplo e um link para a documentação sobre Abrangências.

Problema: ao anexar um documento e, em seguida, clicar em Alterar, posteriormente, se clicar no botão Excluir, o documento aparentemente era removido da tela. No entanto, ao clicar em Alterar novamente, identificamos que o documento não era realmente excluído.

Correção efetuada: alteramos o sistema para que, ao clicar no botão Excluir na parte inferior (referente ao anexo) e posteriormente no botão Alterar, o registro seja excluído da visualização na tela.

Incluímos uma observação no campo Valor de Cálculo, informando que nos casos de Insalubridade e Periculosidade, o percentual indicado nesse campo terá prioridade sobre o percentual informado em Histórico Adicionais (FR038HAD).

Problema: quando a empresa utiliza a opção 7 - Município enquadrado nos critérios da legislação vigente no campo Desoneração Folha disponível em Empresas > Filiais > Cadastro, guia GPS, o sistema aplicava o valor da desoneração sobre colaboradores terceiros.

Correção efetuada: ajustamos a relação de INSS, SEFIP, integração financeira, integração contábil e GPS para não aplicar a desoneração sobre colaboradores terceiros.

Para esclarecer como deve ser realizada a correção dos valores variáveis, adicionamos as seguintes informações às documentações referentes às telas Acumular (campo Corrigir) e Sindicatos (campo Índice Correção Variáveis e guia Médias):

O sistema não corrige automaticamente os valores variáveis durante o cálculo das férias. O comportamento padrão do sistema é sempre buscar o valor que consta em Colaboradores > Férias > Períodos > Cadastro (FR040FER), guia Acumulados, sempre que o campo Valores Variáveis estiver definido como S - Sim no cadastro do sindicato (guia M. Férias Período). Sendo assim, para calcular a média dos valores variáveis, considerando o Índice Correção Variáveis (disponível na guia Cadastro, em Tabelas > Sindicatos > Cadastro (FR014SIN)), o usuário deve:

1. Corrigir os valores, acessando o menu Colaboradores > Férias > Totalizadores > Acumular (FRACUTOT) e definindo o campo Corrigir como S - Sim;
2. Calcular as férias;
3. Verificar se o valores estão corretos em Colaboradores > Férias > Períodos > Cadastro (FR040FER), guia Acumulados.

Realizamos ajustes nas documentações referentes ao leiaute S-1200 - Remuneração de trabalhador vinculado ao Regime Geral de Previdência Social e à tela Origem Cálculos:

• na seção Pagamentos após a rescisão do leiaute S-1200, ajustamos as informações para esclarecer que é possível enviar informações referentes aos valores no leiaute S-1200 após a rescisão somente de categoria eSocial sem vínculo de emprego/estatutário diferente de 721.
• no campo Envios Periódicos eSocial, da tela de origem dos cálculos, ajustamos a descrição do campo para informar que o usuário deve definir se a geração do leiaute S-2299/S-2399/S-1200/S-1202/S-1207 irá considerar a competência da folha origem (opção R - Retificar) ou a competência da data de pagamento do cálculo cadastrado (opção D - Data de Pagamento).

Problema: ao assinalar o campo Baixa Provisão FGTS 13º Salário Adto com N - Não, o sistema gerava uma duplicação de valores na empresa destino para colaboradores que foram transferidos e que receberam adiantamento de 13º salário nas férias na competência anterior.

Correção efetuada: ajustamos a rotina de provisão para evitar a duplicação de valores para colaboradores transferidos que tenham recebido adiantamento de 13º salário nas férias na competência anterior quando o campo Baixa Provisão FGTS 13º Salário Adto está marcado como N - Não

Problema: o afastamento por maternidade empresa cidadã influenciava incorretamente no cálculo de provisão de 13º salário.

Correção efetuada: ajustamos o cálculo de provisão 13º salário para não considerar afastamentos por maternidade empresa cidadã.

Problema: ao listar o arquivo de retorno 002 - S-5002 - IRRF Por Trabalhador (FPAR002.ESO) com o campo Exibir em Colunas assinalado como A - Sim - Analítico, não ocorria a soma dos valores com o mesmo IDEDEV, exibindo apenas os primeiros valores encontrados.

Correção efetuada: ajustamos o arquivo de retorno mencionado para garantir que, ao ser executado com o campo Exibir em Colunas assinalado como A - Sim - Analítico, liste os valores de forma correta, realizando a soma dos valores com o mesmo IDEDEV e TIPINF.

Problema: o modelo 003 - Relação Cálculo - Rateio (FPRF003.OPE) apresentava, de maneira invertida, os valores das colunas Provisão 13º Salário e Provisão Férias, indicando os valores de férias na coluna do 13º salário, e os valores do 13º salário na coluna de férias.

Correção efetuada: ajustamos o modelo para que os valores sejam corretamente atribuídos às suas respectivas colunas.

Acrescentamos mais detalhes à descrição do parâmetro traBHr, da porta Filial_4 do web service com.senior.g5.rh.fp.historicos. A descrição do parâmetro agora informa que caso possua Gestão do Ponto e banco de horas com saldo em aberto, o campo é Obrigatório, e, se não for preenchido, ocorrerá erro ao utilizar o web service com.senior.g5.rh.fp.historicos. Caso não possua saldo em aberto e o preenchimento do campo na requisição seja enviado, também poderá gerar erro, mas o histórico poderá ser criado mesmo assim.

Problema: ao gerar o modelo 001 - Comprovante de Rendimentos Legal (FPIN001.ANU), ocorria duplicação de valores associados ao código de receita 5936 - Reclamatória Trabalhista para colaboradores que possuíam desconto de pensão alimentícia na folha 94 - Reclamatória Trabalhista.

Correção efetuada: realizamos um ajuste no modelo para não duplicar os valores quando há código de receita 5936 - Reclamatória Trabalhista.

Adicionamos uma nota à documentação da variável PerRef para informar que essa variável sempre retorna o primeiro dia do mês do cálculo.

Problema: ao executar a rotina de integração dos valores de plano de saúde para o módulo Administração de Pessoal, o valor não era corretamente integrado.

Correção efetuada: ajustamos a rotina para que o sistema traga o valor correto ao realizar integração dos valores de plano de saúde para o módulo Administração de Pessoal.

Acrescentamos uma nota à documentação do campo Tipo do Cálculo da rotina de Processo Automático de Cálculo para esclarecer que relatórios que exigem a tela de entrada não irão funcionar no processo automático de geração de eventos, pois não há iteração com o usuário para informar os parâmetros.

Problema: ao digitar marcações em pares de forma sequencial, a partir da segunda marcação elas eram alocadas em datas aleatórias.

Correção efetuada: ajustamos o sistema para que não aloque as marcações em datas aleatórias mesmo quando digitado vários colaboradores ou dias diferentes em sequência.

Acrescentamos uma nota de destaque na documentação do campo Gerar Solicitação na Admissão da tela Definições do Crachá. Destacamos que os crachás previamente solicitados são emitidos através da tela Emissão de crachás, acessada pelo menu Colaboradores > Histórico > Crachá > Emissão de Crachás.

Informamos, ainda, que um crachá é considerado emitido quando a(s) solicitação(ões) for(em) selecionada(s) e o botão Imprimir for pressionado. Isso automaticamente imprimirá o crachá na impressora definida e gerará o(s) histórico(s) de crachá(s).

Problema: ao utilizar o processo de integração dos dados com o Marcação de Ponto 2.0 não estava sendo enviada a informação de Empresa e portanto, também não era criado o centro de custo.

Correção efetuada: ajustamos o processo de integração das informações do módulo Controle de Ponto e Refeitório do sistema Gestão de Pessoas | HCM e do módulo Controle de Terminais de Ponto do sistema Ronda Senior para o aplicativo Marcação de Ponto 2.0. Agora, além dos dados usuais, também serão enviadas as informações de Empresa e Centro de Custo ao qual se vinculam os colaboradores. É importante observar que o Centro de Custo será obtido do histórico de centro de custo (R038HCC), não refletindo as trocas temporárias realizadas por programações.

Complementamos a documentação da guia Pedidos da tela Detalhamento do Pedido com a informação de que nesta guia deve ser informada a multa do FGTS para que ela seja calculada.

Além disso, na página sobre o Tipo de Verba 63 - FGTS Multa, informamos que a competência será determinada pela informação preenchida no pedido.

Complementamos a documentação sobre Atestados Médicos com a informação de que a data de término é indicada de acordo com os dados de histórico do GHE por colaborador (FR038GHE). Se a data de fim (DatFim) não estiver informada nesta tela, o colaborador continuará aparecendo na tela de manutenção do GHE.

Complementamos a documentação da nota de importante do campo Resultados Audiometria, localizado na guia Audiometria da tela Definições Audiometria.

A partir de agora, a informação consta da seguinte forma: Toda vez que este campo for alterado de 0 - Considerar por Exame para 1 - Considerar por Orelha, ao pressionar o botão Alterar, será realizada uma conversão em que as informações dos campos R108RES.TipExa, R108RES.NorAlt, R108RES.EvoRes e R108RES.SitRes (referentes aos resultados da audiometria da orelha direita) serão duplicadas para os campos TipEsq, ResEsq, EvoEsq e OcuEsq, respectivamente (referentes à orelha esquerda). Esses campos são exibidos na guia Itens Resultado da tela Resultado Exames (FR108RES).

Melhoramos a documentação referente à opção Gerar nova conforme dias (campo Solicitação em aberto), da tela Gerar Solicitação, adicionando exemplos mais detalhados sobre o funcionamento padrão do sistema em relação a essa opção.

Complementamos as informações do campo Requisição da documentação sobre Próximos Exames, esclarecendo que se o campo permanecer sem informação, a rotina buscará todos os candidatos externos que estiverem com a situação 1 - Ativo no Processo (R122CEX.SitCex = 1) e que não estejam efetivados em nenhuma requisição (R126CPE).

Complementamos a documentação do campo Salário Admitidos, da tela Versão do Orçamento, adicionando as informações das seguintes opções:

• 10 - Salário médio dos ocupantes do posto;
• 11 - Salário menor dos ocupantes do posto;
• 12 - Salário maior dos ocupantes do posto;
• 13 - Salário de mercado do posto na estrutura salarial;
• 14 - Salário inicial do posto na estrutura salarial;
• 15 - Salário final do posto na estrutura salarial;
• 16 - Salário médio do posto na estrutura salarial - Todos os níveis;
• 17 - Salário médio do posto na estrutura salarial - Inicial e final.

Na documentação sobre Concurso Público - Candidatos Externos, acrescentamos uma nota sobre o preenchimento da data de desistência.

Acesse a documentação para mais informações.

Problema: na guia Saída da tela de Valores de Entrada, ao exportar um modelo de relatório com o formato padrão (.IMP) e executar o executável View.exe para visualizá-lo, as páginas do relatório eram apresentadas em branco.

Correção efetuada: ajustamos rotina de carregamento de arquivos do View.exe para reconhecer o algoritmo correto para descompressão, garantindo assim a exibição correta dos dados no relatório.

Problema: na versão 6.10.3.84, liberada em 21 de junho de 2024, o sistema apresentou uma falha na utilização da função LSP JWTGerar devido a uma incompatibilidade com a biblioteca JWT.

Nessa situação, a mensagem Class NoClassDefFoundError doesn't have classType. era apresentada.

Correção efetuada: ajustamos a incompatibilidade para permitir a correta execução das funções LSP.

Adicionamos a seguinte nota sobre as avaliações de eficácia às documentações Efetuar Avaliação de Eficácia, Gerar Avaliação de Eficácia e Avaliação de Eficácia :

No TR Web 5.0, para mostrar as avaliações em Treinamento > Avaliação de Eficácia, essas avaliações devem estar com a coluna Histórico definida como 2 - Completo para todos os participantes da turma, em Treinamento > Turmas > Avaliar (FR140NPC).