Gabriel Frones

Pra mim está funcionando com a última versão do trunk. Tem como você anexar o arquivo que você está lendo para ver se o problema não é nele?

Então mostra o código que você está usando para ler a NFe que tem algo errado com ele (ou com o ACBr ). A ideia é que o ACBr verifique a versão do XML e leia dEmi quando for versão 2 e dhEmi quando for versão 3.10... tem que ver se está funcionando. Pra mim está, mas eu tenho modificações locais que não foram pro repositório oficial, mas não lembro de ter mexido nessa parte não.

Italo, Uma sugestão: criar a propriedade dhEmi referenciando também a dEmi; property dEmi: TDateTime read FdEmi write FdEmi; property dhEmi: TDateTime read FdEmi write FdEmi; Assim, internamente a propriedade é uma só, mas tem o "alias" pra quem estiver seguindo o novo manual no seu programa.

Colega, do manual e da última NT que descreve o leiaute: "Informar somente os algarismos, sem os caracteres de formatação (ponto, barra, hífen, etc.)". Em qual NT você viu que ele pede a formatação? Eu imagino (não tenho como confirmar aqui) que o ACBr deva estar removendo a formatação do campo, devido a essa informação do manual.

Colega, seu item possui CST = 00. Consulte o manual da NFe (o último leiaute está na NT 005/2013), essa CST não suporta desoneração de ICMS. PS: Curiosidade, por que converter para string e depois para currency de volta?

Colegas, O problema descrito aqui: Não afeta vocês?

Colegas, precisei fazer uma cópia de uma instância de um TNFe e percebi que o método Assign não estava implementado. Deu um trabalhão (principalmente pro notepad++ que teve que executar vários regexes rs), mas eu implementei. Estou anexando aqui os arquivos alterados. Ainda pretendo implementar isso no TCTe futuramente. Seguem algumas observações importantes: A implementação das coleções (TCollection e TCollectionItem) estava com duas coisas estranhas que eu corrigi para ficar formalmente mais correto: O constructor do TCollectionItem não estava definido como um override do constructor base e não tinha parâmetros, de maneira que o item não tinha ciência de qual TCollection era seu Owner/Parent. Eu redefini os constructors como overrides, com o parâmetro Collection e chamando inherited no começo. A função Add da classe pai (TCollection) chamava o método create na instância já criada do TCollectionItem (Result.create;). Acho que isso foi a maneira que se encontrou de contornar os problemas decorrentes do equívoco acima. Eu usei os seguintes regexes nas propriedades published das classes para transformar a declaração da propriedade em uma cópia do seu valor: 'property ([\w]+): (Integer|String|TDateTime|Currency|Double|Tpcn).*write.*;' para '\1 := nomeclasse\(Source\)\.\1;' 'property ([\w]+): T.*;' para '\1.Assign\(nomeclasse\(Source\)\.\1\);' Como só precisa copiar as propriedades published, eu imaginei que isso poderia ser implementado de uma maneira mais simples por meio de RTTI. Mas como a própria Borland nunca fez nada do tipo, eu achei que seria muita ousadia minha. Além disso, eu não faço ideia de como funciona o RTTI no Lazarus/FPC. Preferi ser cauteloso e fazer a implementação no braço. Essas alterações trazem a necessidade de ser ter um cuidado ao alterar as classes da TNFe para fazer as alterações relevantes nos métodos Assign. Mas como as propriedades dessa classe só vão mudar quando a receita mudar o leiaute de novo, acho que isso não vai ser um trabalho muito árduo. E mesmo que por descuido sejam feitas alterações nas propriedades que se esqueça de fazer nos Assign's, o svn diff é nosso amigo. pcnNFe.pas pcnProcNFe.pas pcnSignature.pas

Caros, Percebi uma diferença de comportamento entre o ID do TNFe e do TCTe. Quando se le o arquivo XML por meio de TNFeR/TCTeR.LerXml, o ID fica preenchido sem o literal 'NFe', no caso de TNFe, mas com o literal 'CTe' no caso de TCTe. Os trechos de pcnNFeR/pcteCTeR relevantes são: NFe.infNFe.ID := copy(Leitor.Arquivo, I+1, J - (I+1)); NFe.infNFe.ID := StringReplace( UpperCase(NFe.infNFe.ID), 'NFE', '', [rfReplaceAll] ) ; CTe.infCTe.ID := copy(Leitor.Arquivo, I + 1, J - I -1); Então veja que o NFeR remove o literal, enquanto que o CTeR não remove. Eu acho que seria legal uniformizar, mas não sei qual alternativa é melhor, nem se o impacto da alteração não será grande demais para valer a pena. Meu palpite é manter o literal, uma vez que o manual da receita especifica que o campo possui o literal.

Pra ter duas NFe's no arquivo exportado... na verdade, eu fiquei com "preguiça" de preencher todos os campos de novo com dados diferentes, mas esse seria o ideal para o teste. rs PS: Alterei o arquivo do post inicial para usar um copy no lugar do StringReplace, igual estava na revisão 7482.

