Gestão de Pessoas | HCM - 6.10.1.100

Problema: quando a empresa utiliza no campo Apresentação CA a opção C - Distribuição - Considerando CA informado na distribuição do EPI e o colaborador estava afastado, uma pendência do leiaute S-2240 para envio ao eSocial era gerada e ocorria a mensagem Não foi encontrado nenhum CA para o EPI: X, PPRA: X, GHE: X, Revisão: X, Agente: X ao tentar processar.

Correção efetuada: efetuamos um ajuste para desconsiderar a pendência do leiaute S-2240 quando ocorrer essa situação.

Criamos a tela de Carga Inicial S-2240 - Retorno Afastados. Por meio desta tela, o sistema busca os colaboradores que tiveram:

• afastamento iniciado antes do início do período de obrigatoriedade do cadastro de eventos de SST;
• retorno posterior ao início do período de obrigatoriedade do cadastro de eventos de SST; e
• que não possuem o evento S-2240 - Condições Ambientais do Trabalho enviado para o eSocial (ou pendências de envio).

A partir dessas condições, ao clicar no botão Processar, serão geradas pendências de envio do leiaute S-2240.

Para mais informações, verifique a documentação da tela.

Problema: ao realizar o envio do leiaute S-2299, era retornada a crítica Não foi possível integrar o arquivo: O arquivo não segue o formato esperado quando o colaborador tinha um pagamento de dissídio na mesma competência em que ocorreu a demissão. Ao incluir os valores do dissídio, o sistema realizava a montagem separando esses valores no leiaute.

Correção efetuada: ajustamos o sistema para gerar corretamente o leiaute S-2299, permitindo a integração adequada do arquivo mesmo quando há pagamento de dissídio na mesma competência de demissão.

Problema: quando um colaborador foi transferido para outra empresa, onde já possuía um afastamento em andamento sem data de término definida, ao realizar o fechamento da admissão na nova empresa, foi gerado o leiaute S-2200 com a data de afastamento anterior à nova admissão. Posteriormente, o afastamento foi excluído, e o leiaute S-3000 gerado foi excluído também por não possuir nenhum leiaute S-2230 de início. Ao tentar cadastrar um novo afastamento, o eSocial rejeita a ação de envio do leiaute S-2230 e retorna com a crítica 183 - Ação não permitida. É necessário que o trabalhador esteja em atividade na data do afastamento. Ação Sugerida: Verificar se a data do afastamento está correta, pois o colaborador já está afastado. O sistema não estava gerando uma retificação do leiaute S-2200 sem o afastamento para que, então, fosse possível gerar um novo afastamento.

Correção efetuada: ajustamos o sistema para que, ao excluir um afastamento com data de início anterior à data de admissão, seja gerada uma pendência de retificação para o leiaute de admissão.

Problema: quando ocorre a incorporação de uma empresa e é necessário reintegrar alguns colaboradores, é preciso enviar o leiaute S-2200 com a data de admissão e desligamento e, em seguida, realizar a rotina de reintegração. No entanto, o sistema, além de gerar o leiaute S-2200 com a data de desligamento, também gerava o leiaute S-2299, que retornava do eSocial com as seguintes críticas: 106 - Foi localizado no sistema um evento em duplicidade com o evento a ser enviado, 180 - O Vínculo Trabalhista não foi localizado e 181 - O Vínculo Trabalhista já se encontra encerrado na data do evento.

Correção efetuada: ajustamos a rotina do fechamento de demissão para não gerar o leiaute S-2299 quando existir o leiaute S-2200 com a data demissão enviado ao eSocial, será gerado um novo leiaute S-2200 retificador com a informação.

Problema: ao processar o leiaute S-1200, onde o colaborador teve uma folha mensal, um adiantamento salarial e uma folha especial para gerar a devolução de IR, ao mover o evento de devolução do dmDev para um novo dmDev, ele era movido para o cálculo tipo 91 - Adiantamento Salarial em vez de ser gerado no cálculo tipo 93 - Especial.

Correção efetuada: realizamos ajustes na rotina de devolução de IR para evitar que o evento de devolução seja movido para uma folha do tipo 91 - Adiantamento Salarial. Além disso, ajustamos a devolução quando houver um valor de IR de desconto do mesmo código de IR com um valor maior ou igual à devolução.

Problema: ao processar o leiaute S-1200 da competência 05/2023 de um colaborador que teve evento de devolução de IRRF no cálculo de dissídio coletivo, o sistema exibia a mensagem O somatório dos Vencimentos e Informativos deve ser maior ou igual ao somatório dos Descontos e Informativo de desconto de cada incidência de IRRF.

Correção efetuada: ajustamos a verificação de IR descontado para que o valor de devolução seja movido para a competência 04/2023.

