Gestão de Pessoas | HCM - 6.10.3.45

Problema: quando ocorria o pagamento de dissídio, não estavam sendo geradas as informações para a tag grauExp no leiaute S-1200, de acordo com o período de apuração atual.

Correção efetuada: ajustamos a geração do leiaute S-1200 para incluir as informações da tag de acordo com o período de apuração atual, em vez da competência do dissídio.

Problema: ao realizar o fechamento da admissão de um colaborador, estava sendo exibida a mensagem É necessário informar a descrição do local. Ocorria porque o local do colaborador não possuía uma descrição.

Correção efetuada: ajustamos o fechamento de admissão para realizar o processamento corretamente.

Problema: ao realizar a importação do XML do leiaute S-1200, estava ocorrendo o erro de Data inválida no campo infoSaudeColet>detPlano>dtNascto quando o valor informado era 1900-01-01.

Correção efetuada: ajustamos a rotina do migrador para corrigir essa situação.

Problema: ao calcular uma folha complementar de dissídio para um colaborador que possui valores referentes a anos anteriores (RRA) e valores referentes aos anos atuais, porém o valor líquido é baixo ou negativo, e nem todas as competências possuem eventos calculados, ao gerar o envio da declaração mensal, o sistema exibia a mensagem de erro Index: 0, Size: 0.

Correção efetuada: ajustamos a rotina para inserir os valores de ajuste de cálculo em competências onde já existem eventos, garantindo que o leiaute seja gerado corretamente.

Problema: quando um colaborador transferido é gerado no envio da folha mensal, a folha complementar não estava sendo incluída nas informações do leiaute.

Correção efetuada: ajustamos o envio da folha mensal para gerar corretamente as informações para os leiautes S-1200/S-1202.

Problema: ao processar o leiaute S-1200 para um colaborador com dissídio parcelado e com vários meses de anos anteriores, bem como vários meses com diferença de pensão alimentícia, o sistema exibia a mensagem Rubrica (evento XXXX) possui valores inválidos.

Correção efetuada: ajustamos o processamento do leiaute S-1200 para gerar corretamente as informações dos eventos de pensão.

A fim de que o sistema esteja em concordância com o que dispõe o capítulo III, item 13.1, referente ao leiaute S-1000 - Informações do Empregador/Contribuinte/Órgão Público, do Manual de Orientação do eSocial (MOS), ajustamos o sistema para que, a partir da versão S-1.1 do eSocial, quando o leiaute S-1000 for gerado, a tag indTribFolhaPisCofins seja sempre enviada ao eSocial quando o campo PIS Folha, da tela de cadastro de empresas, estiver definido com S - Sim.

Problema: quando havia dois cadastros com o mesmo CPF dentro da mesma empresa e um colaborador era demitido, no cadastro de causa de demissão na guia eSocial, o histórico mais antigo tinha a competência posterior à data da demissão. Após ter o novo cadastro do colaborador ativo com dissídio, ao gerar o leiaute S-1200, uma mensagem de erro null era exibida.

Correção efetuada: ajustamos a rotina do sistema para que, caso o registro não exista, não seja gerado o erro null e o leiaute S-1200 seja processado.

Adicionamos a opção de importação pelo Migrador eSocial para os seguintes leiautes relacionados à Reclamatória Trabalhista:

• S-2500 - Processo Trabalhista;
• S-2501 - Informações de Tributos Decorrentes de Processo Trabalhista.

Na documentação sobre Integrações de consulta via pendência, no item 7 da seção Configuração da Integração, que aborda sobre Campos de Exceção, adicionamos uma nota que esclarece que, mesmo quando um campo está informado como exceção, um registro será criado na tabela RTC_Pendencies. No entanto, é importante destacar que esse registro não será incorporado à integração.

Complementamos a documentação sobre Reestruturar Organograma, incluindo as seguintes informações:

Na nota de destaque no começo da página:

• Quando a reestruturação estiver em andamento, não é indicado que sejam cadastrados ou alterados os locais no organograma existente, pois essas modificações não serão levados para a Grade Sublocais. Caso tais ações sejam realizadas e a rotina seja processada, o sistema emitirá um alerta indicando a existência de locais cadastrados após o início do procedimento, impedindo, assim, a continuidade da reestruturação.

