suporteagro

Segue arquivo em anexo. Extraído da pasta ACBr\Fontes\ACBrDFe\ACBrNFe\PCNNFe Att., Gabriel Toledo pcnEnvEventoNFe.pas

Boa tarde, Estou tendo este mesmo problema e acabei de postar sobre esse assunto. Só depois vi sua mensagem. Dê uma olhada la que tem a solução: Att., Gabriel Toledo

Olá a todos, Recentemente comecei a ter problemas de rejeição ao tentar fazer a manifestação do destinatário de uma nota fiscal eletrônica de produtor rural, recebendo o retorno com cStat=805, xMotivo=Rejeicao: CPF Emitente difere do CPF do Certificado Digital. Ao analisar a solicitação do evento (ped-eve.xml) gerado pelo ACBr, verifiquei que ao invés de conter a tag <CNPJ> havia a tag <CPF>, sendo que o conteúdo era na verdade o CNPJ da empresa mas com 11 dígitos. Fazendo o debug de EnviarEvento() identifiquei o seguinte trecho de código na função TEventoNFe.GerarXML da unit pcnEnvEventoNFe.pas: // Verifica a Série do Documento, caso esteja no intervalo de 910-969 // o emitente é pessoa fisica, logo na chave temos um CPF. Serie := ExtrairSerieChaveAcesso(Evento.Items[i].InfEvento.chNFe); if (Length(sDoc) = 14) and (Serie >= 910) and (Serie <= 969) then sDoc := Copy(sDoc, 4, 11); Ao comentar essas linhas e recompilar o projeto a manifestação é autorizada corretamente. Sendo assim, o trecho de código acima está alterando indevidamente o CNPJ para CPF nos eventos que envolvam nota fiscal emitida por pessoa física mesmo nos casos em que o solicitante do evento não seja o emissor da nota. Peço que analisem o caso e façam as devidas correções no código fonte. Atenciosamente, Gabriel Toledo

Sendo assim e tendo em vista os arquivos que você anexou, provavelmente a carteira correta é 04 e no seu sistema está configurado 01. Att., Gabriel Toledo

Boa tarde. Já tive esse problema. Peço desculpas pois não tenho certeza (já faz tempo) mas acho que foi com o Bradesco. Os boletos impressos via web tinham a carteira alterada e, consequentemente, a linha digitável também. Então, verifique com o Santander a carteira de cobrança do boleto. Att., Gabriel Toledo

Bom dia, Recentemente recebi um XML com a mesma característica: todas as tags possuíam o "xmlns". Assim o componente ACBr não conseguiu carregar o arquivo. Se alguém tiver uma sugestão para resolver o problema, agradeço. Att., Gabriel

Boa tarde a todos. Alguém poderia me informar se o problema deste tópico foi solucionado ? Acabei de atualizar para a última versão (12969), fiz um teste com uma nota válida e VerificarAssinatura retorna erro na validação. Obrigado. Gabriel

Boa tarde a todos, Após mais alguns testes, acredito fortemente que o problema esteja relacionado com a propriedade TACBrNFe.Configuracoes.Certificado.VerificarValidade. Descobri que quando ela é True meu sistema apresenta erro HTTP 0 mesmo com as DLLs 0.9.8.14. Modificando seu valor para False, o problema desapareceu. Hoje tive aproximadamente 200 notas faturadas e nenhum problema. Aproveito para reforçar os elogios feitos pelo Douglas. O ACBr sempre foi um ótimo projeto e me ajudou muito. Ainda estou me adaptando ao trunk2 mas gostei bastante das modificações. Meus agradecimentos a todos os colaboradores que dedicaram seu tempo para torná-lo possível. []'s Gabriel

Boa noite a todos, Após migrar do trunk para trunk2 meu sistema também começou a apresentar este erro (nunca havia acontecido em vários anos). Cheguei a migrar para Capicom mas não gostei. Hoje voltei para OpenSLL, troquei as DLLs pelos arquivos que estão no diretório DLLs\OpenSSL\0,9,8,14 e aparentemente resolveu o problema. Não tive mais nenhum erro HTTP: 0. Espero que também funcione com vocês. []'s Gabriel

Boa tarde a todos, Estou passando pelo mesmo problema e concordo que deve haver alguma falha na validação da SEFAZ. Consegui contornar a situação informando alguns campos zerados: <ICMS51> <orig>0</orig> <CST>51</CST> <modBC>0</modBC> <vBC>0.00</vBC> <vICMSOp>0.00</vICMSOp> <pDif>100.0000</pDif> <vICMSDif>0.00</vICMSDif> <vICMS>0.00</vICMS> </ICMS51> Para isso, fiz a atribuição de valores da seguinte forma: With Imposto do begin With ICMS do begin CST := cst51; pRedBC := 0.00001; pICMS := 0.00001; vBC := 0.001; vICMSOp := 0.001; pDif := 100; vICMSDif := 0.001; VICMS := 0.001; end ; end ; Gabriel

Olá, Rômulo, já testei com Windows XP (SP3) e também com Windows 7 e o problema é o mesmo. Angelo, não testei no demo do ACBr mas em ambiente de homologação está funcionando normalmente. Em ambiente de produção até o Emissor Gratuito está dando o mesmo erro. Att., Gabriel

Olá a todos, Continuo sem conseguir emitir carta de correção pelo mesmo motivo (999). E a Fazenda/SP continua incapaz de dar uma explicação coerente. Se alguém de SP tiver alguma informação, por favor compartilhe. Obrigado, Gabriel

Rômulo, Aqui eu utilizo: ACBrNFe1.EnviarEventoNFe(Lote); O arquivo de retorno fica salvo em ACBrNFe1.Configuracoes.Geral.PathSalvar com o nome -ProcEventoNFe.xml Verifique se seu componente ACBr está atualizado. Att., Gabriel

Rômulo, Verifique como está o seu ACBrNFe1.Configuracoes.Arquivos.PathSalvar Att., Gabriel

Olá Rômulo, Estou usando o ACBr sem qualquer alteração. Por curiosidade, instalei o Emissor da Nota Fiscal Eletrônica fornecido gratuitamente e tentei emitir a carta de correção mas tive a mesma resposta de erro. A Fazenda/SP alegou problemas de timeout, depois disse que estava solucionado mas a falha continua.