Gestão de Pessoas | HCM - 6.10.3.57

Problema: após atualização do sistema, verificamos que as informações das tabelas Raça/Etnia (R010ETN) e das datas do eSocial (R000ESO) não foram inseridas corretamente pelo atualizador.

Correção efetuada: ajustamos a inicialização do sistema para que seja realizada uma verificação das informações das tabelas de Raça/Etnia e das datas do eSocial. Caso não haja informação, será inserida da tabela Raça/Etnia.

Já na tabela do eSocial (R000ESO), será verificada se há informações. Caso não haja, serão inseridas todas as datas. Caso haja, será verificado se existe a última data referente a 2023 e, caso não exista, será inserida somente essa data.

Problema: ao tentar realizar um afastamento com 16 dias, o leiaute S-2230 não era gerado para um colaborador com categoria eSocial 301 - Servidor público titular de cargo efetivo, magistrado, ministro de Tribunal de Contas, conselheiro de Tribunal de Contas e membro do Ministério Público e tpRegPrev igual a 1 - Regime Geral de Previdência Social - RGPS.

Correção efetuada: ajustamos o processamento e a geração do leiaute S-2230, contemplando os parâmetros acima descritos.

Problema: o sistema não permitia regerar o leiaute S-1299, quando já possuía um com a situação de erro retornado.

Correção efetuada: ajustamos a tela Fechamento para permitir regerar e enviar o leiaute S-1299 nesta situação.

Problema: o sistema apresentava o log de erro: O participante possui valores para o leiaute S-1210. É necessário enviar o leiaute inicial ou informar o número do recibo. ao gerar o leiaute S-1210. O erro aparecia em casos onde havia dois cadastros de terceiros no mesmo CPF; um ativo e outro desligado anteriormente.

Correção efetuada: ajustamos o leiaute S-1210, assegurando a geração correta e evitando o surgimento de log de erros para estas situações.

Problema: ao gerar o leiaute S-1200 para colaboradores que tiveram várias folhas diferentes dentro da mesma competência, com a folha mensal, folha 14 - Dissídio, folhas 12 - Complementar de várias competências, onde o colaborador teve uma transferência de empresa no meio da competência, o sistema não considerava os cálculos corretamente para a geração das informações dos colaboradores transferidos ou não, não gerando, assim, as folhas do tipo 12 - Complementar.

Correção efetuada: ajustamos a geração do leiaute S-1200 para que seja verificado corretamente a cada cálculo se na competência em questão o colaborador está ou não transferido.

Problema: em casos onde um colaborador era desligado e posteriormente recontratado no ano seguinte, o sistema gerava o leiaute S-1210 inserindo as informações contidas na guia Dados Exterior da Ficha Complementar do cadastro desligado.

Correção efetuada: ajustamos a geração do leiaute S-1210, impedindo-o de levar informações de cadastros desligados.

Problema: quando o arquivo no formato .XML do leiaute S-1210 na versão S-1.2 era gerado, as informações de número de registro do plano de saúde na ANS (regANS) eram inseridas com somente 3 dígitos quando, obrigatoriamente, deveriam ser seis posições.

Correção efetuada: ajustamos a geração do leiaute, apresentando corretamente as informações do número de registro para 6 posições.

Problema: ao processar o leiaute S-1200 para uma folha complementar, onde há evento de devolução de INSS e esse evento é movido para outro DmDev, onde há o evento de desconto de INSS e outros cálculos (além das folhas complementar e mensal), mas, o valor liquido da folha complementar é zerado ou abaixo da devolução, o sistema retornava uma mensagem de erro quando há mais eventos que o evento de devolução e os eventos são com código maior que o evento de devolução.

Correção efetuada: ajustamos a verificação para gerar a sequência correta e inserir os eventos na movimentação corretamente.

Realizamos as seguintes implementações referentes às alterações do leiaute S-1210 do eSocial, conforme publicação da versão S-1.2:

Gerais

• Implementado tratamento na geração de rubricas (leiaute S-1010) para levar os processos de IRRF de colaborador, respeitando a regra do leiaute. Com isso, quando o evento estiver informado na tela de processo por colaborador do tipo IRRF, em Cálculos > Lançamentos > Processos > Individual (FRPJCEMP), ou for um evento com característica e incidência de IR de Exigibilidade Suspensa (conforme tabela 21 do eSocial), suas rubricas serão geradas considerando o processo informado.

