Gestão de Pessoas | HCM - 6.10.3.28

Melhoramos a documentação do campo intConc, do leiaute S-2240 - Condições Ambientais do Trabalho - Agentes Nocivos. Esclarecemos que, caso o campo Utiliza NEN, da tela de cadastro de agentes de risco, esteja definido como S-Sim, o NEN sempre será considerado dentro do Laudo do Agente de Risco.

Problema: ao gerar o leiaute S-1200 para um colaborador em que a configuração da empresa e do eSocial está configurada para lotação por rateio, identificamos que ocorria um acúmulo incorreto do valor nos eventos gerados. Além disso, os eventos estavam sendo atribuídos a lotações incorretas quando havia diferenças de rateio a cada mês e no mês da demissão.

Correção efetuada: ajustamos a geração do dissídio no leiaute S-1200 para que os rateios e os valores correspondentes de cada competência sejam gerados corretamente.

Problema: o sistema gerava indevidamente o leiaute S-1200 referente à competência anterior à transferência entre empresas do colaborador quando ocorriam férias iniciadas após a transferência e com pagamento na competência anterior à transferência.

Correção efetuada: realizamos ajustes na rotina de geração do leiaute S-1200 para evitar que informações de remuneração de férias sejam incluídas na empresa destino quando o pagamento ocorrer ainda na empresa de origem.

Problema: ao gerar a rubrica de evento de férias em que o evento está configurado com um código fixo no campo de incidência de IRRF e integrado na ficha financeira, identificamos que estava sendo gerado indevidamente com o código de IR informado no cadastro do evento.

Correção efetuada: ajustamos a rotina de geração de rubrica para que, mesmo com o código informado manualmente, seja utilizado o código 09 para o campo de incidência de IRRF (codIncIRRF) quando o evento for integrado na folha de pagamento.

Problema: ao gerar novas rubricas em competência anterior a 05/2023, utilizando as naturezas 1020 - Férias ou 1021 - Férias - Abono ou gratificação de férias superior a 20 dias, ocorria a critica 244 - Natureza da rubrica inválida ao realizar o envio do leiaute S-1010 ao eSocial.

Correção efetuada: ajustamos a rotina de geração de rubricas para que seja gerada a data fim na competência 04/2023.

Problema: ao gerar o leiaute S-1200 de um colaborador que possui uma folha normal, uma folha de Participação nos Lucros e Resultados (PLR) e uma folha especial com evento de devolução, identificamos que o sistema não estava movendo corretamente o evento de devolução, resultando na mensagem Demonstrativo XX, Incidência IRRF XX - 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. Verifique o cálculo da folha no log de geração do leiaute.

Correção efetuada: ajustamos a rotina de geração de rubrica para que, mesmo com o código informado manualmente, seja utilizado o código 09 para o campo de incidência de IRRF (codIncIRRF) quando o evento for integrado na folha de pagamento.

Problema: de acordo com o Manual de Orientação do eSocial (MOS), ao informar valores devidos a trabalhador falecido, o campo indApurIr das rubricas deve ser definido como 1 - Situação especial de apuração de IR, porém, esse campo estava sendo gerado com o valor 0 - Normal.

Correção efetuada: ajustamos para que ao informar valores devidos a trabalhador falecido, o campo indApurIr das rubricas seja gerado com o valor 1 - Situação especial de apuração de IR nos seguintes leiautes:

• S-2299 - Desligamento;
• S-2399 - Trabalhador Sem Vínculo de Emprego/Estatutário;
• S-1200 - Remuneração de trabalhador vinculado ao Regime Geral de Previdência Social; e
• S-1202 - Remuneração de servidor vinculado a Regime Próprio de Previdência Social - RPPS.

Realizamos uma melhoria na documentação de Dirf - Declaração do Imposto de Renda Retido na Fonte, com a inclusão de nota referente à rotina de expatriado não separar em respectivas receitas os recebimentos dentro do ano-base:

• Quando o colaborador tiver histórico de Receita IRRF 0473 (Expatriado), os recebimentos durante o ano-base serão todos listados nesse código de receita, não realizando distinção entre outras receitas recebidas nesse contrato durante o ano.

Para verificar a documentação completa, acesse DIRF.

Alteramos a documentação de Dirf - Declaração do Imposto de Renda Retido na Fonte, referente ao campo Dependentes.

De:

• O sistema não emite Informe de Rendimentos para dependentes de colaboradores que recebem pensão alimentícia. O assinalamento do campo Dependentes na tela de geração da Dirf serve apenas para listar os dependentes com Grau de Parentesco = 15 (Pensionista) - uso pela área Pública.

Para:

• O assinalamento do campo Dependentes na tela de geração da Dirf serve para listar os dependentes com Grau de Parentesco = 15 (Pensionista) - uso pela área Pública, e também possibilita a listagem do informe de rendimentos ao(s) dependente(s) do colaborador.

Também foi realizada melhoria da documentação do quadro Importante, com a inclusão de nota referente à geração do Informe de Rendimentos de dependente:

