Business - Automação Comercial

SPEDFiscal - Software para Escriturações de Documentos fiscais

O SINTEGRA, Sistema Integrado de Informações sobre Operações Interestaduais com Mercadorias e Serviços, é um formato padronizado de envio de informações adotado pelas secretarias da fazenda dos estados brasileiros onde os contribuintes devem enviar arquivos de texto contendo informações formatadas de acordo com os padrões estabelecidos pelo próprio SEFAZ.

por Victory Fernandes



Por Victory Fernandes e Juliana Andrade Carvalho

Sintegra x SPEDFiscal

O SINTEGRA, Sistema Integrado de Informações sobre Operações Interestaduais com Mercadorias e Serviços,  é um formato padronizado de envio de informações adotado pelas secretarias da fazenda dos estados brasileiros onde os contribuintes devem enviar arquivos de texto contendo informações formatadas de acordo com os padrões estabelecidos pelo próprio SEFAZ.

O formato das informações utilizadas pelo Sintegra têm como base os layouts fiscais de processamento de dados instituídos através dos chamados Atos Cotepe conforme informações descritas no site oficial www.sintegra.gov.br.

Para aqueles que não estão familiarizados com o Sintegra, sugiro fortemente que antes de continuar a leitura deste artigo, façam a leitura detalhada dos artigos previamente publicados sobre o tema e disponíveis aqui na minha coluna online no site da Revista ActiveDelphi (http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=index&catid=&topic=17&allstories=1).

A partir de 2007, o padrão do Sintegra, ao qual muitos de nós já estávamos habituados, foi alterado conforme o padrão do SPED que instituíram inúmeras mudanças nos tipos de registros, estrutura e conteúdo dos arquivos e na sistemática do processo como um todo. Estas alterações tornaram o processo muito mais abrangente no que tange às informações comtempladas, mas também muito mais complexo nos aspectos que dizem respeito à adequação e desenvolvimento de ferramentas de software que dêem suporte a tais recursos e se façam de acordo com todos os padrões normativos exigidos.

O SPED é dividido em dois tipos básicos, o SPEDFiscal e o SPEDContábil, detalhados no site oficial do projeto em www1.receita.fazenda.gov.br (o link é com “www1” mesmo) e cuja descrição é apresentada a seguir:

· O SPEDContábil nada mais é do que a substituição dos livros da escrituração mercantil, também conhecidos como livros fiscais, pelos seus equivalentes digitais.

· O SPEDFiscal, tema deste artigo, constitui um conjunto de escriturações de documentos fiscais e de outras informações de interesse do fisco, bem como de registros de apuração de impostos referentes às operações e prestações praticadas pelo contribuinte.

De forma geral podemos dividir o SPEDFiscal em três partes:

1- Convênio que define o formato e padrão do arquivo de texto a ser gerado pelo desenvolvedor em seu software gerencial.

2- Geração do arquivo digital constando de todos os registros devidamente formatados.

3- Programa validador do arquivo digital, que o usuário utiliza para verificar os erros ocorridos na forma e conteúdo do arquivo gerado.

Nesta série vamos abordar as fases descritas acima, exemplificando os passos para a padronização dos valores que serão passados para a geração do arquivo digital e sua posterior validação, buscando facilitar ao máximo o entendimento do leitor através da “tradução” do processo descrito na legislação que rege o tema para uma linguagem simples e menos “burocrática” acessível a todos os desenvolvedores.

Prazos de Adequação ao novo Formato

A maior preocupação dos desenvolvedores é a respeito do prazo para se adequar às novas mudanças. Para aqueles que ainda não se adequaram ao SPED, devo alertar que a lista atualizada de empresas obrigadas em 2009 encontra-se disponível em

http://www.fazenda.gov.br/confaz/confaz/Diversos/Anexo%20II%20-Relatório-GT48%20SPED%20FISCAL-2009-06-03%20a%2005.pdf

Sendo assim, todos aqueles já familiarizados ou não com o padrão anterior do Sintegra, devem procurar se atualizar o mais breve possível de forma a adequar seus sistemas à nova sistemática que passará a vigorar muito em breve em todas as empresas o SPED. 

Estrutura do Arquivo

Do ponto de vista do desenvolvedor, o SPED pode ser visto como um arquivo de texto formatado segundo um padrão pré-definido, onde cada linha do arquivo corresponde a um Registro que contém vários campos com tamanho e formato também pré-definidos de acordo com o seu tipo. Tal arquivo, após gerado pelo sistema gerencial, deve então ser validado pelo Programa Validador oficial disponibilizado pela Secretaria da Fazenda antes de ser entregue à Receita através de Programa de Envio, também oficial e disponível para download.

