Por Claudenir Andrade

claudenir@daruma.com.br
Formado pela Academia de Sistemas Informáticos de Madrid, trabalha com automação comercial há nove anos,
foi responsável pela Homologação e aprovação de ECFs brasileiros em países como Equador e Venezuela,
gerencia a equipe de desenvolvimento da Daruma Automação. Autor do primeiro livro de automação comercial
no Brasil - "Automação Comercial com VB.Net e C#", é também MVP da Microsoft e está criando e definindo o
Modelo XML para Automação Comercial, escreve artigos também para o site MSDN e pode ser contatado pelo e-
mail - claudenir@daruma.com.br

Automação Comercial (ECF) x Integração com Software

No ano de 1994, foi aprovada a lei que exige de todos os estabelecimentos
comerciais a instalação de equipamentos fiscais em seu Ponto de Venda – todos
que realizem vendas ao consumidor final.

Desde então, a lei, como tudo em nosso País, passou por uma constante evolução,
por modificações, adendos e convênio o que representa para nosso mercado
(Software de Automação), uma oportunidade de evolução tecnológica e, ao mesmo
tempo, uma necessidade de reestruturação do sistema como um todo e da própria
"software house". Hoje, estamos tão "evoluídos" (se é que podemos chamar a isto
de evolução) que até mesmo o TEF - Transferência Eletrônica de Fundos, foi
legislado como de Responsabilidade da Empresa de Software e do Software de
Automação, para que controle toda a transação.

Está contemplado no novo convênio 50/00, que o software "frente de caixa" (é

assim que costumamos chamar todo software que interage com a impressora fiscal)
também deverá apresentar relatórios contábeis e mapas resumo de toda e qualquer
operação realizada com a impressora fiscal durante o dia, a semana ou o mês em
questão.

Bem, vamos por partes... Entendamos um pouco como funciona "no bit" o trabalho
do software com uma impressora fiscal.

Impressora Fiscal

Muitos desenvolvedores encaram esta impressora como uma MiniImpressora

normal para se trabalhar, aí está o engano e também a dificuldade de entender seu
desenvolvimento. A impressora fiscal contém um set de comandos próprio, com
instruções próprias para a emissão de documentos fiscais e relatórios, sendo assim,
ela não se comporta com uma "LX300" que você liga na paralela e pronto. A
consideração deve começar pelo fato de todas elas (por uma exigência legal) terem
uma saída serial (RS232) seja DB9 ou DB25 pinos. Com esta interface, já se torna
um pouco mais difícil a operação, tornando necessário um protocolo de
comunicação para o uso destas impressoras.

Infelizmente, em nosso País vivemos a "Babilônia" das impressoras fiscais, os

fabricantes não se entendem e cada um eles estabelece seu protocolo de
comunicação, o que, por sua vez, causa um grande trabalho de codificação para a
parte do desenvolvedor.

A título de exemplo, a Mecafe trabalha com um protocolo que inicia pelo byte (02)
STX e finaliza com um CRC único; já a Bematech começa com um (02) e termina
com dois CRCs um que representa o byte mais sig e mais outro que representa o
resto da divisão por 256 (valor comportado por um byte). Hoje, no mercado atuam
pelo menos seis fabricantes expressivos, ou seja, são seis IF´s que o
desenvolvedor terá de incluir, imagine agora você com o seguinte código:
If Mecafe then
....
If Sweda then
....
If Bematech then
....

Onde, para cada fabricante, deverá haver um correspondente set de comandos

diferentes, um diferente protocolo de comunicação e cálculos diferentes!!! Quantas
e quantas horas de código você terá que disponibilizar para deixar seu software
"falando" com os principais fabricantes!

Pensando nisso, a AFRAC de São Paulo, está montando um "braço" de associados

composto por empresas de Software, fato que pode tornar-se uma luz no fim do
túnel para nós desenvolvedores, pois já foi estabelecido por este grupo um padrão
de interface para as impressoras fiscais, cujo conteúdo deverá modelar as
adequações de todo fabricante de impressora fiscal. As empresas de software
podem associar-se a este grupo.

