PGDIRF x DIRF
Mensal
Realidade x Ficção
Atualizado em 13/09/2014 21h17
PAGAMENTOS E RETENÇÕES:
S-1300 QUE VIROU S-1490, QUE VOLTOU A SER S-1300...
E POR AÍ VAI...
E-SOCIAL 1.2 BETA 5.1, 5.2... 5.6...
Um dos pontos mais polêmicos do projeto eSocial está no
evento S-1300 Eventos Periódicos –
Pagamentos Diversos. A atual versão aprovada (1.1) dos leiautes, assim
dispõe:
Pelos Leiautes 1.2 beta 3, o S-1300 virou
S-1490 – Pagamentos e Créditos Diversos
O S-1490
tem a seguinte definição:
Evento
onde são prestadas as informações relativas aos pagamentos diversos efetuados a
pessoas físicas e jurídicas, inclusive rendimentos pagos a residentes e
domiciliados no exterior. Os pagamentos ocorridos durante o mês devem ser
agrupados por beneficiário e por código de receita, sendo gerado apenas um
evento para cada código de receita.
Permanece a mesma forma de escrituração;
centralizada e com apenas um evento por competência, conforme a Ocorrência 1-1.
Leiautes 1.2
Beta 3
E o S-1300 foi transformado em um indicador do
início do envio dos eventos periódicos:
Leiautes 1.2
Beta 3
Entretanto, tenho informações de que há
uma outra versão mais recente, a 1.2 Beta 5.6, onde o evento
sobre pagamentos e retenções voltou para o S-1300 e o S-1490 foi eliminado, mas
continua com a ocorrência 1-1.
Contudo, não importa, seja S-1300 ou S-1490 (nem imagino como terminará isso...), os
arquitetos do eSocial estão realmente determinados a manter o evento de
pagamentos e retenções sempre de maneira centralizada em uma ÚNICA
OCORRÊNCIA (1-1), pela matriz, onde devem ser consolidados todos os
pagamentos por beneficiário e código de rendimento.
Cabe ponderar que a centralização de informações em si
não é uma novidade do eSocial, pois esse critério se observa também na DIRF,
atual obrigação acessória que envolve o tema. Então, qual seria o problema de
um evento UNIFICADO? Será preciso
comparar um recurso do PGDIRF com o que foi teorizado no eSocial.
ESOCIAL X PGDIRF
Como se prestam, atualmente, pelo PGDIRF, as
informações previstas no sobre retenções no eSocial? Vamos imaginar uma empresa
com diversas unidades, onde os dados de pagamentos e retenções são provenientes
de folhas de pagamento, operações com fornecedores, entre outros fatos
geradores. Vamos considerar que tais dados são processados por bases distintas,
em sistemas distintos.
Trazendo o cenário descrito para a DIRF, vamos observar
que cada sistema gera um arquivo DIRF peculiar, contudo, sempre citando a
inscrição da matriz como declarante e detalhando os rendimentos e retenções por
códigos e beneficiários.
Figura 1
Consideremos também que o PGDIRF é um sistema
offline e que tem uma função de consolidação que permite que sejam importados
diversos arquivos TXT. Vale salientar novamente que temos um cenário de geração
de arquivos por sistemas distintos e bases separadas nas unidades (matriz e
filiais).
Sendo a DIRF uma declaração centralizada na matriz,
cuja aplicação declaratória se dá no programa PGDIRF, para que a consolidação
ocorra, basta que seja citada a inscrição da matriz como declarante, em cada
arquivo DIRF TXT a ser importado, e assim o aplicativo PGDIRF se encarregará de
fazer a consolidação dos dados, coisa que o eSocial não será capaz de fazer
(pelo atual modelo), o que chega a ser impressionante, pois em várias
situações, será preciso consolidar XMLs.
Na Figura 1,
temos um universo de uma matriz e seis filiais, onde os arquivos DRF TXT são
gerados separadamente, inclusive, podendo haver mais de um arquivo por unidade,
pois se tratam de gerações por sistemas separados. Os arquivos são encaminhados
para a importação no PGDIRF comum a todas as unidades, onde há a consolidação
feita pelo próprio PGDIRF, normalmente trabalhado na matriz.
Vamos supor que na Matriz esteja sendo processada uma folha de pagamento pelo SISTEMA DO DESENVOLVEDOR A e as demais informações de pagamento em um ERP DO DESENVOLVEDOR B, na Filial 1, temos um sistema de folha de outro desenvolvedor, e o mesmo ERP aplicado na matriz.
Vamos imaginar que nas Filiais 5 e 6,
há sistemas diferentes, todos customizados de acordo com as operações
comerciais e desenvolvidos por empresas de TI locais, além de folhas de
pagamento diferentes e processadas por um escritório de contabilidade
contratado para realizar o serviço de DP.
Mesmo com todo esse emaranhado de sistemas e bases
distintas, não há grandes dificuldades para o cumprimento da obrigação da DIRF,
pois, como já fora abordado, basta que todos os sistemas aplicados gerem os
arquivos DIRF TXT no padrão definido pelo leiaute, citando sempre a matriz como
declarante, para que o PGDIRF, usado normalmente na Matriz,
seja usado pela função de importação, tratando os dados dos blocos contidos nos
arquivos DIRF TXT, direcionando-os a uma declaração ÚNICA, consolidada pelo
próprio sistema do fisco. Assim, como todos os sistemas neste cenário estão adaptados para o uso da “linguagem
DIRF”, não há embaraço na integração com o sistema oficial;
Figura 2
Vamos analisar mais um caso: Um trabalhador esteve
na Filial 5 durante 4 meses no ano
base, onde a folha de pagamento é processada por um escritório de contabilidade.
Então, foi transferido para a Filial 2,
onde a folha é gerada por um sistema interno diferente do que é utilizado no
escritório que presta serviços a unidade de origem (Filial
5). Como ficará isso no eSocial? Um tremendo problema se estivermos
com bases e sistemas distintos!
Em nossos dias, para atender a DIRF, o sistema de
folha do escritório que presta serviços a Filial
5, gera o DIRF TXT do ano base e o encaminha para importação na
Matriz, que também vai receber o DIRF TXT gerado pela folha de Filial 2. Na importação, haverá a
identificação do mesmo CPF sobre um mesmo código de retenção e neste ponto,
entra em ação o consolidador do PGDIRF, unificando o registro para o CPF do
trabalhador em questão. Problema resolvido, informação pronta para ser conferida
e repassada à Receita Federal, como se pode observar no exemplo da Figura 2.
É comum encontrarmos cenários assim? Já me deparei
com várias situações neste nível de dificuldade. Evidentemente, há grandes
empresas que utilizam sistemas de ERP totalmente integrados, com contabilidade
e escrituração trabalhista centralizadas, mas essa não tem sido a regra e sim a
exceção, pelo menos no contexto de minhas andanças, conversando com contadores,
analistas de sistemas e programadores.
Figura 3
Com o PGDIRF, ambientes com sistemas distintos podem
gerar
Arquivos DIRF TXT
que são importados e consolidados
no próprio aplicativo da Receita Federal, coisa que o
eSocial não será capaz de fazer. Por que?
Por que casos que citei serão bem mais complicados
no eSocial? O evento de retenção é único e mensal, baseado em sequenciamento
lógico e consolidação de valores, códigos e bases, tudo antes do envio. Por não
ter previsão para fazer uso de um aplicativo validador offline, como ocorre na DIRF,
o modelo do eSocial, por tabela, não foi pensado para consolidar as informações
de pagamento por códigos de receita e beneficiário e o teor do evento por XML
deve ser encaminhado por meio de Webservice (serviço de mensageria a ser
contratado pelo contribuinte declarante ou terceiro por ele autorizado) à base
de dados do chamado Ambiente Nacional, onde serão armazenadas as
informações, em conjunto com as que foram prestadas na folha de pagamento
digital, para o fechamento da DCTF Prev, que será um meio de confissão de
dívidas e que se dispõe a geração das guias de recolhimento (INSS, FGTS e
retenções). Mas isto não é uma justificativa plausível. Mesmo na sistemática
atual, a DCTF-Prev do eSocial poderia ser um sistema de apuração mediante
eventos escriturados por estabelecimento.
E o sistema no Portal? Uma palavra apenas: RETRABALHO.
Então, voltemos ao cenário da organização da Figura 1, que utiliza sistemas distintos, bases
distintas, em algumas unidades, onde há até um escritório de contabilidade que
processa a folha em uma de suas filiais, e onde também há aplicações
customizadas que contêm retenções sujeitas a informações, enfim, um emaranhado
de fontes de dados que terão que ser organizadas e consolidadas internamente,
em tese, porque o projeto eSocial impõe um novo modelo, tirando uma
funcionalidade que até então vem funcionando satisfatoriamente pelo PGDIRF.
Será que apenas nos casos de matriz e
filias que isto pode ocorrer? Não. Vamos imaginar o cenário de uma empresa sem
filiais, mas com bases distintas onde também há demandas de integração em se
tratando de ambiente com múltiplas fontes de dados. No exemplo abaixo, uma
empresa com três bases separadas (se bem que a gestão financeira e o
faturamento poderiam operar em um ambiente integrado), também serão
confrontadas com o modelo de geração de eventos S-1300 XML do eSocial, que
implica em uma nova etapa: Consolidar os arquivos ou a possibilidade de adoção
de um modelo integrador via ERP.
Figura 4
Com o modelo proposto no eSocial, em cenários sem
filiais, em alguns
casos, Também será preciso inserir uma ferramenta de consolidação
prévia antes do envio ao Ambiente Nacional.
Uma outra solução seria a adoção de ERP.
O que se pode estimar sobre o atual modelo do
eSocial? Certamente, à primeira vista, salvo se
ocorrer alguma reforma profunda, deverá aumentar o trabalho de
integração de dados nas organizações e
lançará o debate, basicamente, sobre três possíveis soluções:
1. Todos
os sistemas distintos que envolvem as unidades da organização deverão gerar
seus próprios eventos S-1300 XML, que seriam reunidos para uma consolidação em
apenas um ÚNICO S-1300 por uma aplicação interna a ser desenvolvida
exclusivamente para isso, fazendo o papel que hoje tem sido realizado pelo PGDIRF,
ou;
2. Substituir
todos os sistemas usados nas unidades por um ÚNICO ERP que fará a integração
automática de todas as bases processadas nas filiais. Isso significa que os
sistemas separados do ERP serão descontinuados e que os serviços de
escrituração dos escritórios de contabilidade de algumas filiais, seriam
dispensados, obviamente, porque tudo passaria a ser processado internamente por
um ERP centralizador, ou;
3. Digitar
tudo no Portal. Parece brincadeira, mas alguns têm sugerido isso. Esta solução
só é viável em pequenas empresas, e significará retrabalho em muitos ambientes;
consumirá tempo excessivo e conseqüentemente, mais custos.
Em relação à solução 2, teríamos uma mudança radical
na organização, a priori, causada
principalmente por um novo sistema do fisco que se propõe a “simplificar” os
processos declaratórios dos contribuintes. Será fácil substituir sistemas e
dispensar serviços terceirizados (escritórios contábeis) que estão ajustados a
estrutura organizacional?
Em relação à solução 1: Faz sentido desenvolver um
trabalho de consolidação que poderia ser feito por um sistema do fisco que se
propõe a ser simplificador e unificador de declarações?
Não chega a ser um contra senso, impor um modelo
onde o contribuinte precisa OBRIGATORIAMENTE consolidar o que atualmente pode
ser feito por um aplicativo oficial de menor envergadura, como é o caso do
PGDIRF?
Por enquanto, o caminho das pedras será o das
“soluções integradoras”. Vejamos uma
abordagem do renomado especialista em Sped e contador, Jorge Campos,, acerca
da questão:
Bem, o que a gente visto,
tem empresa que desenvolveu um integrador, um DW, para trazer todos os dados de
todas as unidades, de todos os estabelecimentos e unificar, e enviar um arquivo
só. Atribuir, a cada estabelecimento a responsabilidade de envio de seus
arquivos tendo como premissa que no final você tem que ter um único, é
complicado, isso não dá certo, a gestão é difícil. Até porque você tem que
integrar todas as informações, tem que tomar cuidado por conta das matrículas
dos trabalhadores e das rubricas. A sugestão é sempre aquela: Você tem que
trabalhar num modelo de integração.
(Fórum
Sped Porto Alegre, 10/04/2014, em debate com a Dra.Tânia Gurgel. Os dois
experts deixaram bem claro que a proposta do modelo demanda integração e
consolidadores)
Então, o eSocial
impõem uma quebra de paradigma, envolvendo a aplicação de sistemas que atualmente funcionam bem com o modelo
da DIRF, mas que não seriam mais viáveis no modelo proposto, caso não estejam
vislumbrando a aplicação de consolidadores.
Em meio a essa questão, os empregadores, talvez, ainda não tenham
consciência de que haverá problemas,
principalmente em relação aos custos, que deverão ser ainda maiores para os que
possuem unidades (matriz e filiais) e bases de dados distintas em sistemas
distintos.
É
bom salientar que soluções integradoras geram custos, desde a demanda (análise
de casos), passando pela aquisição, além da implementação, e não será o fisco
que pagará esta conta:
1.
O eSocial é um projeto de e para grandes empresas
Trata-se
se um modelo de grandes empresas pensado para grandes empresas. Por que foi
projetado dessa forma? Penso que essa pergunta passe por outra: Quem está nos
bastidores do eSocial? Em tese, um consórcio de órgãos (INSS, MTE, Receita
Federal e CAIXA), mas com a participação ativa de empresas de tecnologia que se
situam no piloto, que são focadas no grande porte, TODAS, evidentemente,
produtoras de ERPs.
Desse
ponto, não é surpresa ver que o modelo se encaixa melhor em um ambiente de ERP,
e despreza categoricamente o universo de médias, pequenas e micro empresas,
além dos escritórios contábeis.
2.
O eSocial poderia consolidar os eventos?
Não tenho dúvida. É só uma questão de vontade política dos gestores e
cabe uma outra questão a ser analisada: Se o eSocial consolidasse os eventos
isso seria comercialmente interessante para as empresas de TI que estão
envolvidas no projeto? Creio que não.
É natural, pela lógica mercantilista que o modelo dificulte a escrituração
local e autônoma dos pequenos desenvolvedores, para dar mais ênfase aos
produtos integralizadores.
3.
Quem será mais beneficiado?
Além do
fisco, que trabalha por um sistema
eletrônico de fiscalização bem mais eficiente, o eSocial, no formato em que
se encontra, vai ser uma poderosa ferramenta de marketing para as corporações de TI e consultoria que
estão no piloto.
As
consultorias que estão por lá, indiretamente, acessando informações por meio da
participação de empresas de software que adquiriram, também serão as
instituições mais beneficiadas nesse processo.
4.
Quem será prejudicado
Além dos
produtores independentes de sistemas e alguns escritórios contábeis que
trabalham com empresas onde a escrituração trabalhista é descentralizada, não
tenho dúvida de que muitos empregadores serão prejudicados com o aumento de
custos, seja na aquisição de ERP, ou na contratação de serviços especializados
para consolidar os eventos, objetivando as ditas “soluções integradoras”
apregoadas por teóricos.
SIMPLIFICAÇÃO
Por ser um modelo inspirado na escola corporativista
do Sped, os problemas do eSocial ainda não foram bem discernidos pela classe
contábil em geral. Muitos aplaudem o
projeto sem saber exatamente os seus efeitos entre os médios e pequenos
empresários contábeis.
Imagino que o eSocial será bem sucedido se for um
sistema prático, simples ao máximo possível, e com participação massiva das
partes envolvidas. No lugar de compliance para o fisco, que pensar em aderência
com a realidade do mercado de serviços contábeis e de TI? Se a proposta é ter a
coleta de eventos de forma mais analítica possível, o bojo de toda consolidação poderia ser disponibilizado aos contribuintes, evitando custos
desnecessários. Por que não?
Não cabe ao fisco impor necessidades de soluções
integradoras comuns em grandes corporações. Naturalmente isto vai se
desenvolvendo, conforme os interesses de gestão de cada organização. O modelo
operacional do eSocial é invasivo; para mim é um abuso.
Como ficará a situação de escritórios contábeis
cujos clientes possuem sistemas de gerenciamento financeiro e fiscal com
informações de retenções que precisam ser consolidadas? A tendência é que as
empresas amadureçam a idéia de retirar
a escrita trabalhista do escritório. Quantos empresários contábeis já pararam
para pensar nessa possibilidade?
Quantos empresários de contabilidade já analisaram
com mais rigor a tendência de alguns representantes do projeto insinuando que o
Portal será tão simples que o próprio empresário poderá preencher os campos? O
que isso realmente significa?
O modelo do eSocial tem que ser revisto pela via da
SIMPLIFICAÇÃO e com maior participação de TODOS os desenvolvedores de sistemas
e profissionais de contabilidade. Coisas simples já poderiam ser feitas, como
estabelecer tabelas e eventos por estabelecimento, deixando para a DCTF PREV a
função de consolidar as retenções, o agrupamento de beneficiários e os códigos
de receita.
Talvez alguns advogados deste projeto afirmem que a
simplificação já está sendo providenciada, mas não imagino que seja neste
sentido, considerando os leiautes que estão vazando... Outra coisa: Por que não
informar ao público pelo site oficial (www.esocial.gov.br)
o andamento detalhado do projeto e as alterações que estão sendo feitas? Por
que tanto segredo? A quem interessa uma gestão tão obscura?
Realidade: Os idealizadores do eSocial
precisam entender e aceitar que o mundo da escrituração digital não é apenas o
das grandes corporações. Palestras de conscientização são ótimas, mas entre o
que está teorizado e que vem sendo analisado na estrutura de muitas empresas, a
distância é temerosa e flagrante.
Ficção: O eSocial vai simplificar a vida
dos empregadores. Quanto a esse apelo, basta que cada um analise com a própria
consciência.
Ainda estamos na fase do discurso. Até
quando a ficção prevalecerá?
Vitória de Santo Antão
(PE), 13 de setembro de 2014.
Leonardo Amorim
LLConsulte Soli Deo gloria