Exportação em XML

[João P. Vanzuita]

Pessoal,

estou trabalhando p/ que a exportação em XML funcione, há mais alguém trabalhando nisso ?

Estou com duas dúvidas:

quanto a chave de acesso, alguém sabe onde há documentação com a especificação ?

quanto aos elementos sem valor, ele deve ser mostrados ou omitidos ?

[Fabio Negrini]

Eu fiz boa parte da adaptação para XML e me deparei com um grande problema: Assinatura digital.

Essa informação não existe ainda e por isso não é possível exporta na íntegra a NFe para XML. Outro bug que deixei pela metade foi o campo chave de acesso, está só com números mas tem que ser NFE0000000000...

Quanto aos valores, dependendo do campo deverá ser mostrado com 0,00, dependendo não deverá ser mostrado. Você poderá verificar estes detalhes no documento distribuído pela própria receita federal, segue abaixo o link:

https://www.fazenda.sp.gov.br/nfe/legislacao/manual_de_integracao_contribuinte_v202a.pdf

Att,

[crsilveira]

Vc chegou a ver o projeto PySped, parece que já faz o que vc precisa :

 https://github.com/aricaldeira/PySPED/tree/master/pysped/exemplos

Carlos

[Raphael Valyi]

Pessoal,

so para lembrar, assim que nos vemos existem varias opçoes de exportaçao das NFe's : pysped, pynef, acbr-monitor, dlls, emissor gratuito...

Infelizmente nhenum parece perfeito, nem o PySPED ou PyNFE...

Eu acho que no core desse projeto a gente tem que deixar as opçoes abertas. Tambem infelizmente algumas dessas opçoes sao fechadas. No caso, basta facilitar para produzir os arquivos a ser passado uma DLL ou um webservice, depois a DLL proprietaria ou o servicio web fara o servicio. E com tempo, ficara legal se aparece implementaçoes maduras com soluçoes abertas tipo ACBR-monitor ou PySPED/PyNFE ou outros.

Agora, voces podem ver pela experiença do Fabio Negrini: é bastante trabalhoso fazer algo maduro com essas soluçoes abertas. Eu fico feliz de ver gente trabalhando nisso, mas e bom ninguem se iludir e pensar que vai fazer algo perfeito em 30 horas de trabalho. E um ponto critico do ERP, se essa soluçao travar ou emitir errado a empresa ficaria muito na mao, entao nao vai bastar um proof of concept...

Agora, voces tem que ver que a situaçao atual nao é tao critica: o pessoal costume emitir as NFe's por lotes tipo no fim do dia. Entao, se perde 5 minutos sim, mas geralmente é uma vez no dia so, entao nao é tao absurdo quanto voces poderiam pensar se fosse para cada nota.

Finalmente, aqui a gente tb fez um prototipo de interface com um daquelas bibliotecas nao abertas. Mas bom, a biblioteca nao e aberta mesma, e isso nao é a gente que decide. Entao esse tipo de soluçao tem que exportar os arquivos mas nao importar nada do OpenERP, so se comunicar por arquivos para nao violar a licença AGPL do OpenERP.

Mas de qualquer forma, é claro, no longo prazo a gente queria ver aparecer uma soluçao totalmente aberta e vamos ajudar para isso.

Eu pessoalmente eu acho um absurdo incrivel que alguem decidiu essa norma de NFe tao complexa sem exigir que seja publicado pelo menos uma implementaçao de referencia livre. Se quisesse offerecer o monoplo desse mercado a uma meia duzia de editores proprietarios e fechar o mais possivel o mercado de soluçoes de gestoes de empresas, nao teria jeito melhor de se fazer...

Enfim, para facilitar essa transiçao para ter varias soluçoes de exportaçao direita incluindo algumas livres futuramente, eu tinha comaçado uma branch bem experimental com uma modularizaçao das "estrategias" de exportaçao:

teria que atualizar e testar esse prototipo e depois refazer um merge no trunk:

https://code.launchpad.net/~akretion-team/openerp.pt-br-localiz/nfe-multi-export

A idea e que como nehnuma soluçao de exportaçao é perfeita, o melhor é nao casar o projeto da localizaçao com nehnuma e deixar a possibilidade para modulos adicionais especializados de decidir como satisfazer essa burocratia.

No momento tou sem tempo para isso, mas sei la, ate Agosto eu pretendo trabalhar nisso.

Abraço.

