Texto bem interessante sobre os desafios do "pessoal do TI" para atender ao SPED
Texto original do Ricardo Gimenez publicado originalmente em www.baguete.com.br
Lembro-me bem da primeira reunião com a
equipe de desenvolvimento para o SPED do Grupo Coldwell.
Começamos assim, escrevi a palavra “SPED” na
lousa e pedi para cada membro da equipe escrever em uma folha de papel o que
achava que significava essa sigla, foi no mínimo divertido.
O pessoal escreveu as coisas mais engraçadas
do mundo.
Tínhamos um consultor funcional que era um
contador bastante experiente que escreveu: “Serviço de Procuradoria
Especializada em Diagnósticos”, nós rimos muito juntos!
Era 2007, e ninguém havia lido nada sobre o
Sistema Público de Escrituração Digital ou SPED.
Se um contador com 25 anos na área sabia o
que o governo brasileiro queria, imaginem só uma equipe de desenvolvimento na
faixa de 20 a 25 anos de idade, mais interessada na nova versão de Microsoft
Visual Studio, em discutir se o Linux ia acabar com o Windows e em criar comunidades
engraçadas no velho Orkut.
Não existia Facebook ainda. Era 2007!
Um projeto SPED supera o conhecimento técnico
de ferramentas de Desenvolvimento, seja Java, C#, .NET ou o bom VB, amplia
nossa visão de aglutinar dados de áreas complexas como contábil, fiscal e
previdenciária, além de lidar com interfaces, integrações de bancos de dados e
transferências de arquivos TXT e XML.
É necessário concentrar a atenção em layouts
enormes! O do SPED PIS e COFINS podem chegar a mais de 1,8 mil campos que compõem
arquivos de alto volume, em alguns casos tendo que ser fracionados devido a ter
1GB ou mais.
Tive a oportunidade de trabalhar em projetos
de desenvolvimento de SPED de clientes com dezenas e, em alguns casos, com
centenas de filiais e um volume superior a 6 milhões de notas fiscais.
Para se ter uma idéia, o arquivo texto desse
cliente supera mais de 15 milhões de linhas ou quase 4GB de dados por mês, em
uma rotina de geração de 2 horas de processamento numa maquina de quatro
processadores, coisa grande mesmo!
O segredo de um projeto SPED, seja Contábil,
Fiscal, FCont, PIS e COFINS ou qualquer outro, é manter a aderência e
integração entre os dados dos sistemas legados, ERP e outras fontes como
planilhas Excel e o arquivo final.
Para resolver esse dilema de o que vai para
qual arquivo, criamos um índice de DEPARA entre a NFE (Nota Fiscal Eletrônica
2.0) e todos os arquivos SPED.
Fica mais fácil compor uma documentação de
qual SPED contêm o que, sim os dados de um SPED se repetem em outro e assim por
diante, por exemplo: O SPED EFD Fiscal contêm dados de capa e itens de notas
fiscais eletrônicas e manuais que são os mesmos usados no SPED EFD PIS e COFINS
- falo dos blocos C170 e C190 do layout.
O SPED Contábil detém registros de saldos
contábeis mensais de contas de despesa e receita que são os mesmos do SPED
FCont, sendo os bloco I200 e outros.
A grande armadilha para uma equipe de
desenvolvimento é que os layouts não são fixos ou obrigatórios em sua
totalidade.
Nem todos os campos e blocos devem ser
preenchidos por todos os clientes.
Em layouts como o do SPED Fiscal, existem
campos para ECF, cupom fiscal.
Se sua empresa ou cliente não emitem, então
esse campo não deve ser preenchido, no caso do SPED Pis e Cofins, se não houver
crédito presumido de impostos, determinados campos também não devem ser
preenchidos e por aí vai a “encrenca”.
Esses casos devem seguir um rígido controle
de mapeamento e DEPARA, que serão de qualidade superior se a equipe de
desenvolvimento dispuser do apoio de um consultor funcional ou contador com
“tarimba” em desenvolvimento de softwares para contabilidade e área fiscal.
Outra grande ajuda a um projeto desse tipo
são os vários blogs que encontramos na internet, onde destaco já o do Professor
Roberto Dias Duarte e do José Adriano, ambos profissionais muito requisitados e
experientes no SPED.
Sempre quando converso com uma equipe de
desenvolvimento destaco o valor de ter um código bem comentado, detalhes fazem
a diferença em grandes projetos com equipes diversas, às vezes são necessárias
mais de uma plataforma.
Trabalhei em projetos com até três ambientes
diferentes (ABAP4, NET e JAVA), verdadeiras “saladas técnicas” e a salvação
eram bons comentários nos códigos e uma documentação completa de funções,
conexões e rotinas de atualização, regras de negócios de validação e geração.
Esse parágrafo parece “pregação de professor
de lógica”, mas, é isso aí: “Gente, comentem o código!”, vocês já ouviram isso,
não é?!
Nenhum projeto SPED é bem sucedido sem ter
uma boa equipe de implementação.
Esse time tem de ser parceiro do time de
desenvolvimento e fazer uma boa interface com o cliente ou área de negócios.
Certos detalhes sobre o SPED só podem ser
aprendidos na prática, assim a cada novo cliente ou projeto, você e sua equipe
aprenderão mais uma lição, mais um “macete” ou modo diferente de implantar e
atender o SPED.
Em resumo, nunca vi um projeto de SPED sem um
bom trabalho em equipe, todo bom desenvolvedor conhece a diferença entre o
herói e o mocinho nos filmes, o herói sempre “morre” no final.
Pra contar o final da minha odisséia com o
SPED, posso dizer que apenas começou.
Esse ano teremos o novo eLALUR, depois o SPED
Social e por aí vai.
*Ricardo Gimenez é
sócio-diretor do Grupo Coldwell, especializado em serviços de alta tecnologia.
Veja também:
Veja também:
Comentários
Postar um comentário
Compartilhando idéias e experiências sobre o cenário tributário brasileiro, com ênfase em Gestão Tributária; Tecnologia Fiscal; Contabilidade Digital; SPED e Gestão do Risco Fiscal. Autores: Edgar Madruga e Fabio Rodrigues.