DLLs e Drivers - Middleware Facilitadores

Com o objetivo de facilitar a integração com a impressora fiscal, os fabricantes

disponibilizam drivers ou DLLs que auxiliam ou oferecem recursos de alto nível para
a comunicação com as impressoras fiscais, possibilitando um rápido
desenvolvimento de software com a impressora fiscal.

Esta excelente intenção acabou caindo no mesmo funil de "Babel" de facilitadores,

ou seja, o facilitador da Bematech não é o mesmo que a Sweda que não é o mesmo
que o da Mecafe.

Infelizmente, no mercado hoje existem mais de seis DLLs diferentes para cada
fabricante de impressoras fiscais. DLLs que não conversam entre si e voltam a
trazer o trauma dos "IFs" nos códigos (If DLL Mecafe.... then If DLL Bematech
then .... If DLL Sweda then ... ) o que de nada facilita nossa vida...

A este respeito, a AFRAC estabeleceu um padrão de DLL com chamadas de funções

de alto nível como: Afrac_LeituraX() ou Afrac_VendeItem (código, valor, etc...) esta
iniciativa seguramente será um grande passo para o mercado de desenvolvedores
para automação comercial.

Assim, esta mesma interface deverá "falar" com todas as impressoras fiscais no
mercado, ou seja, tire Bematech e coloque Mecafe ou tire Mecafe e coloque
Bematech que o software terá que funcionar sem problemas de compatibilidade,
ajustes no código e sem a necessidade de estar colocando os IFs dos quais falei.

TEF - Transferência Eletrônica de Fundos

O TEF, o segundo convênio de legislação assinado e aprovado, agora é de

obrigação nossa: desenvolvedores de aplicação. Como? Como integrar o Software
com o TEF? Como integrar as compras com cartão de crédito?

Bem, vamos por partes - como diz o Jack...

Para deixar o software compatível com as administradoras, existe a necessidade da
aquisição de um kit TEF, fornecido atualmente apenas pela Procomp, porque outros
fabricantes de impressoras fiscais ainda não se posicionaram no mercado como
revendedores desta solução. Este kit inclui: um Pinpad (Teclado numérico com
leitor de cartão) e um kit de software para a comunicação com as administradoras.

Existem duas empresas "certificadoras" que estarão autorizando as software houses

a trabalhar com este kit, tal autorização é concedida após homologação na
SevenPDV e SoftwareExpress, duas empresas escolhidas pelas Bandeiras para
efetuar a certificação dos software.

No micro em que o software frente de caixa está rodando, deverá ser instalado um
GP (Gerenciador Padrão) este gerenciador é o que conversará com seu aplicativo
através de arquivo texto, ou seja, o GP fica "alocado" no canto do vídeo, sempre
ativo e buscando arquivos em um determinado diretório.

Quando sua aplicação cria um arquivo para ser enviado para a administradora, o GP
é aberto na tela, o cliente escolhe a forma de pagamento e o GP efetua a
comunicação via modem com as administradoras. Apos a aprovação da transação,
o GP cria um arquivo Texto de resposta, que deverá ser capturado por seu
aplicativo, retrabalhado e impresso no ECF através de um documento fiscal
chamado "Relatório Não Fiscal Vinculado"....UFA!! Que maratona... mas é
exatamente assim que você deverá fazer para deixar seu software compatível com
TEF e dentro da Legislação.

Finalizando, os fabricantes de automação comercial: Bematech, Sweda, Unisys,

Procomp, Mecafe e os outros treze existentes em nosso país, infelizmente estão
muito longe de nossa realidade, muito longe de uma união de Protocolos e
MIDDLEWARE, muito longe do que nós, desenvolvedores que fazermos a "roda do
mercado de automação" girar, necessitamos. No dia em que o foco na venda de
equipamentos for direcionado a preço, pós-venda, atendimento e suporte, aí sim,
neste dia os fabricantes terão enxergado a real necessidade do mercado e estarão
rumando para a excelência em atendimento e apoio a suas software houses.
Sobre o Autor

Claudenir Andrade é formado pela Academia de Sistemas Informáticos de Madrid,