• Para gerar o Informe de Rendimentos de dependente tipo 4 - Outros do evento Pensão Judicial, a DIRF deve ter sido gerada com o parâmetro Dependentes marcado. Caso não tenha sido gerada desse modo, não listará o informe ao dependente do colaborador.

Para verificar a documentação completa, acesse DIRF.

Realizamos melhoria da documentação de Ficha Complementar, referente à guia Contrato Temporário, com inclusão de quadro Importante referente ao uso da tela Contrato Temporário (FR034CTR):

• Essa guia somente deve ser utilizada para colaboradores com categoria eSocial 106 - Trabalhador Temporário - contrato nos termos da Lei 6019/74 ou outra categoria equivalente, também regida pela Lei 6.019 de 1974.

Para verificar a documentação completa, acesse contrato temporário.

Problema: ao utilizar o atalho disponível na tela de Empregados para acessar a tela de Histórico Salarial (FR038HSA), o botão Excluir era desabilitado.

Correção efetuada: realizamos um ajuste no sistema, permitindo que o botão seja habilitado ao acessar a tela de Histórico Salarial pelo atalho.

Melhoramos a documentação do campo Perde Direito ao Período Aquisitivo de Férias da guia Cadastro, adicionando informações da opção A - Perde Direito se > 180 Dias (Aux.Doença). Para mais informações, acesse o Manual do Usuário.

Problema: ocorria lentidão ao abrir a Tela de Entrada do processo automático de relatórios.

Correção efetuada: ajustamos o componente da construção da tela para melhorar a performance.

Problema: ao efetuar uma reestruturação de postos de trabalho, para um colaborador que possuía mais de um histórico de função, apenas um dos históricos era atualizado para o novo posto do colaborador.

Correção efetuada: ajustamos a rotina para que sejam atualizados todos os históricos corretamente.

Ajustamos a documentação do campo codEtb, referente à porta FichaBasica_6 do web service com.senior.g5.rh.fp.fichaBasica, retirando a opção 0 - Não estável da lista de valores possíveis para a definição do campo. Esclarecemos que, como o sistema não permite que o web service seja executado com esse valor, o campo Estabilidade pode permanecer vazio, pois o registro será gravado no banco de dados com o valor 0.

Problema: quando o colaborador possui folha complementar na competência, as deduções da folha mensal não estavam sendo consideradas adequadamente. Isso resultava em um valor de base incorreto e gerava o Imposto de Renda (IR) maior do que o devido.

Correção efetuada: realizamos um ajuste no cálculo do sistema, permitindo que os valores corretos de dedução sejam calculados para todas as folhas referentes à mesma competência de pagamento.

Problema: o sistema não considerava o valor correto de Imposto de Renda (IR) no cálculo com a simplificação, quando o colaborador tinha dependente cadastrado e o evento de pagamento da pensão estivesse informado o IRRF deduzindo da base no cadastro de Eventos (FR008EVC).

Correção efetuada: alteramos o cálculo da pensão judicial para que ao simular o cálculo do IR, acumule o valor calculado da pensão para comparar com a dedução simplificada.

Problema: ao utilizar o filtro do campo Centro de Custo na tela de entrada do modelo 002 - Relação de Vales por C. Custo (BS00002.VAL), foi identificado que o sistema não estava respeitando a competência em que o colaborador estava vinculado no centro de custo.

Correção efetuada: realizamos um ajuste no sistema, de forma a considerar os registros do histórico de Centro de Custo e exibir o registro mais recente associado à competência selecionada.

