alexcassol

Ok, obrigado.

Sim, eu entendo que ela precisa existir no Sefaz para cancelar, isso é lógico. Mas você concorda que o erro retornado para a minha aplicação não podia ser esse: ERRO: Falha na validacao dos dados do Evento: 1839 - Element '{http://www.portalfiscal.inf.br/nfe}nProt': [facet 'pattern'] The value '' is not accepted by the pattern '[0-9]{15}'. Mas sim algo como isso, para que eu possa tratar? Status Código: 217 Status Descrição: Rejeicao: NF-e nao consta na base de dados da SEFAZ

A nfce não está no Sefaz, este é o teste, cancelar uma nfce que não está no Sefaz.

Estou com problema no cancelamento de uma nfce em homologação. O meu teste consiste em cancelar uma nfce que não está no Sefaz. NFe.CancelarNFe("43200203495483000130650020000248259042931827", "Desistencia do cliente","03495483000130") ERRO: Falha na validacao dos dados do Evento: 1839 - Element '{http://www.portalfiscal.inf.br/nfe}nProt': [facet 'pattern'] The value '' is not accepted by the pattern '[0-9]{15}'. Já atualizei o ACBrMonitorPlus para a versão 1.3.0.268 (x86). Pelo log dá pra notar que a resposta retorna corretamente, mas mesmo assim o erro acima ocorre. Inicio TNFeConsulta Versão Layout: 4.00 Identificador: 43200203495483000130650020000248259042931827 Ambiente: 2 Versão Aplicativo: RSnfce201809061124 Status Código: 217 Status Descrição: Rejeicao: NF-e nao consta na base de dados da SEFAZ UF: RS Chave Acesso: 43200203495483000130650020000248259042931827 Recebimento: 30/12/1899 00:00:00 Protocolo: Digest Value: logs.zip

Funcionou o instalador da versão 32 bits corretamente, vou utilizar essa a partir de agora.

Perdão, verifiquei aqui que não altero o xml, na verdade incremento o número da nota e chamo novamente o CriarNFe para gerar um novo xml. Aquele que foi gerado anteriormente vou cancelar ou inutilizar caso entre em contingência. Vou testar a instalação 32 bits primeiro.

Daniel, Altero somente quando coloco em contingência. Não usei o CriarEnviarNFe porque esses dois comandos me atendem e não tem nada no help que diga que foram descontinuados, já utilizo a mais de ano e não me deram problema. José, Vou verificar as tags, mas de qualquer forma funcionou atualizando a versão para a 1.2.0.84, pois a versão 1.3 (x86 e x64) em alguns casos está ocorrendo erro na abertura do ACBRMonitorPlus após a instalação. Estou anexando o XML com problema e a imagem do erro de instalação da versão 1.3 (não sei se não seria outro tópico). 43191007132271000140650020001604711992904061-nfe.xml

Estou com esse problema de rejeição e não consegui identificar o motivo, pois não tem caracteres estranhos ou espaços nas tags. O erro ocorre algumas vezes, e me parece que sempre com o mesmo produto "AGUA 500ML". O estranho é que a maioria das vezes consigo vender esse produto normalmente. Estou anexando os logs do ACBR Monitor Plus. Versão do ACBR: 1.2.0.46. logs.zip

Funcionou, obrigado. [DistribuicaoDFe] CStat=138 CUF=0 DhRecbto=30/12/1899 Msg=Documento(s) localizado(s) VerAplic=1.2.0 Versao=1.01 XMotivo=Documento(s) localizado(s) arquivo=6106xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx477810001-resEventoNFe.xml dhResp=24/04/2019 17:14:59 indCont=0 maxNSU=000000000012361 tpAmb=1 ultNSU=000000000011012

Bom dia, Testei com a versão 1.2.0.46 e funcionou normalmente. Seguem os logs. logs-vr-46.zip

Segue. logs.zip

Não retorna em nenhum momento, mesmo passando um NSU. 22/04/2019 11:42:41 - NFe.DistribuicaoDFe("AN", "101xxxxxxxx157", 10992, , "") 22/04/2019 11:42:49 - OK: [DistribuicaoDFe] CStat=138 CUF=0 DhRecbto=30/12/1899 Msg= VerAplic=1.2.0 Versao=1.01 XMotivo=Documento(s) localizado(s) arquivo=43190156xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx170-nfe.xml dhResp=22/04/2019 11:42:37 indCont=0 maxNSU=000000000012276 tpAmb=1 ultNSU=

Sim, estou passando 0 porque é a primeira consulta, depois eu guardo no banco de dados o último NSU e uso ele.