-- 

Raphaël Valyi

Founder and consultant

http://twitter.com/rvalyi

+55 21 2516 2954

www.akretion.com

2012/7/7 crsilveira <crsil...@gmail.com>

[João P. Vanzuita]

Só p/ esclarecer o que estou fazendo, minha idéia é exportar o XML e usar o Uninfe (monitor NFe) p/ assinar, validar, etc. Se eu não exportar em TXT eu teria que chamar outro monitor NFe (acbr monitor) p/ converter o TXT p/ XML e depois manda-lo p/ o Uninfe.

Vejo que nosso cenário é o sonho e a realidade.

O sonho: módulo do oERP que faria a assinatura, validação, envio, envio do email, interface p/ gerenciar (verificar status, cancelamento, inutilização NFe, etc).

A realidade atual: exportar o XML e chamar um monitor NFe p/ fazer o gerenciamento.

--

Raphael, o q faz o nfe-multi-export ?

Fabio, eu estou imaginando que é só exportar o XML e usar outro programa p/ assinar, validar e emitir, estou errado ? Pelo que entendi só falta criar a chave de acesso e ajustar os campos que estão enviando os dados errado como no CNPJ estava indo formatado com . e / ,há campos que devem ser string e estavam indo como inteiro.

Alias, obrigado pelo trabalho, criar o método de exportação do zero daria muito trabalho.

[João P. Vanzuita]

Progressos!

Está exportando o XML sem erros, mas ainda tem alguns detalhes p/ ver.

* Quando é empresa do Simples, a nomenclatura de algumas tags são diferentes, como poderia verificar se a empresa é do Simples ?

* A chave da NFe que não estava criando corretamente ainda não tive tempo de ver.

A assinatura da NFe não vou implementar agora porque o Uninfe faz o trabalho, mas se alguém quiser um exemplo peguei esse em Java no GUJ http://paste2.org/p/2068058

Vejo que tem bastante gente interessada p/ trabalhar nessa implementação, podemos criar um branch ou uma lista separada p/ tratar do desenvolvimento, conversar, elaborar uma especificação, criar um roadmap, milestone, documentação, etc, o que acham ?

Se não for ruim p/ vocês, gostaria de criar um projeto novo no Github p/ usar o Git, não consigo me entender com o Bazaar (e é muito lento).

[Raphael Valyi]

2012/7/8 João P. Vanzuita <joaopaul...@gmail.com>

Progressos!

Está exportando o XML sem erros, mas ainda tem alguns detalhes p/ ver.

* Quando é empresa do Simples, a nomenclatura de algumas tags são diferentes, como poderia verificar se a empresa é do Simples ?

Tem como ver essa configuraçao no objeto res.company eu acho, talvez o Renato pode explicar melhor.

 

* A chave da NFe que não estava criando corretamente ainda não tive tempo de ver.

A assinatura da NFe não vou implementar agora porque o Uninfe faz o trabalho, mas se alguém quiser um exemplo peguei esse em Java no GUJ http://paste2.org/p/2068058

Vejo que tem bastante gente interessada p/ trabalhar nessa implementação, podemos criar um branch ou uma lista separada p/ tratar do desenvolvimento, conversar, elaborar uma especificação, criar um roadmap, milestone, documentação, etc, o que acham ?

Se não for ruim p/ vocês, gostaria de criar um projeto novo no Github p/ usar o Git, não consigo me entender com o Bazaar (e é muito lento).

Ola, pode sim. Mas eu imagino que teria que trabalhar um pouco naquela minha branch nfe-multi-export de forma que na verdade para isso vc nao precisa criar uma nova branch da localizaçao, mas apenas um modulo de extençao que vai exportar utilizando uma certa ferramenta (outros jeitos poderiam aparescer).

O lance do git é que claro ta muita melhor, mas mesmo se vc botar um modulo no git, vc ainda vai ter que pegar uns 500 pelo bzr, entao infelizmente isso nao resolve muito. Talvez para voce fica menos para aprender. Mas para os iniciantes que ja tem que encarar o bzr para se virar com o OpenERP, eles ainda vao ter que encarar o git. No final eu nao tenho certeza se simplifica muito a situaçao, mas enfim, se vc liderar esse modulo e utilizar o git/github, nao é a gente que vai reclamar (usamos tb em algumas ferramentas liagadas ao OpenERP, mas geralemente que nao sao modulos do OpenERP). Tb, para um so modulo, a velocidade do git nao vai fazer tanta diferença. E sobre botar todo OpenERP no git, é complicado, dificilmente vc continu capaz de integrar os patch bzr, ou contribuir de volta no projeto, alem disso eu acho que ultrapassa o espaço de graça no Github, enfim é um saco no momento...

