O que é o PAF-ECF ?
PAF-ECF é o Programa Aplicativo Fiscal que faz a interface com o ECF-IF (Emissor de Cupom Fiscal – Impressora Fiscal). Até recentemente cada estado definia como o Aplicativo Fiscal deveria atuar com o ECF. O Fisco publicou 2 documentos contendo as informações para análise do PAF-ECF, que é o Ato Cotepe 06/08e o Convênio ICMS 15/08,passando a ser de abrangência nacional, quer dizer, todas as software-houses deverão atendê-los. O PAF-ECF precisa passar por uma análise funcional por órgão técnico credenciado pelo COTEPE/ICMS, obtendo um Laudo de Análise Funcional de PAF-ECF e com este em mãos poderá solicitar registro em cada unidade federada, e conforme a legislação de cada estado. Durante esta análise a Software-House deverá entregar os códigos-fonte de seu aplicativo para análise, que depois deverá gerar uma chave MD5 do conteúdo e lacrado, ficando em poder da própria software-house como fiel depositária. O prazo de validade da análise funcional é estabelecido pela unidade federada, podendo ainda ser cancelada, suspensa ou cassada. Caso o aplicativo seja alterado, este deverá ser reanalisado depois de decorrido o prazo, sob pena de ser cancelado o registro.
O que muda com o PAF?
Algumas siglas foram criadas para documentos que a maioria já faz uso:
- Auto-serviço– forma de atendimento em que o consumidor escolhe os produtos e leva ao caixa.
- Pré-venda– forma de atendimento em que o consumidor escolhe os itens e recebe um código ou senha de identificação e se dirige ao caixa para pagamento, ou seja, não pode ser impresso nenhum documento.
- Documento Auxiliar de Venda (DAV)– é um tipo de documento emitido e impresso antes de terminar a operação de compra, para atender as necessidades operacionais do estabelecimento comercial. Serve para operações como orçamento, pedido, ordem de serviço, etc. O DAV não substitui o Cupom Fiscal, que deverá ser emitido. O DAV não pode ser usado em bares e restaurantes. Existe um padrão para o tipo de impressão do DAV.
Além das novas nomenclaturas, estabelece normas e requisitos para os Aplicativos Comerciais e com estas regras alguns procedimentos do PAF-ECF são padronizados.
Há regras definidas para diversos ramos de atividade, conforme suas peculiaridades, como por exemplo: postos de combustíveis, bares, restaurantes, farmácias de manipulação, oficina de consertos e transportes:
- O PAF-ECF deve ser instalado de forma a possibilitar o funcionamento do ECF independentemente da rede (Caixa Off);
- A impressão dos itens no cupom fiscal deverá ser concomitante;
- Realizando uma Pré-venda o sistema não poderá imprimir nenhum documento // Nota de Balcão
- As Pré-vendas deverão obrigatoriamente ser convertidas em Vendas em até 2 dias, caso o usuário não comande a sua impressão o sistema fará automaticamente a conversão e seu cancelamento no cupom fiscal.
- O orçamento passa a ser identificado como DAV e não poderá ser alterado ou excluído. Mesmo sendo convertido em Venda deverá permanecer no sistema com a informação do número do cupom fiscal da venda gerada.
- A configuração da impressora fiscal passará a ser feito em um programa externo, apenas pelos técnicos da software-house, não sendo disponibilizado ao cliente.
- Não basta mais criptografar o número de série do ECF e verificar sua troca, há que verificar ainda o GT (grande total) do ECF. Assim não há como trocar o ECF em operação. Há alguns números que são impressos em mais de um documento, gerando uma informação cruzada.
- O PAF-ECF deve possuir um Menu Fiscal, com varias funções disponibilizadas para o fiscal da Secretaria da fazenda, não pode ser restrito por direitos do usuário.
- O PAF-ECF será obrigado a gerar um arquivo diário com o movimento das vendas.
- Os dados gerados pelo PAF-ECF deverão ser assinados digitalmente, identificando quem as gerou. Ou seja, se o fisco receber informações alteradas, poderá facilmente identificar qual o PAF-ECF que as gerou.
- O PAF-ECF deve impedir o seu próprio uso sempre que o ECF estiver sem condições de emitir documento fiscal. Pode disponibilizar apenas consultas ou emissão de outro documento fiscal, nota fiscal de venda a consumidor D1, pelo movimento de estoque (PED)
- O PAF-ECF para bares e restaurantes só deve permitir a utilização de impressora não fiscal para a cozinha. Todos os demais documentos deverão ser emitidos no ECF.
- Todos os itens cancelados registrados nas mesas, obrigatoriamente devem ser impressos no cupom fiscal de venda para bares e restaurantes e automaticamente cancelados no cupom fiscal.
- Os itens transferidos devem indicar a mesa de origem.
- As mesas abertas deverão ser registradas automaticamente em relatório gerencial, denominado Mesas Abertas e este deve ser emitido antes da redução Z.
- Não é possível excluir todos os itens de uma mesa e reativação da mesa. Todas as operações devem ser impressas em cupom fiscal.
RELATÓRIO BÁSICO
Pelo o que eu pesquisei para fazer os arquivos do Sintegra, preciso gerar os seguintes registros:
- Registro 10
- Registro 11
- Registro 60M (Mestre)
- Registro 60A (Analitico)
- Registro 60R (Resumo Mensal)
- Registro 60D (Resumo Diário)
- Registro 60I (Item)
- Registro 75 (código de produto ou serviço)
- Registro 90
Os registros 10,11 e 90 são obrigatórios. Os outros dependem do tipo de estabelecimento que vai gerar o Sintegra.
No convênio ICMS 57/95, tem explicado cada campo de cada registro que é necessário gerar. Alguns estão um poucos confusos, como o campo 6 do registro A, que diz que é o totalizador parcial para cada alíquota. Eu achei que fosse a base do ICMS acumulado para cada alíquota no dia, mas achei que os cancelados não entravam. Mas entra sim, tem que somar tudo, tanto os cupons cancelados quanto os cancelados. Além disso não é a base de calculo e sim o valor total dos produtos.
Para testar o arquivo do Sintegra, existe um programa, o ValidaSintegra, que verifica se está tudo ok. A melhor maneira é ir fazendo registro a registro e testando com o programa validador.
Eu utilizei o componente ACBRSintegra, do projeto ACBR, e me poupou muito tempo. O importante apenas é prestar bem atenção no que está colocando em cada campo, e o resto o componente faz para você, tudo muito fácil. Agradeço imenso aos idealizadores desse projeto.
REGISTROS
Fazendo mais e mais testes na geração do sintegra, ontem deparei-me com mais um problema: a soma do campo 6 dos registros 60A devem bater com o campo 11, valor da venda bruta do registro 60M.
Explicando um pouco melhor: cada registro 60M, ou mestre, tem seus registros A filhos, ou seja, para cada registro M haverá a quantidade de registros A referentes a cada alíquota registrada na ECF. Então, no registro 60M, o campo 11 tem o valor total das vendas efetuadas no dia, total bruto, ou seja, inclui até os cupons que foram cancelados.
Até aí tudo bem, mas acontece que além de incluir os valores das vendas canceladas, também é preciso incluir os valores dos itens que foram cancelados, nesse caso, sem o cupom inteiro ter sido cancelado.
No meu caso, quando precisava cancelar um item de um cupom, simplesmente excluia-o do banco. Mas não pode, esse item excluído deverá aparecer no arquivo do sintegra. Para isso ao invés de excluir, criei um campo booleano na minha tabela de itens e quando for excluído um item basta marcar como true, e aí terei ele para jogar no campo 6 do registro 60A.
Já no registro 60I, nos campos 10 (valor unitário do produto), 11 (base de cálculo de ICMS) e 13 (valor do ICMS), os itens cancelados nem os cupons cancelados entram, aí sim deve acumular apenas os valores que foram realmente efetivados, ou seja, as vendas finalizadas.
O Registro 60I é um filho do A, tendo em cada linha cada item vendido em cada cupom, por isso vai ter quantas linhas forem necessárias para demonstrar cada cupom vendido. Outro detalhe desse registro é o campo 6, número de ordem do cupom fiscal, nesse campo deve ser mostrado o número da seqüência em que os itens foram vendidos no cupom, para fazer isso eu usei um laço for incrementando esse número, comparando o COO, quando for um COO diferente ele zera e começa do 1 novamente para o próximo COO. Eu guardo no banco o COO de cada venda.
Quero aproveitar e dizer aqui que é preciso guardar tudo em banco, quanto mais dados existirem no banco de dados mais fácil fica para gerar o sintegra e conseqüentemente o PAF ECF depois, é o que eu espero, pelo menos.
Uma das exigências tanto da receita federal quanto do PAF é que exista um arquivo, inacessível ao usuário, que contenha, criptografado, o número de série da ECF a qual está conectada no computador. Para que, não aconteça de o dono do estabelecimento simplesmente trocar a ECF registrada por outra.
Na Norma de Procedimento Fiscal, a qual eu estou seguindo para homologar na receita federal do estado do Paraná, no artigo 93, diz que esse número de série deve ser guardado em um arquivo e que deve estar criptografado. Pelo o que eu entendi, O banco de dados com o número criptografado dentro dele, e essa criptografia deve ser a MD5, que é um tipo que não tem como ser descriptografado, apenas conseguimos comparar a sequência gerada com outra sequência, e, se forem iguais, quer dizer que a palavra criptografada é a mesma nos dois casos.
No meu sistema eu fiz assim: no executável de configuração da ECF (que deve ser diferente do que o cliente irá usar), eu fiz gerar no banco de dados, e dentro dele eu coloco o número de série da ECF, utilizando uma função chamada MD5 Hash,
Na verdade são algumas units que devem ser colocadas junto da pasta de seu projeto e depois declarar a use U_Cipher. Depois que criei o arquivo com o número criptografado a partir do meu sistema de configuração da ECF, fiz a validação no sistema do Caixa, pegando o número serial a impressora conectada, fazendo o MD5 e comparando os dois. Se por acaso forem diferentes, deve dar uma mensagem de erro e não deixar utilizar o caixa.
