Gestão de Pessoas | HCM - 6.10.3.49

Complementamos a documentação de Dissídio sobre a geração do leiaute S-1200, onde o colaborador possui apenas Devolução de INSS, sem o desconto, que ocorre a mensagem no log:

Demonstrativo XXX000, Incidência INSS 31 - 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 INSS. Verifique o cálculo da folha.
DD/MM/YYYY 00:00:00 00 - Vencimentos (0,09)
DD/MM/YYYY 00:00:00 00 - > Evento: 000 Valor: 0,09
DD/MM/YYYY 00:00:00 00 - Informativo (0,00)
DD/MM/YYYY 00:00:00 00 00 - Descontos (0,00)
DD/MM/YYYY 00:00:00 00 00 - Informativo de desconto (0,00)

O Evento: 000 Valor: 0,09 é a Devolução de INSS.

Considerando que esta devolução é devida, a sugestão é criar um evento para a devolução deste valor ao colaborador com característica 39Z, incidência positiva para IRRF (conforme evento de devolução de IRRF), natureza eSocial 9201 e lançar o valor da Devolução do INSS nesse evento criado e excluir o evento de devolução de INSS dessa ficha financeira.

Problema: ao processar o leiaute S-1207, quando existem pagamentos do cálculo do tipo 91 - Adiantamento, os valores não eram levados no leiaute.

Correção efetuada: ajustamos o processamento do leiaute S-1207 para considerar o envio das informações geradas do cálculo de adiantamento.

Enriquecemos a documentação da tela Exclusão de Pendências, enfatizando que essa rotina deve ser empregada somente quando há a necessidade de excluir múltiplas pendências simultaneamente, e/ou quando não é viável modificar a folha de pagamento ou outros procedimentos que resultam em pendências de eventos periódicos.

Para informações adicionais, consulte a documentação específica da tela Exclusão de Pendências.

Problema: ao processar um volume grande de pendências de leiautes não periódicos, o sistema retornava o erro Java heap space.

Correção efetuada: ajustamos o processamento dos leiautes não periódicos para que não ocorra o erro mencionado.

Problema: ao utilizar a rotina de Fechamento SST, o sistema estava exibindo a mensagem O NIS do(a) colaborador(a) não foi informado na Ficha Cadastral. No entanto, essa informação não é mais obrigatória para o eSocial desde a implementação da Simplificação do eSocial.

Correção efetuada: removemos a validação para o campo NIS.

Na documentação da guia Cálculos da tela Eventos, adicionamos a seguinte informação: Para eventos integrados de outros módulos, o sistema não utiliza esse parâmetro como consistência. Isso significa que, mesmo que os eventos estejam configurados corretamente, eles serão calculados se forem integrados no tipo de cálculo inadequado.

No que diz respeito à documentação das telas Manutenção Lançamentos para Colaborador e Lançamentos Fixos e Variáveis, as informação foi inserida da seguinte forma: Para eventos integrados de outros módulos, o sistema não realiza consistência entre o tipo de cálculo selecionado no momento da integração e os cálculos válidos cadastrados na aba Cálculos do cadastro do evento (Tabelas > Eventos > Eventos > Cadastro). Isso significa que, mesmo que os eventos estejam configurados corretamente, eles serão calculados se forem integrados no tipo de cálculo inadequado.

Adicionamos uma observação na documentação da tela Efetuar Cálculo para destacar que, ao realizar o cálculo através dos botões Assíncrono ou Agendar, não deve ser informado um lote no botão Seleção.

Melhoramos a documentação da tela Pagamentos Física ao incluir a informação de que, ao cadastrar pagamentos para terceiros com o mesmo CPF, é necessário seguir as diretrizes de cálculo de alíquota progressiva descritas na documentação da Regra de Sistema 26 - INSS.