Adicionamos mais informações sobre a tag indGuia do leiaute S-1260 - Comercialização da Produção Rural Pessoa Física do eSocial. Informamos que esse campo deve ser preenchido conforme parametrizações que constam nas Definições do eSocial. Além disso, caso a empresa esteja enquadrada na simplificação, será gerada a tag indGuia nos eventos periódicos e nos eventos de desligamento (S-2299 e S-2399), sendo:

• A - Automática: a tag indGuia somente será gerada se a classificação tributária da empresa for igual a 22 - Segurado especial, inclusive quando for empregador doméstico;
• S - Sim: a tag indGuia será sempre gerada, independentemente da classificação tributária da empresa;
• N - Não: a tag indGuia não será gerada, independentemente da classificação tributária da empresa.

Para mais informações, acesse a documentação do leiaute S-1260.

Ajustamos a geração de pendências de alteração e exclusão do leiaute S-1070 - Tabela de Processos Administrativos/Judiciais para tratar vários históricos no mesmo período inicial. Com isso, caso um histórico seja excluído e haja outro mais recente na mesma competência, a pendência de exclusão criada será automaticamente descartada.

Problema: ao gerar o leiaute S-1200/S-1202, quando houvesse dissídio parcelado com RRA, poderia ocorrer diferença de arredondamento ao somar as rubricas de todos os grupos dmDev. Isso ocorria porque, na folha de tipo 14, o evento de pensão judicial é dividido em Pensão Judicial e Pensão Judicial RRA, enquanto que, na folha de tipo 13, é considerado apenas o evento Pensão Judicial. Sendo assim, ao somar as rubricas de Pensão geradas em todos os grupos dmDev, o somatório poderia apresentar uma diferença de centavos, uma vez que é aplicado o valor da parcela para cada grupo dmDev.

Correção efetuada: ajustamos para que a rubrica de Pensão Judicial RRA seja gerada ao calcular a folha de tipo 14. Dessa forma, o valor dos dois eventos será somado para verificar se há diferença de valores, e os centavos de diferença serão levados para o último grupo dmDev gerado.

Para o eSocial será sempre considerada a rubrica gerada para o evento de Pensão Judicial das folhas de tipo 13, pois é o grupo infoRRA do grupo dmDev que identifica qual valor é de RRA .

Problema: ao processar o leiaute S-2500, em algumas situações, ocorria o erro Grupo de Exposição a Agentes Nocivos não deve ser preenchido. Verifique as condições de preenchimento.

Correção efetuada: ajustamos a verificação da Mudança da Categoria nos processos trabalhistas para validação correta do parâmetro infoAgNocivo.

Problema: poderiam ocorrer erros de consistência no campo Grau Exposição, da tela Processo Trabalhista - eSocial S-2500, caso não fosse retornado o código da categoria no select do método retornarCategoriaEsocialColaborador. Consequentemente, na tela Histórico de Categoria eSocial, quando o campo Data Alteração fosse posterior às datas dos períodos, o campo Categoria Trabalhador era retornado com valor de inicialização.

Correção efetuada: adicionamos uma nova validação na busca de categoria para o campo Grau Exposição da tela Processo Trabalhista - eSocial S-2500. Agora, caso a data de histórico de categorias seja posterior aos períodos de pagamento, será considerada a informação do campo Data Sentença ou Data Conciliação para apuração do histórico.

Em uma base de dados Oracle, ao realizar uma rescisão complementar informando uma estabilidade superior a 999 dias, ocorria a mensagem Não foi possível gravar as informações. Erro: Erro de acesso ao banco de dados Oracle. Para solucionar essa questão, realizamos um ajuste no tamanho do campo Estabilidade, permitindo que agora seja possível efetivar a rescisão complementar com uma estabilidade de até 9999 dias.

Problema: o modelo 005 - Comprovante de Rendimentos Legal-Portal (FPIN005.ANU) não era gerado quando o usuário estava designado como substituto.

Correção efetuada: efetuamos ajustes no sistema para gerar o relatório corretamente.

Problema: ao emitir o arquivo de retorno S-5001 - Contribuições sociais por trabalhador (FPAR001.ESO) com filtro para a Filial X, o relatório exibia colaboradores não vinculados à Filial X.

Correção efetuada: realizamos ajustes no sistema para listar apenas os colaboradores vinculados.

Realizamos as seguintes melhorias no relatório 002 - S-5002 - Imposto de Renda Retido na Fonte por Trabalhador (FPAR002.ESO):

• Agora, quando o relatório for gerado de forma analítica, as informações da coluna Legenda de bases, deduções, isenções e retenções de IRRF serão agrupadas por códigos de incidência IRRF, conforme descrito no leiaute S-5002 - Imposto de Renda Retido na Fonte;
• Implementamos a opção de geração do relatório, de forma sintética, quando se tratar de retorno na versão S-1.1 do eSocial;
• Adicionamos uma seção, condicionada à nova opção de entrada Exibir Apuração Diária, para quando o relatório for gerado de forma analítica na versão do S-1.1 do e-Social.

