Este evento deve ser utilizado pelo empregador/contribuinte/órgão público para informar rubricas de natureza remuneratória (proventos e descontos) ou não (informativa ou informativa redutora) para todos os seus trabalhadores, estagiários e bolsistas, exceto àqueles vinculados ao Regime Próprio de Previdência Social – RPPS, cuja informação deve ser prestada em evento próprio (S-1202).
Quem está obrigado: Todos os empregadores/contribuintes/órgãos públicos que tenham dados de folha de pagamento a informar no mês de referência.
Prazo de envio: Deve ser transmitido até o dia 15 do mês subsequente ao mês de referência do evento. Antecipa-se o vencimento para o dia útil imediatamente anterior quando não houver expediente bancário.
Os eventos não periódicos só serão enviados conforme a configuração do parâmetro MV_FASESOC, MV_RHTAF e MV_EFDMSG, que deve ser:
MV_FASESOC
" " - Default 1 - Não Periódicos (fase não periódicos) 2 - NP + Periódicos (fase não periódicos e periódicos)
MV_RHTAF
.T. (habilita integração de eventos não periódicos com o TAF)
Empresas com Faturamento Superior a 78 milhões.
Os eventos periódicos serão enviados a partir de
Para melhor entendimento, esclarecemos que esta entrega, a ser feita até refere-se a Folha de Pagamento de Maio/2018 e Pagamentos efetuados em Maio/2018.
Sendo assim, entende-se que o pagamento realizado em Maio da folha de Pagamento de Abril deve ser considerado no evento S-1210, como Pagamento do Tipo 9 - Pagamento Anteriores a Obrigatoriedade do eSocial.
O parâmetro MV_DTCGINI deve ser configurado para 01/03/2018 para geração correta do tipo 9.
Empresas com Faturamento Menor que 78 milhões.
Os eventos periódicos serão enviados a partir de contemplando os dados da folha a partir de Janeiro/2019.
Para melhor entendimento, esclarecemos que esta entrega, a ser feita até refere-se a Folha de Pagamento de Janeiro/2019 e Pagamentos efetuados em Janeiro/2019.
Sendo assim, entende-se que o pagamento realizado em Janeiro da folha de Pagamento de Dezembro deve ser considerado no evento S-1210, como Pagamento do Tipo 9 - Pagamento Anteriores a Obrigatoriedade do eSocial.
O parâmetro MV_DTCGINI deve ser configurado para 10/10/2018 para geração correta do tipo 9.
No evento S-1200 são enviados dados da Remuneração do trabalhador no mês de referência informado na tela inicial, todo o pagamento efetuado ao trabalhador deve ser referenciado no evento S-1200, porém quando o trabalhador tem rescisão ele não será levado para este evento, pois os dados dele já constarão no evento S-2299/S-2399, conforme regra do eSocial.
Para cada funcionário com remuneração é gerado um evento S-1200, no evento são informados os dados das verbas a serem pagas referente a competência indicada, com exceção das verbas de Imposto de Renda, neste registro também são informados dados de Plano de Saúde.
São gerados dados de todos os vínculos que o funcionário tem com a empresa, considerando os 8 primeiros dígitos do CNPJ.
Sendo assim, se o funcionário trabalhar em duas filiais da empresa, no mesmo registro S-1200 serão gravados dados do recibo de pagamento agrupando pelo Estabelecimento e por categoria.
Na configuração 1 X 1 essa unificação é feita através do TAF.
Após o processamento, é impresso um log com todos os funcionários considerados no processamento.
As Tag´s controladas pelo nosso sistema são:
Informação de Múltiplos Vínculos: Serão lidos os dados informados nas tabelas RAZ/RAW. Essa funcionalidade deve ser utilizada para funcionários que tem vínculo em outra empresa, com raiz de CNPJ diferente da empresa que está declarando o eSocial.
Informações complementares de identificação do trabalhador: São informações dos trabalhadores autônomos que não tem vínculo com a empresa (não foi enviado o S-2300), também utilizada para trabalhadores cedidos (caso de órgãos públicos), atualmente nosso programa não efetua este controle, será disponibilizado futuramente.
Informações sobre a existência de processos judiciais do trabalhador: Nesta Tag devem ser prestadas informações sobre os processos que o Trabalhador tenha contra um dos entes participantes do eSocial, atualmente é necessário que esta informação seja incluída no TAF após a integração do evento.
Informações relativas ao trabalho intermitente: Dados do Contrato Intermitente, lidos das nossas tabelas SV7/SV6
Demonstrativos de valores devidos ao trabalhador no mês de apuração: Nesta Tag são detalhados os dados de demonstrativos de pagamentos. Considerados os roteiros de Adiantamento, PLR e Folha, não será considerado o roteiro VEX.
Número do demonstrativo: (gerado automaticamente com os dados Filial+data de Pagamento+Periodo+Roteiro)
Estabelecimento: (Filial do Funcionário ou Obra Própria)
Código da Lotação: (Código do Centro de Custo)
Quantidade de Dias trabalhados na Lotação (apenas para funcionários avulsos, não tratamos este caso)
Matricula do Funcionário: Lido da SRA
Substituição da contribuição no caso de empresas do tipo Simples
As verbas pagas em Folha: São os itens de verbas da SRD
Grau de Exposição: Lido do Cad. Funcionários
Funcionários intermitentes:Dia do mês efetivamente trabalhados pelo empregado com contrato de trabalho intermitente.
Temos também a Tag de Informações de Períodos Anteriores que refere-se:
a) remuneração relativa a diferenças salariais provenientes de acordos coletivos, convenção coletiva e dissídio;
b) remuneração relativa a diferenças de vencimento provenientes de disposições legais (órgãos públicos);
c) bases de cálculo para efeitos de apuração de FGTS resultantes de conversão de licença saúde em acidente de trabalho.
d) verbas de natureza salarial ou não salarial devidas após o desligamento
Para opção A, serão considerados os dados provenientes das tabelas RHH/SR7/SR3
Para a opção D, serão considerados dados de Rescisão Complementar que não originaram um evento S-2299 retificador (conforme MOS PLR e diferenças salariais pagas em decorrência de dissidio)
Temos que informar a Descrição do instrumento ou situação que originou o pagamento das verbas relativas a períodos anteriores que será lido de uma tabela S126.
O formato da Tag de pagamento de Períodos Anteriores será idêntico ao de pagamento do período Atual.
ObservaçõesObservação:
Para os dados de Autônomos lidos do Financeiro, utilizaremos a rotina do financeiro FINA240A, que atualmente integra os autônomos para a Folha, a fim de que possam ser considerados na SEFIP.
Na ocasião de férias na competência será gerado um ideDmDev
Retificação
Caso o cálculo da folha de um período fechado precise ser retificado devido a erro (por exemplo: falta de pagamento de alguma verba), haverá possibilidade de efetuar a retificação desse período.
Caso deseje que a geração dos estabelecimentos no evento S-1200 seja efetuada de acordo com o centro de custo do funcionário e não de acordo com os centros de custo do movimento da folha, haverá possibilidade do sistema seguir esse conceito.
Como gerar o evento com informações do calculo da 1ª Parcela do 13º Salario
Premissas
Quando efetuado o cálculo da 1ª parcela do 13º salário onde o pagamento ocorre até 30/11, os valores devem ser gerados no evento S-1200 deixando o campo REF. 13 igual a NÃO, conforme exemplos abaixo.
Conforme tabela 03 (natureza de rubricas) a natureza para o calculo do 13º salário 1ª parcela deve ser a 5504 (13º salário - Adiantamento) na verbas de provento/desconto utilizadas nesse calculo.
Note que em todos os cenários só existe um evento S-1200 separado por recibos de pagamento.
1º Cenário: Trabalhador sem Adicionais
2º Cenário: Trabalhador com Adicionais
3º Cenário: Trabalhador em licença maternidade
Card
default
true
id
13_2ªP
label
S-1200 2ª Parcela Pago em 12/xxxx
Como gerar o evento com informações do calculo da 2ª Parcela do 13º Salário em Dezembro
Premissas
O cálculo da primeira parcela já deve ter sido realizado.
Conforme tabela 03 (natureza de rubricas) a natureza para o calculo do 13º salário 1ª parcela deve ser a 5504 (13º salário - Adiantamento) e para 2ª parcela deve ser a 5001 (13º salário) em verbas de provento/desconto utilizadas nesse calculo.
Observações Sistêmicas
Quando efetuado o cálculo da 2ª parcela do 13º salário onde o pagamento ocorre até 20/12, os valores devem ser gerados no evento S-1200 deixando o campo REF. 13 igual a SIM, no cálculo da folha deve ser gerado outro S-1200 com o campo REF. 13 igual a NÃO, conforme exemplos abaixo.
O evento S-1210 não é gerado com o campo REF. 13 SIM, só existe um S-1210 para o mês de dezembro.
O período de apuração (tag <perRef>) será gerada no formato AAAA (por exemplo: 2018).
Para acessar os exemplos clique nos links abaixo:
Expandir
title
1. Calculo
Calculo do 13º SIGAGPE
1º Cenário: Trabalhador sem Adicionais
2º Cenário: Trabalhador com Adicionais
3º Cenário: Trabalhador em licença maternidade
Expandir
title
2. Geração do Evento
Geração dos Eventos:
Note que ao deixar o campo Ref. 13 com SIM só fica habilitado o S-1200, pois para folha de 13º só deve ser gerado o S-1200.
Exemplo S-1200
O período de Apuração (tag <perRef>) será gerada no formato AAAA (por exemplo: 2018) para o 13º salário 2ª Parcela.
TAF visualização S-1200:
Note que em todos os cenários só existe um evento S-1200 separado por recibos de pagamento.
1º Cenário: Trabalhador sem Adicionais
2º Cenário: Trabalhador com Adicionais
3º Cenário: Trabalhador em licença maternidade
Geração dos Eventos:
S-1200 com campo Ref. 13 com NÃO em Dezembro para gerar dados da folha.
Exemplo S-1200
O período de Apuração (tag <perRef>) será gerada no formato AAAA (por exemplo: 2018) para o 13º salário 2ª Parcela.
1º Cenário: Trabalhador sem Adicionais
2º Cenário: Trabalhador com Adicionais
3º Cenário: Trabalhador em licença maternidade
Card
default
true
id
13_1ªP
label
S-1200 2ª Parcela Pago antes de 12/xxxx
Como gerar o evento com informações do cálculo da 2ª Parcela do 13º Salário pago antes da competência de dezembro.
Premissas
Conforme tabela 03 (natureza de rubricas) a natureza para o cálculo do 13º salário 1ª parcela deve ser a 5504 (13º salário - Adiantamento) e para 2ª parcela deve ser a 5001 (13º salário) em verbas de provento/desconto utilizadas nesse cálculo.
O evento S-1210 é gerado somente na competência de dezembro.
Deve no cadastro uma verba de desconto vinculada ao id 1655 (13º integral pago antes de dezembro) com incidência para FGTS.
Observações Sistêmicas:
13º Salario 2ª Parcela Calculo total em até a competência de Novembro
Em novembro ao gerar a rotina eventos periódicos o campo Ref. 13 deve ficar com NÃO. Os valores de cálculo do 13º 1ª parcela são gerados no S-1200 junto com o cálculo da folha;
Em dezembro será necessário gerar 2 eventos S-1200 mesmo que o calculo total foi efetuado em novembro, um com o campo Ref. 13 deve ficar com SIM. para gerar no TAF os valores da folha de 13º salario, e outro com S-1200 com o campo Ref. 13 com NÃO para gerar o valor da folha de dezembro;
Deve ser gerado apenas 1 evento S-1210 que contém que vai conter as informações da folha e 13º salario.
O evento S-1210 de dezembro referente ao roteiro 132 será gerado com valor zerado, devido a inclusão do desconto do adiantamento e as rubricas de IRRF e/ou pensão alimentícia serão geradas normalmente.
O período de apuração (tag <perRef>) será gerada no formato AAAA (por exemplo: 2018).
O trecho da Nota Orientativa transcrito abaixo orienta sobre como deve ser informado o evento S-1200 no mês que foi efetuado o pagamento da 2ª parcela do 13º salário (roteiro 132):
No eSocial, o empregador deve informar o adiantamento (correspondente ao valor líquido) no evento S-1200 referente a remuneração do mês em que esse adiantamento foi incluído
Ainda há o o exemplo de como deve ser efetuado a geração:
Por exemplo, o valor do 13º salário de um empregado é R$ 1.000,00. O desconto correspondente à contribuição previdenciária é de R$ 80,00. Se o empregador vai pagar o valor integral do 13º na competência novembro de 2018, deve incluir no S-1200 da competência 11/2018, a rubrica de “Adiantamento 13º salário” (Natureza 5504) no valor de R$ 920,00.
Note que no TAF no mês de novembro onde foi calculada a 2ª parcela o sistema gerou a verba de ID 0022 com o valor do líquido.
No mês de dezembro
Para informar o desconto do adiantamento gerado no evento S-1200 de novembro, o sistema irá gerar uma rubrica a mais, que possuirá o código da verba cadastrada no Id de cálculo 1655 (13º integral pago antes de dezembro), que deverá ser uma verba de Desconto e com incidência para FGTS.
Geração dos Eventos:
Note que ao deixar o campo Ref. 13 com SIM só fica habilitado o S-1200, pois para folha de 13º só deve ser gerado o S-1200.
Exemplo S-1200
O período de Apuração (tag <perRef>) será gerada no formato AAAA (por exemplo: 2018) para o 13º salário 2ª Parcela.
Geração dos Eventos:
S-1200 com campo Ref. 13 com NÃO em Dezembro para gerar dados da folha.
Exemplo S-1200
O período de Apuração (tag <perRef>) será gerada no formato AAAA (por exemplo: 2018) para o 13º salário 2ª Parcela.
Card
id
autonomo_1200
label
Autônomo Sem S-2300
O MOS tem uma orientação de que, não é necessário ter o S-2300 para as categorias abaixo, sendo optativo a geração do evento:
701 Contribuinte individual - Autônomo em geral, exceto se enquadrado em uma das demais categorias de contribuinte individual 711 Contribuinte individual - Transportador autônomo de passageiros 712 Contribuinte individual - Transportador autônomo de carga 741 Contribuinte individual - Microempreendedor Individual
Por este motivo para esses autônomos é possível fazer a geração do S-1200 sem que existe o S-2300 no TAF.
Será efetuado o seguinte controle:
Não gravar o registro S-2300 caso o mesmo não exista, quando for uma das categorias acima
Para as categorias acima, no evento S-1200 gerar as tags infoComplem e infoComplCont,
Para gravar a Natureza de Atividade só conseguiremos verificar se é Produtor Rural PJ, através do SIGAMAT, as demais Classificações Tributárias não serão levadas neste momento.
Para as demais categorias, continuar efetuando o controle antigo.
Notas:
As informações das Tags são:
infoComplem
nmTrab - Nome do Funcionário
dtNascto - Data de Nascimento
infoComplCont
codCBO - Codigo do CBO (SRA)
natAtividade - Rural ou Urbano (SRA) - Só deve ser informado se a Classificação Tributária da empresa (leitura do sigamat) (somente o controle de Produtor Rural)
No evento S-1200 é necessário informar dados de Múltiplos Vínculos do Funcionário, para o eSocial, múltiplo Vínculo indica que o funcionário trabalhou em outra empresa (raiz do CNPJ diferente)
Ao realizar o lançamento manual para um funcionário (GPEA090), caso seja informado uma verba com um desses ID's de cálculo abaixo:
0288 - Salário de Contribuição - INSS outras empresas
0290 - Salario de Contribuição INSS 13 Outras Empresas
Será aberta uma tela, onde o usuário informará os Detalhes de Múltiplos Vínculos. Deverá ser informado o CNPJ (lembrando que os 8 primeiros dígitos não podem pertencer a empresa que o funcionário está cadastrado), Indicador de recolhimento , Categoria do trabalhador na outra empresa e Valor do rendimento na outra empresa
Alimentaremos as tabela RAZ/RAW com os dados informados nesta tela.
Card
default
true
id
Trab_SIGAGPE
label
Trabalhadores no SIGAGPE
Múltiplos Vínculos Trabalhadores Cadastrados no SIGAGPE
Realizados diversos ajustes na geração dos eventos S-1200 e S-1210 para funcionários múltiplos vínculos para que os recibos de pagamento sejam aglutinados.
Aviso
title
Premissas
Existem três premissas para a geração aglutinada dos funcionários múltiplos vínculos:
O mnemônico P_ESOCMV, se versão P12, ou M_ESOCMV, se versão 11, deve estar configurado com .T.;
A atualização do dicionário diferencial do TAF de Julho/2018 deve ter sido executada;
A aglutinação é efetuada para os funcionários que possuem o campo RA_OCORREN no cadastro do funcionário preenchido com05, 06, 07 ou 08 (motivo: é o campo utilizado para identificar os funcionários múltiplos vínculos na SEFIP; sem essa configuração, a apuração dos valores na SEFIP ficava incorreta) ou para os funcionários que tenham recibo de pagamento em mais de uma matrícula mesmo não sendo múltiplos vínculos, por exemplo o caso onde no mesmo período tem a rescisão complementar por dissídio na matrícula 1 e a folha na matrícula 2.
Obs.: não haverá nenhuma mudança na geração e gravação do evento caso o funcionário não seja identificado como um múltiplo vínculo.
Toggle Cloak
id
@cloak01
Se as premissas foram verificadas, clique aqui para verificar a mudança no conceito da geração dos eventos S-1200 e S-1210
Cloak
id
@cloak01
Foi efetuado alteração no identificador do recibo de pagamento da tag <ideDmDev> para o formato: [Filial] + [Matrícula] + [Data de Pagamento (formato AAMMDD)] + [Período (formato AAMM)] + [Roteiro].
Exemplo: Para o funcionário da filial 01, matrícula 000010, roteiro FOL do período 201807 com data de pagamento em 06/08/2018, o identificador do recibo de pagamento será 010000101808061807FOL.
Obs.: Na versão 11 não existe roteiro, então o código do recibo será 010000101808061807.
Importante
Como houve alteração no identificador do recibo de pagamento (tag <ideDmDev>), caso tenha sido enviado o evento S-1200 com o identificador do recibo de pagamento no formato antigo e o evento S-1210 tenha sido enviado com o identificador do recibo de pagamento no formato novo, o sistema do governo irá acusar erro na validação do S-1210 pois não encontrará o S-1200 correspondente.
Dessa forma, deve-se excluir os eventos S-1200 dos funcionários múltiplos vínculos e retificá-los, para que o identificador do recibo de pagamento seja gerado e enviado no formato novo.
A gravação dos eventos no TAF será efetuada na matriz da empresa e não mais na filial do funcionário. Obs.: foram criados novos campos para armazenar as informações de rubricas, estabelecimentos, lotação no TAF.
@cloak02 Houve alterações importantes no conceito de gravação dos registros no TAF e no monitor de transmissão. Clique aqui para efetuar leitura das mudanças no conceito (clique novamente para ocultar a página).
@cloak02
Segue abaixo exemplos de integração dos eventos de múltiplos vínculos:
A empresa possui o cadastro abaixo:
Filial
Matriz
01
Sim
02
Não
03
Não
Ou seja, a filial 01 é a matriz e 02 e a 03 são filiais.
Exemplo 1:
Funcionário possui os vínculos abaixo:
Filial
Matrícula (GPE)
ID Trabalhador (TAF)
Recebeu Pagamento?
02
000020
100020
Sim
03
000030
100030
Sim
Como o funcionário possui dois recibos de pagamento, o evento será integrado na matriz.
Como o funcionário não tem vínculo na matriz, o evento não estará vinculado a um ID de trabalhador, sendo o registro gravado conforme exemplo abaixo:
Filial
ID Trabalhador (TAF)
C91_CPF/T3P_CPF
01
<vazio>
<número do CPF do funcionário>
Exemplo 2:
Funcionário possui os vínculos abaixo:
Filial
Matrícula (GPE)
ID Trabalhador (TAF)
Recebeu Pagamento?
02
000020
100020
Não
03
000030
100030
Sim
Como o funcionário possui apenas um recibo de pagamento, o evento será integrado na filial onde o funcionário recebeu o pagamento, que no caso é a 03.
Como o funcionário possui vínculo na filial 03, o registro estará vinculado ao ID do trabalhador dessa filial, sendo o registro gravado conforme exemplo abaixo:
Filial
ID Trabalhador (TAF)
C91_CPF/T3P_CPF
03
100030
<vazio>
Exemplo 3:
Funcionário possui os vínculos abaixo:
Filial
Matrícula (GPE)
ID Trabalhador (TAF)
Recebeu Pagamento?
01
000010
100010
Sim
03
000030
100030
Sim
Como o funcionário possui dois recibos de pagamento, o evento será integrado na matriz.
Como o funcionário possui vínculo na matriz, o registro estará vinculado ao ID do trabalhador dessa filial, sendo o registro gravado conforme exemplo abaixo:
Filial
ID Trabalhador (TAF)
C91_CPF/T3P_CPF
01
100010
<vazio>
Exemplo 4:
Funcionário possui os vínculos abaixo:
Filial
Matrícula (GPE)
ID Trabalhador (TAF)
Recebeu Pagamento?
01
000010
100010
Sim
01
000011
100011
Sim
03
000030
100030
Sim
Como o funcionário possui dois recibos de pagamento, o evento será integrado na matriz.
Como o funcionário possui vínculo na matriz, o registro estará vinculado ao primeiro ID do trabalhador dessa filial, sendo o registro gravado conforme exemplo abaixo:
Filial
ID Trabalhador (TAF)
C91_CPF/T3P_CPF
01
100010
<vazio>
Exemplo 5:
Funcionário possui os vínculos abaixo:
Filial
Matrícula (GPE)
ID Trabalhador (TAF)
Recebeu Pagamento?
01
000010
100010
Não
01
000011
100011
Não
03
000030
100030
Sim
Como o funcionário possui apenas um recibo de pagamento, o evento será integrado na filial onde o funcionário recebeu o pagamento, que no caso é a 03.
Como o funcionário possui vínculo na filial 03, o registro estará vinculado ao ID do trabalhador dessa filial, sendo o registro gravado conforme exemplo abaixo:
Filial
ID Trabalhador (TAF)
C91_CPF/T3P_CPF
03
100030
<vazio>
Card
effectDuration
1.5
label
Banco de Horas
effectType
fade
Banco de Horas e Saldo Anterior ao e-Social
A quase totalidade das empresas que utilizam o Ponto Eletrônico possuem períodos de apuração distintos da Folha de Pagamento. Ou seja, enquanto a folha de pagamento compreende o período de uma única competência (01/01/XX a 30/01/XX), o ponto eletrônico em geral compreende duas competências, exemplo: 16/01/XX a 15/02/XX. Isso se faz necessário para que seja haja tempo hábil de se fazer as devidas apurações e tratamentos nos apontamentos dos funcionários antes de se realizar o pagamento da Folha propriamente dita.
Contudo, com o advento do e-Social, agora as empresas precisam enviar ambas as informações, tanto da folha de pagamento quanto do ponto do funcionário dentro de cada competência que estiver sendo apurada.
Então, para as empresas que utilizam o Ponto Eletrônico do Protheus (módulo SIGAPON), e precisam enviar as informações do banco de horas antes do fechamento do período de apontamento, foi disponibilizada a rotina "Apuração do Banco de Horas para o e-Social" (PONM081):
Image Removed
Por meio desta rotina será possível fazer a geração do banco de horas, exclusivamente para o e-Social, com as seguintes informações:
Saldo de banco de horas anterior ao e-Social
As horas debitadas em banco de horas no mês
As horas creditadas em banco de horas no mês
E para que seja possível enviar essas informações para a Folha de Pagamento, foram disponibilizados os seguintes identificadores de cálculo:
Código
Descrição
Tipo
Natureza da rubrica
1549
Saldo de banco de horas anterior ao e-social
3 - Base Provento
9950 - Horas Extraordinárias - Banco de Horas
1550
Horas debitadas em banco de horas no mês
3 - Base Provento
9951 - Horas Compensadas - Banco de Horas
1551
Horas creditadas em banco de horas no mês
3 - Base Provento
9950 - Horas Extraordinárias - Banco de Horas
Principais parâmetros da rotina "Apuração do Banco de Horas para o e-Social":
"Código Eventos" = Permite filtrar quais eventos apurados pelo Ponto Eletrônico serão utilizados para geração do Banco de Horas para o e-Social. O sistema irá fazer o somatório dos Débitos e dos Créditos considerando esses eventos. Caso não seja informado nenhum código o sistema irá considerar todos os eventos do funcionário.
"Eventos" = Permite filtrar os Tipos de Eventos apurados pelo Ponto Eletrônico que serão considerados: Autorizados, Não Autorizados; Ambos.
"Data Início Mov. Mês" e "Data Final Mov. Mês" = É a faixa de datas que será utilizada para gerar as informações referentes a apuração mensal dos créditos e débitos do banco de horas. Esse campo é de preenchimento obrigatório.
"Data Ini. Saldo Ant." e "Data Fin. Saldo Ant." = É a faixa de datas que será utilizada para gerar o saldo do Banco de Horas anterior ao e-Social. Observação: a empresa irá gerar essa informação somente uma vez.
"Dt. Ref. Folha Pagto" = É a data de referência da competência da Folha de Pagamento, mesmo que a empresa trabalhe com regime "Caixa". Exemplo: para gerar o banco de horas da competência 04/2018, que será demonstrado no recibo da Folha de Pagamento em 05/05/2018, deve ser informada uma data de referência que esteja dentro do mês 04/2018.
Observações:
As verbas cadastradas dos identificadores 1549, 1550 e 1551 precisam ser cadastradas com Tipo 3 (Base Provento), e não possuir nenhuma incidência de cálculo.
As horas apuradas serão obtidas diretamente no banco de horas existente no Ponto Eletrônico. Ou seja, é necessário que o Cálculo Mensal do Ponto Eletrônico tenha sido executado previamente, pois somente assim será possível fazer a geração do Banco de Horas para o e-Social.
As horas geradas para o e-Social serão obtidas a partir do banco de horas do Ponto eletrônico, mesmo que o período de apontamento ainda esteja aberto. Ou seja, caso seja gerado o banco de horas para o e-social, e houver manipulação dos dados até o fechamento do Ponto Eletrônico, poderá haver divergência entre as horas enviadas ao Governo e aquelas que serão efetivamente remuneradas e/ou descontadas do funcionário.