Na documentação da Grade Locais, através de uma nota de destaque:

• A rotina não inclui a opção de exclusão de dados durante uma reestruturação em andamento, mas pode-se utilizar a combinação de teclas CTRL + DELETE no local indicado na Grade Locais. Isso resultará na limpeza dos dados, permitindo que um novo local seja informado para a reestruturação.
• Após o início do processo, os dados são registrados na tabela Histórico Reestruturação Organograma - Sublocais (R016HRS) e não serão substituídos pelo procedimento mencionado acima.

Problema: nas versões 6.10.3.32 e 6.10.1.100 do sistema, o cadastro e a duplicação de organograma apresentavam erro quando eram utilizados 4 dígitos (9999) no banco de dados Oracle. Sendo assim, foi necessário adicionar uma restrição no cadastro e duplicação de organograma para não permitirem o uso de mais de 3 dígitos (999) nesse banco de dados.

Correção efetuada: aumentamos o tamanho do campo novOrg, (da tabela R016ORE), para 4 dígitos (9999) e retiramos a restrição que havia sido adicionada no cadastro e na duplicação de organograma, que impossibilitava o uso de mais de 3 dígitos (999) no banco de dados Oracle.

Sendo assim, os usuários do banco de dados Oracle podem utilizar normalmente a rotina de organograma com 4 dígitos.

Com o objetivo de melhorar a documentação relacionada ao campo Afastamentos INSS Mensalista da tela de Definições Previdência Social e oferecer uma explicação mais precisa de seu funcionamento, adicionamos um exemplo que ilustra como o sistema se comporta com base na opção escolhida neste campo.

Complementamos a documentação de Duplicação de Código de Cálculo informando que é utilizado os mesmos critérios listados para determinar se os códigos de cálculo são iguais e se o cálculo a ser duplicado é válido no processo de duplicação.

Problema: ao calcular uma pensão para um dependente com configuração de pensão fixa, que envolve descontos nas férias e no valor mensal, o sistema apresentava o Erro: -1 ao calcular o evento de Pensão sobre os valores mensais.

Correção efetuada: ajustamos o cálculo da pensão para calcular os valores de diferença da pensão corretamente.

Para que o sistema esteja em concordância com o que dispõe a COSIT nº 209, de 16 de dezembro de 2021, realizamos as seguintes implementações relacionadas aos eventos de diferença de abono e diferença de 1/3 sobre o abono:

• Criamos duas novas características:
  • 12K - Diferença de 1/3 sobre abono; e
  • 42J - Diferença negativa de 1/3 sobre abono.

• No cálculo da diferença de férias, na ficha financeira e no cálculo da rescisão, caso haja abono no recibo de férias e um reajuste de salário onde deva ser paga a diferença, agora o sistema irá verificar se existe algum evento com a característica 12K - Diferença de 1/3 sobre abono. Caso haja, irá calcular o valor referente ao 1/3 de abono no evento com essa característica.
• Alteramos o cálculo da provisão para que, ao apurar os valores de baixa na ficha financeira, seja verificado se há eventos de diferença de abono. Caso haja, irá verificar se o evento com a característica 12K - Diferença de 1/3 sobre abono foi calculado. Caso não tenha sido calculado na ficha financeira, porém exista um evento cadastrado com essa característica, irá proporcionalizar o valor do evento com a característica 12E - 1/3 s/ Abono, separando o valor da diferença do abono normal e 1/3 de abono nos respectivos cálculos na provisão. O mesmo vale para a característica 42J - Diferença negativa de 1/3 sobre abono.

Além disso, alteramos a geração do DIRF para considerar as características 12K - Diferença de 1/3 sobre abono e 42J - Diferença negativa de 1/3 sobre abono como rendimentos isentos quando a incidência de IR for igual a N - Não.

Adicionamos um tratamento para que os índices do IPE sejam gravados na tabela IDP (R046IDP). Com isso, quando o usuário emitir o relatório 006 - Gravação dos dados para demonstrativo (FPEN006.ENV), a base do IPE será gravada nesse relatório e também será apresentada para fins da apuração do cálculo da contribuição previdenciária do servidor público.

