dalpiaze

Blz, Daniel, Então está explicado... por isso funcionava assim no trunk1... OK, então vou aguardar a alteração... Muito obrigado.

Pessoal, fiz o seguinte teste, apenas para deixar aqui registrado: Envio o XML, que é autorizado pela SEFAZ, blz.. aí faço o seguinte: Nota.GerarXML; //que inclui a tag protNFe Nota.Assinar; //que incluir novamente a assinatura ConteudoXML := Nota.XML; Aí blz, nesse caso fica correto, ou seja, o xml fica assinado e com a tag protNFe. Porém é claro, imagino que não se deva fazer isso pois assim estou forçando assinar a nota novamente, o que acho que não seria interessante uma vez que a SEFAZ já possui um XML assinado o qual deveria ficar intacto... Certo? O que me dizem?

Ítalo, bom dia, Exato, aí que eu queria chegar... Concordo com o ajuste que deveria ser feito! Porém, mesmo assim, fiz o teste aqui chamando manualmente a função GerarXML antes de salvar, para que seja incluída a tag "protNFe". Nesse caso, blz, a tag é incluída na propriedade ACBrNFe.NotasFiscais.Items[n].XML, porém ela perde a Assinatura...

Daniel, bom dia, Os fontes estão atualizados... verifiquei o código da função de GravarXML - ok ela realmente não re-gera o xml.. porém mesmo assim ele é salvo sem o "protNFe"... Mas de qualquer forma não uso essa função.. faço a leitura da propriedade "XML" no NFe diretamente para salvar em banco de dados, o qual também está vindo sem o protNFe. Acabei de verificar que isso está ocorrendo também no MDF-e.. mesmo caso.. não consegui testar ainda no CT-e para saber se também ocorre.

Como utilizo a gravação do XML direto em Banco de Dados, utilizo estou lendo a propriedade XML do objeto NotaFiscal: ConteudoXML := ACBrNFe.NotasFiscais.Items[0].XML; Tentei pegar a propriedade "XMLAssinado" também, mas não possui a tag procNFe tambem. Tentei também utilizar a função de GravarXML (que salva em arquivo) apenas para testar - nessa função ele re-gera o XML, onde a tag procNFe é incluída, porém a assinatura é perdida do xml...

Blz Régyz, obrigado pelo rápido retorno! Porém atualizei os fontes agora e mesmo assim continua ocorrendo o mesmo.

Pessoal, boa noite. Estou fazendo as adaptações de nosso sistema com o novo padrão do Trunk2, onde utilizamos NF-e, CT-e e MDF-e. Até o momento ocorreu tudo certo. Todas as adaptações realizadas e 3 módulos funcionando gerando os xmls, enviando, autorizando... ok O único porém que encontrei foi no ACBrNFe: Antes, ao autorizar uma nfe, quando eu salvava o XML dessa nota já autorizada, sempre já ficava incluso junto no próprio xml a tag "protNFe", onde estão os dados de autorização de uso. O caso é que no Trunk2 parece que algo diferente não está fazendo com que isso fique desta maneira. O que acontece é que: envio o xml, ele é autorizado, as propriedades estão preenchidas internamente no objeto do "protNFe" no NFe, porém nada consta no arquivo XML salvo. Blz, eu verifiquei que se eu chamar a função "GerarXML", onde o XML é gerado novamente, essa tag é inclusa. Ótimo, porém quando rodo essa função ocorrem 2 problemas: 1. A assinatura do arquivo é perdida, ou seja, é incluída a tag protNFe, porém fica sem a assinatura. 2. Como o XML é re-gerado, não seria uma rotina segura a se executar depois de autorizar o XML, já que por algum motivo desconhecido, alguma vírgula poderia ser alterada e o XML seria reconstruído e assinado novamente, e então incluída a tag protNFe, onde então acreditaríamos estar tudo certo, porém nesse caso haveria o risco de xml não ser o mesmo que a SEFAZ tem. O que deveria ocorrer de fato é o XML que estava gerado original apenas ter a tag protNFe inclusa, correto?! Acredito que era assim que ocorria anteriormente no trunk1, o que me dizem? Obrigado desde já pelo auxílio.