Alteramos a comunicação de aviso de férias do relatório 002 - Aviso de Férias (FPFE002.COL), excluindo a convocação do funcionário para receber no local. Os novos textos do relatório são:

• Contrato Intermitente:
  • Comunicamos que você possui direito às férias que correspondem ao período aquisitivo de XX/XX/XXXX a XX/XX/XXXX. Assim, as férias serão concedidas a partir de XX/XX/XXXX a XX/XX/XXXX e podendo ser convocado a partir de XX/XX/XXXX.
• Demais Contratos:
  • Comunicamos que você possui direito às férias que correspondem ao período aquisitivo de XX/XX/XXXX a XX/XX/XXXX. Assim, as férias serão concedidas a partir de XX/XX/XXXX a XX/XX/XXXX e seu retorno ao trabalho está previsto para o dia XX/XX/XXXX.

A fim de mantermos o relatório 016 - TRCT - Termo de Quitação/Homologação (FP00016.RCS) compatível com o que dispõe a reforma trabalhista, excluímos de seu texto as informações referentes ao parágrafo 1º do artigo 477 da Instrução Normativa SRT nº 15/2010.

Ao monitorar a base de Imposto de Renda (IR) no recálculo de pensão, não estava claro o que compõe a informação do campo Base IR. Realizamos melhorias para explicitar que a base demonstrada não inclui a dedução do dependente, alterando o texto de Base IR para Base IR sem Dependente.

Problema: o aviso prévio indenizado na rescisão complementar calculava considerando a proporção total dos dias de aviso quando havia alteração salarial no penúltimo ou no último dia de Aviso Prévio.

Correção efetuada: ajustamos a rescisão complementar para calcular corretamente, levando em conta a proporção de dias da alteração até o fim do aviso prévio.

Problema: ao calcular o lançamento do vale, o sistema não estava considerando o valor da Base de IR Simplificado.

Correção efetuada: ajustamos a rotina de lançamento do vale para respeitar a tabela de simplificação.

Problema: o sistema apresentava perda de desempenho no cálculo da folha de pagamento ao utilizar a busca de Bases de INSS e IR de outros contratos.

Correção efetuada: realizamos ajustes na rotina de busca de Bases de INSS e IR de outros contratos no sistema, visando melhorar a performance durante o cálculo da folha de pagamento.

Problema: ao acessar a tela de Consulta de Informações da Base de Cálculo, informar o tipo de colaborador, pesquisar pelo cálculo e selecionar qualquer um dos cálculos da lista, com exceção do primeiro, era retornada uma mensagem de erro indicando que o código de cálculo selecionado não existe.

Correção efetuada: ajustamos a consulta do código de cálculo na tela de Consulta de Informações da Base de Cálculo para permitir que o usuário selecione qualquer código de cálculo ao qual o colaborador esteja vinculado.

A Medida Provisória nº 1.171/2023, publicada em 30 de abril de 2023, divulgou uma nova tabela progressiva mensal a ser utilizada, a partir do mês de maio do ano-calendário de 2023, no cálculo do Imposto de Renda Retido na Fonte (IRRF) sobre os rendimentos pagos a pessoas físicas. No dia 05/05/2023, foi liberada a versão 6.10.1.92 do sistema, contendo as implementações necessárias. Além das atualizações já mencionadas, também realizamos as seguintes implementações no sistema:

• No cadastro da Base Cálculo (FRIRFBAS), adicionamos:
  • o campo Eventos para demonstrar o valor do somatório dos eventos de INSS, IPE, Previdência Privada, Pensão Judicial, FAPI e Fundação Prev. Complementar e comparar com o valor informado na tabela do Imposto de Renda (FR026IRF); e
  • o campo Tabela Ded. Simp para demonstrar o valor da dedução simplificada, permitindo comparar os dois valores, onde, caso a base:
    1. seja menor que o valor da dedução, significa que o sistema aplicou a dedução simplificada;
    2. não seja menor que o valor da dedução,  significa que o sistema não aplicou a dedução simplificada.
• No lançamento de Bases (FR044BAS) incluímos os campos Deduções IR Simplificado Mês, Deduções IR Simplificado Férias e Deduções IR Simplificado 13º Salário para informar o valor da dedução simplificada calculado por outro sistema, separando por folha mensal, férias e 13º salário;
• No cadastro da tabela de Imposto de Renda (FR026IRF) incluímos os campos Dedução IR Simplificado RRA e Dedução IR Simplificado 13º Salário. Ao calcular as fichas financeiras com a folha do tipo 14 - Pagamento Dissídio ou 32 - 13º Salário Integral, será realizado um comparativo da soma dos valores dos eventos de INSS, IPE, Previdência Privada, Pensão Judicial, FAPI e Fundação Prev. Complementar com o respectivo campo do cadastro do imposto de renda;
• Na tela de Consulta de informações do cálculo (FRFICINF), adicionamos o campo Ded. Simp. IRRF para demonstrar a base utilizada como dedução simplificada no cálculo.

