Gabriel Frones

Leandro, veja também: Tem algumas outras correções além das duas citadas por você.

O ACBr te permite gerar os arquivos no formato TXT a partir do componente TNFe. Você usa um código como esse: NFeW := TNFeW.Create(NFe); Try NFeW.Opcoes.GerarTXTSimultaneamente := True; NFeW.GerarXml; NFeW.Gerador.SalvarArquivo('C:\teste.txt', fgTXT); Finally NFeW.Free; End; E o arquivo sai pronto para ser importado no emissor (como você está usando a versão 3.10, veja este tópico: ) Abraços, Gabriel

Colega, Se eu entendi bem, você vai jogar como hora o horário da exportação do arquivo, certo? A princípio, acho que não tem problema, exceto pelo fato de que você não vai conseguir gerar o mesmo txt depois... você perde reprodutibilidade. Eu, pessoalmente, prefiro alterar os campos para timestamp, já que é uma modificação simples, que não vai precisar migrar dados nem nada do tipo. PS: Você está gerando o TXT na mão? Por que não usar o TNFe / TNFeW?

O post do André: Mas Juliomar, pra que serve o TXT se o emissor não vai importar? Digamos que a RFB leve meses para corrigir o manual. A NFe 3.10 já será obrigatória e o ACBr será incapaz de gerar um txt que funcione, mesmo que as correções já sejam conhecidas. Acho que não precisa engessar tanto. Pra mim já foi solicitado que sejam feitos testes com a 3.10, então no meu caso, não dá pra esperar a RFB corrigir (não estou cobrando nada, por favor não me entenda mal, mas veja a ótica dos usuários do ACBr... eu já alterei e estou usando).

Eu segui o manual do layout TXT exatamente, exceto nestes 3 casos, onde o manual está incorreto - vi um post do André afirmando isso em algum lugar, dizendo que a RFB já reconheceu que há alguns erros mais ainda não corrigiu:

Caros colegas, Eu não sei como o projeto ACBr gera os DANFe's, e estou um pouco apurado agora para procurar na base de código. Mas segue uma procedure que le um TObject e joga todas as suas propriedades (e até collections) dentro de variáveis do FastReport, usando o RTTI. Isso é útil para fazer um Danfe usando os nomes de propriedades do próprio TNFe. Exemplo: <NFe.infNFe.ID> Procedure GetVars(Vars: TfrxArray; AObject: TObject; Prefix: String); Var I, Count: Integer; PList: PPropList; Begin If Not Assigned(AObject) Then Exit; If AObject Is TCollection Then Begin Vars[Prefix + '.Count'] := TCollection(AObject).Count; For I := 0 To TCollection(AObject).Count - 1 Do GetVars(Vars, TCollection(AObject).Items[I], Prefix + '[' + IntToStr(I) + ']'); End; Count := GetPropList(AObject, PList); For I := 0 To Count - 1 Do Begin If PList^[I].PropType^.Kind = tkClass Then GetVars(Vars, GetObjectProp(AObject, PList^[I].Name), Prefix + '.' + PList^[I].Name) Else If PList^[I].PropType^.Kind = tkEnumeration Then Vars[Prefix + '.' + PList^[I].Name] := GetOrdProp(AObject, PList^[I].Name) Else Begin Case PList^[I].PropType^.Kind Of tkLString: Vars[Prefix + '.' + PList^[I].Name] := AnsiQuotedStr(GetStrProp(AObject, PList^[I].Name), ''''); tkInteger, tkFloat: Vars[Prefix + '.' + PList^[I].Name] := GetPropValue(AObject, PList^[I].Name); End; End; End; End; Var NFe: TNFe; Vars: TfrxArray; begin Vars := TfrxArray.Create; NFe := TNFe.Create; Try ... GetVars(Vars, NFe, 'NFe'); frxReport1.Variables.Assign(Vars); frxReport1.ShowReport; Finally NFe.Free; Vars.Free; End; end; Para acessar os itens de collections, tem que fazer algo assim em um MasterData (ou outra banda de dados): [Get('NFe.Det[' + IntToStr(<Line> - 1) + '].Prod.xProd')] E você pode colocar esse código no OnBeforePrint para definir o número correto de linhas do MasterData (defina como 1 inicialmente, para que ele seja impresso): MasterData1.RowCount := <NFe.Det.Count>; PS: Fiz usando a versão antiga do RTTI (pré-D2010) porque uso D7 e não faço idéia de como fica no Lazarus/FPC. Abraços, Gabriel.

Ok... mas qual o procedimento correto? Estava na 3a página já. Agora que você respondeu eu sei que já foi visto por alguém da equipe, então com certeza não "bumpo" mais. Me baseei no manual do layout TXT v3.1.0 (24/11/2014) e na NT 2013/005 v1.21 (Novembro 2014). Testei vários arquivos da versão 3.10 com o emissor gratuito da receita. Os campos que eu testei (que sairam corretamente no arquivo e foram lidos corretamente pelo emissor) estão marcados com //ok, conforme convenção já presente no arquivo. Alguns campos tive que ajustar em desacordo com o manual para que o emissor aceitasse o arquivo (veja no post inicial as observações). Obrigado e abraços.

bump

Colegas, fiz mais algumas pequenas atualizações no pcnLayoutTXT. Ia atualizar o post original, mas como já teve gente que baixou, decidi postar um novo.

Caros colegas, estou anexando os arquivos que alterei para fazer a geração dos arquivos TXT da NFe 3.10. Algumas notas importantes: 1) O manual do txt possui vários erros. Alguns deles: Não traz as tags pai, como "BA|" e "GA|", mas sem elas o emissor recusa o arquivo. Mostra o refCTe (B19) como filho do refNFP (B10), mas na verdade, ele é filho do NFref (B01). 2) Criei uma uma procedure gtEliminarRegistros no pcnGerador para eliminar os registros não utilizados (identica à rotina que já existia em gtAjustarRegistros) e alterei a wGrupo para realizar essa "limpeza" sempre que um grupo for fechado. Essa alteração é importante para evitar erros na geração de alguns registros (e.g., BA13/BA14, GA02/GA03). Apenas para deixar mais claro qual o erro que ocorre: With NFe.autXML.Add Do CNPJCPF := '00000000000000'; With NFe.autXML.Add Do CNPJCPF := '11111111111111'; With NFe.autXML.Add Do CNPJCPF := '11111111111'; With NFe.autXML.Add Do CNPJCPF := '22222222222222'; Esse código gera no TXT os seguintes registros: GA| GA02|00000000000000 GA03|11111111111 GA| GA02|11111111111111 GA03|11111111111 GA| GA02|22222222222222 GA03|11111111111 GA| GA02|22222222222222 3) Existem muitas situações que eu não testei. Eu mantive a convenção de comentar um //ok no final das linhas testadas. 4) A maior parte das correções aqui são consequência direta de erros no manual do TXT. A equipe do ACBr está dependendo de a receita liberar uma versão corrigida do manual para corrigir os fontes no SVN oficial. Além disso, como não sou da equipe, não posso garantir que os arquivos no SVN oficial serão exatamente esses que coloco aqui. Eles são apenas uma sugestão que funciona para mim e para alguns colegas que deram feedback. pcnGerador.pas pcnLayoutTXT.pas pcnNFeW.pas pcnNFeRTXT.pas

Colega, Isso resolveu o seu problema com o layout TXT da NFe 3.10? Usando a última atualização dos fontes (trunk apenas) e com essa sua correção, eu ainda tenho os seguintes problemas: - Não gera as tags iniciais, "NOTA FISCAL|1" e "A|3.10|NFexxx"; - Não gera a tag pai do BA02, "BA|"; //o manual não menciona a necessidade mas o emissor rejeita o arquivo - Não gera a tag pai do GA02, "GA|"; //o manual não menciona a necessidade mas o emissor rejeita o arquivo - O CNPJ que vem em GA02 é o mesmo do local de entrega (G02), e não o informado em autXML; - Gera as tags O10 e O11 simultaneamente quando tem IPI (elas são excludentes); - Gera UF e xMun invertidos em X03 (isso acho que está errado no manual do layout txt). Isso é uma análise preliminar de uma nota apenas que tive que corrigir para o emissor importar o TXT. Ainda falta verificar se todas as tags foram exportadas realmente. Eu estava trabalhando nessas correções, mas agora que vi que você parece não ter tido os mesmos problemas que eu, fiquei preocupado de estar trabalhando em fontes desatualizados.

Colegas, Percebi que a exportação do layout TXT do PCN para NFe 3.10 não está funcionando corretamente, então decidi tentar corrigir o problema. Esbarrei na seguinte dificuldade: As chaves O10 e O11 são excludentes. Uma ou a outra. No entanto, como ambas são classificadas como O07, ambas são geradas quando da geração das tags do IPI. LoadLayout('<O07> O07|CST¨|VIPI¨'); LoadLayout('<O07> O10|VBC¨|PIPI¨|VIPI¨'); LoadLayout('<O07> O11|QUnid¨|VUnid¨|VIPI¨'); Como a tag O07 também tem que ser gerada, a solução que encontrei foi duplicar a chave O07, uma na categoria )10 e outra na O11 (com as devidas alterações no pcnGerador). Ficou assim: LoadLayout('<O10> O07|CST¨|VIPI¨'); LoadLayout('<O10> O10|VBC¨|PIPI¨|VIPI¨'); LoadLayout('<O11> O07|CST¨|VIPI¨'); LoadLayout('<O11> O11|QUnid¨|VUnid¨|VIPI¨'); Minha dúvida é: Tem alguma maneira melhor de fazer? Ainda estou trabalhando nessa correção e assim que tiver algo pronto e testado eu anexo aqui no fórum para avaliação. PS: Sou só eu ou a rotina de exportação do TXT é muito mais complicada do que o necessário? rs. Lendo o código, fico com a impressão de que a ideia era ter a geração do TXT e do XML na mesma base de código. Mas talvez isso traga mais complicações do que vantagens. Abraços, Gabriel.

Colegas, Atualmente estou trabalhando com git e para minha conveniencia, criei um mirror do repositório do ACBr (apenas trunk) no GitHub. Estou postando aqui caso possa ser útil a outros na minha situação: https://github.com/GabrielF7/ACBr Esse repositório é atualizado automaticamente a cada hora por um script instalado em meu servidor de fontes, de forma que deve permanecer sempre razoavelmente atualizado.

Caros, Mil desculpas... aparentemente, fui eu mesmo que fiz essa modificação localmente. Está correto no SVN atualizado. Que coisa maluca. rs Abraços, Gabriel.

Caros, Vi que o mantis está offline devido a uma mudança de servidor, então estou postando aqui, porque senão vou esquecer depois. rs linha 115 de pcnRetCancNFe.pas: if cStat = [101,151,155] then Acho que a intenção era usar o "in" no lugar de "=". Abraços, Gabriel.

Colega, Eu sou o desenvolvedor da primeira versão do ACBrTER (possivelmente o único) e, mesmo eu, nunca tive a oportunidade de testar. Quando comecei o componente, eu já não estava mais em posse dos terminais (eram de um cliente). Nem mesmo sei se o componente funciona, pois nunca tive feedback. Eu fiz o componente baseado no código de um programa stand-alone que eu tinha desenvolvido para comunicação com os terminais. O programa é específico para o meu sistema, com a lógica deste, e usa a minha base de dados e até um componente que possivelmente eu sou um dos únicos no mundo que usa (THalcyonDataSet, para acesso a DBF). rs Mas, tirando a parte do banco de dados, o programa funciona bem e faz toda a comunicação essencial com os MicroTerminais Wilbor. Tenho duas versões do programa: uma TCP e outra Serial... a TCP é bem mais nova e o código deve ser bem mais organizado, embora não tenha comentários (nunca consegui pegar o hábito). Ainda assim, pode valer o esforço dar uma estudada no código... posso disponibilizar para você e para o projeto ACBr, caso alguém tenha condições de testar o componente e continuar o desenvolvimento.

Colega, Estou usando em SP... mas o projeto é de ambito nacional. Todas as UFs deveriam (eu acho) adotar as datas estabelecidas no manual de integração (data de inicio da vigencia no ambiente de produção: 01/04/2010, no manual 4.01-NT200906 - última versão)... ainda mais sendo uma diferença tão grande. Será que o erro não é outra coisa? Edit: Acabei de ver que a fazenda do PR, realmente, ainda não adotou a NFe 2.0 no ambiente de produção: http://www.fazenda.pr.gov.br/modules/no ... 00-da-NF-e Bom, mas acho que ir de NFe 2.0 para 1.0 não vai ser grande problema... em geral eu uso só o PCN (para geração do XML), e só o que tenho que fazer é mudar o schema. NFe 2.0 teve muita coisa adicionada (para optantes do simples), mas quase nada foi removido/alterado... então, acho que você pode tentar instalar os componentes da NFe 1.0 e tentar compilar, comentando as linhas que derem undeclared identifier. Em principio, acho que deve funcionar. PS: Se nós atrasamos quase um ano no prazo, não quero nem imaginar o que poderia acontecer... mas a fazenda do PR pode, né? rsrs

NFe 2.0 torna-se obrigatória a partir de abril/2011... mas você já pode usar no ambiente de produção desde abril/2010. Eu já estou usando. Abraços.

Colega, Veja esse post, e verifique se a solução sugerida resolve o seu problema: viewtopic.php?f=6&t=525

O ACBrNFe, até onde sei, é Delphi... para usar no VB6, você vai precisar usar o ACBrNFeMonitor, e comunicar-se com ele por uma das alternativas que ele oferece (arquivo texto e TCP, acredito). Tem um exemplo em CLIPPER no SVN: ACBr\Projetos\ACBrNFeMonitor\Exemplos\Clipper. Talvez mais instrutivo do que o exemplo, seja esse "tutorial" do projeto: http://acbr.sourceforge.net/drupal/?q=node/40 Abraços.

Colegas, Linha 122: I := RetornarPosEx('"', Leitor.Arquivo, I + 2); if I = 0 then raise Exception.Create('Não encontrei inicio do URI: aspas inicial'); Existe alguma razão para não haver suporte a XML's com aspas simples nos campos? Abraços.

Colegas, Linha 669 do arquivo Fontes\PCN2\pcnGerador.pas: Conteúdo atual: if StrToIntDef(Copy(ConteudoProcessado, pos(DecimalSeparator, ConteudoProcessado) + NumeroDecimais + 1, 6),0) > 0 then walerta(ID, Tag, Descricao, ERR_MSG_MAXIMO_DECIMAIS + ' ' + IntToStr(NumeroDecimais)); Problema: Quando o valor é inteiro, pos(DecimalSeparator,ConteudoProcessado) = 0, e dessa forma, o alerta é sempre gerado. Sugestão: Verificar diretamente na variável float valor se o número de casas decimais excede NumeroDecimais: if not SameValue(Abs(Frac(valor*Power(10,NumeroDecimais))), 0.0, {epsilon = }0.0000001) then walerta(ID, Tag, Descricao, ERR_MSG_MAXIMO_DECIMAIS + ' ' + IntToStr(NumeroDecimais)); Nota: Em tese, o valor de Abs(Frac(valor*Power(10,NumeroDecimais))) deveria ser exatamente igual a zero, caso não hajam mais casas decimais do que o esperado. Mas é sabido que comparações do tipo == com floats são problemáticas. Nota 2: Tem que adicionar a unit Math nos uses. Abraços.

Converter para XLS? Acho pouco provável que você consiga uma ferramenta para essa tarefa (menos provavel ainda que encontre um componente)... PDF e XLS são tipos de arquivo com propósitos totalmente distintos. Nem dá para fazer uma ferramenta que faça conversão de qualquer PDF para um XLS.

Você pode: - Copiar a função do ACBr (na unit ACBrNFeNotasFiscais.pas) e fazer as modificações necessarias; - Enviar por Indy, com um dos milhares de exemplos que existem por aí; ou - Criar uma nova função utilizando a Synapse (biblioteca leve, que o ACBr usa). Os servidores do GMail são SMTP, normal. Abraços.

As grandes empresas devolvem mercadoria quando ainda não tem XML.... costuma evitar reincidencias. rs