Italo, bom dia, Blz, ficou 100%. Mais uma vez muito obrigado!

Italo, boa tarde, Seria possível acrescentar um IF na rotina de Salvar o XML da nota quando é efetuada a consulta de Distribuição de Documentos em ACBrNFeWebServices (function TDistribuicaoDFe.TratarResposta). ? Pois está sempre salvando o xml independente da propriedade Geral.Salvar estar False. Veja como está agora: for I := 0 to FretDistDFeInt.docZip.Count - 1 do begin AXML := FretDistDFeInt.docZip.Items[I].XML; NomeArq := ''; if (AXML <> '') then begin case FretDistDFeInt.docZip.Items[I].schema of tsresNFe: NomeArq := FretDistDFeInt.docZip.Items[I].resNFe.chNFe + '-resNFe.xml'; tsresEvento: NomeArq := OnlyNumber(TpEventoToStr(FretDistDFeInt.docZip.Items[I].resEvento.tpEvento) + FretDistDFeInt.docZip.Items[I].resEvento.chNFe + Format('%.2d', [FretDistDFeInt.docZip.Items[I].resEvento.nSeqEvento])) + '-resEventoNFe.xml'; tsprocNFe: NomeArq := FretDistDFeInt.docZip.Items[I].resNFe.chNFe + '-nfe.xml'; tsprocEventoNFe: NomeArq := OnlyNumber(FretDistDFeInt.docZip.Items[I].procEvento.Id) + '-procEventoNFe.xml'; end; if NomeArq <> '' then FConfiguracoes.Geral.Save(NomeArq, AXML, GerarPathDistribuicao); // <-------------------------- **** end; end; Obrigado.

Italo, bom dia, Blz, funcionou 100%... Mais uma vez muito obrigado!

Segue um xml de exemplo na versão 3.10: teste310.xml

Estou com o mesmo problema aqui. Verificando agora seu tópico, parece que o problema está realmente na unit pcnNFeR na leitura da versão do xml. No meu caso também é lida a versão como 2.00 sempre que executo um LoadFromFile, onde o xml é gerado novamente. Tópico:

Acredito ser o mesmo caso que está ocorrendo aqui também. Porém no meu caso, não ocorre erro na leitura do campo, mas sim um XML da versão 3.10 é lido como versão 2.00, acredito pelo fato de falhar nesse momento do carregamento do campo "versão", então fica o valor padrão que é "2.00" Tópico:

Se for o mesmo caso que está ocorrendo aqui, é quando carrega um arquivo XML da versão 3.10, a versão é lida como 2.00... Tópico:

Italo, boa noite, Nesta ultima versão do SVN 8867 começou a acontecer o seguinte: - Ao efetuar o LoadFromFile no componente ACBrNFe de um XML gerado na versão 3.10 do Layout, esse layout é trocado diretamente para versão 2.00. Fiz o seguinte teste básico: Tendo um XML gerado na versão 3.10 salvo em uma pasta, criei uma aplicação em branco apenas colocando um componente ACBrNFe e colocando o código: ACBrNFe1.NotasFiscais.LoadFromFile('teste310.xml'); Caption := ACBrNFe1.NotasFiscais[0].NFe.infNFe.VersaoStr; O retorno da versão é lido como versao="2.00" Isso também esté gerando problemas em outros momentos, como por exemplo o fato de trocar a configuração do componente para Versao=ve200 (como sabemos já, no ACBrNFe, ao abrir um XML da versão 2.00 por exemplo, é setado essa versão nas configurações, porém o XML que estou abrindo é da versão 3.10). Conforme outros posts, parece que o problema está na leitura da versão do xml na unit pcnNFeR no método LerXML. Poderia verificar para nós? Obrigado.