Para que o usuário possa optar ou não pelo cálculo simplificado por colaborador, realizamos as seguintes implementações no sistema:

• Incluímos o campo Cálculo Simplificado na tela Histórico Receita IRRF. Esse campo ficará habilitado somente quando o campo Cálculo IR estiver definido como S - Sim, cálculo normal.. As opções do campo Cálculo Simplificado são:
  • 0 - Aplica melhor cálculo; e
  • 1 - Aplica cálculo sem dedução simplificada.
• Alteramos o cálculo do imposto de renda para verificar se, na tela Histórico Receita IRRF, o colaborador aplica ou não a dedução simplificada. Com isso:
  • caso o colaborador não tenha histórico cadastrado, ou a data do histórico seja posterior à competência de cálculo, o sistema irá considerar que o colaborador aplica a dedução simplificada;
  • caso, na tela Histórico Receita IRRF, o campo Cálculo Simplificado esteja definido como 1 - Aplica cálculo sem dedução simplificada, o sistema irá calcular o valor do evento de IRRF sem comparar com o valor informado no cadastro do imposto de renda, mesmo que a soma dos eventos seja menor que o informado no cadastro do imposto de renda.

Além disso, os dados de dedução simplificada, das telas de consulta de Base Cálculo e Consulta Informações Cálculo, serão apresentados apenas quando, no histórico de IR vigente na competência de pagamento:

• o campo Cálculo IR estiver definido como S - Sim, cálculo normal; e
• o campo Cálculo Simplificado estiver definido como 0 - Aplica melhor cálculo.

Problema: na tela de Lançamento Coletivo de RRA, o usuário era obrigado a informar um processo, mesmo quando o tipo desse processo fosse igual a 1 - Administrativo. Além disso, quando ocorria um erro no processamento, não era informado com qual colaborador ocorreu o erro e não era retornada a mensagem descritiva. Ainda, quando era realizado rollback das informações gravadas após um erro, também era realizado incorretamente o rollback do log de erro.

Correção efetuada: ajustamos a tela em questão para que seja obrigatório informar o processo apenas quando o tipo do processo informado for igual a 2 - Judicial. Também ajustamos para que erros sejam gravados no log após o rollback.

Atualizamos as telas de Informações RRA e de RRA Coletivo para otimizar a experiência do usuário. Agora, nessas telas, somente estão disponíveis para seleção os cálculos dos tipos 12 - Complementar, 14 - Pagamento Dissídio e 15 - Complementar Rescisão.

Essa mudança visa simplificar a escolha dos cálculos e facilitar o processo de trabalho relacionado às informações do RRA.

Problema: as opções referentes à reclamatória trabalhista ficavam disponíveis para os clientes que não possuem o módulo Jurídico (JR).

Correção efetuada: ajustamos o sistema para que opção de tipo do processo 5 - Reclamatória Trabalhista e as guias Proc. Trabalhista e Informações Tributos - Observações, da tela de cadastro de Processos Judiciais, somente estejam disponíveis quando o módulo Jurídico (JR) estiver habilitado.

Adicionamos as informações do campo Escala Noturna à documentação referente ao Cadastro de Escalas. Nesse campo, o usuário deve informar se a escala cadastrada se trata de uma escala noturna ou não.

Para mais informações, acesse a documentação sobre Cadastro de Escalas.

Adicionamos uma validação na tela de cadastro de aviso prévio (FR042AVI) para verificar se a data de fim do aviso prévio está dentro do período que antecede a data base do colaborador. Logo, caso o colaborador esteja dentro desse período, será retornada a mensagem Colaborador demitido no período de 30 (trinta) dias que antecede a sua a data-base. Conforme art. 9º da Lei nº 7.238, de 29 de outubro de 1984 é devido o pagamento de indenização adicional.

Ajustamos o sistema para que a validação da tela de cálculo da rescisão de contrato de trabalho seja realizada com base no código do Motivo eSocial informado nessa tela, ao invés de ser feita pelo código da causa de demissão cadastrada. Com isso, será considerado o código 06- Rescisão por término do contrato a termo, ao invés da causa de demissão 12- Fim do Contrato de Trabalho.

Realizamos as seguintes implementações e ajustes a fim de atender à versão S-1.1 do eSocial:

• Nas telas Históricos Coletivos e Histórico de Afastamento, renomeamos o campo Data Fim Quarentena para Data Rem. após o Deslig.. Além disso, adicionamos em ambas as telas o campo Indicativo Rem. após o Deslig., onde o usuário deve informar o indicativo da situação de remuneração após o desligamento. A informação do campo será considerada no envio do leiaute S-2399, na versão S-1.1 do eSocial;
• Na tela de Gerar Não Periódicos, implementamos tratamento na geração do leiaute S-2399 para que ele seja gerado conforme a informação dos campos Data Rem. após o Deslig. e Indicativo Rem. após o Deslig.;
• Adicionamos os campos indRem e fimQua à porta Afastamento, versão 4, do web service com.senior.g5.rh.fp.historicosColetivos.