Sobre especificaçoes e milestones, vc pode usar tento como quiser a infraestrutura do projeto Launchpad se quiser.

Abraço e parabens pelo trabalho.

[marcelo-bello]

João, só para constar, estou copiando abaixo um email que recebi de um cliente do segmento de calçados. Vejam que tem indústrias exigindo muito mais que uma nota fiscal, eles querem todas as informações corretamente parametrizadas no xml da nota. Sem contar que agora a Receita exige que todos os produtos que possuam código de barras EAN tenham o codigo EAN correspondente incluído no xml (por sorte ai da não há punição prevista para quem não inclui o EAN na nota, mas é questão de tempo até isso mudar).

Basicamente o que quero dizer com este email é que conseguir assinar e enviar o arquivo direto pra Receita será um passo importantíssimo (e suficiente para a maioria), mas há uma série de detalhes importantes que precisarão ser endereçados cedo ou tarde pelo oERP.

========
Prezado fornecedor,

Visando melhorar os nossos processos internos, através da leitura do código de barras do DANFE, solicitamos aos senhores:

1) Ordem de Compra No arquivo XML da Nota Fiscal, informar no campo (tag) " xPed" de cada item o número da Ordem de Compra correspondente; Para cada item informar somente uma Ordem de Compra.

2) Duplicatas Informar os dados da(s) duplicata(s) nos campos (tags) corretos e NÃO no quadro dos Dados Adicionais.

No campo "nDup" informar o número da duplicata. No campo "dVenc" informar o vencimento da duplicata. No campo "vDup" informar o valor da duplicata.

A NF-e permite informar n duplicatas.

Quando os dados das duplicatas são informados no quadro dos Dados Adicionais não é possível fazer a leitura automática.

Senhor fornecedor, se nos seus arquivos XML de NF-e, os campos citados acima já estão sendo preenchidos corretamente, então ignore este e-mail.

Atenciosamente, Departamento de compras Universo dakota

[Fabio Negrini]

Quanto à chave é só incluir a constante NFE antes dos 44 números. Vi isso depois de fazer o commit e não mexi mais.

[João P. Vanzuita]

Raphael, 

obrigado pelos esclarecimentos, com certeza vou olhar seu trabalho e ver como posso ajudar.

Marcelo,

esses ajustes são importantes, mas como estou com muita coisa p/ fazer aqui, infelizmente não vou poder implementa-las. Se você precisar de ajuda p/ implementar pode contar comigo. Ainda não consegui imprimir uma DANFE vinda do XML que estamos criando, talvez precise adicionar algumas tags referente ao valor da duplicata.

Fabio,

acabei refatorando a criação da chave porque a forma de cria-la mudou, adicionei também aquele cálculo do digito verificador seguindo a especificação.

Atualizei meu branch: http://bazaar.launchpad.net/~g-joao-p/openerp.pt-br-localiz/vanzuita/revision/333

ainda estou trabalhando nele, mas atualizei p/ que vocês que já trabalham a mais tempo com o oERP possam acompanhar como estou trabalhando e se eu fizer alguma lambança vocês podem me dar um red card rsrs.

A implementação referente aos descontos ainda não consegui testar e provavelmente vou tirar aquilo referente a precisão decimal pois é desnecessário. Fazendo o merge percebi também que assinei um método fora do padrão do projeto, próximo merge corrijo.

--

No momento estou tentando entender como assinar o XML com o Uninfe (monitor NFe) , com o ACBrNFeMonitor consegui assinar e validar usando aquela minha implementação por telnet, mas pelo Uninfe me retorna o mesmo erro que o site do SEFEZ RS retorna:

• The element 'NFe' in namespace 'http://www.portalfiscal.inf.br/nfe' has incomplete content. List of possible elements expected: 'Signature' in namespace 'http://www.w3.org/2000/09/xmldsig#'.

  Caminho: nfeProc/NFe[1]/
•  The element 'nfeProc' in namespace 'http://www.portalfiscal.inf.br/nfe' has incomplete content. List of possible elements expected: 'protNFe' in namespace 'http://www.portalfiscal.inf.br/nfe'.

  Caminho: nfeProc/

