Confirmei o que pensava: muitas empresas ainda estão pensando que o projeto eSocial é apenas a automação do envio de folha de pagamentos de empregados para o ambiente do SPED – Sistema Público de Escrituração Digital.
Este equívoco poderá custar caro, pois o projeto é mais minucioso e muito mais amplo do que isso. Até mesmo nas reuniões de planejamento do projeto do grupo das empresas piloto, no âmbito estatal, o assunto “folha” prepondera massivamente. Eu por outro lado, penso que o envio da folha mensal, apesar de “pesado” será trabalho fácil se bem automatizado. Muito pior será o controle de eventos ocasionais passíveis de envio e sua sincronia com o ambiente do eSocial. Por exemplo, afastamentos, férias, entrega de EPI, Exame de Saúde Ocupacional – ASO, etc. Muito além dos requisitos técnicos, teremos o maior e o mais impressionante impacto sobre a cultura e os processos das organizações.
Vejamos o caso de entrega de um EPI, Equipamento de Proteção Individual, por exemplo. Qual é o controle que as companhias realizam sobre estas entregas atualmente? Alguma planilha com o nome do colaborador, data e o tipo de EPI, se tanto. A partir deste paupérrimo controle, como pretenderão informar ao eSocial adequadamente?
Minha doutrina de análise é que tenhamos visão global das situações. Ou seja, quais outros impactos ocorrerão na adequação da sistemática atual? Quais os ganhos possíveis para tonar a companhia menos vulnerável? Onde poderá ser implementado o controle? Quem será o responsável pela qualidade e execução do processo? Como terá continuidade o controle após a implantação? Quais serão os itens de controle da nova sistemática? Enfim, na minha visão é importante que a empresa ao realizar uma adaptação ao ambiente do SPED – Sistema Público de Escrituração Digital, use este “motivador” para implementar uma melhoria no processo atual e possivelmente automação e controle via sistema.
Para mim é muito importante avaliar como serão registradas, conciliadas, controladas e enviadas as contratações de empresas prestadoras de serviços (Pessoa Jurídica) e seus pagamentos. Nunca foi muito adequada a visão de que a DIRF (Declaração de Imposto de Renda Retido na Fonte) fosse pensada apenas em Fevereiro de cada ano, afinal, ela é parte de uma rotina de pagamentos e controles das empresas e deveria estar conciliada mensalmente.
Assim, é difícil imaginar que os sistemas e processos envolvidos no ambiente do eSocial serão executados por um sistema único. Poderá até haver uma mensageria única, porém duvido que alguém numa empresa possa ser o responsável – único – por todos os envios. Ou seja, se atualmente as declarações são geridas por áreas distintas (tal como a DIRF) porque no ambiente do eSocial seria diferente. Na minha visão o sistema de controle de pagamentos deverá, assim como o de remuneração de colaboradores, medicina do trabalho, jurídico, tributário, contábil e outros, estar integrado com a solução – ou as soluções – de envio de informações para o eSocial.
Uma facilidade para as empresas é que há possibilidade de ter um ou mais sistemas operando harmoniosamente no envio de informações para o eSocial. Neste quesito a equipe técnica do projeto está novamente de parabéns, pois elaborou uma solução ampla e ao mesmo tempo segura pela assinatura digital. Por exemplo: uma companhia poderá enviar as informações da matriz pelo sistema de RH e outros sistemas as informações das filiais. Outro caso poderia ser o sistema de pagamentos informar os eventos das retenções, o de medicina do trabalho os atestados médicos e o de RH os pagamentos de colaboradores e estagiários.
Não simplifico demais. Apenas detesto soluções simplistas que complicam os processos das organizações. Continuo afirmando que os sistemas são mecanismos que automatizam e controlam as decisões das empresas e não são implementadores de cultura. Vejam os casos de operadores de sistemas que passam muitos anos após implantações reclamando que o sistema não faz isso ou aquilo. Será que o projeto de implantação priorizou o sistema ou o processo? Pior do que ter customização num sistema adquirido é não ter funcionalidades adequadas!
Fonte: Baguete
Por Mauro Negruni – Diretor de Serviços da Decision IT