Para mais informações sobre os campos mencionados, verifique as documentações das telas Históricos Coletivos e Histórico de Afastamento.

A fim de mantermos o sistema em concordância com a versão 2.02 do Sistema de Fiscalização Integrada de Gestão (e-Sfinge), realizamos as seguintes implementações;

• tela Atualização do Cargo ou Função (FR304ACF): adicionamos a opção 4 - Desativação por questões de Sistema/Correção à lista de opções do campo Tipo Atualização;
• tela Dados Funcionais do Agente Público Ativo (FR304DAD): adicionamos a opção 99 - Desativação por questões de Sistema/Correção à lista de opções do campo Tipo de Movimentação.

Alteramos os seguintes campos da guia Incidência, da tela de cadastro de eventos, para que sejam de preenchimento opcional:

• Repercute DSR;
• Repercute Aviso Prévio;
• Repercute 13º salário; e
• Repercute Férias.

Criamos a tela Compilar Regras, exclusiva para clientes GO UP. Através desta tela, será possível compilar regras customizadas pelo consultor para que sejam aplicadas no ambiente do usuário.

Para mais informações, verifique a documentação da tela.

Para mantermos sistema em concordância com o que dispõem a publicação da Receita Federal sobre os novos códigos obrigatórios do Imposto de Renda Retido na Fonte sobre rendimentos do trabalho, e o Manual de Orientação do eSocial (MOS), realizamos as seguintes implementações e ajustes:

• Criamos o campo IR EFD-Reinf na tela de cadastro de Imposto de Renda. Esse campo será utilizado para consultar/ajustar o valor de imposto de renda retido quando existir uma rescisão por motivo de morte. Na causa de demissão informada na rescisão, o motivo eSocial deve ser igual a 10 - Rescisão por falecimento do empregado;
• Adicionamos uma nova opção à lista do campo Tipo de Título: R17 - IR Rescisão por morte do empregado. Essa opção permite habilitar os mesmos campos que são habilitados quando informado o tipo R02 - IR Rescisão, sendo:
  • Tipo de Título;
  • Tipo ERP;
  • Tipo Agrupamento;
  • Rateio;
  • Data Entrada;
  • Data Emissão;
  • Fornecedor Individual; e
  • Regra.

O título cadastrado com esta opção será utilizado para criar pendências com valores de IR quando existir rescisão por morte, já que estes valores deverão ser gerados pela EFD-Reinf.

• Implementamos tratamento nas telas de cálculo de rescisão para que quando o motivo eSocial da causa de demissão for igual a 10 - Rescisão por falecimento do empregado e a data de pagamento for maior ou igual a 01/05/2023, os valores de IR sejam gravados no novo campo IR EFD-Reinf, ao invés do campo IR Retido, na tabela de Valores de IRRF. Ainda, também tratamos para que estes valores, que não são recolhidos pela DCTFWeb, sejam levados na integração financeira para que sejam recolhidos pela EFD-Reinf. As pendências de integração serão gravadas conforme o título cadastrado com o tipo R17 - IR Rescisão por morte do empregado;

Além disso, também criamos:

• uma nova coluna na grade das telas Consulta IR Retido e Resumo IR Retido para demonstrar o valor de IR EFD-Reinf;
• o campo IR EFD-Reinf na tela de Base Cálculo para demonstrar o valor de IR EFD-Reinf;
• uma nova coluna nos relatórios 001 - Imposto de Renda Colaboradores (FPRE001.IRF) e 004 - Imposto de Renda Colaboradores - Centro de Custo (FPRE004.IRF) para demonstrar o valor de IR EFD-Reinf. Além disso, para o primeiro relatório também criamos o totalizador para o coluna no fim da listagem e, para o segundo, um totalizador por centro de custo e por empresa.

Realizamos ajustes na rotina de Estrutura de Organograma, aumentando a quantidade de posições do campo tabOrg (Código da Tabela de Organograma) de 3 para 4 posições. Anteriormente, era possível cadastrar até 999 estruturas, agora, o cliente poderá cadastrar até 9999 estruturas. Sendo assim:

• o campo tabOrg (Código da Tabela de Organograma) dos seguintes web services passou a ter 4 posições:

Web service	Porta
com.senior.g5.rh.cs.locais	Local, versão 2
com.senior.g5.rh.fp.locais	Local, versão 2
com.senior.g5.rh.hr.locais	Local, versão 2
com.senior.g5.rh.jr.locais	Local, versão 2
com.senior.g5.rh.plr.locais	Local, versão 2
com.senior.g5.rh.plr.locais	Local, versão 2
com.senior.g5.rh.ql.locais	Local, versão 2
com.senior.g5.rh.rs.locais	Local, versão 2
com.senior.g5.rh.sm.SegurancaPPRAPorGHE	SegurançaPPRAPorGHE
com.senior.g5.rh.sm.locais	Local, versão 2
com.senior.g5.rh.tr.locais	Local, versão 2