Alguns pontos importantes relacionados à estrutura de arquivos do Sintegra tendo em vista a nova e a antiga estrutura são:

1. A legislação do SPED lista um total de 151 registros possíveis de serem gerados contra um total de 60 registros listados no Sintegra, o que nos mostra que realmente a abrangência das informações contempladas está muito mais ampla. Além disso nota-se que o número maior de registros também faz aumentar a complexidade do sistema gerencial que terá de se adequar ao novo padrão e estar de acordo com um maior número de registros.

2. No Sintegra os campos tinham tamanho fixo determinado devendo ser feito preenchimento dos espaços remanescentes, caso necessário, de acordo com seu tipo, alfanumérico ou numérico. Na nova versão a separação dos campos se dá através de barras verticais ”|” utilizadas como caractere delimitador, conforme mostrado na Figura 01.

a. O caractere delimitador não deve ser incluído como parte integrante do conteúdo de quaisquer campos numéricos ou alfanuméricos.

b. Na ausência de informação, o campo vazio (campo sem conteúdo; nulo; null) deverá ser iniciado com caractere "|" e imediatamente encerrado com o mesmo caractere "|" delimitador de campo.

c. Campos alfanuméricos representados pela letra "C" terão tamanho máximo de 255 caracteres, exceto se houver indicação distinta e podem conter todos os caracteres das posições da Tabela ASCII, exceto os caracteres "|" (Barra Vertical: caractere 124 da Tabela ASCII) e os caracteres não-imprimíveis (caracteres 00 a 31 da Tabela ASCII).

d. Campos numéricos representados pela letra "N" podem conter algarismos numéricos (caracteres 48 a 57 da Tabela ASCII) sem restrição de tamanho máximo e deverão ser preenchidos sem os separadores de milhar, sinais ou quaisquer outros caracteres (tais como: ".", "-", "%"), devendo a vírgula ser utilizada como separador decimal (Vírgula: caractere 44 da Tabela ASCII).

e. Campos de data devem ser informados conforme o padrão "diamêsano" (ddmmaaaa), excluindo-se quaisquer caracteres de separação (tais como: ".", "/", "-", etc). Para campos onde data representa período,  devem ser informadas conforme o padrão "mêsano" (mmaaaa), também excluindo-se quaisquer caracteres de separação.

3. No Sintegra os registros eram identificados pelos 2 primeiros caracteres da linha que eram sempre numéricos e seguiam numerações do tipo 10, 11, 50, 51 e etc. Na nova versão, os registros são identificados pelo primeiro campo da linha, contido entre as duas primeiras barras verticais utilizadas como caractere delimitador. São valores contendo 4 caracteres onde o primeiro caractere indica o bloco a que o registro pertence e os demais indicam o tipo de registro, conforme mostrado na Figura01.

Figura 01: Início de registro. Primeiro caractere representa bloco e demais caracteres representam tipo do registro.

4. No SPED, para fins de organização tendo em vista o grande volume de informações, o leiaute fiscal de processamento de dados foi dividido em blocos de informações que, por sua vez, estão organizados em registros que contém dados. A seguir é apresentada a estrutura geral dos registros.

a. Bloco 0 – Abertura, identificação e referências;
Blocos 1, C, D, E e H – Regitros com uma série de informações fiscais;
Bloco 9 – Encerramento do arquivo;

b. A listagem completa dos blocos disponíveis pode ser vista na Tabela 01

5. Dentre os registros de cada bloco há os registros de abertura e fechamento do bloco que devem ser usados no início e fim de cada bloco, respectivamente. A seguir é apresentada a estrutura geral de abertura e fechamento dos blocos.

a. Registro 0000 - Abertura do arquivo;
Registro 0001 - Abre o Bloco 0;
Registros 0005 a 0460: informa os dados;
Registro 0990 - Encerra o Bloco 0;
Registro 9001 - Abre o Bloco 9;
Registro 9990 - Encerra o Bloco 9;
Registro 9999 - Encerramento do arquivo;

6. Mantendo o padrão original, os registros mantêm a organização hierárquica da seqüencia de informações de apresentação dos registros. Sendo assim, os registros devem ser chamados de forma ordenada, de acordo com sua seqüencia de apresentação na legislação, bem como continua existindo as relações de registro em modo PAI-FILHO.

7. Mantendo o padrão original, todos os registros devem conter no final de cada linha do arquivo digital, após o caractere delimitador Pipe acima mencionado, os caracteres "CR" (Carriage Return) e "LF" (Line Feed) correspondentes a "retorno do carro" e "salto de linha" (CR e LF: caracteres 13 e 10, respectivamente, da Tabela ASCII).

 

Ocorrência de Registros

Registros Obrigatórios