Problema: no cadastro de Outras Empresas, o campo Número era limitado a 5 caracteres.

Correção efetuada: foi realizado um ajuste no sistema para que o campo agora comporte 6 caracteres.

Atualizamos a documentação do campo Considerar eSocial informando que se o valor de vales tiver incidência de IRRF (Imposto de Renda Retido na Fonte), este campo deve permanecer como S - Sim para o correto envio dos valores de IRRF ao eSocial. Neste caso, o evento de IRRF sobre Vales (característica 40G), deve estar parametrizado com o Tipo Evento 4 - Outros e permanecer sem Natureza eSocial.

Atualizamos a documentação sobre a Reforma Trabalhista (Lei nº 13.467 de 2017): contratos intermitentes, com os seguintes acréscimos:

• No segmento que esclarece que ao utilizar a função de Contratos Intermitentes, o cliente deve obrigatoriamente empregar a função de Escala de Horários como pré-requisito, adicionamos a informação de que o cadastro do tipo de escala deve ser configurado como I - Jornada Intermitente.
• Na última nota de destaque da página, incluímos a observação de que não é permitido criar uma escala para um colaborador intermitente que já esteja sendo usada por um colaborador que não seja intermitente.

Problema: na transferência de filial colaboradores que possuem informações de demonstrativos de holerite o sistema gerava registros órfãos nas tabelas de Informações Demonstrativo Pagamento - Eventos (R046IDE) e Informações Demonstrativo Pagamento - Contas Bancárias (R046ICO).

Correção efetuada: ajustamos a rotina de transferência de filial para não gerar registros órfãos nas tabelas de holerite.

Problema: ao calcular o recibo de férias individual do colaborador, mesmo quando este possui data de término das férias maior que o término do período seguinte, a mensagem de aviso perguntando se deseja pagar multa não era apresentada. Isso ocorria porque havia um evento com data de validade já expirada e uma exceção de vínculo cadastrada.

Correção efetuada: ajustamos o sistema para validar se o evento está com a data de validade expirada ou não, realizando a consistência de forma correta e apresentando a mensagem Fim das Férias > término período seguinte. Pagamento sujeito a multa.

Atualizamos a descrição do modelo 007 - Declaração de Deslocamento (FPDO007.COL) com a observação de que é necessário informar o Histórico de Vale Transporte Ativo na data de geração do relatório e preencher os campos Bairro e Cidade na Ficha Complementar do colaborador.

A descrição do modelo 001 - Relatório Coleta (FPPF001.COL) não reportava que a coluna de sugestão aplicava-se à validação para informar a data mediante o assinalamento do campo Qtd. Período Vencido Multa, que encontra-se presente na guia Férias do Sindicato atrelado ao colaborador.

Atualizamos a descrição do relatório informando que o campo Qtd. Período Vencido Multa irá interferir diretamente na coluna Sugestão e consequentemente alterar os valores apurados pelo campo Data Limite Concessão de Férias(LIMCON) da tabela Período de Férias (R040PER).

Problema a função RetornaPostoPai não retornava corretamente quando o usuário ativo estivesse vinculado a um colaborador ou não fosse Administrador/Master.

Correção efetuada: ajustamos a função para ignorar a abrangência do usuário ativo.

Problema: ao realizar uma consulta utilizando campos numéricos com ponto flutuante como filtro era apresentado o erro Não foi encontrado rateio para a fatura.

Correção efetuada: ajustamos a rotina para efetuar a conversão corretamente.

Implementamos tratamento para que o valor informado para um evento com característica 49R - RRA Despesas Advogado seja considerado na DIRF. Desse modo, o usuário terá esses valores somados aos valores do evento com característica 49M - Despesas com Ação Judicial RRA, que é apresentado no campo Desp. Ação Jud., da guia Rendimentos da tela Alterar Rendimentos Informe e DIRF (gerado no arquivo através do campo DAJUD).