• O campo tabOrg (Código da Tabela de Organograma) passa a ter 4 posições em todos os relatórios/modelos que possuem esse campo;
• As variáveis TabOrgEmp e TabOrgEmpCen também passaram a ter 4 posições.

Realizamos ajustes na rotina de Estrutura de Cargo, aumentando a quantidade de posições do campo estCar (Código da Estrutura de Cargos) de 3 para 4 posições. Anteriormente, era possível cadastrar até 999 estruturas, agora, o cliente poderá cadastrar até 9999 estruturas. Sendo assim:

• o campo estCar (Código da Estrutura de Cargos) dos seguintes web services passou a ter 4 posições:

Web service	Porta
com.senior.g5.rh.bs.cargos	Cargo, versão 4
com.senior.g5.rh.cs.CargosDescricaoHistorica	CargosDescricaoHistorica
com.senior.g5.rh.cs.CargosEstrutura	CargosEstrutura
com.senior.g5.rh.cs.cargos	Cargo, versão 4
com.senior.g5.rh.fp.CargosEstrutura	CargosEstrutura
com.senior.g5.rh.fp.cargos	Cargo, versão 4
com.senior.g5.rh.hr.cargos	Cargo, versão 4
com.senior.g5.rh.jr.cargos	Cargo, versão 4
com.senior.g5.rh.plr.cargos	Cargo, versão 4
com.senior.g5.rh.ql.cargos	Cargo, versão 4
com.senior.g5.rh.rs.SolicitacaoDeAberturaDeVaga	SolicitacaoAberturaVaga
com.senior.g5.rh.rs.cargos	Cargo, versão 4
com.senior.g5.rh.rs.persistencia	Requisição
com.senior.g5.rh.sm.CargosDescricaoHistorica	CargosDescricaoHistorica
com.senior.g5.rh.sm.CargosEstrutura	CargosEstrutura
com.senior.g5.rh.sm.SegurancaPPRAPorGHE	SegurançaPPRAPorGHE
com.senior.g5.rh.sm.cargos	Cargo, versão 4
com.senior.g5.rh.tr.cargos	Cargo, versão 4

• O campo estCar (Código da Estrutura de Cargos) passa a ter 4 posições em todos os relatórios/modelos que possuem esse campo.
• As variáveis EstCarEmpCen, EstCarEmp, EstCarEmpCen e EstCarFnc também passaram a ter 4 posições.

Problema: ocorria o Erro ao executar requisições HTTP(POST).java.lang.NoClassDefFoundError] org/apache/commons/logging/LogFactory$1 ao efetuar assinatura de modelos Fiscais, nos processos automáticos do Mobilidade e ao utilizar a função HttpPost em regras LSP.

Correção efetuada: ajustamos o sistema para permitir executar esses processos corretamente.

Existe um botão Verificar que, ao ser clicado, deveria verificar todos os dias do ponto do respectivo colaborador. No entanto, ocorre um erro na tela exibindo a mensagem Ocorreu um erro ao verificar o colaborador. Realizamos um ajuste para fornecer uma mensagem mais específica, que melhor descreve o motivo do erro de acordo com a situação.

Problema: ao efetuar a integração para rescisão e o colaborador possuindo banco de horas com prazo de compensação tipo Dias e tipo de compensação como Período/Situação/Dia, as horas a serem pagas com data anterior à demissão não estavam sendo somadas nas horas

.

Correção efetuada: realizamos ajustes na rotina para garantir que todas as horas a serem pagas sejam integradas no caso de rescisão.

Problema: ao editar uma nomeação de substituto, não era possível ajustar a data de término para uma data anterior à data atual, nem quando o substituto estava afastado nessa nova data.

Correção efetuada: realizamos ajustes no sistema para permitir a validação de uma data de término menor que a data atual, desde que o substituto não esteja afastado nessa nova data. Essa validação ocorre apenas durante a inserção de uma nova nomeação, não afetando a alteração de nomeações já cadastradas.

Problema: a descrição do campo no menu de substituição estava exibindo substituído.

Correção efetuada: realizamos a atualização da descrição para a forma correta, agora informando substituto.

Realizamos as seguintes implementações baseadas no item 3.2 Nota Técnica S-1.1 nº 02/2023:

• Ajustamos a geração do leiaute S-2500 para adequação à nova regra da NT S-1.1 nº 02/2023 quanto ao não envio de bases de cálculo zeradas quando não há complemento de remuneração a declarar.

• Alteradas as descrições dos Códigos da Receita 121851 e 122151, da reclamatória trabalhista, sendo:
  • De 121851- Sest a cargo da empresa sobre a remuneração do segurado transportador autônomo para 121851 - Sest a cargo da empresa sobre a remuneração do segurado empregado ou trabalhador avulso;
  • De 122151 - Senat a cargo da empresa sobre a remuneração do segurado transportador autônomo para 122151 - Senat a cargo da empresa sobre a remuneração do segurado empregado ou trabalhador avulso.