trabalha com automação comercial há sete anos, gerenciando a equipe de
desenvolvimento de MiddleWare da Bematech para conectividade com os periféricos
de automação comercial na América Latina. É também responsável pelo Programa
de Parcerias da Bematech - Bematech Software Partners. Foi palestrante de vários
eventos de automação comecial, incluindo o BDD - Bematech Developers Days, de
sua autoria. Para entrar em contato com o autor, escreva para
claudenir@bematech.com.br.
Por Victory Fernandes
victory@igara.com.br
Victory Fernandes é Mestrando em Redes de Computadores e desenvolvedor sócio da TKS Software - Soluções
de Automação Softwares Dedicados.
Pode ser contactado através dos sites www.victory.hpg.com.br - www.igara.com.br - www.sintregrafacil.com.br.

SIntegra: Entendendo e implementando!

Creio que muitos de vocês leitores, assim como eu, venham sendo constantemente
abordados por seus clientes a respeito da obrigatoriedade de seus respectivos
sistemas satisfazerem à legislação do SIntegra.

Assim como há algum tempo atrás houve uma onda acerca da obrigatoriedade dos
emissores de cupom fiscal - ECF, existe uma tendência cada vez maior por parte da
Federação em cobrar das empresas que as mesmas estejam adaptadas ao sistema
do SIntegra.

Em amboso os casos, cabe a nós desenvolvedores, a compreensão e adaptação dos

aplicativos de nossos clientes.

Tentando facilitar e agilizar este processo de implementação e adaptação, venho

por meio deste artigo apresentar características gerais do SIntegra bem como uma
solução de implementação rápida e segura do mesmo, a SIntegra32Dll.dll.

O que é o Sintegra?

O Sistema Integrado de Informações sobre Operações Interestaduais com

Mercadorias e Serviços - SIntegra, foi criado visando o controle informatizado das
operações de entrada e saída interestaduais realizadas pelos contribuintes do ICMS.

Sendo o SIntegra obrigatório a todos os contribuintes que emitam documento fiscal

por processamento de dados (Notas Fiscais ou Cupons Fiscais) e/ou façam a
escrituração de Livro Fiscal por processamento de dados, existe a necessidade da
adaptação de grande parte dos softwares comerciais, para que atendam à nova
legislação.

O SIntegra é descrito no Convênio ICMS 57/95, que define quem é considerado

contribuinte usuário de sistema de processamento eletrônico de dados, disciplina as
obrigações a serem cumpridas por estes contribuintes e estabelece o padrão de
arquivo magnético para entrega ao Fisco.

Entendendo o Arquivo do SIntegra

Em termos práticos o arquivo do SIntegra pode ser resumido, do ponto de vista do

desenvolvedor, como um arquivo de texto formatado segundo um padrão pre-
definido, onde cada linha do arquivo corresponde a um Registro, que contém vários
campos, também pre-definidos de acordo com o tipo de registro. Registros e
campos estes oriundos das informações contidas nos documentos fiscais que devem
ser validados pelo Programa Validador antes de serem entregues ao Fisco.

Existe uma série de registros disponíveis para serem adicionados no arquivo, sendo
que cada um deles tem suas características, aplicações e requisitos. A exemplo:

REGISTRO 10:
"Mestre do Estabelecimento - Indentifição do Estabelecimento informante" é um
registro obrigatório a todo e qualquer arquivo do SIntegra, e contém dados sobre a
quem pertence aquele arquivo, como CGC, IE, e Endereço do estabelecimento
informante.

REGISTRO 11:
"Dados complementares do informante" é um registro obrigatório a todo e qualquer
arquivo do SIntegra, e contém dados complementares sobre a quem pertence
aquele arquivo, como Telefone, Bairro, e CEP do estabelecimento informante

REGISTRO 50:
Este registro deverá ser composto por contribuinte do ICMS, obedecendo a
sistemática semelhante à da escrituração dos livros Registro de Entradas e Registro
de Saída

REGISTRO 51:
Este registro deverá ser composto somente por contribuintes do IPI, obedecendo a
sistemática semelhante à da escrituração dos livros Registro de Entradas e Registro
de Saídas