Meu arquivo XML: http://joao.toolshotel.com/tmp/nfe_239.xml

Pelo que entendi esse validador pede o XML assinado. Será que estou esquecendo de algo ? 

*No site do Uninfe diz que ele faz a assinatura.

Obrigado pelo apoio de vocês!

[Leonardo Santagada]

sobre o código, como eu faria a função de verificação de digitos: https://gist.github.com/3080729

[João P. Vanzuita]

Leonardo,

legal sua implementação, ficou mais elegante. 

Porem chamei nossas funções com a mesma chave e está retornando valores diferentes. Como meu conhecimento em python ainda não é tão avançado eu não entendi sua implementação, você teria como ver porque nossas funções estão retornando valores diferentes ?

[Leonardo Santagada]

Tu tem a definição dessa função de verificação? O que parece é que a tua esta calculando algo muito errado (acessando as listas usando como chave elementos da lista e fazendo um produto cartesiano com os 2 fors).

[João P. Vanzuita]

Tenho,

http://cl.ly/3g070p3n3N0l3l14092r

Retirado daqui: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=TIiR6jY8fsM=

[Leonardo Santagada]

então estão ambas muito erradas. eu penso nisso depois.

[Leonardo Santagada]

https://gist.github.com/3080729 pronto, testei com o caso de exemplo da receita '5206043300991100250655012000000780026730161' e funcionou... tem que ver outros casos de exemplo.

[João P. Vanzuita]

Maravilha Leonardo !

fiz outros 3 testes e está 100%.

[Luis Felipe Miléo]

>>> print a.nfe_digito_verificador('35110453939351[.....]21029900058')

9

>>> print a.nfe_digito_verificador('35110553939351[.....]781015017446')

1

>>> print a.nfe_digito_verificador('35110553939351[.....]3781015017446')

1

>>> print a.nfe_digito_verificador('35110553939351[.....]23861000005805')

1

>>> print a.nfe_digito_verificador('3511065393935[.....]1870700406')

9

>>> print a.nfe_digito_verificador('35110653939351[.....]51370050008')

5

Testado mais algumas x. 

To com tempo de sobra essa semana, hoje a noite vou me dar uma relida no tópico pra ajudar.

Ao meu ver um fluxo interessante seria....

Exportação XML/TXT -> Validação/Emissão/Danfe automática -> Anexar o Danfe e o XML na fatura no openERP e o envio para o cliente de forma automatica.

Abraços

--
Luis Felipe Sant' ana

+5512 8135-1450

+5511 3522-8530

Consultoria e Serviços em Tecnologia

[Leonardo Santagada]

só pra alertar, tem muito mais coisa nesse código que eu não gostei/parece errado.

[João P. Vanzuita]

qual código ? o meu ?

vamos lá arrumar, onde está errado ?

[Cloves Almeida]

Está correto. É uma implementação "estilo funcional" do algorítmo módulo 11 usado em quase tudo no governo (CPF, CNPJ, várias IE). Bem legal essa função 'cycle' que eu não conhecia.

Criei uma versão mais genérica, em que "peso" é variável e permite calcular o DV de um monte de coisas e a IE da maioria dos estados.

https://gist.github.com/3087725

[Leonardo Santagada]

cleanString deveria se chamar clean_string ou ainda melhor remove_pontuação.