Bom dia pessoal, Gostaria de sugerir uma alteração no ACBrNFe e aos demais (ACBrCTe, ACBrMDFe...) que possuem essa mesma situação: No componente ACBrNFe, temos uma propriedade Configuracoes.Geral.PathSalvar Essa configuração é setada padrão o diretório corrente, que fica a pasta Bin do Delphi. Se eu quiser deixá-la em branco, por exemplo, ele volta a setar essa mesma pasta. Logicamente, essa pasta é setada pela minha aplicação em tempo de execução, conforme o programa está instalado no cliente. Por isso não faz muito sentido eu deixá-la definida fixa em tempo de design. O problema relacionado a isso é que: quando eu abro o projeto, ele tenta sempre criar essa pasta se ela não existir. Por isso se eu deixar lá gravado, por exemplo: c:\teste, cada vez que eu abro o projeto no Delphi, ele cria essa pasta desnecessariamente. Pelo que vi nos fontes, isso ocorre na verdade pela unit da DANFe (ACBrNFeDANFeClass): function TACBrNFeDANFEClass.GetPathArquivos: String; begin if DFeUtil.EstaVazio(FPathArquivos) then if Assigned(FACBrNFe) then FPathArquivos := TACBrNFe(FACBrNFe).Configuracoes.Geral.PathSalvar; if DFeUtil.NaoEstaVazio(FPathArquivos) then if not DirectoryExists(FPathArquivos) then ForceDirectories(FPathArquivos); Result := PathWithDelim(FPathArquivos); end; Acredito então que para evitar essa questão de ficar criando a pasta, poderia colocar um if not DesignTime... para que crie a pasta somente quando em execução. Porém, na verdade acho que o mais correto seria permitir que deixasse em branco essa propriedade diretamente no componente principal (no caso o ACBrNFe), pois se vou definí-la em tempo de execução, não deveria ficar outra pasta sem sentido gravada nessa propriedade. OBS: Percebi isso pois agora que troquei do XE5 para o XE6, todos os meus componentes do ACBr estão com esse valor padrão gravado no projeto como "C:\XE5\Bin", que era a pasta onde estava o XE5. Agora, como essa pasta não existe mais, cada vez que abro o projeto, ele cria automaticamente (ForceDirectories) as pastas C:\XE5\bin... Desde já obrigado.

Pessoal, boa tarde, Estava acompanhando aí, pois uso o Rave Code Base e sempre precisava ir nos fontes e descomentar a linha do Collate. Estou usando a versão Rave 11.0.6 Testei agora aqui e funcionou... ficou show... agora com a diretiva, vem sempre habilitado por padrão o Collate. Blz Muito obrigado.

Italo, bom dia, Perfeito, funcionou! Muito obrigado pela atenção. Até.

OK, segue arquivo XML de retorno para NF-e autorizada normal (WS Paraná envio sincrono) 2-pro-lot.xml (Nesse caso o tratamento do componente ocorre normal sem problemas por causa da sub-tag com os dados protNFe)...

Segue arquivo XML do Retorno do WS do Paraná (envio SINCRONO)... 1-pro-lot.xml