Na geração do arquivo SPED, todos os blocos, salvo quando houver especificação em contrário, têm por obrigatoriedade que conter no mínimo os registros de abertura e fechamento do próprio bloco, sendo esses registros os de número ?001 e ?990 onde “?” representa o caractere de indicação do bloco em questão. Além, é claro, dos registros 0000 e 9999 que também são obrigatórios e têm maior importância na geração do arquivo digital por representarem a abertura e fechamento do arquivo como um todo.

A legislação do SPED indica em um tabela a obrigatoriedade de cada registro conforme a seguinte sistemática:

· O = O registro é sempre obrigatório.

· OC = O registro é obrigatório, se houver informação a ser prestada. Ex. Registro C100 - só deverá ser apresentado se houver movimentação ou operações utilizando os documentos de códigos 01, 1B, 04 ou 55.

· O(...) = O registro é obrigatório se atendida a condição. Ex. Registro D590 - O(Se existir D500) - O registro é obrigatório sempre que houver o registro D500.

· N = O registro não deve ser informado. Ex. Registro D110 - em operações de aquisição de serviços não deve ser apresentado.

Todos os registros obrigatórios de serem informados possuem a indicação “Registro obrigatório” no tópico “observações da documentação” contido no Ato Cotepe, como pode ser vista na Figura 02, que apresenta o registro I020 conforme consta na legislação.

Figura 02: Legislação com atenção para a indicação de registros obrigatórios

Além dos registros obrigatórios há outros tipos de ocorrência de registros no arquivo magnético, são eles:

1. Os registros que contiverem a indicação "Ocorrência - um (por arquivo)", somente devem figurar uma única vez no arquivo digital.

2. Os registros que contiverem itens de tabelas, totalizações, documentos (dentre outros) podem ocorrer uma ou mais vezes no arquivo por determinado tipo de situação. Estes registros trazem a indicação "Ocorrência - vários (por arquivo)", "Ocorrência - um (por período)", "Ocorrência - vários (por período), etc.".

3. Um registro "Registro Pai" (cabeçalho de documento) pode ocorrer mais de uma vez no arquivo e traz a indicação "Ocorrência - vários por arquivo".

4. Um registro dependente ("Registro Filho") detalha o registro principal e traz a indicação "Ocorrência - 1:1", significando que somente deverá haver um único registro filho para o respectivo registro pai; quando o registro dependente traz a indicação "Ocorrência - 1:N" significa que poderá haver vários registros filhos para o respectivo registro pai.

5. A geração do arquivo requer a existência de pelo menos um "Registro Filho" quando houver um "Registro Pai" correspondente e, reciprocamente, de um "Registro Pai" quando houver pelo menos um "Registro Filho".

6. Poderá ocorrer uma indicação do número máximo de registros dependentes em relação ao respectivo registro principal: "Ocorrência - 1:N” (máximo de ‘n’ registros).

Figura 03: Legislação com atenção para a indicação dos níveis e ocorrência.

A listagem completa dos registros disponíveis em cada bloco, bem como a ocorrência de cada um deles e seus campos e formatações, podem ser obtidas no que descreve o ATO COTEPE/ICMS Nº 9, DE 18 DE ABRIL DE 2008.

O que é a SPEDFiscal32dll.dll?

A SPEDFiscal32dll.dll é um produto desenvolvido com base na experiência e qualidade reconhecida da Sintegra32dll.dll, pioneira no mercado de Sintegra desde 2002 e com mais de 500 licenças vendidas para desenvolvedores em todo o território nacional incluindo clientes de porte como a Zanthus Automação (www.zanthus.com.br) que implementa inúmeras soluções baseadas em nossos produtos.

Seguindo a linha dos produtos já consagrados, e implementando diversas melhorias com base nas melhores práticas e sugestões dos nossos usuários, a SPEDFiscal32dll.dll está totalmente de acordo com a nova legislação do SPED e suas alterações subseqüentes, se destacando por ser mais uma vez pioneiro e atualmente o único produto disponível no mercado para este tipo de aplicação.

O produto constitui uma solução que visa facilitar e agilizar o processo de tratamento das informações relativas ao SPED, com base na legislação pertinente, possibilitando que o desenvolvedor abstraia quase que completamente a camada de geração do arquivo magnético, log de geração de registros e log de erros de geração de registros.

Podendo ser usada em conjunto com qualquer linguagem de programação a SPEDFiscal32dll.dll representa uma solução muito eficiente e eficaz, capaz de reduzir drasticamente o tempo de programação necessário à implementação e adequação do seu sistema aos novos requisitos do SPED, que já estão em vigor.

Dentre as muitas vantagens da SPEDFiscal32dll.dll destacam-se:

· Velocidade na implementação e adaptação do seu software à legislação do Sintegra.