• Incluímos novos tipos de contratos de trabalho para reclamatória trabalhista. Além disso, na tela Processo Trabalhista - eSocial S-2500, nas guias Geral e Contrato, criamos consistências referentes ao tipo de contrato 8 - Responsabilidade indireta, que deve ser utilizado quando as informações do responsável direto estiverem preenchidas;
• O preenchimento do campo Data de Admissão Original, da tela Processo Trabalhista - eSocial S-2500, agora será obrigatório apenas se o Tipo Contrato for igual 2 - Trabalhador com vínculo formalizado, com alteração na data de admissão ou 4 - Trabalhador com vínculo formalizado, com alteração nas datas de admissão e de desligamento e deverá ser maior que a data de nascimento do colaborador.

Além disso, a partir da NT S-1.1 Nº 02/2023, é possível informar na Sucessão de Vínculo o Tipo de Inscrição igual a 6-CEI, independentemente da Data de Transferência.

Problema: o modelo 008 - Relação Próximos Exames (SMPC008.GER) listava todos os próximos exames, independentemente da situação em que o colaborador se encontrava.

Correção efetuada: Realizamos um ajuste na descrição do relatório, informando que:

• Este modelo lista os próximos exames independente se o colaborador está afastado ou não, para filtrar os próximos exames de colaboradores que estão com a situação 1 - Trabalhando o campo Situação deve ser preenchido na tela de entrada do modelo.

Atualizamos o Currículo Web para apresentar informações completas sobre os cookies utilizados pela plataforma, buscando garantir a segurança e proporcionar o esclarecimento necessário ao usuário. Agora, a mensagem Esta página utiliza cookies que permitem funcionalidades essenciais. Esses cookies não podem ser desativados, pois recusá-los implicaria em não ser possível sua utilização será apresentada na parte inferior do sistema, enquanto o usuário não aceitar.

Além disso, atualizamos o banner de cookies, direcionando o cliente para a política de cookies da Senior. E também, disponibilizamos o botão Opções nessa nova mensagem, que serve para apresentar os cookies do tipo Requerido. Esses cookies não podem ser desmarcados, pois permitem funcionalidades essenciais do sistema, tais como segurança, verificação de identidade e gestão de rede.

No módulo Gestão de Recrutamento e Seleção (senior X), no momento da aprovação dos candidatos, é permitido a inserção de valores diferentes de salário para dois ou mais desses candidatos em uma mesma vaga. Porém, durante a efetivação dos candidatos no módulo Administração de Pessoal (XTended), o salário do último candidato aprovado na vaga sobrescrevia o salário do candidato anterior e, com isso, o salário do candidato era apresentado com o valor incorreto. Isso ocorria porque, na versão XTended do sistema, é utilizada apenas uma requisição para dois ou mais candidatos, e o valor do salário é salvo nessa requisição. Logo, o salário do último candidato sempre iria sobrescrever o salário do candidato anterior.

Sendo assim, com base no cenário descrito, realizamos as seguintes implementações:

• Adicionamos o novo campo ValSal à tabela R126CAN (Requisições - Vaga Candidato) na versão XTended do sistema. Com isso, o salário do candidato será salvo e, assim, quando for realizada a sua efetivação no módulo Administração de Pessoal (XTended), o salário do candidato será buscado com base nesse campo;
• Também implementamos o campo ValSal no Integrador para que a informação seja salva e repassada corretamente para a versão XTended do sistema. Então, quando se tratar da aprovação de uma vaga, o Integrador irá preencher esse campo com o salário informado para esse candidato na tabela R126CAN (Requisições - Vaga Candidato). Os fluxos que devem apresentar esse comportamento são:
  • Candidato Interno Aprovado; e
  • Candidato Externo Aprovado.

Além disso, ao realizar a efetivação do candidato no módulo Administração de Pessoal (XTended), a partir do menu Colaboradores > Ficha Cadastral > Empregados > botão Efetivação, agora o sistema buscará o salário do candidato a partir do campo ValSal da tabela R126CAN (Requisições - Vaga Candidato), e não mais da R126RQU (Requisições - Definição).

Problema: ao listar o modelo 002 - Revisões Previstas (SMMA002.GER), ocorria a duplicação de um equipamento, sendo listado em um local onde ele não estava vinculado.

Correção efetuada: realizamos ajustes no modelo para evitar a duplicação do equipamento e listar somente no local ao qual está vinculado corretamente.

Problema: ao listar o modelo 002 - Inventário de Riscos Ocupacionais (SMIR002.GER), nem todas as assinaturas eram exibidas em todos os GHE's no campo 6 - Data e assinaturas.

Correção efetuada: realizamos ajustes no modelo para garantir que todas as assinaturas sejam listadas corretamente.