Ajustamos a integração com a Colabbe (senior X) para que os candidatos não sejam duplicados, conforme número de CPF, ao processar as pré-admissões. Anteriormente, era criado um novo cadastro para o candidato sem que fosse verificado se já havia um cadastro. Isso gerava retrabalho ao usuário, já que os candidatos duplicados precisavam ser excluídos manualmente. Sendo assim:

• ao processar uma pré-admissão que não esteja vinculada a uma requisição, uma nova requisição será automaticamente criada. Porém, a criação de um novo candidato não será vinculada à essa nova requisição, pois o novo cadastro de um candidato será criado somente quando não existir um cadastro para o mesmo CPF;
• havendo um cadastro para o mesmo CPF, será realizada a atualização do cadastro com os dados recebidos da pré-admissão. Isso ocorrerá havendo uma requisição vinculada ou não.

Implementamos para que o sistema guarde o retorno de cada envio de leiaute do e-Sfinge realizado para o Tribunal de Contas do Estados de Santa Catarina (TCE/SC). Sendo assim, quando desejar, o usuário poderá baixar um arquivo do tipo JSON com as informações retornadas pelo TCE/SC.

Para mais informações, verifique a seção Gerar JSON da documentação referente à Consulta/Envio dos Layouts eSfinge.

Nas documentações das telas Digitar Passes Vale-Transporte e Histórico de Escala de Vale-Transporte, adicionamos a informação de que quando houver alteração de histórico de escala de vale transporte e for utilizada uma nova linha nesse novo registro, as ausências durante o período em que era utilizada a linha anterior não serão consideradas na apuração de faltas do período informado.

Atualizamos a documentação do web service com.senior.g5.rh.hr.geracaoEventos para deixar claro que não é recomendável efetuar sua chamada durante o processo de cálculo de rescisão. Isso se deve ao fato de que determinadas informações necessárias para o cálculo da rescisão são carregadas previamente, antes da execução da regra por processo, a fim de possibilitar a realização de outros comandos importantes. Em decorrência disso, os registros inseridos no banco de dados por meio do web service não serão lidos.

Melhoramos o processo de integração das marcações do aplicativo Marcação de Ponto 2.0 para os módulos Controle de Ponto e Gestão do Ponto, tornando-o mais eficiente.

Nesta atualização, introduzimos a incorporação do external ID do colaborador, que leva em consideração as marcações vinculadas aos dados de cadastro (abrangendo NumEmp\TipCol\NumCad) durante o processo de integração. Isso permite que o sistema reconheça e encaminhe de maneira adequada as marcações dos colaboradores com múltiplos vínculos na mesma empresa ou em empresas diferentes no sistema. Anteriormente, o sistema agrupava todas as marcações apenas com base no CPF para importação online ou off-line (através de arquivo).

Com essa melhoria, as marcações agora são automaticamente direcionadas aos contratos e cadastros correspondentes, eliminando a necessidade de intervenções manuais por parte do RH. Isso se traduz em redução do trabalho administrativo e em uma gestão de ponto mais precisa e eficaz.

Problema: ao efetuar o acesso à lista de incidentes no período nos acertos da minha equipe via dispositivo móvel, as informações não eram apresentadas ao usuário.

Correção efetuada: ajustamos o sistema para que demonstre corretamente os incidentes no período.

Problema: ao fazer o login no sistema de gestão do ponto, ocorria a mensagem Core.core404.text.contentNotFound e não era claro o real problema no acesso.

Correção efetuada: foi realizado ajuste para que, caso aconteça algum erro após o login, seja direcionado para a página apresentando as mensagens corretamente de erro de forma clara e precisa.

Melhoramos o processo de integração das marcações do aplicativo Marcação de Ponto 2.0 para os módulos Controle de Ponto e Gestão do Ponto, tornando-o mais eficiente.

Nesta atualização, introduzimos a incorporação do external ID do colaborador, que leva em consideração as marcações vinculadas aos dados de cadastro (abrangendo NumEmp\TipCol\NumCad) durante o processo de integração. Isso permite que o sistema reconheça e encaminhe de maneira adequada as marcações dos colaboradores com múltiplos vínculos na mesma empresa ou em empresas diferentes no sistema. Anteriormente, o sistema agrupava todas as marcações apenas com base no CPF para importação online ou off-line (através de arquivo).