Ítalo, bom dia, Acho que descobri o que é... Parece que o WS do Paraná, diferente dos outros WS, quando o Lote/Nota é rejeitado por algum erro, não retorna cStat=104 (Lote Processado), como por exemplo no WS do RS. Assim, estou enviando NF-e para o WS do Paraná que está com rejeição 231(erro de inscrição estadual). O retorno do cStat=231 é diretamente na primeira tag onde para os outros ws retorna 104. No código da unit pcnRetConsSitNFe.pas é que ocorre o problema: (Veja que na função, se cStat=104 então ele lê os retornos para protNFe, mas no caso do WS do Paraná, cStat está 231 por exemplo, aí o protNFe fica todo em branco) function TRetConsSitNFe.LerXml: Boolean; var ok: Boolean; i: Integer; begin Result := False; try if leitor.rExtrai(1, 'retConsSitNFe') <> '' then begin (*ER03 *)FtpAmb := StrToTpAmb(ok, leitor.rCampo(tcStr, 'tpAmb')); (*ER04 *)FverAplic := leitor.rCampo(tcStr, 'verAplic'); // Consta no Retorno da NFC-e (*ER04a*)FnRec := leitor.rCampo(tcStr, 'nRec'); (*ER05 *)FcStat := leitor.rCampo(tcInt, 'cStat'); (*ER06 *)FxMotivo := leitor.rCampo(tcStr, 'xMotivo'); (*ER07 *)FcUF := leitor.rCampo(tcInt, 'cUF'); (*ER07a*)FdhRecbto := leitor.rCampo(tcDatHor, 'dhRecbto'); (*ER07b*)FchNFe := leitor.rCampo(tcStr, 'chNFe'); case FcStat of 100,101,104,110,150,151,155,301,302: begin if ((Leitor.rExtrai(1, 'protNFe') <> '') or (Leitor.rExtrai(1, 'infProt') <> '')) then begin protNFe.tpAmb := StrToTpAmb(ok, Leitor.rCampo(tcStr, 'tpAmb')); protNFe.verAplic := Leitor.rCampo(tcStr, 'verAplic'); protNFe.chNFe := Leitor.rCampo(tcStr, 'chNFe'); protNFe.dhRecbto := Leitor.rCampo(tcDatHor, 'dhRecbto'); protNFe.nProt := Leitor.rCampo(tcStr, 'nProt'); protNFe.digVal := Leitor.rCampo(tcStr, 'digVal'); protNFe.cStat := Leitor.rCampo(tcInt, 'cStat'); protNFe.xMotivo := Leitor.rCampo(tcStr, 'xMotivo'); end; end; end; if FcStat in [101,151,155] then begin if Leitor.rExtrai(1, 'infCanc') <> '' then begin retCancNFe.tpAmb := StrToTpAmb(ok, Leitor.rCampo(tcStr, 'tpAmb')); retCancNFe.verAplic := Leitor.rCampo(tcStr, 'verAplic'); retCancNFe.cStat := Leitor.rCampo(tcInt, 'cStat'); retCancNFe.xMotivo := Leitor.rCampo(tcStr, 'xMotivo'); retCancNFe.cUF := Leitor.rCampo(tcInt, 'cUF'); retCancNFe.chNFe := Leitor.rCampo(tcStr, 'chNFe'); retCancNFe.dhRecbto := Leitor.rCampo(tcDatHor, 'dhRecbto'); retCancNFe.nProt := Leitor.rCampo(tcStr, 'nProt'); end; end; {eventos_juaumkiko} if Assigned(procEventoNFe) then procEventoNFe.Free; procEventoNFe := TRetEventoNFeCollection.Create(Self); i:=0; while Leitor.rExtrai(1, 'procEventoNFe', '', i + 1) <> '' do begin procEventoNFe.Add; procEventoNFe.Items[i].RetEventoNFe.Leitor.Arquivo := Leitor.Grupo; procEventoNFe.Items[i].RetEventoNFe.XML := Leitor.Grupo; procEventoNFe.Items[i].RetEventoNFe.LerXml; inc(i); end; Result := True; end; except Result := False; end; end; Com isso, na função "function TNFeRecepcao.Executar: Boolean;" da unit ACBrNFeWebServices, a leitura desses valores fica toda em branco também: 2063: NFeRetornoSincrono.LerXml; TACBrNFe( FACBrNFe ).SetStatus( stIdle ); aMsg := 'Ambiente : '+TpAmbToStr(NFeRetornoSincrono.TpAmb)+LineBreak+ 'Versão Aplicativo : '+NFeRetornoSincrono.verAplic+LineBreak+ 'Status Código : '+IntToStr(NFeRetornoSincrono.protNFe.cStat)+LineBreak+ 'Status Descrição : '+NFeRetornoSincrono.protNFe.xMotivo+LineBreak+ 'UF : '+CodigoParaUF(NFeRetornoSincrono.cUF)+LineBreak+ 'dhRecbto : '+DateTimeToStr(NFeRetornoSincrono.dhRecbto)+LineBreak+ 'chNFe : '+NFeRetornoSincrono.chNfe+LineBreak; if FConfiguracoes.WebServices.Visualizar then ShowMessage(aMsg); if Assigned(TACBrNFe( FACBrNFe ).OnGerarLog) then TACBrNFe( FACBrNFe ).OnGerarLog(aMsg); FTpAmb := NFeRetornoSincrono.TpAmb; FverAplic := NFeRetornoSincrono.verAplic; // Consta no Retorno da NFC-e FRecibo := NFeRetornoSincrono.nRec; FcStat := NFeRetornoSincrono.protNFe.cStat; <--------- ******************************************* FcUF := NFeRetornoSincrono.cUF; FMsg := NFeRetornoSincrono.protNFe.xMotivo; <--------- ******************************************* FxMotivo := NFeRetornoSincrono.protNFe.xMotivo; <--------- ******************************************* chNFe := NFeRetornoSincrono.ProtNFe.chNFe; // Alterado por Augusto Fontana em 09/07/2014. // Verificar se a NF-e foi autorizada com sucesso Result := (NFeRetornoSincrono.cStat = 104) and (NFeRetornoSincrono.protNFe.cStat = 100); E por isso antes de sair da função de envio, cStat está = 0 e xMotivo/Msg = '' e então ocorre Raise em branco e não é possível obter os retornos dos erros... Penso que algum ajuste para quando UF do WS='PR'(41) em alguma dessas duas unit's.... Obrigado.

