Desenvolvimento - Java
Iniciando um projeto de Nota Fiscal Eletrônica - NFe
A Nota Fiscal Eletrônica envolve uma série de tecnologias complexas. No entanto, tarefas que inicialmente são consideradas detalhes acabam por tomar grande quantidade de tempo. Nesse artigo descrevo algumas atividades importantes para o bom andamento dos projetos e que devem ser realizados antes mesmo de emitir a primeira NFe.
por Pedro Caetano (Quito3010)Primeiro vamos definir o quão crítica é a sua situação:
- Se a sua empresa exerce um atividade que não tem previsão de obrigatoriedade de emissão de NFe, está na hora de dar os primeiros passos porque a tarefa é árdua e demorada.
- Se a sua empresa tem que começar a emitir NFe em agosto, você está com a água na metade do peito.
- Agora, se estiver obrigado a emitir NFe partir de abril e você não tiver começado o trabalho, então já está numa situação em que precisa dar pulos para respirar. É muito provável que você não consiga produzir uma solução a tempo.
Acredite meu caro, desenvolver um aplicativo de suporte para a NFe foi uma dor de cabeça imensa para mim. Se eu tivesse cabelos eles teriam ficado brancos. E isso que eu não tinha prazo, estava apenas testando um componente activex.
As tecnologias envolvidas no projeto da NFe não faziam parte do meu dia-a-dia. XMLDsig, SOAP, webservice e C14n são termos comuns do vocabulário de um estudante de Ciências da Computação, mas eu sou um mero "fuçador". Já estava desistindo quando encontrei um componente que fazia toda a parte de criação, assinatura e envio dos pacotes. Achei ques estava salvo, mas aí começaram problemas que, de início, considerei meros detalhes.
Para ajudar os amigos, compilei essa pequena lista de dificuldades e soluções que compartilho agora com vocês.
E-CNPJ A1 OU A3?
Como o componente que eu estava testando só aceitava A1 não precisei fazer essa escolha, mas você pode ter que decidir. Nesse caso considere o seguinte:
- quando bem manuseado, o certificado A1 é tão seguro quanto o A3, com as vantagens de ser mais barato e muito mais rápido. Por "bem manuseado" entenda: instalado no menor número possível de equipamentos, todos com acesso restrito e protegido por senha de verdade ("123456" ou "senha" não servem);
- o certificado A3 armazena a chave criptográfica em hardware (cartão) que impede a cópia. Se usar um A3 ele precisará ficar conectado à máquina que emitirá as NFe.
- o A1 têm validade de um ano, o A3 vale por 3 anos.
CÓDIGOS DE MUNICÍPIOS E UF DO IBGE
Acredito que o desenvolvedor vai encontrar problemas na hora de converter os dados dos municípios nos cadastros de fornecedores e clientes. Mesmo entre os órgão públicos não há consenso quanto à padronização dos códigos de municípios. Assim é que o código de uma cidade na Receita Federal é diferente do IBGE que é, obviamente, diferente do código criado pelo desenvolvedor em seu solitário recinto de trabalho.
Para unificar essas informações eu imaginei usar o CEP como "grude" entre as diferentes visões do município porque, muito provavelmente, essa informação estaria correta no banco de dados da empresa e não está tão sujeita a variações durante a digitação. No entanto, quando tentei achar uma tabela que transformasse o CEP em código IBGE, não encontrei nenhuma. Tive, então, que improvisar uma tabela usando os dados do CEP e dos municipios usada pela Receita Federal em seus programas e ligar com a tabela do IBGE que se encontra no endereço ftp://geoftp.ibge.gov.br/Organizacao/Divisao_Territorial/2006/DTB_2006.zip.
Ficou mais ou menos assim:
- o CEP da tabela da Receita liga-se ao Código TOM, também da Receita, para obter o nome da cidade;
- com o nome da cidade acha-se o código do município e da UF na tabela do IBGE.
Essa abordagem tem algumas falhas porque há casos em que o nome do município é grafado de forma diferente nas tabelas do IBGE e da Receita e, em outros casos, mais de uma cidade possui o mesmo nome. De qualquer forma economizou muito tempo de digitação. Sugiro uma conferida na tabela antes de "se jogar do avião". Não fiz essa conferência porque sou muito preguiçoso e desatento.
Uma cópia da tabela de conversão está anexada a esse artigo, façam bom proveito dela e, por favor, divulguem qualquer melhoria que fizerem ou falha que encontrarem.
Atenção: os municípios maiores têm "faixas de CEP", nesse caso deve-se verificar se o CEP do banco de dados esta "ENTRE" <fxInicialCEP> E <fxFinalCep>.
DADOS INCOMPLETOS, INCORRETOS OU INEXISTENTES
No caso de dados incompletos, incorretos ou inexistentes há pouco a fazer além de "meter a mão na massa". As SEFAZ vão exigir que os dados de seus cadastros batam com os dados recebidos e você não pode esperar para acertar isso na hora em que as mercadorias estão saindo.
Aos sortudos que não estão obrigados a iniciar a entrega da NFe em abril ou agosto de 2008 há a opção de aguardar que as SEFAZ implementem o web service de "consultaCadastro", previsto no manual de integração. Esse webservice permite buscar os dados existentes nos bancos de dados oficiais para atualizar o cadastro local. Testei um componente ActiveX muito interessante que faz essa consulta ao cadastro, verifica se a NFe é "quente" e ainda permite gerar comandos SQL para inserção dos dados da NFe. Quando tiver um OK do desenvolvedor eu publico o nome do componente.
Na falta de solução melhor, o guia para o trabalho de correção dos cadastros é o Manual de Integração que pode ser baixado de http://www.nfe.fazenda.gov.br/portal/integracao.aspx. Mãos à obra.
XML GERADO COM ERROS
Assim funciona a NFe no mundo real. Se você transmitir uma NFe para a SEFAZ receberá, após alguns segundos, um XML contendo o diagnóstico do processamento dessa NFe. Se houver algum erro nos formatos dos campos ou na estrutura do XML você receberá a informativa mensagem "Falha no Schema", nada mais.... nem uma dica de onde está o problema... nem uma mensagem de boa sorte na procura, nada.
Se você está trabalhando na geração do XML precisa de uma forma de validá-lo, de preferência sem precisar comprar um aplicativo completo de NFe para isso. Para esses casos eu criei um APL. Chamo de APL porque APLICATIVO seria um nome muito grande para a simplicidade do código ("MORT, ED MORT... está na tabuleta").
A operação é bem simples:
1 - carregue o arquivo XML que contém a NFe;
2 - escolha o Schema que será usado para validar;
3 - defina se o arquivo da NFe será validado com assinatura ou não;
4 - clique em [Validar NFe].
A mensagem de erro, se houver, será mostrada no campo abaixo do código da NFe.
Você pode fazer as alterações diretamente no campo de código da NFe e validar novamente até descobrir qual o erro.
Os erros mais comuns envolvem formatos incorretos (pattern constraint failed. The element: "{http://www.portalfiscal.inf.br/nfe}xxx" has an invalid value according to its data type) e tags faltando, sobrando ou fora de ordem (Element content is invalid according to the DTD/Schema.
Expecting: {http://www.portalfiscal.inf.br/nfe}xEnder).
Mais uma coisa: lembre-se que o XML é "case sensitive", isso vai evitar muitas horas de trabalho.
O projeto do APL em VB6 e os arquivos XSD usados na validação da NFe estão disponíveis no anexo, fiquem a vontade para melhorá-lo ou incluí-lo em seu próprios projetos. Eu anexei também um executável para facilitar. Os arquivos XSD atualizados podem ser baixados do endereço http://www.nfe.fazenda.gov.br/portal/schemas.aspx.
BUSCANDO AJUDA
Se você conta com a ajuda dos órgão públicos envolvidos na NFe para criar seu aplicativo é bom arranjar uma cadeira confortável. A burocracia e a má-vontade são dificuldades quase tão grandes quanto a complexidade da NFe em si.
Fora do eixo JAVA - .NET há pouca coisa disponível sobre assinaturas digitais, SOAP e webservices. Se você programa em VB ou Delphi encontrará uns poucos componentes comerciais que facilitam muito o desenvolvimento. Em outras linguagens o suporte é quase zero.
Considere a possibilidade de contratar um serviço de emissão de NFe ou adquirir software pronto se perceber que o tempo é insuficiente. É fácil convencer a diretoria mostrando o quanto se economiza em pré-impressos e burocracia. Na verdade, a experiência tem mostrado que os projetos com NFe são auto-sustentáveis e chegam a gerar economias substanciais com o passar do tempo.
COMECE LOGO
Não importa se a sua empresa ainda não está entre as obrigadas a emitir NFe nos próximos mêses, é uma questão de tempo até que ela seja gentilmente coagida a adotar essa tecnologia, não só pelos governos, mas pelos clientes também. Os seus clientes vão querer importar informações das centenas de itens de notas fiscais diretamente para seus bancos de dados, sem digitação e sem erros.
Além disso você deve lembrar que uma fração substancial do processo não está sob o seu controle. Você depende de autorizações, de documentação, de bênçãos e de certificados digitais e isso leva tempo.
A implementação da NFe começou e não vai retroceder, isso é certo. Melhor abraçar logo o problema e transformá-lo em oportunidade.
Baixe aqui os arquivos.
CAROS.... BOA SORTE E BONS NEGÓCIOS.
qto3010@hotmail.com
- Se a sua empresa exerce um atividade que não tem previsão de obrigatoriedade de emissão de NFe, está na hora de dar os primeiros passos porque a tarefa é árdua e demorada.
- Se a sua empresa tem que começar a emitir NFe em agosto, você está com a água na metade do peito.
- Agora, se estiver obrigado a emitir NFe partir de abril e você não tiver começado o trabalho, então já está numa situação em que precisa dar pulos para respirar. É muito provável que você não consiga produzir uma solução a tempo.
Acredite meu caro, desenvolver um aplicativo de suporte para a NFe foi uma dor de cabeça imensa para mim. Se eu tivesse cabelos eles teriam ficado brancos. E isso que eu não tinha prazo, estava apenas testando um componente activex.
As tecnologias envolvidas no projeto da NFe não faziam parte do meu dia-a-dia. XMLDsig, SOAP, webservice e C14n são termos comuns do vocabulário de um estudante de Ciências da Computação, mas eu sou um mero "fuçador". Já estava desistindo quando encontrei um componente que fazia toda a parte de criação, assinatura e envio dos pacotes. Achei ques estava salvo, mas aí começaram problemas que, de início, considerei meros detalhes.
Para ajudar os amigos, compilei essa pequena lista de dificuldades e soluções que compartilho agora com vocês.
E-CNPJ A1 OU A3?
Como o componente que eu estava testando só aceitava A1 não precisei fazer essa escolha, mas você pode ter que decidir. Nesse caso considere o seguinte:
- quando bem manuseado, o certificado A1 é tão seguro quanto o A3, com as vantagens de ser mais barato e muito mais rápido. Por "bem manuseado" entenda: instalado no menor número possível de equipamentos, todos com acesso restrito e protegido por senha de verdade ("123456" ou "senha" não servem);
- o certificado A3 armazena a chave criptográfica em hardware (cartão) que impede a cópia. Se usar um A3 ele precisará ficar conectado à máquina que emitirá as NFe.
- o A1 têm validade de um ano, o A3 vale por 3 anos.
CÓDIGOS DE MUNICÍPIOS E UF DO IBGE
Acredito que o desenvolvedor vai encontrar problemas na hora de converter os dados dos municípios nos cadastros de fornecedores e clientes. Mesmo entre os órgão públicos não há consenso quanto à padronização dos códigos de municípios. Assim é que o código de uma cidade na Receita Federal é diferente do IBGE que é, obviamente, diferente do código criado pelo desenvolvedor em seu solitário recinto de trabalho.
Para unificar essas informações eu imaginei usar o CEP como "grude" entre as diferentes visões do município porque, muito provavelmente, essa informação estaria correta no banco de dados da empresa e não está tão sujeita a variações durante a digitação. No entanto, quando tentei achar uma tabela que transformasse o CEP em código IBGE, não encontrei nenhuma. Tive, então, que improvisar uma tabela usando os dados do CEP e dos municipios usada pela Receita Federal em seus programas e ligar com a tabela do IBGE que se encontra no endereço ftp://geoftp.ibge.gov.br/Organizacao/Divisao_Territorial/2006/DTB_2006.zip.
Ficou mais ou menos assim:
- o CEP da tabela da Receita liga-se ao Código TOM, também da Receita, para obter o nome da cidade;
- com o nome da cidade acha-se o código do município e da UF na tabela do IBGE.
Essa abordagem tem algumas falhas porque há casos em que o nome do município é grafado de forma diferente nas tabelas do IBGE e da Receita e, em outros casos, mais de uma cidade possui o mesmo nome. De qualquer forma economizou muito tempo de digitação. Sugiro uma conferida na tabela antes de "se jogar do avião". Não fiz essa conferência porque sou muito preguiçoso e desatento.
Uma cópia da tabela de conversão está anexada a esse artigo, façam bom proveito dela e, por favor, divulguem qualquer melhoria que fizerem ou falha que encontrarem.
Atenção: os municípios maiores têm "faixas de CEP", nesse caso deve-se verificar se o CEP do banco de dados esta "ENTRE" <fxInicialCEP> E <fxFinalCep>.
DADOS INCOMPLETOS, INCORRETOS OU INEXISTENTES
No caso de dados incompletos, incorretos ou inexistentes há pouco a fazer além de "meter a mão na massa". As SEFAZ vão exigir que os dados de seus cadastros batam com os dados recebidos e você não pode esperar para acertar isso na hora em que as mercadorias estão saindo.
Aos sortudos que não estão obrigados a iniciar a entrega da NFe em abril ou agosto de 2008 há a opção de aguardar que as SEFAZ implementem o web service de "consultaCadastro", previsto no manual de integração. Esse webservice permite buscar os dados existentes nos bancos de dados oficiais para atualizar o cadastro local. Testei um componente ActiveX muito interessante que faz essa consulta ao cadastro, verifica se a NFe é "quente" e ainda permite gerar comandos SQL para inserção dos dados da NFe. Quando tiver um OK do desenvolvedor eu publico o nome do componente.
Na falta de solução melhor, o guia para o trabalho de correção dos cadastros é o Manual de Integração que pode ser baixado de http://www.nfe.fazenda.gov.br/portal/integracao.aspx. Mãos à obra.
XML GERADO COM ERROS
Assim funciona a NFe no mundo real. Se você transmitir uma NFe para a SEFAZ receberá, após alguns segundos, um XML contendo o diagnóstico do processamento dessa NFe. Se houver algum erro nos formatos dos campos ou na estrutura do XML você receberá a informativa mensagem "Falha no Schema", nada mais.... nem uma dica de onde está o problema... nem uma mensagem de boa sorte na procura, nada.
Se você está trabalhando na geração do XML precisa de uma forma de validá-lo, de preferência sem precisar comprar um aplicativo completo de NFe para isso. Para esses casos eu criei um APL. Chamo de APL porque APLICATIVO seria um nome muito grande para a simplicidade do código ("MORT, ED MORT... está na tabuleta").
A operação é bem simples:
1 - carregue o arquivo XML que contém a NFe;
2 - escolha o Schema que será usado para validar;
3 - defina se o arquivo da NFe será validado com assinatura ou não;
4 - clique em [Validar NFe].
A mensagem de erro, se houver, será mostrada no campo abaixo do código da NFe.
Você pode fazer as alterações diretamente no campo de código da NFe e validar novamente até descobrir qual o erro.
Os erros mais comuns envolvem formatos incorretos (pattern constraint failed. The element: "{http://www.portalfiscal.inf.br/nfe}xxx" has an invalid value according to its data type) e tags faltando, sobrando ou fora de ordem (Element content is invalid according to the DTD/Schema.
Expecting: {http://www.portalfiscal.inf.br/nfe}xEnder).
Mais uma coisa: lembre-se que o XML é "case sensitive", isso vai evitar muitas horas de trabalho.
O projeto do APL em VB6 e os arquivos XSD usados na validação da NFe estão disponíveis no anexo, fiquem a vontade para melhorá-lo ou incluí-lo em seu próprios projetos. Eu anexei também um executável para facilitar. Os arquivos XSD atualizados podem ser baixados do endereço http://www.nfe.fazenda.gov.br/portal/schemas.aspx.
BUSCANDO AJUDA
Se você conta com a ajuda dos órgão públicos envolvidos na NFe para criar seu aplicativo é bom arranjar uma cadeira confortável. A burocracia e a má-vontade são dificuldades quase tão grandes quanto a complexidade da NFe em si.
Fora do eixo JAVA - .NET há pouca coisa disponível sobre assinaturas digitais, SOAP e webservices. Se você programa em VB ou Delphi encontrará uns poucos componentes comerciais que facilitam muito o desenvolvimento. Em outras linguagens o suporte é quase zero.
Considere a possibilidade de contratar um serviço de emissão de NFe ou adquirir software pronto se perceber que o tempo é insuficiente. É fácil convencer a diretoria mostrando o quanto se economiza em pré-impressos e burocracia. Na verdade, a experiência tem mostrado que os projetos com NFe são auto-sustentáveis e chegam a gerar economias substanciais com o passar do tempo.
COMECE LOGO
Não importa se a sua empresa ainda não está entre as obrigadas a emitir NFe nos próximos mêses, é uma questão de tempo até que ela seja gentilmente coagida a adotar essa tecnologia, não só pelos governos, mas pelos clientes também. Os seus clientes vão querer importar informações das centenas de itens de notas fiscais diretamente para seus bancos de dados, sem digitação e sem erros.
Além disso você deve lembrar que uma fração substancial do processo não está sob o seu controle. Você depende de autorizações, de documentação, de bênçãos e de certificados digitais e isso leva tempo.
A implementação da NFe começou e não vai retroceder, isso é certo. Melhor abraçar logo o problema e transformá-lo em oportunidade.
Baixe aqui os arquivos.
CAROS.... BOA SORTE E BONS NEGÓCIOS.
qto3010@hotmail.com