Com essa melhoria, as marcações agora são automaticamente direcionadas aos contratos e cadastros correspondentes, eliminando a necessidade de intervenções manuais por parte do RH. Isso se traduz em redução do trabalho administrativo e em uma gestão de ponto mais precisa e eficaz.

Problema: ao cadastrar um ASO Externo com um número de atestado contendo mais de 5 dígitos, o sistema gerava a seguinte mensagem Não foi possível gravar as informações: Erro: Erro de acesso ao banco de dados ao tentar salvar o registro.

Correção efetuada: Ajustamos o tamanho do campo Número Atestado para permitir o cadastro de números com até 9 dígitos.

Realizamos as seguintes melhorias no módulo Segurança e Medicina (SM):

Nova coluna Demissional nas telas de periódicos

Para que o usuário possa definir, separadamente, se determinado exame deve ser realizado na demissão e/ou após a demissão (acompanhamento), incluímos a nova coluna Demissional nas seguintes telas e suas respectivas grades:

Relatórios

Adicionamos a coluna Demissional aos relatórios a seguir, a fim de deixá-los em concordância com as telas de cadastro de periódicos:

• PCMSO Histórico igual a S - Sim:
  • 001 - Relação de Periódicos (SMPE001.GER).
• PCMSO Histórico igual a N - Não:
  • 002 - Relação de Periódicos por Empresa (SMPC002.GER);
  • 003 - Relação de Periódicos por Local (SMPC003.GER);
  • 004 - Relação de Periódicos por Cargo (SMPC004.GER);
  • 005 - Relação de Periódicos por Local e Cargo (SMPC005.GER);
  • 006 - Relação de Periódicos Individuais (SMPC006.GER).
• 018 - Riscos e Exames por GHE (SMPC018.GER).

Geração de Solicitação de Exames

Alteramos a rotina de geração de solicitação de exames para considerar a nova definição das telas de cadastro de periodicidade de exames (que determina se o exame deve ser gerado na demissão) separadamente da definição que já existia (coluna Acomp. Demissão). Sendo assim, a nova definição passa a ser específica para exames de acompanhamento pós demissão.

Geração de exame demissional na demissão

Alteramos o processo de geração de solicitação de exame demissional ao demitir um colaborador. Agora, o sistema passou a considerar o campo Demissional e, dessa forma, quando o usuário cadastrar um afastamento por demissão e houver algum exame selecionado para considerar Demissional, será gerada automaticamente a solicitação para o exame em questão.

Problema: ao listar o relatório 001 - Relação de periódicos (SMPE001.GER), o nome/descrição da coluna que apresenta a informação do tipo do colaborador associado à ficha médica era listado como Cada, quando deveria ser Tipo.

Correção efetuada: corrigimos o relatório em questão para mostrar corretamente o texto Tipo na coluna que apresenta a informação do tipo do colaborador associado à ficha médica.

Realizamos algumas melhorias na tela de Distribuição Coletiva de EPI para que o usuário possa visualizar com mais facilidade qual CA do EPI que está sendo entregue, informações sobre a última distribuição do mesmo EPI para o colaborador e qual a data de validade desse EPI. Sendo assim:

• Adicionamos duas novas colunas à grade que lista os colaboradores, sendo:
  • Última Entrega: apresenta a última data em que o EPI foi entregue ao colaborador;
  • Dt. Validade: apresenta a validade do EPI, correspondendo à data da última entrega acrescidos dos dias de validade do EPI.

• Alteramos a legenda da tela Distribuição Coletiva de EPI. Agora, há 3 (três) cores que dividem os EPIs em 3 categorias, sendo:
  • Azul: EPI não distribuído para o colaborador na data de entrega informada.
  • Vermelho: EPI já distribuído para o colaborador na data de entrega informada.
  • Verde-oliva: EPI distribuído para o colaborador em data anterior e ainda válido.

Alteramos os nomes e descrições de campos da tela Cadastro de Acidentes (FR086ACT_2), relacionados à localização do acidente. Facilitando, assim, a visualização e identificação dos dados pertinentes ao endereço do acidente.