Além disso, ajustamos para que o evento de característica 50J - Base Isenta IR - Exigibilidade Suspensa não seja mais levado com a incidência de IR 9011 - Remuneração mensal, já que eventos com essa característica deverão ser configurados com a Natureza de Rubrica igual a 1 - Não válido para o eSocial.

Nova tela

• Criamos a tela Alterar Exigibilidade Suspensa - S-1210, em eSocial > Eventos Periódicos > Exigibilidade Suspensa > Alterar (FR340EXS), com as grades:
  • Deduções Previdência Oficial, Previdência Privada, FAPI e Funpresp; e
  • Deduções Pensão Alimentícia e Dependentes.

Essas informações serão levadas nos grupos infoProcRet, infoValores, dedSusp e benefPen do leiaute S-1210.

Envio Declaração Mensal

• Implementamos para que quando forem informados valores de Exigibilidade Suspensa na Dedução de Dependentes, Pensão Alimentícia, Previdência Privada, FAPI e/ou Funpresp, esses valores sejam deduzidos do valor informado nos grupos dedDepen, penAlim e previdCompl.

Realizamos os seguintes ajustes e implementações em relação à rubrica de pensão judicial para casos em que o colaborador possua moléstia grave:

• Alteramos a geração das rubricas do eSocial para casos em que o colaborador possua histórico de receita com moléstia grave. Os eventos com as características de pensão (45A, 45B, 45C, 45D, 45E, 45F, 45G, 45H, 45I, 45J, 45L, 45M, 45N) serão gerados com a incidência de IRRF (codIncIRRF) igual a 9 - Verba transitada pela folha de pagamento de natureza diversa de rendimento ou retenção/isenção/dedução de IR (exemplo: desconto de convênio farmácia, desconto de consignações etc.);
• Agora, ao gerar o leiaute S-1210, serão buscados os beneficiários de pensão alimentícia e, caso a incidência de IRRF da rubrica seja 9 - Verba transitada pela folha de pagamento de natureza diversa de rendimento ou retenção/isenção/dedução de IR e contenha uma característica de pensão, o campo tpRend do grupo penAlim será gerado como 79 - Rendimento isento ou não tributável. Caso a rubrica seja de RRA, será gerado como 18 - RRA.

Problema: após a liberação das versão 6.10.3.52, o sistema não gerava os valores com seus atributos referentes ao grupo penAlim quando o usuário digitava os dados do dependente, sem buscar do cadastro origem (R036DEP), na tela de informações de tributo.

Correção efetuada: ajustamos o sistema para os valores referentes ao grupo penAlim sejam gerados corretamente no cenário descrito.

Problema: quando eram informados os dados de pensão judicial do dependente diretamente na tela de pagamento de terceiro (FR032TPG), guia pensão Judicial, o dependente não era levado na geração do leiaute S-1210.

Correção efetuada: ajustamos o tratamento na geração do leiaute S-1210, grupo infoDep, a partir da versão S-1.2 do eSocial. Agora, na tela de pagamento de terceiros, guia Pensão Judicial ou Plano Saúde, caso seja informado um dependente não cadastrado previamente (código 0), o grupo infoDep deverá ser gerado.

Além disso, ajustamos para que mesmo que o tipo de dependente eSocial seja informado, ele seja desconsiderado; já que um dependente apenas de pensão judicial ou plano de saúde deve ser considerado como Dependente IR igual a N - Não, não sendo gerado o campo Tipo de Dependente eSocial.

Problema: estava sendo realizada uma validação incorreta no leiaute S-2200, o qual estava verificando erroneamente se as informações do aprendiz estavam presentes em admissões anteriores a 22/01/2024, quando, na realidade, essa obrigatoriedade se aplica apenas a partir de 22/01/2024. Além disso, no leiaute S-2299, a tag indPDV estava sendo gerada de forma incorreta.

Correção efetuada: ajustamos a consistência do leiaute S-2200, eliminando a validação das informações do aprendiz para admissões ocorridas antes de 22/01/2024. Adicionalmente, corrigimos o nome da tag indPDV durante a geração do XML no leiaute S-2299.

Realizamos um tratamento na geração das pendências do leiaute S-2240, ao incluir uma nova distribuição de EPI, para que seja descartada a pendência em casos onde seja distribuído um EPI cujo CA não seja alterado. Sendo assim, não haverá a necessidade de gerar um novo S-2240, já que os mesmos CAs do último envio acabariam sendo levados no evento.