Isaias, acho que estamos com o mesmo problema, para o WS do Paraná (usando envio Síncrono). Veja meu tópico:

Italo, boa tarde, Está acontecendo algo que não consegui identificar o que é nos Fontes... Quando enviando NF-e tanto no Ambiente de Produção/Homologação para o WS do PARANÁ em modo SÍNCRONO, o Retorno do cStat do erro está vindo direto na variável onde deveria vir cStat=104, ocorrendo um RAISE antes de sair da Função ACBrNFe.Enviar. Fiz um DEBUG na unit ACBrNFeWebServices e identifiquei que o Retorno dentro do componente está vindo diferente quando usando o WS do Paraná. Fiz um teste usando o WS de Santa Catarina e funciona normal, veja: Linha 2095 (ACBrNFeWebServices.pas): Result := (NFeRetornoSincrono.cStat = 104) and (NFeRetornoSincrono.protNFe.cStat = 100); No teste para SC, o retorno é NFeRetornoSincrono.cStat = 104 e o NFeRetornoSincrono.protNFe.cStat é o retorno do erro ocorrido, ou então =100 quando nota autorizada. Porém no WS do Paraná, o Retorno do erro é diretamente no NFeRetornoSincrono.cStat (num teste que fiz com Inscrição Estadual em branco para Destinatário com IE, ocorre o erro 231 diretamente em NFeRetornoSincrono.cStat) Pelo que pude ver, o componente lê o cStat final da propriedade NFeRetornoSincrono.protNFe.cStat, porém no caso do WS do Paraná está vindo em branco (zero), e então ocorre um raise na função de enviar com a mensagem de erro em branco. No meu código, para enviar a nota faço o seguinte: ACBrNFe.Enviar('1', False{Imprimir}, True{Sincrono}); cStat := ACBrNFe.WebServices.Enviar.cStat; Já ocorre raise no comando Enviar com a mensagem de erro em branco (e o cStat nesse momento está zero). Desde já, obrigado.

Juliomar, ok, deu certo. Obrigado.

Pessoal, bom dia, Atualizei os fontes do ACBr agora, e depois de rebuild em tudo, agora está ocorrendo o seguinte erro ao abrir o Delphi: Parece algo relacionado ao FastReport... O que sugerem? Uso o Delphi XE5 com FastReport 4.15.10 Obrigado.