Gabriel Frones

Pratic, quanto a esta última mensagem, você está informando a data de emissão? E outra pergunta: você está usando a versão 2.0 da NFe? Na 3.10, o campo mudou para dhEmi (não no ACBr... no ACBr continua dEmi). Se puder enviar o trecho de código que gera sua NFe, ajuda.

Colega, use o método chamado ImprimirInutilizacao.

Felipe, no command line, é só fazer "svn up -r numero_da_revisao". No Tortoise eu não sei te dizer. Mas acho que amanhã pela manhã a correção já estará disponível no SVN.

Essa alteração quebra a leitura do arquivo TXT, que depende dessa linha para identificar a versão do arquivo importado. Para resolver, sugiro alterar em pcnNFeRTXT.pas: Remover este bloco (essa parte depende do versao¨ que estava no pcnLayoutTXT): if ID = 'A' then begin NFe.infNFe.Versao := LerCampo(tcDe2, 'versao'); end; E colocar essas linhas para ler a versão (as duas últimas. As duas primeiras são só pra localizar no código): // Ler chave da NFe NFe.infNFe.ID := copy(FconteudoArquivo[1], 8, maxInt); //Preenche número da versão NFe.infNFe.Versao := StrToFloat(StringReplace('0' + versao, '.', DecimalSeparator, []));

Felipe, Uma alteração no SVN, na revisão 8877 fez com que a leitura de TXT deixasse de reconhecer a versão do arquivo, o que quebrou tudo. Para resolver agora, faz um svn up -r 8876. Eu vou verificar o porque da alteração 8877 e corrigir. Editado: Segue tópico com a alteração que foi feita e uma sugestão de correção:

Felipe, A data de emissão está saindo em branco. Você está preenchendo a data? Pode mostrar o código que está gerando e validando a nota?

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.

Pode enviar um exemplo do código que você está usando para gerar / enviar essas NFe's? A tag enderEmit.fone não está aparecendo corretamente também. Seu ACBr está atualizado? A assinatura do documento é um hash no final que garante a autenticidade do documento. Se uma vírgula for alterada no documento, a assinatura torna-se inválida.

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).