Problema: os modelos 019 - Estatist.Sexo/Idade(gráfico perc. por sexo (CSRE019.COL) e 020 - Estatist.Sexo/Idade(gráfico perc.Idade) (CSRE020.COL) estavam considerando colaboradores com data de nascimento zerada.

Correção efetuada: ajustamos os relatórios para desconsiderem colaboradores com data de nascimento zerada.

Atualizamos a documentação da tela Definição Integração (FR060DIN) com as seguintes informações:

• No campo Evento Horas Normais Diurnas e Evento Horas Normais Noturnas, esclarecemos que esse evento não será integrado com base nas horas efetivamente trabalhadas no período. Para colaboradores mensalistas, esse evento é utilizado para completar as 220:00 horas de trabalho. Caso precise integrar as horas de trabalho conforme apuração, é necessário remover esse evento das definições de integração e informar a situação de trabalho na guia Situação do cadastro de eventos de trabalho diurno e noturno.
• No campo Gerar Horas Normais Realizadas, adicionamos uma nota para enfatizar que esse assinalamento tem como propósito integrar as horas de trabalho noturno quando o horário do colaborador é diurno, mas ele trabalhou durante a noite. Isso é aplicável geralmente aos horários 3 - flexível. No entanto, devido à integração ser baseada sempre no horário previsto, não serão geradas horas noturnas nesse cenário. Para que sejam geradas horas noturnas, é necessário definir esse campo como S - Sim.

Acrescentamos uma nota na documentação do cálculo de apuração do Tipo 5 - Calcular Refeitório para informar que esse processamento não irá permitir que seja selecionado um arquivo para leitura, uma vez que as marcações de refeitórios já devem ter sido lidas pelo processo tipo 0 - Calcular Apuração e Refeitório.

Problema: as marcações que foram apuradas com o coletor do Captura Ponto 373 estavam sendo desassociadas do ponto quando eram recalculadas com uma nova proprietária que não possuía mais o módulo Captura Ponto 373.

Correção efetuada: realizamos ajustes no sistema para permitir o recálculo da apuração sem desassociar as marcações do colaborador.

Adicionamos uma nota importante na documentação sobre Processos Automáticos, para enfatizar que todos esses processos são executados utilizando o usuário do banco de dados. Portanto, se houver a necessidade de efetuar a carga de abrangência de usuário, definir cálculos ou empresas ativas, ou qualquer outra configuração relacionada ao usuário do sistema, recomendamos utilizar as funções LSP específicas para esses fins.

Por fim, destacamos que é possível encontrar a lista de funções disponíveis no Índice das Funções.

Atualizamos a descrição do campo Considerar Direção Consumo da tela Definições Refeitório (FR068DRF) para informar que quando ele for definido como S - Sim, o sistema considerará apenas a marcação de entrada (Direção = E) como consumo.

Adicionalmente, destacamos que nas marcações de ponto e refeitório (uso da marcação 4), a direção das marcações segue o registro de direção do ponto. Dessa forma, a saída para a refeição é tratada como uma saída regular e não será considerada para o consumo. Somente o momento de retorno da refeição, que corresponde à entrada da tarde, será considerado para o registro adequado.

Incluímos uma observação na documentação da tela Incidentes do colaborador para informar que esta tela não está disponível para visualização em dispositivos móveis.

Na documentação da tela Configurar menu na senior X Platform, complementamos o item 4 do tópico Customizar aplicativos para informar que é necessário certificar-se de salvar o conteúdo exibido em um arquivo com a codificação UTF-8.

Problema: ao utilizar a função possuiConta na regra de apuração, causava uma perda de performance e poderia ocorrer a mensagem java heap space nos domínios do Gestão do Ponto.

Correção efetuada: realizamos uma melhoria na performance ao utilizar a função possuiConta.

Problema: quando o cadastro de violação de intrajornada possuía a mesma situação cadastrada como hora extra, o sistema não realizava o cálculo das horas extras para o colaborador.

Correção efetuada: realizamos um ajuste no sistema para que agora as horas extras e as violações de intrajornada sejam somadas na mesma situação.

Enriquecemos a documentação da tela Meus acertos de ponto, no tópico Incluir ação de acerto, para informar sobre as cores do processo de acerto. Destacamos que a cor do card que indica o prazo para expiração da ação de acerto de ponto é determinada com base no cálculo do percentual a expirar e, com base no valor do percentual, a cor será determinada da seguinte forma:

• Se o percentual for maior ou igual a 30: a cor será verde.
• Se o percentual for maior que 0 e menor que 30: a cor será amarela.
• Se o percentual for igual a 0: a cor será vermelha.

Problema: ao ter um usuário associado logado que ainda não possui uma empresa ativa, o campo Escala não estava sendo exibido.

Correção efetuada: realizamos um ajuste no sistema para exibir a mensagem Selecione uma empresa ativa para prosseguir quando o usuário não estiver vinculado a uma empresa ativa e abrir a tela de solicitação de vaga. Isso permite que o usuário seja alertado sobre a necessidade de selecionar uma empresa ativa antes de prosseguir com a solicitação.

Melhoramos a documentação relacionada à coluna Local, da tela de cadastro de PPRA. Informamos que, quando o usuário utilizar a coluna Local, definindo-a para uma filial específica, obrigatoriamente será necessário que haja uma linha para a filial em questão com o Local zerado.

Adicionamos mais informações à documentação do campo CA EPI Equivalente, da tela Definições Segurança - PPP. Informamos que, caso o usuário utilize EPIs equivalentes, esse campo deve ser definido como S - Sim. Desse modo, ao distribuir um EPI equivalente, na geração do leiaute S-2240, será considerado o CA do EPI equivalente que foi distribuído, desconsiderando o EPI que está na revisão do GHE.

Problema: o modelo 004 - Protocolo Individual de Entrega de EPI (SMEP004.GER) listava o campo Usuário de maneira indevida, não respeitando os parâmetros informados no cadastro da Distribuição do EPI (FR096DIE).

Correção efetuada: ajustamos o modelo para que ele traga o nome do usuário corretamente, respeitando os períodos em que as distribuições foram realizadas.

Problema: quando utilizada a função SegGrpAdicMem para adicionar um usuário, ela removia os demais usuários do grupo, permanecendo apenas o último adicionado.

Correção efetuada: corrigimos alteração que causou a exclusão dos outros usuários do grupo quando um novo usuário era incluído.