Estes são alguns exemplos de registros e suas aplicações, no entanto, é

impressindível para a implementação do SIntegra, seja utilizando a
SIntegra32Dll.dll ou não, que o desenvolvedor leia atentamente a documentação do
Convênio ICMS 57/95 que dicerta sobre o SIntegra e toda sua sistemática.

Antes de questionar como deve ser o arquivo final do SIntegra emitido por seu
cliente, é necessário que você conheça bem todos os Registros possíveis de serem
adicionados a um arquivo do SIntegra. Só assim você será capaz de traçar as
necessidades do seu cliente e definir quais dos registros o arquivo dele deve conter.

Entendendo um Registro do SIntegra

Como forma de exemplificar a confecção do arquivo magnético como um todo,

vamos agora analisar a implementação do Registro 50.

O Convênio ICMS 57/95 indica que registro 50 deve ser gerado para cada um dos
seguintes tipos de documentos fiscais:

 Nota Fiscal, Modelo 1 ou 1-A (código 01) - Quanto ao ICMS

 Nota Fiscal / Conta de Energia Elétrica - Modelo 6 (código 06),
 Nota Fiscal de Serviço de Comunicação - Modelo 21
 Nota Fiscal de Serviços de Telecomunicações - Modelo 22 (código 22)

sendo formatado de acordo com a tabela abaixo:

Nº Denominação do Conteúdo Tamanho Posição Formato
Campo

01 Tipo "50" 02 1 2 N

02 CNPJ CNPJ do remetente nas 14 3 16 N

entradas e do destinatário nas
saídas

03 Inscrição Estadual Inscrição Estadual do remetente 14 17 30 X

nas entradas e do destinatário
nas saídas
04 Data de emissão ou Data de emissão na saída ou de 8 31 38 N
recebimento recebimento na entrada

05 Unidade da Sigla da unidade da Federação 2 39 40 X

Federação do remetente nas entradas e do
destinatário nas saídas

06 Modelo Código do modelo da nota fiscal 2 41 42 N

07 Série Série da nota fiscal 3 43 45 X

08 Número Número da nota fiscal 6 46 51 N

09 CFOP Código Fiscal de Operação e 4 52 55 N

Prestação

10 Emitente Emitente da Nota Fiscal (P- 1 56 56 X

próprio/T-terceiros)

11 Valor Total Valor total da nota fiscal (com 2 13 57 69 N

decimais)

12 Base de Cálculo do Base de Cálculo do ICMS (com 13 70 82 N

ICMS 2 decimais)

13 Valor do ICMS Montante do imposto (com 2 13 83 95 N

decimais)

14 Isenta ou não- Valor amparado por isenção ou 13 96 108 N

tributada não incidência (com 2 decimais)

15 Outras Valor que não confira débito ou 13 109 121 N

crédito do ICMS (com 2
decimais)

16 Alíquota Alíquota do ICMS (com 2 4 122 125 N

decimais)

17 Situação Situação da nota fiscal quanto 1 126 126 X

ao cancelamento

Nesta tabela, percebemos a ordenação dos campos do registro 50, bem como a
quantidade de dígitos de cada campo e seu tipo de formatação, "X" alfanumérico e
"N" numérico.

Os campos de formatação tipo "X" alfanumérico devem ser preenchidos com

espaços em branco a direita, caso seu conteúdo não tenha o número de dígitos do
campo especifico.

Os campos de formatação tipo "N" numérico devem ser preenchidos com zeros a
esquerda, caso seu conteúdo não tenha o número de dígitos do campo especifico.

Assim, o registro deve ser gerado como mostra a ilustração:

O que é a SIntegra32Dll.dll?

Como o SIntegra se baseia em uma série de informações entradas pelo usuário do

sistema gerencial em questão. Como estas informações devem ser cuidadosamente
tratadas antes de serem enviadas para o banco de dados do sistema e por fim
utilizadas na geração do arquivo de texto, sob pena de recusa do arquivo gerado
por parte do Programa Validador, foi desenvolvida a SIntegra32Dll.dll, como uma
solução que visa facilitar e agilizar o processo de tratamento destas informações.

