Junho
Melhoria entregue em 25/06/2026
Atualizado o cadastro de Planos de Previdência e Assistência
Informamos que foi disponibilizada uma atualização na rotina de Planos de Previdência ou Assistência (Configurando > Cadastros Auxiliares), contemplando novas informações de contribuição patronal e o controle histórico dos dados.
Conforme o comunicado realizado em 16/06/2026, foram disponibilizados antecipadamente os novos campos e as adequações nos Service Layers relacionados ao cadastro de Planos de Previdência ou Assistência.
Dessa forma, as entidades poderão antecipar o cadastramento das informações de contribuição patronal, quando aplicável.
Nesta primeira etapa, os novos campos estão disponíveis para cadastro e manutenção das informações, sem impactos imediatos nas saídas do sistema, integrações contábeis, relatórios e demais processos relacionados.
A segunda etapa da implementação, contemplando os impactos nas saídas e integrações do sistema, está prevista para ser disponibilizada durante o mês de Julho.
Alteração:
- Foi incluído o quadro Percentual de contribuição patronal, contendo os campos:
- Fundo (%);
- Taxa administrativa (%);
- Índice de aporte (%).
|
|---|
A partir desta atualização, o sistema controla o histórico de alterações para os campos:
- Fundo (%);
- Taxa administrativa (%);
- Índice de aporte (%);
- Ato;
- Observação.
Para garantir a consistência do banco de dados, todos os registros já existentes receberão automaticamente um registro histórico inicial com a data de competência padrão de 01/1900.
IMPORTANTE:
- Os novos campos serão inicialmente preenchidos com valor nulo.
- Caso um dos percentuais seja informado, os três campos passarão a ser obrigatórios.
- O valor 0 (zero) será aceito como preenchimento válido.
- Não serão permitidos valores negativos ou caracteres alfabéticos.
- Os campos serão desabilitados somente quando o tipo for Previdência e o regime Regime Geral de Previdência Social.
- Não será permitido registrar uma data de criação posterior à vigência do histórico.
1. Além das alterações na interface, o Service Layer de Plano de Previdência ou Assistência foi ajustado para suportar o controle histórico. Com isso, será necessário informar:
- Data de vigência (obrigatório): campo inicioVigencia, no formato AAAA-MM-DDTHH:mm:ss.SSSZ (ex.: 2026-06-01T00:00:00.000Z), conforme padrão utilizado em outras APIs de Service Layer que comportam controle histórico;
- Históricos (Opcional): campo historicos, no formato de array de objetos, sendo estes objetos no mesmo formato do próprio Plano de Previdência ou Assistência, conforme padrão utilizado em outras APIs de Service Layer que comportam controle histórico.
2. Regras para históricos: cada histórico deverá possuir uma competência (mês/ano) distinta. O sistema rejeitará a requisição caso existam dois objetos no campo historicos com a mesma competência informada em inicioVigencia.
3. Nova API de histórico: também foi disponibilizado um novo Service Layer para manutenção dos históricos do Plano de Previdência ou Assistência, seguindo o mesmo padrão adotado pelas demais APIs históricas do Service Layer. Essa nova API, permitirá realizar manutenções pontuais em históricos já cadastrados por meio do Service Layer de Plano de Previdência ou Assistência.
4. Impactos em outras APIs: em decorrência da implementação do controle histórico no cadastro de Plano de Previdência ou Assistência, os cadastros de Cargo e Matrícula, que também possuem controle histórico, passarão a validar a vigência do plano informado em relação à vigência do respectivo registro.
- /v1/api/cargo: o campo planosPrevidencia passará a aceitar apenas planos que possuam registro vigente na data de vigência do registro do cargo;
- /v1/api/matricula: o campo plano, presente nos objetos de previdencias, passará a aceitar apenas planos que possuam registro vigente na data de vigência do registro da matrícula.
Como os planos já existentes até a disponibilização desta alteração terão automaticamente sua vigência inicial definida como 01/1900, não são esperados impactos para registros já existentes de cargo e matrícula com plano informado, exceto nos casos em que o registro de cargo ou matrícula possua vigência anterior a 01/01/1900 e possua plano de previdência ou assistência informado, uma vez que este terá vigência a partir de 01/1900.
Entretanto, recomenda-se atenção em novas inserções que criem e incluam planos recém-cadastrados a cargos ou matrículas, uma vez que a vigência do plano deverá ser compatível com a vigência do registro que o referencia.
Recomendamos que os usuários responsáveis revisem seus processos internos e avaliem possíveis impactos decorrentes desta alteração, especialmente em integrações realizadas por meio dos Service Layers.
Fonte de dados para histórico de Planos de Previdência ou Assistência
Também foi disponibilizada uma nova fonte de dados /api/planos-previdencia/historico-plano-previdencia para consulta dos registros históricos dos cadastros de Plano de Previdência ou Assistência.
Entre as informações disponibilizadas estão:
- Origem.id;
- id;
- Descrição;
- Data de vigência;
- Tipo;
- Regime;
- Âmbito;
- CNPJ da previdência complementar;
- Tipo de previdência complementar;
- Plano de segregação;
- Sujeito ao teto RGPS?;
- Fundo (%);
- Taxa administrativa (%);
- Índice de aporte (%);
- Ato;
- Observações.
Os campos Fundo (%), Taxa administrativa (%), Índice de aporte (%), Ato e Observações são apresentados conforme a vigência de cada histórico cadastrado.
A fonte disponibiliza ordenação pelos campos id e Descrição, além dos seguintes filtros:
- Data de vigência;
- Origem.id;
- id.
Também foi incluído o parâmetro Início da vigência, seguindo o mesmo padrão já adotado na fonte histórica de Matrícula.
Melhoria entregue em 22/06/2026
Permitido o cadastramento de CNPJ alfanumérico
Com o objetivo de atender à alteração divulgada pela Receita Federal, que prevê a adoção do formato alfanumérico para novos CNPJs a partir de julho de 2026, o sistema Folha (Cloud) foi atualizado e está preparado para receber e processar essa nova estrutura de identificação.
Foram realizados os ajustes necessários nos Cadastros, Relatórios, Scripts, Fontes de dados e Service Layers, garantindo a compatibilidade com o novo padrão estabelecido.
Importante destacar que os CNPJs já existentes, permanecem válidos e não sofrerão alterações. O formato alfanumérico será aplicado apenas às novas inscrições realizadas pela Receita Federal.
Para mais informações sobre o novo padrão de CNPJ, clique aqui.
Melhoria entregue em 19/06/2026
Atualização na Gestão de períodos aquisitivos - Férias
Informamos que a rotina Gestão de Períodos Aquisitivos – Férias foi atualizada.
Conforme comunicado realizado em 15/05/2026, as alterações já estão disponíveis no sistema.
Esta melhoria tem como objetivo tornar o processo mais transparente, passando a considerar o Saldo Líquido (já descontadas as faltas) para as concessões de férias.
1. Gestão de períodos aquisitivos
Na tela de Gestão de períodos aquisitivos foi criada a coluna Falta bruta, que apresenta o total bruto de faltas ocorridos dentro do período aquisitivo, que possuem a configuração de reduzir férias.
|
|---|
As faltas consideradas nesta coluna, são aquelas que o Tipo de afastamento com o campo Reduz férias? esteja marcado com a opção Sim.
|
|---|
A coluna anteriormente nomeada Falta, foi renomeada para Faltas à desc., esta coluna representa a quantidade de dias de gozo descontados em razão das faltas do período, conforme a configuração de férias.
|
|---|
A coluna Configuração de férias foi removida, e as informações da configuração passam a ser exibidas na própria coluna Período abaixo das datas:
|
|---|
Atenção na coluna Saldo!
- Quando o parâmetro Descontar faltas sobre férias, inclusive na rescisão (Configurando > Parâmetros > Cálculo) estiver habilitado, o Saldo exibido será automaticamente o valor líquido (Direito menos Faltas à desc.).
- Quando o parâmetro Descontar faltas sobre férias, inclusive na rescisão, não estiver habilitado, o saldo permanece com o comportamento atual.
- Nas concessões, o saldo será atualizado quando ao menos uma concessão manual ou via folha possuir desconto de faltas.
- A data final é definida pela quantidade de dias de gozo.
- Agora é possível cadastrar concessão manual somente com dias de faltas sem informar dias de gozo.
- O sistema entenderá que o período foi quitado somando os dias de gozo + faltas.
2. Impactos na Migração e Tratamento de dados
- Dados Migrados até 18/06: passarão por um tratamento automático.
O sistema converterá o campo Dias de gozo das concessões antigas para o valor real.- Por exemplo: 10 dias de gozo com 4 faltas (totalizando 14), ele será convertido para exibir apenas 6 dias de gozo, adequando-se ao novo modelo de quitação.
- Dados Migrados a partir de 19/06: já deverão ser inseridos seguindo o novo formato de saldo líquido.
- Observação: a atualização automática do saldo para o formato líquido só ocorrerá em períodos que não possuam concessões registradas até a data da entrega da melhoria.
3. Alteração em eventos
Para atender ao novo modelo de saldo, houve uma alteração na forma como o sistema processa as variáveis que alimentam os eventos de folha, o sistema não subtrai mais as faltas durante o processamento (diasGozo - diasFalta), pois a variável diasGozo agora já é o valor líquido final.
|
|---|
Os eventos que são padrões do sistema já serão liberados com a adequação necessária. Caso existam eventos customizados ou que sigam a lógica descrita, será necessário revisá-los e ajustá-los.
Orientamos atenção especial aos eventos abaixo:
- 168 - BASE I.N.S.S. OUTRAS EMPRESAS
- 169 - RETENÇÃO I.N.S.S. OUTRAS EMPRESAS
- 172 - BASE I.R.R.F. OUTRAS EMPRESAS
- 173 - RETENÇÃO I.R.R.F. OUTRAS EMPRESAS
- 312 - BASE I.N.S.S. OUTRAS EMPRESAS AUTÔNOMO
4. Aprimoramento da tela de cálculo e programação de férias
As rotinas de Gestão de pagamentos (Executando > Folha de pagamento > Gestão de pagamentos > Cálculos > processamento Férias (Integral) > Seleção de matrículas Individual) e Programação de férias (Administrando > Processos > Programação de férias) também tiveram suas telas aprimoradas.
Na tela de Cálculos individual, realizamos as seguintes alterações:
|
|---|
Cálculo individual com múltiplos períodos:
|
|---|
- Campo Seleção de matrículas é obrigatório, quando não for informado, os demais campos ficam desabilitados;
- A tela foi separada em dois quadros: Período aquisitivo e Informações para pagamento;
- Os campos abaixos foram formatados:
- Calcular com múltiplos períodos?: alterado formato do campo;
- Habilitar logs de cálculo?: alterado formato do campo;
- Descontar faltas?: alterado formato do campo;
- Pagar ⅓ integral? renomeado para Em férias fracionadas, pagar ⅓ integral?;
- Pagar 13º salário?: renomeado para Adiantar 13º salário?;
- Considera avos perdidos?: renomeado para Considera avos perdidos do 13º salário?;
- Data inicial: renomeado para Data inicial de gozo;
- Data final: renomeado para Data final de gozo.
- Adicionamos o campo Abono pecuniário?, com isso o campo Dias de abono está condicionado ao preenchimento deste campo;
- Quando selecionado um período aquisitivo, agora é apresentada a informação da última remodelagem realizada;
Na tela de Cálculos coletivos, realizamos as seguintes alterações:
|
|---|
- As regras são válidas para Seleção Temporária ou Avançada;
- O campo Seleção de matrículas é obrigatório;
- Os campos abaixo foram formatados:
- Calcular com múltiplos períodos?: alterado formato do campo;
- Calcular férias coletivas?: renomeado para Calcular como férias coletivas?.
- Habilitar logs de cálculo?: alterado formato do campo;
- Descontar faltas?: alterado formato do campo;
- Pagar ⅓ integral?: renomeado para Em férias fracionadas, pagar ⅓ integral?.
- Pagar 13º salário?: renomeado para Adiantar 13º salário?.
- Considera avos perdidos?: renomeado para Considera avos perdidos do 13º salário?.
- Data inicial: renomeado para Data inicial de gozo;
- Data final: renomeado para Data final de gozo.
- Adicionamos o campo Abono pecuniário?, com isso o campo Dias de abono está condicionado ao preenchimento deste campo;
Na tela de Programação de férias, também alteramos e renomeamos os campos, além de dividir em dois quadros Período aquisitivo e Informação de pagamento:
|
|---|
5. Regras para concessão de férias com abatimento de faltas
Quitação: quando houver desconto de faltas por parâmetro geral ou por parâmetro do cálculo Descontar faltas? a quitação passa a considerar Dias de direito ou Dias a adquirir no período - para casos de férias coletivas que ultrapassam o saldo- , menos dias de abono, dias de gozo e faltas à desc.
Limite de Dias de gozo: o máximo permitido passa a ser o saldo líquido disponível.
- Exemplo: servidor com 30 dias de direito, porém teve 12 dias de faltas no período.
- Como fica: você informará apenas 18 dias de gozo. Ao finalizar este cálculo, o sistema entenderá automaticamente que o período de 30 dias foi quitado.
Férias coletivas: as regras foram ajustadas para respeitar a configuração de pagamento:
- Pagamento integral: o limite de dias de gozo continuará sendo a quantidade de Dias a adquirir no período menos Faltas à desc.
- Pagamento proporcional: o limite será os dias adquiridos menos Faltas à desc.
Períodos sem direito de gozo - faltas zeram o saldo: se as faltas eliminarem totalmente o direito, o sistema solicitará apenas a data do pagamento, um alerta é emitido ao usuário de que não haverá cálculo, apenas fechamento do período.
|
|---|
|
|---|
- Cancelamentos e reversões: consideram os dias de faltas, já que a implementação do cancelamento considera apenas dias de gozo e abono.
Com isso, as faltas passam a consumir diretamente o saldo disponível. Se o saldo líquido estiver zerado, o período automaticamente será quitado.
A quitação considera os dias de gozo informados: faltas baixas = total do período.
Isso permite que períodos sejam quitados com base no saldo líquido, inclusive em múltiplas concessões, adequando o comportamento da remodelagem ao novo formato de cálculo.
Comunicado realizado em 16/06/2026
ATENÇÃO: Atualização no cadastro de Planos de Previdência e Assistência
Previsão de liberação em: 25/06/2026
Informamos que será disponibilizada uma atualização na rotina de Planos de Previdência ou Assistência (Configurando > Cadastros Auxiliares), contemplando novas informações de contribuição patronal e controle histórico dos dados.
Devido ao impacto direto será realizada uma liberação antecipada do cadastro e dos Service Layers dos novos campos nos cadastros de Plano de Previdência e Assistência.
Dessa forma, as entidades poderão antecipar o cadastramento das informações de contribuição patronal, quando aplicável.
Nesta primeira etapa, as alterações não terão impactos nas nas saídas do sistema, integrações contábeis, relatórios e demais processos relacionados.
A segunda etapa da implementação, contemplando os impactos nas saídas e integrações do sistema, está prevista para ser disponibilizada durante o mês de Julho.
Alteração:
- Inclusão do quadro Percentual de contribuição patronal, contendo os campos:
- Fundo (%);
- Taxa administrativa (%);
- Índice de aporte (%).
|
|---|
A partir desta atualização, o sistema passará a controlar o histórico de alterações para os campos:
- Fundo (%);
- Taxa administrativa (%);
- Índice de aporte (%);
- Ato;
- Observação.
Para garantir a consistência do banco de dados, todos os registros já existentes receberão automaticamente um registro histórico inicial com a data de competência padrão de 01/1900.
IMPORTANTE:
- Os novos campos serão inicialmente preenchidos com valor nulo;
- Caso um dos percentuais seja informado, os três campos passarão a ser obrigatórios;
- O valor 0 (zero) será aceito como preenchimento válido;
- Não serão permitidos valores negativos ou caracteres alfabéticos;
- Os campos serão desabilitados somente quando o tipo for Previdência e o regime Regime Geral de Previdência Social;
- Não será permitido registrar uma data de criação posterior à vigência do histórico.
1. Além das alterações na interface, o Service Layer de Plano de Previdência ou Assistência foi ajustado para suportar o controle histórico. Com isso, será necessário informar:
- Data de vigência (obrigatório): campo inicioVigencia, no formato AAAA-MM-DDTHH:mm:ss.SSSZ (ex.: 2026-06-01T00:00:00.000Z), conforme padrão utilizado em outras APIs de Service Layer que comportam controle histórico;
- Históricos (Opcional): campo historicos, no formato de array de objetos, sendo estes objetos no mesmo formato do próprio Plano de Previdência ou Assistência, conforme padrão utilizado em outras APIs de Service Layer que comportam controle histórico.
2. Regras para históricos: cada histórico deverá possuir uma competência (mês/ano) distinta. O sistema rejeitará a requisição caso existam dois objetos no campo historicos com a mesma competência informada em inicioVigencia.
3. Nova API de histórico: também será disponibilizado um novo Service Layer para manutenção dos históricos do Plano de Previdência ou Assistência, seguindo o mesmo padrão adotado pelas demais APIs históricas do Service Layer. Essa nova API, permitirá realizar manutenções pontuais em históricos já cadastrados por meio do Service Layer de Plano de Previdência ou Assistência.
4. Impactos em outras APIs: em decorrência da implementação do controle histórico no cadastro de Plano de Previdência ou Assistência, os cadastros de Cargo e Matrícula, que também possuem controle histórico, passarão a validar a vigência do plano informado em relação à vigência do respectivo registro.
- /v1/api/cargo: o campo planosPrevidencia passará a aceitar apenas planos que possuam registro vigente na data de vigência do registro do cargo;
- /v1/api/matricula: o campo plano, presente nos objetos de previdencias, passará a aceitar apenas planos que possuam registro vigente na data de vigência do registro da matrícula.
Como os planos já existentes até a disponibilização desta alteração terão automaticamente sua vigência inicial definida como 01/1900, não são esperados impactos para registros já existentes de cargo e matrícula com plano informado, exceto nos casos em que o registro de cargo ou matrícula possua vigência anterior a 01/01/1900 e possua plano de previdência ou assistência informado, uma vez que este terá vigência a partir de 01/1900.
Entretanto, recomenda-se atenção em novas inserções que criem e incluam planos recém-cadastrados a cargos ou matrículas, uma vez que a vigência do plano deverá ser compatível com a vigência do registro que o referencia.
Recomendamos que os usuários responsáveis revisem seus processos internos e avaliem possíveis impactos decorrentes desta alteração, especialmente em integrações realizadas por meio dos Service Layers.
Melhoria entregue em 02/06/2026
Atualização no envio do evento S-2500
Realizamos adequações na rotina de Processo Trabalhista - geração e envio do evento S-2500, em conformidade com as regras da versão S-1.3 do eSocial (Consolidada até a N.O. nº 10/2026).
Com essa atualização, o sistema passa a permitir o envio do domínio de Processos Trabalhistas também para cenários anteriormente não contemplados, incluindo processos do tipo Justiça Comum.
A partir de agora, o envio do S-2500 não fica mais restrito apenas aos trabalhadores CLT. Processos de trabalhadores Estatutários ou Pessoas Sem Vínculo também poderão ser gerados, desde que vinculados ao Regime Geral de Previdência Social (RGPS).
Regras para geração do domínio:
1. Justiça Trabalhista, CCP ou NINTER: para processos da Justiça do Trabalho ou demandas submetidas à CCP/NINTER, o sistema realizará as seguintes validações:
- Trabalhadores CLT: mantém a regra atual de envio;
- Trabalhadores Estatutários: serão gerados desde que o regime previdenciário seja igual a RGPS (Previdência Federal);
- Regra por matrícula: a matrícula vinculada deve apresentar ao menos um registro de histórico no período de referência do processo com previdência do tipo Federal;
- Pessoa sem vínculo: o processo será gerado quando, na aba Dados da pessoa sem vínculo, o campo Regime de previdência estiver preenchido com a opção 1 - Regime Geral de Previdência Social (RGPS).
Atenção à data: para este grupo, a data da sentença ou da conciliação (dtSent ou dtCCP) deve ser maior ou igual a 01/10/2023.
2. Justiça Comum (Nova Regra)
Passam a ser gerados os processos vinculados a pessoas/matrículas que possuam verbas remuneratórias e regime de previdência RGPS.
Como o sistema identifica verbas remuneratórias?
Sempre que houver valor maior que zero (> 0) nos campos Base previdência mensal e/ou Base previdência 13º, localizados na aba Dados das bases de cálculo.
Além disso:
- a matrícula deve apresentar ao menos um registro de histórico no período de referência do processo com previdência do tipo Federal;
- para pessoas sem vínculo, o campo Regime de previdência (aba Dados da pessoa sem vínculo) deve estar preenchido com a opção 1 - Regime Geral de Previdência Social (RGPS).
Atenção à data: para os processos da Justiça Comum, a data da sentença deve ser maior ou igual a 27/04/2026.
Comunicado realizado em 01/06/2026
Orientações sobre o Abono Salarial (PIS/PASEP) 2026 para Empregadores
Clique aqui e acesse o Manual de Orientação para o Empregador
Com o objetivo de apoiar os profissionais responsáveis pelo envio de informações ao eSocial, reforçamos a importância da correta parametrização e transmissão dos dados que impactam diretamente a concessão do Abono Salarial (PIS/PASEP).
As informações prestadas ao eSocial são utilizadas pelos órgãos governamentais para identificação dos trabalhadores elegíveis ao benefício.
Dessa forma, inconsistências cadastrais, parametrizações incorretas, classificação inadequada de rubricas ou atrasos nos envios podem comprometer o processamento das informações e gerar impactos ao trabalhador
- Não concessão do Abono Salarial a trabalhadores que atendem aos requisitos legais;
- Perda indevida do direito ao recebimento do Abono Salarial pelo trabalhador;
- Concessão indevida do benefício em decorrência de informações incorretas prestadas ao eSocial, sujeitando o beneficiário a futuras cobranças ou processos de regularização pelos órgãos competentes, caso o pagamento indevido seja identificado;
Recomendamos a leitura atenta do material oficial Abono Salarial – Manual de Orientação para o Empregador, especialmente dos tópicos abaixo, que possuem impacto direto no processamento das informações enviadas ao eSocial:
- Prazos de envio das informações e outras determinações conforme a Resolução CODEFAT nº 1.032, de 16 de dezembro de 2025;
- Cenários que deverão ser observados quanto à classificação da natureza da rubrica referente ao 1/3 de férias;
- Registro infoPerAnt;
- Processamento Transitório das Rubricas de Adiantamento de Férias;
- Férias informadas somente na folha do adiantamento (situação que não possibilita reprocessamento automático e recurso administrativo);
- Parametrização da Tabela de Rubricas do eSocial para o Abono Salarial;
- Rubricas do eSocial válidas a partir de 2026;
- Tabela de Natureza de Rubricas para o Abono Salarial.
A correta prestação das informações ao eSocial é fundamental para o processamento do Abono Salarial pelos órgãos governamentais. Por isso, recomendamos a leitura integral do Manual de Orientação para o Empregador, com atenção especial aos tópicos destacados neste comunicado. A adoção das orientações apresentadas no material contribui para reduzir inconsistências, evitar retrabalho e garantir maior segurança no processamento das informações que impactam a concessão do benefício.