Para que o usuário possa registrar corretamente o perigo durante o cadastro de riscos ocupacionais, no menu Segurança > Gestão de GHE > Laudo do agente de risco > Inventário de Risco, realizamos as seguintes implementações:

• Criamos a guia Riscos Ocupacionais na tela de agentes de riscos. Através desta guia, será possível descrever os eventuais riscos ocupacionais que estão ligados aos agentes de risco.
• Na guia de Inventário de Riscos, da tela de laudo do agente de riscos, adicionamos os botões:
  • Sugerir Riscos: ao clicar neste botão, será inserida uma linha na grade para cada risco ocupacional existente no agente, preenchendo o código com um número sequencial e a coluna Risco Ocupacional com a descrição do risco previamente cadastrado na tela de cadastro de agentes de riscos; e
  • Lupa, na coluna Risco Ocupacional: ao clicar neste botão, serão listados os riscos ocupacionais já cadastrados para o agente de risco do laudo. Ao selecionar um registro, será apresentada a descrição do risco ocupacional do registro em questão.

• Implementamos o Registro 4, referente aos riscos ocupacionais, no relatório de importação 00018 - Agente Risco (SMIM00018.SCF);
• Alteramos o web service com.senior.g5.rh.sm.agentesrisco (porta Agentes e revisão 2) para também considerar os registros de riscos ocupacionais.

Problema: o sistema não registrava as abrangências por módulo na primeira tentativa do usuário, sendo necessário repetir o processo para que fossem gravadas com sucesso.

Correção efetuada: Ajustamos o sistema para registrar as informações na primeira tentativa de acesso.

O sistema permitia selecionar no CBDS (Central de Banco de Dados Senior) se a tabela Troca de Horário - TRIGGERS (R064THR_AUX) seria temporária na base de dados, isto era opcional e muito utilizado por diversos clientes.

Alteramos a rotina para que a tabela R064THR_AUX seja temporária de forma obrigatória.

Problema: no formulário de Auditoria de Telas - Consulta, com o menu XT habilitado e fixado, o sistema não carregava as informações após utilizar os filtros da tela.

Correção efetuada: ajustamos a rotina de filtragem do formulário para carregar as informações corretamente.

Problema: as rotinas auxiliares que faziam comunicação com servidores da Senior utilizavam o protocolo HTTP nas requisições.

Correção efetuada: ajustamos o protocolo utilizado nas URLs usadas para realizar requisições para servidores da Senior, a fim de utilizarem o protocolo HTTPS, bem como a atualização de comunicados e do Analytics.

Problema: ao utilizar aplicações que utilizem o recurso XT, um log de eventos era gerado no diretório de aplicação ocupando espaço em disco de forma desnecessária.

Correção efetuada: ajustamos para que o log seja gerado somente quando é necessário uma análise por parte dos times técnicos na aplicação, utilizando parametrização específica.

A fim de melhorar a experiência do usuário, aprimorarmos a usabilidade do sistema na versão XTended através das seguintes melhorias:

• Tela de login: será sempre iniciada na versão XTended, exceto em casos de aplicações de Middleware (MA/BA);
• Tela principal: a definição de se a versão XTended é utilizada ou não, agora será por usuário, e não mais por estação;
• Tela para habilitar/desabilitar a versão XTended: assim como a tela principal, agora também passa a ser tratada por usuário, e não mais por estação.

Além disso, a guia Início também será apresentada na versão XTended para que o usuário possa ter acesso às telas mais utilizadas.

Atualizamos o Tour do Gestão de Pessoas | HCM (XTended) para que suas informações estejam de acordo com o funcionamento do sistema. Sendo assim, adicionamos ao Tour o passo VISTOS POR ÚLTIMO, disponível logo após o passo 3, AGILIDADE PARA VOCÊ ENCONTRAR O QUE PRECISAR. Esse novo passo introduz o usuário à funcionalidade Vistos Por Último, cuja função é disponibilizar um histórico onde o usuário pode acessar com facilidade o que foi visualizado recentemente.

Ajustamos a tela de login do XTended para que não seja apresentada a opção de Recuperação de Senha quando a forma de logon for LDAP ou NTLM.