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.
Controle RRA
Para o Leiaute S-1.1, é necessário a informação de RRA pago a funcionários:
Mas o que é RRA? Rendimento pago de forma acumulada (art. 12-A da Lei no 7.713, de 1988) , relativo a anos-calendário anteriores ao do pagamento, decorrentes de:
a) aposentadoria, pensão, transferência para a reserva remunerada ou reforma, pagos pela Previdência Social da União, dos estados, do Distrito Federal e dos municípios; ou ainda
b) os provenientes do trabalho, inclusive aqueles oriundos das decisões das Justiças do Trabalho, Federal, Estaduais e do Distrito Federal, relativos a anos-calendário anteriores ao do pagamento;
c) A partir da DIRF de 2017, passou a ser obrigatório as seguintes informações referentes ao pagamento de RRA:
Nome e CPF/CNPJ do Advogado;
Valores referente Pensão Alimentícia discriminado por Dependentes.
Como será feita a geração dos dados para o eSocial?
Para gerar as informações dos RRA para no eSocial, o usuário deve seguir o processo já existente no sistema, porém com preenchimento de novos campos:
Cadastrar o Processo e Informações do Advogado, nas rotinas de Processos Trabalhistas. Cadastro de Processos Trabalhistas (APTA100).
Ainda no Cadastro de Processos se atente aos campos Tipo de Processo e Número de Processo eSocial.
Para a correta geração do evento, será necessário o preenchimento de dados do advogados e Valor de Despesas do Advogado
Por fim, realizar o cadastro do Complemento Trabalhista (GPEA850), onde foram criados os campos Custas Judiciais e Total Despesas Advogados
No cálculo do dissídio informar o complemento trabalhista se houver, indicando que há RRA no mês
Gerar o IRRF de RRA (GPEM690)
Geração (Geração do Dissídio para lançamentos Mensais ou Valores Futuros)
Após este processo serão gerados os valores nas Tabelas RFC (Lançamentos de RRA) e RGB (Lançamentos por período) OU SRK
Deverá ser realizado o Cálculo da Folha
Ao encontrar uma Folha mensal com ID´s de RRA, a rotina de eSocial irá separar os valores em DOIS idemDev, um com o final FOL, com os valores de Folha mensal e outro com o final RRA.
o idemDev com final RRA, terá os valores distribuídos nas tags infoPerApur com valor de IRRF e infoPerAnt com os demais valores.
O evento S-1210, acompanha essa estrutura, trazendo o valor líquido isolado de RRA e um ideDev de Folha.
Importante:
1) 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.
2) 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.
3) 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.
54)Após todo os processamentos, é impresso um log com todos os funcionários considerados no processamento.
65) A partir do leiaute S-1.0 o trabalhador sem vínculo será enviado com o campo matrícula.
76)Para TSV com desligamento (exceto o Diretor não empregado com FGTS - Categoria 721), as verbas da rescisão devem ser elencadas no S-1200. Então, mesmo encontrando a rescisão deste tipo de trabalhador, deverá ser gerado do evento S-1200
87) Férias: Nesta versão, ao encontrar férias processadas deverá se gerado um demonstrativo de Antecipação de Férias. Para definição do código idmDev, utilizar o "FER". Deverão ser consideradas férias pagas no mês de apuração
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 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.
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.
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
id
Diss_ret
label
Dissidio Retroativo
Incluir Página
DRHESOCP-4092 Geração Evento S-1200 - Dissídio
DRHESOCP-4092 Geração Evento S-1200 - Dissídio
Card
id
Faqs_não_periodicos
label
Faqs
Incluir Página
Faqs S-1200 - Remuneração de trabalhador vinculado ao Regime Geral de Previd. Social
Faqs S-1200 - Remuneração de trabalhador vinculado ao Regime Geral de Previd. Social
Card
id
tecnica
label
Informações Técnicas
Deck of Cards
id
Deck_tecnica
Card
id
correspondencia_layout
label
Campos GPE x TAF x Layout
Incluir Página
Correspondência Layouts eSocial x Protheus
Correspondência Layouts eSocial x Protheus
Card
id
share_tabelas
label
Compartilhamento Tabelas eSocial
Incluir Página
Como deve ser definido o Compartilhamento de Tabelas SIGAGPE x SIGATAF
Como deve ser definido o Compartilhamento de Tabelas SIGAGPE x SIGATAF