Boa tarde, Mas passei como parâmetro o ambiente nacional e também o valor 0 para o último nsu, ou seja, quero que traga tudo do ambiente nacional. O comando DistribuicaoDFePorUltNSU não retorna, apesar de ter os mesmos parâmetros do comando DistribuicaoDFe.

A Distribuição DFe parou de funcionar no ACBrMonitorPlus na versão que estou utilizando 1.2.0.55. Ou também posso estar fazendo algo errado. Ao executar o comando "NFe.DistribuicaoDFePorUltNSU("AN", "101xxxxxxxx157", 0)" retorna que não tem documento localizado, abaixo a consulta. NFe.DistribuicaoDFePorUltNSU("AN", "101xxxxxxxx157", 0) OK: [DistribuicaoDFe] CStat=137 CUF=0 DhRecbto=30/12/1899 Msg= VerAplic=1.2.0 Versao=1.01 XMotivo=Nenhum documento localizado arquivo=43190xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx44170-nfe.xml dhResp=22/04/2019 11:11:12 indCont=1 maxNSU=000000000012276 tpAmb=1 ultNSU= Mas se executo a consulta com o comando "NFe.DistribuicaoDFe("AN", "101xxxxxxxx157", 0, , "")" retornam os documentos normalmente. NFe.DistribuicaoDFe("AN", "101xxxxxxxx157", 0, , "") OK: [DistribuicaoDFe] CStat=138 CUF=0 DhRecbto=30/12/1899 Msg= VerAplic=1.2.0 Versao=1.01 XMotivo=Documento(s) localizado(s) arquivo=43190100131299xxxxxxxxxxxxxxxxxxxxxxx1029014-resNFe.xml dhResp=22/04/2019 11:24:53 indCont=0 maxNSU=000000000012276 tpAmb=1 ultNSU= Então tenho duas questões: Devo usar o comando NFe.DistribuicaoDFe ou NFe.DistribuicaoDFePorUltNSU ? Mesmo o comando NFe.DistribuicaoDFe trazendo os documentos, o campo "ultNSU" vem sempre vazio, fazendo com que eu tenha que pegar o maior NSU da primeira consulta e utilizando este como parâmetro pra próxima.

Ok, obrigado a todos pelos esclarecimentos!

Fiz um teste agora alterando a leitura do certificado de Capicom para o OpenSSL, com o arquivo pfx mesmo , e funcionou normalmente!! O que não entendo é que isso vai contra qualquer orientação que se vê no fórum, inclusive relatos de lentidão usando o OpenSSL.

Eu realmente não sei como vocês iriam reproduzir o problema, pois ele acontece em alguns clientes como mencionei antes. Sendo que nesse, dos 3 pdvs, somente 1 tem o problema. Qualquer operação que envolva enviar algo pro Sefaz está lento, como enviar a NFCe, Cancelamento. Forcei a contingência e tudo funciona normalmente. Tenho um programa que roda numa outra thread e fica enviando esses arquivos em contingência, e a demora é a mesma. Vou anexar os logs do ACBR Monitor e o INI de configuração. Fiz um outro teste ontem, peguei um dos arquivos que gerei em contingência e fui no ACBR Monitor e Enviei, sem envolver nenhum programa meu, e mesmo assim ficou lento. logs acbr.zip ACBrMonitor.ini

Não resolveu, aparentemente ficou até mais lento.

Não foi resolvido após apagar os arquivos. Quanto ao erro do cancelamento ok, eu sabia que ia dar, mas o problema não é esse e sim o tempo entre enviar o evento e esperar uma resposta, note que foram 1min e 13s nesse processo. Fiz testes de venda e continua o problema.

Tentei enviar um cancelamento e ocorre o mesmo problema. 13/09/2018 17:16:34 - NFe.CancelarNFe("43180904064099000123450040000424891725379765", "Desistencia do cliente","01111199000146") 13/09/2018 17:17:47 - OK: Rejeicao: Duplicidade de Evento