Incluímos uma observação na documentação do campo Diferença Positiva/Negativa, localizado na guia Cadastro da tela Empresas, a fim de esclarecer que, ao parametrizar o campo com a opção S - Sim, mesmo os eventos de férias que não possuírem indicação dos eventos de diferença nos campos Diferença Positiva e Diferença Negativa, serão considerados no cálculo.

Acrescentamos um exemplo na documentação do campo Gerar Estabilidade, localizado na guia Cadastro da tela Situações.

Nesse exemplo ilustramos a situação em que o campo Gerar Estabilidade é configurado como F e o limite máximo de dias é definido como 30. Isso resulta na criação automática de períodos de estabilidade após afastamentos por férias, e caso um novo afastamento coincida com um período de estabilidade existente, o sistema gerará registros adicionais de estabilidade e reajustará os dias para acomodar o novo afastamento.

Complementamos a documentação da tela Situações com o intuito de esclarecer na documentação do campo Tipo da Situação, que o tipo 13 - Aviso Prévio Trabalhado é aceito no módulo de Administração de Pessoal.

Adicionalmente, incluímos uma nova observação na nota de destaque do campo, informando que ao utilizar o tipo de situação 13 - Aviso Prévio Trabalhado, será calculado na ficha financeira o evento de horas aviso prévio. Se os dias de afastamento na situação forem calculados em rescisão, as horas de afastamento serão calculadas no evento saldo de salário.

Adicionamos uma nota na documentação do campo Data Criação, localizado na guia Cargo da tela Cadastro de Cargos, para destacar que seu preenchimento é relevante e obrigatório ao criar um novo cargo. Dessa forma, deve-se avaliar quando essas informações serão utilizadas, bem como o processo de criação de um novo cargo.

Adicionalmente, destacamos que, caso seja necessário, informações sobre a data de criação para o CBO 2002 podem ser encontradas no site do Ministério do Trabalho.

Problema: na documentação do campo Médias 13º limitar ao ano estava informando que a opção N - Não considerava os meses do ano atual e os meses do ano anterior para o cálculo das médias.

Correção efetuada: ajustamos a documentação do campo para informar que ao utilizar a opção N - Não, é considerado o mês de dezembro do ano anterior e os meses do ano atual.

Complementamos a documentação da tela Abrangências, destacando a informação de que a Abrangência Normal/Tradicional e a Abrangência de Hierarquia não devem ser aplicadas simultaneamente a um único usuário. Caso um usuário possua ambas as abrangências, o sistema irá mesclá-las. Como resultado dessa combinação, com base na tabela associada à abrangência e na condição da forma de aplicação (abrangência geral ou abrangência por módulo), o sistema pode gerar conflitos nas condições do usuário.

Ajustamos a descrição do relatório 001 - S-5001 Contribuições sociais por trabalhador (FPAR001.ESO) para facilitar o entendimento de todas as suas funcionalidades.

Problema: o modelo 001 - Lançamentos Variáveis (FPLV001.LAN) não estava listando informações para o cálculo do tipo 94 - Reclamatória Trabalhista.

Correção efetuada: realizamos ajustes no relatório para listar as informações corretamente para o cálculo do tipo 94 - Reclamatória Trabalhista.

Complementamos a documentação da função DefineAbrUsu para destacar que, quando deseja-se trabalhar com mais de um tipo de abrangência (segundo parâmetro, por exemplo, com os valores 1 e 3), existem duas abordagens possíveis:

• Separar os tipos e gravá-los individualmente, utilizando a função GravaNoBancoAbrUsu(): deve-se informar um tipo de abrangência, gravá-lo e, em seguida, informar o outro tipo de abrangência desejado e gravá-lo também; ou
• Informar os valores de forma decrescente e gravar apenas uma vez: nesse caso, pode-se informar todos os tipos de abrangência desejados em ordem decrescente e gravá-los em uma única operação.

Para melhor exemplificar a informação, adicionamos exemplos na documentação.

Melhoramos a documentação do campo Criar Usuário Por Colaborador, da tela Assinalamentos de Usuários, relacionando suas opções com suas respectivas definições, sendo:

• S - Sim: o usuário será criado pelo sistema somente ao clicar no botão Criar Usuário, presente na tela de associação de usuário a colaborador (ao clicar no botão, será aberta a tela de cadastro de usuários do SGU). Essa tela é acessada pelo botão Usuários da ficha cadastral ou através do menu Diversos > Usuários > Associar Colaborador.
• N - Não: a tela de associação de usuário a colaborador não poderá ser acessada. Consequentemente, não será possível criar um novo usuário para colaboradores admitidos.
• A - Automático: imediatamente após concluir o cadastramento de um novo colaborador, será aberta a tela do SGU para cadastrar o novo usuário. Depois de concluído o seu cadastramento, será feita automaticamente a associação do usuário ao colaborador (tabela R034USU).

Ao listar o modelo 003 - Histórico de Cargo (CSRE003.COL), ocorria a mensagem Não houve informações a listar quando informada uma data de anos anteriores no campo Data Inicial da tela de entrada.

Complementamos a descrição do relatório informando que o modelo respeita a hierarquia de um organograma, ou seja, dentro desse organograma, existem diferentes níveis de locais. Ao registrar uma nova atualização na hierarquia e ao gerar um relatório a partir dessa data, ele refletirá com precisão a estrutura hierárquica vigente nesse momento. O relatório se baseia exclusivamente nas informações contidas nesse organograma e não tem acesso aos registros anteriores.

Problema: na geração do modelo 004 - Arquivo Eletrônico de Jornada (AEJ Portaria 671) (HRFI004.GER), as marcações com direção e número sequencial do par estavam sendo exibidas de forma inadequada em datas com marcações noturnas. Estas marcações noturnas ocorriam em uma data, mas pertenciam à jornada da data anterior.

Correção efetuada: ajustamos o sistema para listar corretamente as marcações.

Problema: na apuração diária, as horas de violação de interjornada não eram calculadas quando o dia era DSR (horário 9999) e a data anterior correspondia a um feriado (horário 9997) que foi trabalhado, não atendendo ao requisito de 35 horas de descanso necessárias para o DSR.

Correção efetuada: ajustamos o sistema para que realize o cálculo corretamente nesse cenário.

Problema: tela de acertos na interface Web 5.0 não aplicava corretamente a regra por processo 375 - Consistir Marcações nos Acertos na Data quando usuário inseria ou excluía marcações.

Correção efetuada: ajustamos o sistema para garantir que a regra seja processada corretamente nessa situação.

Problema: ao realizar o cálculo de apuração em um dia no qual a última marcação excede o limite de separação de jornada, e o dia seguinte é designado como horário compensado, folga ou DSR, com a definição de apuração configurada para considerar pares, o sistema estava alocando a última marcação para o dia seguinte, desrespeitando essa configuração.

Correção efetuada: ajustamos o sistema para garantir que, mesmo quando a marcação ultrapassa o limite de separação de jornada, caso esteja configurado para considerar pares, a marcação seja realocada para o dia anterior.

Complementamos a documentação do campo Manter Histórico das Reservas de Vagas Requisições, localizado na guia Controle de Vagas da tela Assinalamentos Diversos, para destacar que ao parametrizar esse campo como 2 - Não podem ocorrer inconsistências em telas como Consulta Comparativa do Quadro e relatórios derivados delas. Dessa forma, sempre que for alterado, esse assinalamento deve ser normalizado o efetivo.

Problema: no campo de nome, ao enviar convites, ocorria a remoção dos espaços no final do conteúdo digitado, impedindo a inserção adequada de nomes compostos.

Correção efetuada: implementamos uma solução para preservar os espaços no final do conteúdo, removendo somente os espaços desnecessários. Isso permitirá a inserção correta de nomes compostos.

Problema: não era possível fazer login usando a autenticação SAML para integração da plataforma.

Correção efetuada: ajustamos o login do sistema quando utilizada a autenticação SAML para integração da plataforma.