· Validação e formatação automática dos campos de acordo com os padrões da legislação vigente

· Validação de informações genéricas como: Datas, CNJP, CPF, UF e CEP.

· Validação de informações específicas do SIntegra a exemplo de: CFOP, CIF/FOB, Código de Identificação do Convênio, Código de Finalidades da Apresentação do Arquivo Magnético, Código de Identificação da Natureza das Operações Informadas, Código de Modelo de Documentos Fiscais, Código de Posse das Mercadorias Inventariadas, Emitente de Nota Fiscal, Código da Situação Tributária, dentre outras.

· Log de erros de geração de registros automático e completo contendo inúmeras informações pertinentes a respeito do processo de geração e dos problemas detectados.

· Log de geração de registros automático completo contendo percentuais e quantidades de registros gerados.

O produto é composto por inúmeras funções disponíveis ao desenvolvedor que serão chamadas de acordo com a necessidade específica da implementação em questão. As funções são muito intuitivas, utilizam a mesma nomenclatura de registros e campos apresentada na legislação permitindo assim um fácil uso da mesma. De forma geral a SuperSintegra32dll.dll é dividida em 3 blocos de funções:

· A função Inicia_SPED indica à dll que o uso da mesma será iniciado, o que faz com que todos os seus contadores sejam zerados e a dll esteja pronta para ser usada. Esta função deve ser chamada antes de serem chamadas as funções que irão gerar os registros do SPED.

· As funções de RegistroXXXX, são as funções principais da dll onde “XXXX” representa o registro a ser gerado. Elas recebem os parâmetros necessários para a criação do registro, retornando uma Integer que informa a correta geração do registro solicitado ou a presença de erros no processo.

· A função Finaliza_SPED indica à dll que o uso da mesma será finalizado e finaliza o processo de geração como um todo deixando disponíveis ao usuário final o arquivo magnético do SPED gerado e os demais arquivos de log.

A SPEDFiscal32dll.dll vem acompanhada da documentação completa sobre como utilizar suas funções e quais os tipos de erros retornados por cada função. Há ainda uma aplicação demo completo implementado em Delphi que demonstra como conectar a dll ao seu programa e testar a saída da mesma para todos os registros disponíveis conforme apresentado na Figura03.

O produto conta com versão 100% funcional disponível para download que apresenta apenas mensagem de “Produto não Registrado”, o que permite que qualquer um avalie suas funcionalidades e ateste suas indiscutíveis qualidades e benefícios.

Figura 04: Aplicativo demo da SPEDFiscal32dll

Uma vez avaliado, o produto pode ser adquirido em 2 modalidades, com e sem código fonte.

Sinta-se livre para optar por qualquer uma das modalidades do produto afinal todas as duas modalidades são plenamente funcionais e atendem aos propósitos de geração do SPED mantendo os padrões de qualidade e confiabilidade exigidos pelas maiores e melhores empresas de desenvolvimento do país.

Para obter uma cópia e maiores informações sobre a SPEDFiscal32dll.dll visite o site:

http://www.igara.com.br/produto.php?cod_produto=106

Conclusão

Com este artigo, cobrimos os conceitos gerais a cerca da nova legislação do SPED suas respectivas alterações, traçando comparativo com a legislação já conhecida do Sintegra ATO COTEPE 57/95 bem como apresentando a SPEDFiscal32dll.dll, solução pioneira no mercado voltada para o público desenvolvedor de software e baseada na já consagrada Sintegra32dll.dll que permite a completa abstração da camada de geração do arquivo magnético do SPED conforme os requisitos da nova legislação vigente.

No próximo artigo da série será descrito todo o processo de implementação do SPED Contábil utilizando a SPEDContabil32dll.dll, incluindo demo completo de uso da solução dll conforme os padrões da legislação.

Juliana Andrade Carvalho é graduanda em Engenharia Mecatrônica pela UNIFACS e estagiária da TKS Software - Soluções de Automação e Softwares Dedicados. Pode ser contatada em juliana@unifacs.edu.br

Victory Fernandes é Engenheiro, Professor do Departamento de Engenharia da UNIFACS – Universidade Salvador e diretor técnico da TKS Software - Soluções de Automação e Softwares Dedicados, responsável pela criação do projeto Sintegra32dll e Supersintegra32dll. Pode ser contatado em victory.fernandes@igara.com.br, ou através do site www.igara.com.br/victory

Victory Fernandes

Victory Fernandes - Professor do Departamento de Engenharia da Faculdade Area1, Engenheiro Eletricista, Pós-Graduado em Docência, e desenvolvedor sócio da TKS Software - Soluções de Automação e Softwares Dedicados. Pode ser contatado em victory@igara.com.br, ou através dos sites www.igara.com.br - www.tkssoftware.com/victory