Problema: durante a validação do campo codAgntCausador, era incorretamente considerada a data de início de simplificação na produção restrita ao invés da data efetiva de início da versão S-1.2 do eSocial (22/01/2024).

Correção efetuada: ajustamos a validação do campo codAgntCausador, do evento S-2210, para considerar a data 22/01/2024 em sua validação.

Atualizamos as informações do Mobilidade e CodMod, disponíveis na documentação da Contagem de Colaboradores da Cópia.

Problema: após atualização do sistema, verificamos que as informações das tabelas Raça/Etnia (R010ETN) e das datas do eSocial (R000ESO) não foram inseridas corretamente pelo atualizador.

Correção efetuada: ajustamos a inicialização do sistema para que seja realizada uma verificação das informações das tabelas de Raça/Etnia e das datas do eSocial. Caso não haja informação, será inserida da tabela Raça/Etnia.

Já na tabela do eSocial (R000ESO), será verificada se há informações. Caso não haja, serão inseridas todas as datas. Caso haja, será verificado se existe a última data referente a 2023 e, caso não exista, será inserida somente essa data.

Problema: não era possível efetuar alterações ou exclusões no aviso prévio quando o colaborador estivesse em período de afastamento.

Correção efetuada: adequamos o sistema, permitindo a alteração e exclusão do aviso prévio, mesmo quando o colaborador estiver afastado.

Complementamos a documentação de Postos de Trabalho, informando que não é permitida a alteração das características da Empresa e Filial devido ao impacto nos colaboradores que ocupam o posto. Portanto, é necessário que não haja nenhum ocupante registrado na data de histórico para a qual a alteração está sendo solicitada.

Problema: ao gerar o relatório 001 - Imposto de Renda Colaboradores (FPRE0001.IRF), o sistema não apresentava o IRRF PLR de expatriado quando o PLR é calculado junto na folha mensal.

Correção efetuada: o cálculo foi ajustado, gravando e exibindo no relatório as informações corretas neste cenário.

Realizamos os seguintes ajustes e implementações no sistema para casos em que a ficha financeira seja gerada para um colaborador aposentado, considerando que haja isenção/dedução de IRRF referente à aposentadoria aos 65 anos:

• Criamos os seguintes acumuladores:
  • 9545 - Isenção IR 65 Anos do Mês;
  • 9546 - Isenção IR 65 do Cálculo;
  • 9547 - Isenção IR 13º 65 do Mês;
  • 9548 - Isenção IR 13º 65 do Cálculo;
  • 9549 - Isenção IR RRA 65 Anos do Mês;
  • 9550 - Isenção IR RRA 65 Anos do Cálculo;
  • 9551 - Isenção IR 13º RRA 65 Anos do Mês; e
  • 9552 - Isenção IR 13º RRA 65 Anos do Cálculo.
• Criamos as seguintes características:
  • 59A - Dedução Isenção IR 65 Anos; e
  • 59B - Dedução Isenção IR 13º 65 Anos.

Agora, ao calcular os valores de aposentadoria/pensão de colaboradores a partir dos 65 anos de idade, o usuário deverá criar dois novos eventos para cada tipo de cálculo, sendo:

•  Mensal:
  • Um evento de Isenção Apos./Pen 65 Anos, utilizando a utilizando a característica 59A - Dedução Isenção IR 65 Anos;
  • Um evento evento de Redutor Apos./Pen 65 Anos, utilizando a característica 59A - Dedução Isenção IR 65 Anos.
• 13º Salário:
  • Um evento evento de Isenção Apos./Pen 65 Anos, utilizando a utilizando a característica 59B - Dedução Isenção IR 13º 65 Anos;
  • Um evento evento de Redutor Apos./Pen 65 Anos, utilizando a característica 59B - Dedução Isenção IR 13º 65 Anos.

Para mais informações, verifique a documentação das características 59A - Dedução Isenção IR 65 Anos e 59B - Dedução Isenção IR 13º 65 Anos.

Melhoramos a informação da nota de destaque do campo Afastamento Período Apuração da tela Tipos de Vales, para que a informação fique mais completa. A partir de agora essa nota informa que: Este tratamento somente será válido para rotina de vales gerado e que tenha quantidade de vales informado por dia útil, em que o controle de afastamento é feito tanto através do período de faltas como também pelo período de apuração.

Enriquecemos a documentação do campo Unidade, localizado na guia Eventos da tela Eventos, para destacar que a rotina de geração do evento de refeição não gera valores no campo quantidade do evento. Portanto:

• Se o tipo do Evento for definido como V - Valor, o sistema realiza a soma dos valores das marcações, os quais são então registrados na coluna Valor.
• Se o tipo do Evento for diferente de V - Valor, a rotina soma as quantidades das marcações e insere esse total na coluna Valor.

Adicionamos uma nova informação na nota de destaque documentação de Autorização de Horas Extras para informar que, caso a data inicial e final sejam iguais, o sistema ainda permitirá informar a hora final menor que a hora inicial. Nessa situação, o sistema interpretará que a programação se estende até a hora final do dia seguinte.

Com o intuito de tornar essa informação mais clara, incluímos também um exemplo ilustrativo.

Problema: de forma intermitente, ocorria a geração de um arquivo de marcação vazio que, mesmo assim, alterava as marcações na base do mobilidade como se tivessem sido lidas. Porém, na execução subsequente, essas marcações deixavam de ser importadas.

Correção efetuada: realizamos ajustes para incluir um aviso no log do agendador, informando sobre o problema caso o arquivo de marcações não seja criado corretamente, bem como para que na próxima execução do processo elas sejam lidas novamente.

Complementamos a documentação de Restrições da Apuração - Horário Flexível, no tópico relacionado ao Controle de Ponto e Refeitório, para adicionar a seguinte informação: No caso do horário flexível (tipos 3 e 6), o momento em que o colaborador inicia o trabalho não influencia na apuração. O sistema analisa o período desde o início até o término da jornada, considerando a flexibilidade. Se houver horas extras antes do horário regular, o sistema prioriza o tempo trabalhado e a escala antes de calcular as horas extras remanescentes. Entretanto, se as horas extras ocorrem após o expediente, o sistema avalia a escala do colaborador, tratando essas horas como extras justificadas no final do turno, utilizando o tipo de uso 08 - Extra Justificada cadastrado nas marcações.

Problema: ao possuir a proprietária Solução Ponto que, por padrão, inclui os módulos Controle do Ponto, Gestão do Ponto e APP de marcação, o menu Refeitório estava sendo exibido indevidamente.

Correção efetuada: ajustamos o sistema que o menu Refeitório não seja apresentado ao utilizar a proprietária Solução Ponto.

Problema: ao listar o relatório 004 - Arquivo Eletrônico de Jornada (AEJ Portaria 671) (HRFI004.GER), ocorria um erro que exibia a mensagem Necessário cadastrar o número de identificador do REP para os coletores XXX para coletores de marcações que não eram REP de classificação de modelo 07 - Controlador Ponto.

Correção efetuada: ajustamos o relatório para que ele liste todas as marcações do colaborador.

Problema: ao listar o relatório 004 - Arquivo Eletrônico de Jornada (AEJ Portaria 671) (HRFI004.GER) com um horário que acabe em 00:01, dentro do AEJ era apresentado um campo em branco.

Correção efetuada: ajustamos o relatório para que ele liste todos os horários corretamente.

Problema: quando o usuário possuía a permissão de inserção ou alteração na tela de manutenção de banco de horas, porém não tinha a permissão de exclusão, não era habilitado o botão Gravar dessa tela, impossibilitando a realização dos ajustes permitidos.

Correção efetuada: ajustamos o sistema que, quando o usuário possuir a permissão para ajustes na tela, o botão Gravar seja habilitado.

Atualizamos a documentação da Lei 13.103 (Motorista), corrigindo uma informação equivocada no tópico Cálculo do tempo de espera > Formas para o cálculo do uso de espera, que sugeria que a parametrização geraria excedentes no tempo de espera.

Para informações adicionais, consulte a documentação da Lei 13.103 (Motorista).

Ao tentar realizar ajustes para os quais o usuário não possuía permissão, o log do Glassfish registrava a mensagem Usuário sem abrangência para executar a operação, sem fornecer informações sobre qual usuário ou rotina originou a falta de permissão.

Para resolver essa situação, ajustamos o sistema para que o log mostre o usuário e a API do Gestão Ponto que ele está tentando acessar. Essa informação será apresentada somente se a chave com.senior.mostrar.usuario.api.log for inserida no Central de Configurações Senior com o valor true. Caso a chave esteja com valor false ou ausente, o log será gravado como anteriormente.

Problema: ao efetuar um fechamento de banco de horas de forma assíncrona, com a opção de fechamento de conta ao final do processamento, ao verificar o log, a quantidade de colaboradores processados era o dobro do valor real.

