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 não 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! Os 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 1 GB
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 ideia, o
arquivo texto desse cliente supera mais de 15 milhões de linhas ou quase
4 GB de dados por mês, em uma rotina de geração de duas 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 a 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 quê, 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 o 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 para um projeto desse tipo são os vários blogs que
encontramos na internet, entre os quais destaco o do Professor Roberto Dias
Duarte (www.robertodiasduarte.com.br) e do José Adriano (www.joseadriano.com.br), ambos profissionais muito requisitados e experientes no SPED.

Sempre que 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 é  necessária 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 um 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.

Para contar o final da minha odisséia com o SPED, posso dizer que apenas
começou… Este ano teremos o novo eLALUR, depois o SPED Social, e por aí
vai.