Com o objetivo de atendermos ao que dispõe a Lei nº 14.457/2022, atualizamos a redação dos relatórios 010 - Requerimento MTB (SMCI010.GER) e 013 - Comprovante de inscrição na eleição da CIPA (SMCI013.GER) com a nova nomenclatura da CIPA. Logo, onde a nomenclatura fosse apresentada como Comissão Interna de Prevenção de Acidentes, agora será apresentada como Comissão Interna de Prevenção de Acidentes e de Assédio.

Alteramos a funcionalidade da coluna EPI da guia EPIs, da tela de Revisão do GHE. Agora, ao clicar no botão de pesquisa, caso não tenha sido informado um código de agente na coluna Agente, será retornada uma mensagem ao usuário perguntando se deseja visualizar todos os EPIs cadastrados ou apenas os EPIs que estão relacionados aos agentes da respectiva revisão de GHE.

Para mais informações, acesse a documentação sobre Revisão do GHE.

Realizamos as seguintes implementações relacionadas à tela de Distribuição Coletiva de EPI por Colaborador:

• Na grade EPIs, a coluna CA (Certificado de Aprovação) estará sempre visível, independentemente de como o campo Apresentação CA, da tela Definições de Segurança - PPP, estiver definido. No entanto, o conteúdo da coluna pode variar de acordo com a definição do campo Apresentação CA, sendo:
  • E - EPI: será apresentado o CA cadastrado diretamente no EPI;
  • F - Fornecedor, V - Fornecedor ou D - Fornecedor: exibirá o CA configurado no Fornecedor do EPI;
  • C - Distribuição - Considerando CA informado na distribuição do EPI: a coluna exibirá o CA do fornecedor, porém, será editável para que o usuário realize qualquer alteração que desejar.
• Adicionamos duas novas colunas à grade EPIs da tela, sendo:
  • Última Entrega: data da última entrega (se houver) antes da data que se pretende realizar a nova entrega; e
  • Data Validade: data de validade do EPI. Essa data compreende o intervalo entre a data da última entrega + os dias de validade do EPI (informado no cadastro do próprio EPI).
• Na grade EPIs, quando houver um registro que corresponda a um EPI que já foi entregue em data anterior e ainda estiver válido, esse registro será apresentado na cor verde. Além disso, caso o usuário tente selecionar um registro que já tenha sido distribuído no dia ou em data anterior (que ainda seja válida), o sistema retornará uma mensagem informando e questionando se o usuário deseja mesmo realizar a distribuição novamente.

Para mais informações, acesse a documentação sobre Distribuição Coletiva de EPI por Colaborador.

Problema: ao acessar a guia de participantes e utilizar o filtro de Pessoas, o sistema não funcionava corretamente ao selecionar as opções Com vínculo, Sem vínculo ou Todas.

Correção efetuada: ajustamos o sistema para que, ao escolher o tipo de pessoa no filtro, o resultado da pesquisa retorne as pessoas de acordo com o filtro selecionado.

Adicionamos uma nota à documentação sobre avaliações de eficácia para esclarecer que não é possível buscar o avaliador pela hierarquia. O avaliador somente pode ser buscado pela chefia, a partir da tela Chefes.

Para mais informações, verifique a documentação sobre Avaliação de Eficácia.

Problema: o sistema apresentava falha ao carregar algumas telas de integração com o painel de gestão.

Correção efetuada: efetuamos ajustes para carregar as telas corretamente.

Realizamos as seguintes melhorias e ajustes no HCM XTended para melhorar a experiência do usuário em relação as notificações recebidas e aos tipos de arquivos que agora podem ser baixados:

Notificações

Adequamos a opção para visualizar as notificações do senior X Platform pelo HCM XTended. Agora, além de apresentar a quantidade de notificações não lidas pelo usuário, também há a opção Visualizar todas a notificações, onde o usuário poderá ver todas as notificações e baixar arquivos.

Download de arquivos

Disponibilizado download de arquivos dos recursos senior X Platform pelo HCM XTended. Sendo assim, para arquivos:

• que não possuem preview (ex.: .zip, .exe etc.), será aberta apenas a tela para escolher onde salvar o arquivo em questão;
• que possuem preview (ex.: imagens, .mp3 etc.), será aberta a tela com a preview. Com isso, em seguida, virá a opção para definir onde o arquivo será salvo. Caso o usuário opte por não salvar imediatamente o arquivo, será necessário fechar a preview e reabri-lo.
• no formato .pdf, será aberto o plugin de preview.

Atualmente, não é possível fazer download de arquivos .html.

Adicionamos à tela inicial do HCM XTended o componente de NPS, do Track.io, cuja finalidade é medir o nível de satisfação dos usuários em relação ao sistema. Informamos que esse widget:

• não causará impactos no uso do sistema;
• poderá ser exibido para todos os usuários; e
• somente será exibido novamente após 90 dias da resposta informada.