Por Leonardo Amorim
eSocial (S-2800) x HomologNet
Por Leonardo Amorim
A princípio, considerando o disposto nos leiautes e o que vem sendo dito em palestras por representantes do eSocial, o HomologNet será mantido no advento do novo (e polêmico) sistema de escrituração digital trabalhista e previdenciário não tem no seu escopo a intenção inicial de substituir a rescisão gerada no sistema do Ministério do Trabalho e Emprego (MTE), e assim os empregadores terão que conviver com os dois, salvo se houver alguma mudança no decorrer da implementação do eSocial.
Tudo flui, nada permanece, como certa vez disse o filósofo Heráclito de Éfeso... O eSocial que temos teoricamente é uma coisa, na prática, ninguém sabe, e quando estiver funcionando (só Deus sabe) certamente passará por aprimoramentos.
Os dados rescisórios no eSocial serão informados no evento S-2800 – Desligamento, onde destaco as informações detalhadas sobre as bases de cálculo, indicadores para identificação dos efeitos do aviso prévio e os lançamentos dos rubricas rescisórias.
O primeiro ponto a ser considerado é que o atual modelo do eSocial não efetua cálculos rescisórios. O HomologNet faz exatamente isso, sendo essa a diferença fundamental entre os dois.
A semelhança entre os dois está no formato do arquivo de repasse (no caso de importação da folha), que é o mesmo do eSocial (XML). O HomologNet também oferece uma digitação em sistema Web, o que, aliás, tem sido a forma mais usada, por causa de questões envolvendo batimento imediato com os cálculos dos sistemas internos.
Em termos sucintos: O S-2800 do eSocial é exclusivamente uma coleta de lançamentos financeiros, bases de cálculo e dados do desligamento, e o HomologNet é um receptor de dados para efetuar cálculos, ressalvando as situações de rubricas externas e o movimento financeiro, que acatam valores para lançamentos de verbas, o que não se aplica ao que deve ser calculado (Férias e Décimo Terceiro) com base no fornecimento de um histórico de períodos e outros detalhes.
HomologNet
Vamos a um trecho de um XML do HomologNet, tratando especificamente do lançamento das Férias.
Observe que se informam em <Férias> dados dos períodos aquisitivos <PeriodoAquisitivo>. São repassadas as datas iniciais em <DTInicio> e finais em<DTFim>, dentro de sua respectiva estrutura, além do tipo da quitação em <TPQuitacaoFerias> (1. SIM 2. NÃO, conforme código no manual) e a quantidade de faltas no período em <NRFaltas>. Isso vai se repetindo conforme os períodos aquisitivos informados. Assim, o HomologNet procederá com os cálculos das férias.
A grande dificuldade atualmente no HomologNet é o batimento dos cálculos com os da folha interna, sendo um dos gargalos do sistema, e neste caso, são feitos lançamentos de ajuste para que os valores do sistema interno estejam refletindo o que se encontra registrado no HomologNet.
Há um arquivo XML que pode ser baixado contendo o TRCT, o que pode ser usado atualmente para ajustar as diferenças de cálculos entre a folha de pagamento e o HomologNet, mas como o SEFIP realiza cálculos de INSS dos segurados, essa terceira variável se torna um complicador. E no eSocial, também será assim?
Trecho de um XML. TRCT baixado pelo empregador. Cálculos do HomologNet
Não seria melhor resolver tudo no eSocial? Veremos...
S-2800 eSocial
Agora para facilitar a didática desta análise comparativa, vamos a um trecho de XML do S-2800 do eSocial, apenas com duas rubricas, cujos códigos são01001 para Férias Vencidas e 01002 para 1/3 de Férias Vencidas (lembrando que os códigos são definidos previamente pelos empregadores):
Nos leiautes, este trecho está assim:
Observe que nesta parte de XML do S-2800, se informam as rubricas em <codRubrica>, a quantidade em <qtdRubrica>, o valor unitário em <vlrUnitario> e o valor total da rubrica em <vlrRubrica>, cujo cadastramento deve constar na tabela S-1010 – Tabela de Rubricas, hospedada no Ambiente Nacional.
Pergunta: Não vejo a descrição do lançamento e como o eSocial saberá que a rubrica 01001 significa Férias Vencidas e 01002 significa o seu respectivo 1/3? Sempre considere que há uma tabela de rubricas (S-1010) com os dados de 01001 e 01002 que foram previamente cadastrados pelo empregador. Será sempre a base para verificações, neste caso, pois o eSocial é um sistema de escrituração digital usando a tecnologia cloud computer (nuvem), e não apenas um validador de eventos isolados.
Como o eSocial saberá as incidências (FGTS, INSS, IR e CS)? Mais uma vez será feito um cruzamento com a tabela de rubricas (S-1010), e a consulta a classificação definida pelo próprio empregador/procurador declarante, além do código da natureza, que vai definir do que se trata a rubrica (Férias vencidas? Horas extras?).
Parametrização de rubricas no eSocial será o cérebro de toda a folha de pagamento (Imagem do Curso DP eSocial 2013).
É por isso que digo sempre alerto que a tabela de rubricas é o cérebro da folha de pagamento no eSocial. Pense no seguinte: Se essa tabela for preenchida com erros de classificação tributária, haverá sérios problemas no processamento para apuração tributária seja com base no S-2800, ou S-1200, a remuneração do trabalhador.
Então, por que o eSocial pede, por exemplo, a base previdenciária no S-2800 se tudo pode ser identificado no cruzamento com o S-1010? Sim, é verdade. Mas veja o que diz uma orientação no leiaute do S-2800:
BcCP - Informar o valor total da base de cálculo da contribuição previdenciária para o trabalhador.
Validação: Deve corresponder ao somatório do campo {vlrRubrica} das rubricas de PROVENTOS(*) menos as rubricas de DESCONTOS(*), relacionadas nos registros de itens da remuneração (vinculados a este) e cuja classificação da rubrica no campo {codIncidCP} da tabela de RUBRICAS para o respectivo código tenha sido definido como [11, 12, 21, 22].
Caso {codIncidCP} seja igual a [91,92,93,94] e {indDecisao} do respectivo processo seja diferente de [10] (decisão definitiva), o valor também deverá ser computado.
Em outras palavras, o eSocial impõe um critério dentro do próprio evento escriturado para ser mais uma forma de conferência no processo de análise de consistência.
Assim, fica claro que no HomologNet, em termos de lançamentos de verbas, são fornecidos parâmetros para o sistema oficial prosseguir, embora tenha exceções de rubricas externas e valores informados com códigos determinados, enquanto que no eSocial, são informados valores a uma determinada rubrica previamente cadastrada em uma base de dados nas nuvens (Ambiente Nacional) refletindo o que foi designado no S-1010.
“Integração”
De certa forma, ter que usar o eSocial e o HomologNet não deixa de ser uma forma de repetição de informações de mesma natureza, o que contraria (no meu ponto de vista) uma das mais importantes justificativas para implementação do eSocial, que é canalizar o envio de dados em um ÚNICO meio, se bem que os defensores do projeto contra argumentam que não é objeto do eSocial calcular rescisão de contrato, como faz o HomologNet.
Vamos a uma resposta dada por representantes do eSocial no Fórum Sped de Porto Alegre em abril deste ano:
“capitação” (sic) “suas finalidade” (sic)
Fiquei curioso com as aspas para integração... Ora, a simples explicação baseada no fato de que o S-2800, assim como toda a base de dados do eSocial, e o HomologNet, possuem funções distintas seria incontestável se o eSocial não realizasse cálculos.
http://www.esocial.gov.br/doc/ApresentacaoPadraoeSocial.pdf
Então o eSocial calculará uma folha de pagamento, mas não será capaz de calcular uma rescisão, que fica dentro da folha? Interessante... Quanto esforço para manter o HomologNet !!!
Mesmo considerando que tem características de ser um sistema mais coletor de eventos em relação ao HomologNet, o eSocial terá, entre outras atribuições, a finalidade de ser a Folha de Pagamento com validade jurídica, digital, substituindo as folhas de pagamento atualmente adotadas nos sistemas internos dos empregadores, a partir do início de sua obrigatoriedade, inclusive com cálculos próprios que deverão ser confrontados com os da folha interna(semelhante ao que ocorre hoje na GFIP via SEFIP na análise previdenciária e do FGTS), e por isso, não se pode deixar de considerar que as informações rescisórias, especialmente as de natureza tributária, estão no bojo.
Neste aspecto, cabe também salientar que o HomologNet apresenta a rescisão de contrato juridicamente válida e os cálculos ali registrados devem bater 100% com os da folha de pagamento, e isso também será válido na “era eSocial”. Não existe folha de pagamento sem os dados rescisórios nos detalhes encontrados nos TRCTs.
Com a permanência do sistema do MTE, ambos serão juridicamente representativos (eSocial e HomologNet) e devem ter o mesmo conteúdo em termos de valores e repercussões tributárias, como atualmente deve ser observado no batimento de cálculos entre a folha de pagamento (documento impresso), o SEFIP e o HomologNet (quando aplicável).
Enfim, é mais um ponto discutível do projeto eSocial, entre tantos, e o ideal, no meu entendimento, é que seria melhor descontinuar o HomologNet, um projeto repleto de problemas, por ser um modelo operacional de rescisão via internet exageradamente burocrático. O eSocial terá uma base de dados capaz de realizar as funções do HomologNet, e certamente, penso ser mais interessante aproveitar a proposta unificadora e promover incrementos no S-2800 para realmente reduzir o tempo que o trabalhador leva nos órgãos para ser atendido, inserindo um novo conceito de rescisão digital, com um código semelhante ao usado no DANFE (NF-e), eliminando assim as vias atuais. Penso que os demais órgãos (CAIXA e o próprio MTE) poderiam usar o código localizador para atender aos trabalhadores nas solicitações subseqüentes (saque FGTS e SD, este último já previsto no eSocial).
Tudo isso tem que ser pensado com pacimônia... Algo raro em nossos dias de Sped.
Entendo que o eSocial poderia prestar um enorme favor tirando o HomologNet de vez, no cotidiano dos empregadores e dos colegas do departamento.
Comentários