Correção efetuada: ajustamos o log para que mostre a quantidade correta de colaboradores processados.

Problema: ao efetuar leitura de um arquivo de ponto no modelo não AFD, através do Gestão do Ponto, era apresentado o erro de IndexOutOfBoundsException: Index: 0, Size: 0 caso a tabela R250ALT não possuísse valor de DatHor para o CodAlt = 67.

Correção efetuada: ajustamos o sistema para que, caso as informações não estejam em banco, sejam inseridas corretamente pelo sistema.

Problema: na apuração diária do ponto, o sistema não estava desconsiderando as marcações dentro do intervalo entre marcações, quando era utilizado o intervalo 3 - Segundo Data, Hora, Relógio e Função das Marcações, e havia várias marcações dentro do intervalo intercalando entre coletor e função.

Correção efetuada: realizamos ajustes no sistema para que ele analise corretamente esse cenário.

Na documentação sobre Configurar menu na senior X Platform, complementamos a informação do tópico Administrar permissões. Informamos que no Gestão do Ponto, o comportamento difere da versão client. O comportamento padrão consiste em exibir os itens de menu para todos e, caso seja necessário revogar a permissão de um usuário específico, é preciso restringir a permissão ao grupo de usuários Todos e conceder permissão ao usuário ou grupo desejado.

Para maiores informações sobre como realizar essa operação, acesse a documentação.

Problema: o sistema permitia que a quantidade de requisições do quadro de vagas ficasse negativa.

Correção efetuada: ajustamos o sistema para que valide operações realizadas na requisição que afetam o quadro de vagas e impeça que negative. Caso identifique um caso negativo, será zerado e informado na Rastreabilidade do Quadro.

Complementamos a documentação de Gerenciar Processo Seletivo informando que a visualização das solicitações na tela está diretamente associada à tabela de Requisições (FR126RQU). Portanto, se o usuário deseja operar por meio de uma restrição por abrangências, é necessário que esteja ciente dos campos considerados pela tabela, os quais serão aplicados conforme as condições definidas pelo usuário.

Problema: quando havia a tentativa de exclusão da distribuição de EPI de um colaborador transferido na empresa destino, o sistema apresentava o seguinte erro: O colaborador XX foi transferido de empresa e/ou teve troca de cadastro na data DD/MM/AAAA. Para alterar essa distribuição você deve alterar a distribuição no cadastro de origem: Empresa: XX, Colaborador: XX.

Correção efetuada: ajustamos o sistema para que permita excluir as distribuições feitas na empresa destino após a data da transferência do colaborador.

Atualizamos as informações na nota de observação do campo Nome na documentação de Parâmetros. Acesse a documentação e confira.

Complementamos a documentação de Funções para Requisições HTTP informando que as funções para requisições HTTP não oferecem suporte ao uso de certificados digitais e permitem apenas informar parâmetros que compõem as requisições, tais como: alteração do Header, application/type e etc.

Problema: ao realizar requisições SOAP de serviços do editor de serviços, com a bridge habilitada, esporadicamente a requisição falhava e retornava a mensagem de erro HTTP Status: 500. Expected EOF at line 1 column 6 ao realizar o parse do JSON dos módulos com deploy no sistema.

Correção efetuada: ajustamos a rotina de carregamento da lista de módulos instalados.

Problema: ao enviar arquivo anexo do relatório a partir do gerador de relatórios por e-mail, o arquivo não era enviado.

Correção efetuada: alteramos a rotina que causava o erro que não adicionava o arquivo gerado aos anexos do e-mail.

Problema: foi identificada uma falha onde não era realizado o tratamento correto do retorno das execuções realizadas via processo automático, o que não finalizava a execução corretamente.

Correção efetuada: ajustamos a rotina de execução via processo automático para que a inconsistência seja apresentada no log e a execução finalizada corretamente.

Adequamos os manuais de Avaliação de Reação e Notas Treinamento. Ambos possuíam informações sobre a conclusão de avaliações, mas com conteúdos diferentes, gerando dúvidas. Os dois manuais foram complementados, esclarecendo a conclusão de cada avaliação.

Implementada a integração dos novos campos do Registro Nacional de Estrangeiro (RNE), disponibilizados na Colabbe, com o Gestão de Pessoas | HCM - versão XTended. Agora, os dados preenchidos na seção RNE da Colabbe serão transportados para a guia Estrangeiro, nos cadastros do candidato e do colaborador.