1 - Eu sempre desabilito, só comentei porque já passei por esse problema no inínio. 2 - Na pasta Logs haviam 32 mil arquivos, então apaguei e recriei 3 - Eu utilizo TCP/IP 4 - Consultei o status e retornou o 404, utilizando a versão 3.10 Depois alterei a versão para 4.0 e ele consultou, como pode ser visto no "log_comp.txt" 13/09/2018 17:01:34 - EACBrDFeException - WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. Erro Interno: 0 Erro HTTP: 404 URL: https://nfe.sefazrs.rs.gov.br/ws/NfeStatusServico/NfeStatusServico2.asmx 13/09/2018 17:01:34 - WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. Erro Interno: 0 Erro HTTP: 404 URL: https://nfe.sefazrs.rs.gov.br/ws/NfeStatusServico/NfeStatusServico2.asmx Log_comp.txt Inicio TNFeEnvEvento Inicio TNFeStatusServico ERRO: WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. Erro Interno: 0 Erro HTTP: 404 URL: https://nfe.sefazrs.rs.gov.br/ws/NfeStatusServico/NfeStatusServico2.asmx Inicio TNFeStatusServico Versão Layout: 4.00 Ambiente: 1 Versão Aplicativo: RS201805211008 Status Código: 107 Status Descrição: Servico em Operacao UF: RS Recebimento: 13/09/2018 17:09:38 Tempo Médio: 1 Retorno: Observação: ACBrMonitor.ini

Tenho num cliente 3 pdvs com o ACBrMonitorPlus, e em somente 1 pdv começou uma demora de mais de 30s para enviar uma nfce. Ontem estava normal, mas hoje este cliente (e outros) começaram a relatar essa lentidão. Verifiquei no log.txt e, como pode ser visto, demorou 35s entre enviar e receber a resposta. Tenho casos de 1 minuto. 13/09/2018 13:07:46 - NFe.EnviarNFe("C:\ACBrMonitorPLUS\Logs\43180992797950000107650030000633649031693650-nfe.xml",0,1,0,,0) 13/09/2018 13:08:21 - OK: Lote recebido com sucesso A configuração do INI é a mesma em todos os pdvs e os outros dois demoram nem 2s para enviar. A versão da nfce é a 3.10 e o sistema está instalado no RS. Não está ativo "Exibir linhas do log...", o certificado está instalado "libCapicom". Existe algum outro log mais detalhado do comando "NFe.EnviarNFe"? O que poderia causar essa lentidão?

Funcionou para mim, obrigado!

Baixei novamente as dlls, mas acho que nada tinha sido alterado pois as datas eram as mesmas. Bom, consegui resolver utilizando a ferramenta Fuslogvw.exe (Assembly Binding Log Viewer) que vem com o .Net. Neste link mostra onde ela se encontra: http://stackoverflow.com/questions/1674279/cant-locate-fuslogvw-exe-on-my-machine Pelo log que ele gerou, vi que estava utilizando o .Net 4.0 ao invés do 3.5, como pode ser visto na linha "Assembly manager loaded from". Note também que no final do log existem duas versões: a 0.9.2.8 (Provavelmente a que compilei e instalada no .Net 4.0) e a 0.9.2.7 (a correta). *** Assembly Binder Log Entry (15/3/2013 @ 13:51:01) *** The operation failed. Bind result: hr = 0x80131040. No description available. Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\clr.dll Running under executable c:\minha_DLL\MeuTeste.exe --- A detailed error log follows. === Pre-bind state information === LOG: User = PC-01\USER LOG: DisplayName = ACBrFramework.Net, Version=0.9.2.8, Culture=neutral, PublicKeyToken=4ca716d5e1bd4ba3 (Fully-specified) LOG: Appbase = file:///C:/minha_DLL/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = MeuTeste.exe Calling assembly : (Unknown). === LOG: This bind starts in default load context. LOG: Download of application configuration file was attempted from file:///C:/minha_DLL/MeuTeste.exe.config. LOG: Configuration file c:\minha_DLL\MeuTeste.exe.config does not exist. LOG: No application configuration file found. LOG: Using host configuration file: LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config. LOG: Post-policy reference: ACBrFramework.Net, Version=0.9.2.8, Culture=neutral, PublicKeyToken=4ca716d5e1bd4ba3 LOG: GAC Lookup was unsuccessful. LOG: Attempting download of new URL file:///C:/minha_DLL/ACBrFramework.Net.DLL. LOG: Assembly download was successful. Attempting setup of file: c:\minha_DLL\ACBrFramework.Net.dll LOG: Entering run-from-source setup phase. LOG: Assembly Name is: ACBrFramework.Net, Version=0.9.2.7, Culture=neutral, PublicKeyToken=4ca716d5e1bd4ba3 WRN: Comparing the assembly name resulted in the mismatch: Revision Number ERR: The assembly reference did not match the assembly definition found. ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated. O que fiz foi remover o .Net 4.0, pois não tem o GacUtil.exe e não conseguia remover o Assembly ACBrFramework.Net.dll dele. Valeu pela ajuda!