Juliomar, Na verdade, no exemplo que eu coloquei, eu carreguei 5 NFe's diferentes. Só que essa linha só deveria aparecer uma vez no arquivo todo (ela identifica justamente quantas NFe's seguem abaixo): NOTA FISCAL|5 Eu dei uma vasculhada pra tentar descobrir quando o problema começou. Acho que a última vez que a função SaveToTXT funcionou perfeitamente, foi na revisão 7482, de 22/09/2014. Nesse commit, o arquivo era preenchido assim: loSTR.Text := loSTR.Text + copy(ArqTXT,14,length(ArqTXT)); Então, esse copy já eliminava o "NOTA FISCAL|1" que tem em cada nota, e talvez seja uma solução melhor que o StringReplace que eu coloquei. Depois desse, o próximo commit que teve nessas linhas aí já quebraram a geração do TXT aqui nos meus testes. Abraços, Gabriel.

Colegas, Eu uso bastante os WS da Sefaz para consulta de situação e manifestação de documentos recebidos (NFe e CTe) e consulta de cadastros de entidades nos meus sistemas. Desde a semana do dia 23/03 a situação ficou caótica por aqui, e como nada mudou no meu sistema e os erros são intermitentes, acredito que seja problema na receita mesmo. Um detalhe é que meus usuários não têm relatado problemas com a autorização de notas, de maneira que talvez a instabilidade afete apenas os serviços síncronos.

João, Obrigado pelo seu feedback. Eu atualizei os 4 arquivos no post inicial para corrigir o problema da geração do XML. A alteração que tinha sido feita e que quebrou a geração do XML tinha a ver com a leitura do TXT, então tive que alterar outros arquivos para conseguir fazer a leitura sem depender dessa alteração. Quanto à sua primeira dificuldade, a da duplicação do cabeçalho quando se usa ACBrNFe, eu fiz um teste aqui usando a última versão do trunk e ela já ocorria. Então, como não tem relação com a NFe 3.10 em si, eu criei outro tópico: Por favor, verifique se tudo está funcionando pra você agora. Abraços, Gabriel.

Caros, Usando a última versão do trunk, quando chama ACBrNFe.NotasFiscais.SaveToTXT, o componente gera um arquivo com cabeçalho duplicado, como o exemplo abaixo: NOTA FISCAL|5 NOTA FISCAL|1 A|versao|NFe... ... NOTA FISCAL|1 A|versao|NFe... ... Segue uma sugestão de correção: function TNotasFiscais.SaveToTXT(PathArquivo: String): Boolean; var loSTR: TStringList; ArqXML, Alertas, ArqTXT : String; I: Integer; begin Result:=False; loSTR := TStringList.Create; try loSTR.Clear; for I := 0 to Self.Count - 1 do begin ArqTXT := Self.Items[I].GerarXML(ArqXML, Alertas, True); loSTR.Text := loSTR.Text + copy(ArqTXT,14,length(ArqTXT)); end; if loSTR.Count > 0 then begin loSTR.Insert(0,'NOTA FISCAL|'+IntToStr(Self.Count)); for I := loSTR.Count - 1 downTo 0 do begin if loSTR.Strings[I] = '' then loSTR.Delete(I); end; if DFeUtil.EstaVazio(PathArquivo) then PathArquivo := PathWithDelim(TACBrNFe( FACBrNFe ).Configuracoes.Geral.PathSalvar)+'NFe.TXT'; loSTR.SaveToFile(PathArquivo); Result:=True; end; finally loSTR.free; end; end; Essa correção faz os seguintes itens: Remove o cabeçalho NOTA FISCAL|1 que aparecem individualmente por nota, e que vem do TNFeW Adiciona os arquivos TXT por meio de loSTR.Text := loSTR.Text + ... ao invés de Add. Dessa maneira, cada linha do TXT estará em uma linha do arquivo de saída, o que é necessário para que possamos limpar as linhas em branco mais abaixo; Alterei o trecho que remove as linhas em branco para um for invertido (downTo), que acho que fica mais claro que o while que estava antes, e que cumpre a mesma função. O pas alterado segue anexo por conveniencia. Abraços, Gabriel. ACBrNFeNotasFiscais.pas

Você tem que especificar para o ACBr que você quer exportar o arquivo na versão 3.10. Acho que vai ser algo como: ACBrNFe.Configuracoes.Geral.VersaoDF := ve310 Ou: NFe.infNFe.Versao := 3.10; Além disso, como você está usando o txt, veja este tópico, que contem correções importantes no layout:

João e Claudemir, Tem outras correções também. Vejam este tópico, onde estou tentando centralizar essas correções: Abraços, Gabriel.

Colegas, Atualizei os anexos com a correção do Dante e algumas outras que identifiquei na leitura do TXT

Dante, entendi. Eu não uso a importação de TXT, então nem percebi. Vou incorporar suas alterações e atualizar os anexos no post inicial logo mais.

Sim. Estou usando em produção já desde quarta (18/03).

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.