Gabriel Frones

Colegas Dante e Tiago, vejam o primeiro post deste tópico. Nele eu falo sobre essas e outras correções necessárias ao ACBr para gerar um txt que o emissor da NFe importe. Tem também 3 arquivos anexos com todas as correções que eu identifiquei. Essas correções entrarão no repositório oficial assim que a receita soltar o manual do TXT corrigido (www.emissornfe.fazenda.sp.gov.br/manuais_v310.html). Abraços, Gabriel.

Talvez um pouco fora de tópico, mas eu não acho que qualquer empresa que não tenha IE se encaixe como "contribuinte isento de inscrição". Acho que depende de uma análise, e algumas empresas (prestadores de serviço de informática, por exemplo?) serão enquadradas como "não contribuintes", assim como as pessoas físicas. Do RICMS/SP: "Artigo 9º - Contribuinte do imposto é qualquer pessoa, natural ou jurídica, que de modo habitual ou em volume que caracterize intuito comercial, realize operações relativas à circulação de mercadorias ou preste serviços de transporte interestadual ou intermunicipal ou de comunicação (Lei 6.374/89, art. 7º, na redação da Lei 9.399/96, art. 1°, III). Artigo 10 - É também contribuinte a pessoa natural ou jurídica que, mesmo sem habitualidade ou intuito comercial (Lei 6.374/89, art. 7º, parágrafo único, na redação das Leis 9.399/96, art.1º, III, e 11.001/01, art. 1º,IX): (Redação dada ao "caput" e ao inciso I, mantido os demais incisos, pelo Decreto 46.529 de 04-02-2002; DOE 05-02-2002; efeitos a partir de 22-12-2001) I - importe mercadoria ou bem do exterior, qualquer que seja a sua finalidade (Lei 6.374/89, art. 7º, parágrafo único, 1, na redação da Lei 11.001/01, art. 1º, IX); Artigo 10 - É também contribuinte a pessoa natural ou jurídica que, mesmo sem habitualidade (Lei 6.374/89, art. 7º, na redação da Lei 9.399/96, art 7º, III): I - importe mercadorias do exterior, ainda que as destine a consumo ou ao ativo permanente do estabelecimento; II - seja destinatária de serviço prestado no exterior ou cuja prestação se tenha iniciado no exterior; III - adquira, em licitação, mercadoria ou bem importados do exterior e apreendidos ou abandonados; IV - adquira energia elétrica ou petróleo, inclusive lubrificantes e combustíveis líqüidos ou gasosos dele derivados, oriundos de outro Estado, quando não destinados à comercialização ou à industrialização. V - administre ou seja sócia de fato de sociedade empresarial constituída por interpostas pessoas (Lei 6.374/89, art. 7º, na redação da Lei 13.918/09, art.12, I). (Inciso acrescentado pelo Decreto 55.437, de 17-02-2010; DOE 18-02-2010; Efeitos a partir de 23-12-2009)" Aqui na empresa, eu deixei essa informação como parametrizável pelo setor de contabilidade.

Colega, Mas veja o tópico linkado pelo colega Leandro. O manual do txt da receita ainda tem outras incompatibilidades com o emissor.

Colegas, O manual para o layout do arquivo TXT: http://www.emissornfe.fazenda.sp.gov.br/manuais_v310.html O erro que o colega citou é neste manual, do arquivo TXT. Tem outros também.

Colegas, Atualizei todos os arquivos que tinha alterado e inclui um novo. Estão anexos no primeiro post. Uma observação importante: a receita corrigiu a validação do emissor de acordo com o manual no caso da inversão de UF e xMun na transportadora (X03). Leandro, eu dei uma olhada nas suas alterações. Acho que todas elas estão contempladas agora nos arquivos que eu upei. Eu fiz alguns testes e me parece que a minha alteração não interfere nas demais versões da NFe, mas acho que a sua vai interferir sim, porque você altera a ID de alguns grupos no NFeW.pas (observe que sempre que uma ID mudou eu coloquei um IIF, para não quebrar as versões anteriores da NFe). Por favor, faça alguns testes com os arquivos que eu coloquei no primeiro post e me diga se está funcionando pra você. Acho que vamos conseguir colaborar melhor se mantivermos uma versão apenas das alterações (eu não marquei com comentários onde alterei, mas acho que isso pode ser suprido facilmente com uma ferramenta de diff - o próprio svn/git, provavelmente já serve). Abraços, Gabriel.

Leandro, Não há problemas para o gerador do XML ao se alterar o pcnLayoutTXT.pas. Só precisa tomar algum cuidado com as alterações em pcnNFeW. Essa sim pode influenciar na geração do XML. Eu tentei ter esse cuidado nas alterações que fiz, anexadas no post inicial. E respondendo ao colega Guilherme, eu não olhei ainda as alterações que o Leandro fez, mas já fiz diversos testes com as alterações que anexei no post inicial. Estão funcionando em todos os casos que eu uso aqui na empresa. Tem apenas uma alteração que preciso fazer para gerar os campos BA13 e BA14, que já percebi que o problema que eu tinha levantado no item 2 do post inicial não é tão grave, já que o gerador só preenche campos no contexto do grupo que ele está trabalhando, então a alteração é simples. Assim que tiver um tempo (acho que só amanhã =/) vou dar uma olhada nas alterações do Leandro, nas últimas alterações do SVN e atualizar meus anexos do post inicial.

Amigo, se eu entendi bem, você está procurando pelo comando raise: try ACBrNFe1.EnviarEventoNFe(1); ... except //faz o tratamento necessário. raise; end; Apenas observando que isso vai lançar o exception novamente, e portanto, não vai executar o código que vier depois.

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.