Uma dll que implementa boa parte dos tratamentos necessários para a geração do
arquivo magnético e pode ser usada em conjunto com qualquer linguagem de
programação.

Dentre as muitas vantagens da SIntegra32Dll.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
do SIntegra
 Validação de informações como: Datas, CNJP, CPF, UF e CEP.
 Validação de informações específicas do SIntegra como: 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.
 Tratamento de Erros que retorna String indicando qual dos valores passados
está incorreto.

Tudo isso torna a dll uma solução muito eficiente, pois é importante lembrar que o
arquivo do sintegra será gerado referente a um período anterior, com base em
informações que já foram adicionadas a um banco de dados e que devem ser
coerentes com o sintegra.

Então, a dll deve ser usada na verdade em dois momentos, a exemplo:

  Momento 1: Em um sistema de controle de Notas fiscais com Sintegra, a
entrada e saída das notas deve ser feita levando em consideração que o
banco de dados gerado será usado para geração do sintegra, assim, logo
após o preenchimento de cada nota fiscal, o sistema antes de mandar as
informações para o banco de dados, pode antes de tudo chamar a dll para
os registros correspondentes e testar se houve erro, salvando as
informações, caso nenhuma exceção seja encontrada.
 Momento 2: No momento da geração do arquivo magnético propriamente
dita, o sistema deve ler as informações do banco de dados e fazer as
chamadas às funções da dll de acordo com o registros desejados.

A SIntegra32Dll.dll é composta por uma função Inicia_Sintegra, uma função

Finaliza_Sintegra e mais uma função para cada um dos tipos de registros
disponíveis nos padrões do SIntegra.

A função Inicia_Sintegra 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 SIntegra.

A função Finaliza_Sintegra indica à Dll que o uso da mesma será finalizado.

As funções de Registro, são as funções principais da Dll. Elas recebem os

parâmetros necessários para a criação do registro, retornando uma String contendo
o registro completamente formatado ou retornando uma String de erro, caso algum
parâmetro esteja incorreto.

Assim, para implementar a linha do Registro 50 descrito anteriormente, a chamada

à função da dll seria feita da seguinte forma:

var
Form1: TForm1;

implementation
Function Registro50(CNPJ, Insc_Est, Data_Emissao_Recebimento, UF, Modelo, Serie,
Nro, CFOP, Emitente, Valor_Total, Base_ICMS, Valor_ICMS, Isenta, Outras,
Aliquota, Situacao: ShortString): ShortString; stdcall; external
'SIntegra32Dll.DLL';

procedure TForm1.Button3Click(Sender: TObject);

var
TempStr: String;
begin
//Registro50 - Registro de Total de Nota Fiscal
TempStr := Registro50('23.859.507/0001-09', //CNPJ
'7.075.793.310.062', //Insc_Est
'21/06/95', //Data_Emissao_Recebimento
'BA', //UF,
'1', //Modelo
'1', //Serie
'501306', //Nro
'5111', //CFOP
'P', //Emitente
'518,19', //Valor_Total
'518,19', //Base_ICMS
'36,27', //Valor_ICMS
'', //Isenta
'0,00', //Outras
'7,00', //Aliquota
'N' //Situacao
);

if TempStr[1] <> '-' then

Memo1.Lines.Add(TempStr) //Adiciona no Memo o Registro 50 formatado
else
 ShowMessage(Copy(TempStr, 6, Length(TempStr))); //Mostra a mensagem de erro recebida
end;
A SIntegra32dll.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
um demo completo em Delphi que mostra como conectar a dll ao seu programa e
testar a saída da mesma.

Para obter uma cópia e maiores informações sobre a SIntegra32Dll.dll visite os

sites:

http://www.delphibr.com.br/vendas.php
http://www.victory.hpg.ig.com.br/

Conclusão

Com este artigo, espero ter esclarecido alguns questionamentos básicos sobre a
sistemática do SIntegra, bem como ter trazido ao seu conhecimento a
SIntegra32Dll.dll, uma solução única no mercado para este tipo de implementação.

Abaixo estão alguns links relacionados ao assunto abordado neste artigo:

Site Oficial do Sintegra - http://www.sintegra.gov.br/

Ministério da Fazenda - http://www.fazenda.gov.br/

Conheça a Nomenclatura Comum do Mercosul -

http://www2.ciesp.org.br/oportunidades/ncm.asp

Victory Fernandes é desenvolvedor sócio da TKS Software - Soluções de Automação

Comercial e Softwares Dedicados. Pode ser contactado em victory@igara.com.br,
ou através dos sites www.victory.hpg.com.br - www.igara.com.br -
www.enge.cjb.net.
Por André Luiz R. Munhoz
andre.munhoz@bematech.com.br
Bematech: DSP - Desenvolvimento de Software e Parcerias.
Visite o site: http://www.bematech.com.br.

Bematech: Transferência Eletrônica de Fundos (T.E.F.) -

Discado - Passo 1/10 - Conhecendo a Lógica de
Funcionamento
Antes de iniciarmos a lógica de funcionamento do TEF, vamos verificar quais são os
pré-requisitos que precisamos conhecer para a sua implementação:

- Aplicativo de Automação Comercial

É responsável pela impressão do Cupom Fiscal e do Comprovante da transação TEF.

- Gerenciador Padrão

É o módulo responsável pelo direcionamento da transação para os respectivos

Módulos TEF (American Express, Redecard e Visanet) e efetua o tratamento das
atividades, permitindo que o Aplicativo de Automação Comercial interaja com as
Administradoras de Cartão de Crédito e de Débito, de forma simples e eficiente.

- Módulo TEF

É o componente que interage com o usuário para coleta de dados da transação a

ser executada. Cada rede possui um Módulo TEF próprio.

Comunicação entre o Aplicativo de Automação Comercial e o Gerenciador

Padrão - Lógica de Funcionamento

A comunicação entre o seu Aplicativo e o Gerenciador Padrão é realizada através de

arquivos no formato "texto" com mensagens próprias. Os diretórios utilizados para
a troca destes arquivos, são: C:\TEF_DIAL\REQ e C:\TEF_DIAL\RESP (ambos
default do Gerenciador Padrão).
 O seu Aplicativo criará o arquivo INTPOS.001 solicitando a realização da
transação TEF e enviará para o diretório C:\TEF_DIAL\REQ. Este diretório é usado
pelo seu Aplicação para envio de dados ao Gerenciador Padrão.

Os dados de resposta do Gerenciador Padrão, após o processamento da transação

pelo Módulo TEF (American Express, Redecard ou Visanet), serão enviados para o
diretório C:\TEF_DIAL\RESP. Este diretório é usado pelo seu Aplicativo para receber
as respostas do Gerenciador Padrão.

O seu Aplicativo, após ter enviado o INTPOS.001 para o Gerenciador Padrão

(C:\TEF_DIAL\REQ), deverá aguardar por 7 segundos o recebimento do arquivo
INTPOS.STS enviado pelo Gerenciador Padrão (C:\TEF_DIAL\RESP). Esse processo
significa que o Gerenciador Padrão recebeu o INTPOS.001 com a solicitação da
transação TEF, enviado pelo seu Aplicativo. Caso o Gerenciador Padrão não
disponibilize este arquivo no tempo previsto, você poderá informar ao operador que
houve algum problema, como por exemplo: "O Gerenciador se encontra desativado,
favor verificar!".

Após o envio do INTPOS.STS, o Gerenciador Padrão irá exibir a tela com os

Módulos TEF disponíveis para a escolha.

O seu Aplicativo deverá aguardar o arquivo INTPOS.001 com o resultado da

transação. Este arquivo será gerado no diretório C:\TEF_DIAL\RESP.

Após seu Aplicativo realizar a impressão do comprovante TEF, deverá ser

enviado um arquivo INTPOS.001, ao Gerenciador Padrão (C:\TEF_DIAL\REQ),
confirmando ou não esta transação.

Após este envio, o Gerenciador Padrão responderá um INTPOS.STS

(C:\TEF_DIAL\RESP), confirmando este procedimento.

Sequência de execução do TEF