O jeito de montar a nfe_key é diferente do resto do código (eu faria ele todo usando %s,%d que nem o resto. na verdade eu faria melhor, já consertando para no futuro arrumar todo aquele código:

reg_N10c = {

  'Orig': 'nacional',

  'CSOSN': '34234',

}

str_N10c = 'N10c|%(Orig)s|%(CSOSN)s' % reg_N10c

porque faz bem mais sentido do que como esta sendo feito, a nfe_key ficaria algo como:

nfe_key = {

  'IBGE': company_addr_default.state_id.ibge_code,

  'data': inv.date_invoice[2:4] + inv.date_invoice[5:7],

}

str_nfe_key = '%(IBGE)s%(data)s' % nfe_key

assim o código fica bem mais limpo.

até pensei em algo mais direto como:

str_nfe_key = '%(IBGE)s%(data)s' % {

  'IBGE': company_addr_default.state_id.ibge_code,

  'data': inv.date_invoice[2:4] + inv.date_invoice[5:7],

}

o que é mais compacto e fica numa ordem que faz mais sentido: quais dados são necessários e depois de onde eles vem. Até onde eu sei % tem zfill então dá pra fazer isso direto na string de formatação.

[Luis Felipe Miléo]

Em conversa com o João comecei a desenvolver um script XML-RPC para conectar a qualquer sevidor openERP e salvar o arquivo XML de exportação da NFE.

Tornando assim o processo de emissão da NF-e automatico, somente sendo necessário colocar a fatura no estado enviar para a RECEITA.

from xmlRPC import *

srv = openErpServer('xmlRPC','192.168.56.101:8069','senha')

uid = srv.common.login('treinamento','admin','senha')

datas = {'file_type': 'xml',

     'company_id': '1',

     'nfe_environment': '1',}

xml = srv.wizard.execute('treinamento',uid,'l10n_br_account.nfe_export', datas,'init','1')

Bom estou com erro na chamada do wizard...

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "xmlRPC.py", line 165, in execute

    return self.wizard.execute(dbname, uid, wiz_id, datas, action, context)

  File "/usr/lib/python2.7/xmlrpclib.py", line 1224, in __call__

    return self.__send(self.__name, args)

  File "/usr/lib/python2.7/xmlrpclib.py", line 1578, in __request

    verbose=self.__verbose

  File "/usr/lib/python2.7/xmlrpclib.py", line 1264, in request

    return self.single_request(host, handler, request_body, verbose)

  File "/usr/lib/python2.7/xmlrpclib.py", line 1297, in single_request

    return self.parse_response(response)

  File "/usr/lib/python2.7/xmlrpclib.py", line 1473, in parse_response

    return u.close()

  File "/usr/lib/python2.7/xmlrpclib.py", line 793, in close

    raise Fault(**self._stack[0])

xmlrpclib.Fault: <Fault AccessDenied: 'Access denied.'>

 

Vou continuar pesquisando e tentando, entretanto o material de acesso de wizards via xml-rpc não é dos melhores.

Se conseguir posto aqui.

Abraços

[Luis Felipe Miléo]

Deu certo,

Testes preliminares OK:

Como funciona:

O Script conecta no OpenERP via XML-RPC e baixa os arquivos TXT ou XML com nas nfes, salva na pasta, o UniNFE faz todo o resto automaticamente:

Autoriza, autentica, faz tudo e envia por email p/ o cliente.

Amanha eu continuo, 

Qualquer ideia ou sugestão são bem vindas, 

Abraços

[crsilveira]

Olá Luis Felipe,  no wizard vc conseguiu fazer funcionar  ?


Carlos

[Luis Felipe Miléo]

Cris pelo wizard eu não consegui, mas to chamando o metodo que o wizard chama, ta funcionando legal.

Não ta 100% finalizado, mas eu vou criar um respositorio no GIT só pra galera ter acesso ao codigo e ja posto aqui.

Abraços

[Luis Felipe Miléo]

https://github.com/mileo/openerp-rpc-nfe

Ta rolando, segue video em anexo.

O processo todo demora alguns segundos, tirando VM com 512 de ram + o gravador de video. Testem ai que da pra ter uma noção melhor

Ao clicar em confirmar, o script busca notas com o status 'Enviar para a Receita' e salva no diretório especifico.

Logo em seguida o UNINFE faz a parte dele validando a NFE e enviando o XML e o DANFE por email para o cliente.

O João ta fazendo um manual detalhado de como configurar o uninfe. 

Próximo passo é verificar o diretório com os retornos dos sefaz e tratar os arquivos XML. Vou dar um olhada nisso final de semana.

Com o UNINFE da pra, autorizar, criar cartas de correção, cancelar notas e etc.

Creio ser uma boa opção tratarmos as opções de gerenciamento das Notas fiscais para depois partirmos para o processo direto de transmissão.

Abraços

[João P. Vanzuita]

Parabéns Luis, muito legal !!

Vamo que vamo.

[Carlos]

Parabéns, ficou ótimo.

[Luis Felipe Miléo]

Scipt ta atualizado:

Atualiza o status da NFe no sistema:

 

Ainda estou com problemas ao mudar o status do workflow do sistema.

Mas devo resolver isso amanhã, e deixar ele melhor preparado para rodar direto.

Código atualizado no git 

https://github.com/mileo/openerp-rpc-nfe/blob/master/nfeRPC.py

Abraços