guilherme_desordi

Então, o problema é que eu não tenho esse retorno. Tenho apenas os arquivos de consulta, sem retorno. Me parece que os dados não são enviados corretamente ou algo assim...

Pode ser. Tenho que rever todas as configurações mesmo... Mas eu saio meio dia do estagio, então continuarei amanha. Muito obrigado, hein!

Obrigado por ajudar! Eu uso proxy e ele está configurado. Não mudou nada no proxy ou no firewall de sexta-eira para cá.

Exato, Douglas! Isso é o que me fez concluir que o problema é local. Se fosse no WS, ele deveria me retornar um erro como 108 ou 109 e no xMotivo informar "Serviço paralisado" ou seja lá o que for. Mas retDistDFeInt está vazia. Eu não obtive nenhum retorno, nem arquivo SOAP nem nada. Executando sem depuração e sem meu tratamento de exceções, a mensagem de erro mostrou o código 12002, como está anexo. Pesquisei esse erro no fórum e realmente costuma aparecer quando o WS não está funcionando. Será que é isso? Será que o WS está realmente inoperante? Acho que se tivesse alguém teria confirmado para mim, né?

Na verdade, para mim o WS NOVO parou de funcionar! Vejam o erro que estou recebendo ao Enviar Dados (anexo).. estou desconfiado que seja um erro meu, porque isso acontece na consulta do WS novo e ao fazer manifestação. Fico confuso porque isso acontece no mesmo aplicativo que funcionava normalmente na sexta-feira. Testei o Certificado e está OK. Atualizei os fontes e recompilei e continua dando esse mesmo erro. Acontece em homologação e em produção. Não boto fé de que seja erro no WS, alguém tem alguma ideia do que possa ser? Parece que tem alguma configuração errada no componente, não sei.

nfeProc é NF-e que você já manifestou.

Isso mesmo, e ainda tem a chance de não ser nenhum dos dois, então teste vários. Depure e teste a sua descompactação. Veja se ao ler o xml ele passa o valor correto, a resposta vai praticamente resolver o problema.

Voce decodificou e descompactou o conteúdo retornado antes de fazer essa verificação?

Uma dúvida simples: Antes a instrução era baixar apenas as NF-e faltantes, agora vamos receber do novo WS todas as NFs manifestadas? Sem exceção? Basta estar manifestada (exceto "desconhecimento da operação")?

Olha o lado bom, vc sabe por que deu consumo indevido... Hahaha

Olha, pode ser. Continuo trabalhando com o ConsultaNDFest em ambiente de produção ao mesmo tempo. Mas não sei... Acho um absurdo algo assim acontecer. Nem o NSU é o mesmo, recomeçou do 0 nesse WS novo! Será?

Primeiramente, não entendo por que o DownloadNFe está te retornando algo zipado. Eu consigo baixar o XML da nota normalmente, como sempre. Quanto à sua outra pergunta, o fluxo exemplificado da NT, na página 11, item 8, diz: "O destinatário consulta o WS NFeDistribuicaoDFe a partir do último NSU recebido e recupera a NF-e"; Não te garanto que isso esteja funcionando agora. Optei por continuar usando o DownloadNFE por garantia, por enquanto. Mas minha conclusão é de que o novo WS é que será responsável por essa tarefa agora. ___ Não havia lido a resposta do Tiago Ravache antes. Desculpa.

Bom dia Ítalo, Primeiramente, muito obrigado pela sua disposição. Respondendo: a nota diz que o retorno será 137 quando não houver documentos a serem pesquisados, e em seguida diz que não haverá documentos a serem pequisados quando UltNSU = MaxNSU, logo, o retorno será 137 quando UltNSU = MaxNSU. Por essa razão a lógica da minha aplicação é verificar se UltNSU = MaxNSU antes de fazer uma nova pesquisa. Por via das dúvidas e para desencargo de consciência, verifiquei todos os arquivos de retorno e confirmei que em todos constam 138 em cStat, inclusive no retorno que recebo imediatamente antes de fazer a consulta que retorna consumo indevido.

Pessoal, aconteceu novamente e, dessa vez, sem atropelamentos. Estava tudo indo muito bem. 08:40:09 => UltNSU = 7150 08:40:09 Pesquisa: 7150 08:40:16 => UltNSU = 7200 08:40:17 Pesquisa: 7200 08:40:18 Rejeicao: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitacoes subsequentes. Tente apos 1 hora) Esses são os horários do nome do arquivo. No xml os horários são diferentes, mas não servem para comparação porque a consulta não tem tag com horário. Contra minha vontade vou adicionar um sleep à iteração. Não vi essa recomendação nem na NT nem no manual do componente, o que torna essa solução ainda mais incômoda. Se perceberem que estou fazendo alguma coisa errado, por favor, me avisem. Consumo indevido.rar

Pessoal, quanto mais aprendo sobre automação comercial, mais intrigado eu fico. Desabafos à parte, hoje eu eu recebi consumo indevido fazendo tudo certinho, só depois de várias iterações fazendo consulta e não foi a primeira vez. Ao analisar os arquivos, vi que eu recebi o lote que eu esperava ANTES de consultá-lo. Então quando consultei, o WS entendeu que esse não era o último NSU (por que de alguma forma eu recebi sem consultar) e então me bloqueou. Já é a terceira vez que isso acontece. Será que eu tenho que dar algum tipo de sleep entre as consultas? O tempo de descompactar as informações do lote e passar para o banco de dados não é suficiente para fazer outra consulta? Os arquivos estão em anexo, reparem bem na data e horário que estão no nome do arquivo. Me ocorreu também que o mesmo pode estar acontecendo com o colega Douglas, que também parece estar fazendo tudo certo. Consumo indevido.rar

Prezada Darlana, Analisando a NT, com base no que eu vi na página 10, sob o item 2.10.1 "Leiaute Resumo da NF-e" (NT 2014/002 versão 1.01 ago/2014), cheguei à conclusão de que a tag cSitNFe não receberá mais a situação cancelada. Isso ficará agora apenas por conta do evento. Será que eu estou equivocado? O que vocês acham?

OK. Obrigado, Ítalo.

Então Ítalo, até o NSU 16, que eu consultei em dezembro, havia notas de fornecedores e ainda de outras empresas do mesmo grupo emitidas a nosso pedido. De qualquer maneira, deveria constar o 16 como NSU máximo no caso de não haver mais notas, correto? Estou acreditando que seja um problema com o WebService, que tem realmente se mostrado instável desde sua implementação, e contando com a possibilidade de que em breve volte a me responder normalmente. Você concorda?

Senhores, bom dia. Estou intrigado com o ambiente de homologação. De repente ele parou de me responder como o esperado, retornando "nenhum documento encontrado" e o valor 0 para último e máximo NSU. Atualizei os fontes, na quarta-feira, e nada. Eu já fiz consulta com o último NSU que eu tenho, com um NSU específico que eu já tinha recebido e com 0. Nada. Enquanto isso, em ambiente de produção tudo funciona normalmente. Alguém sabe por que isso acontece? Em anexo estão as consultas e os retornos. AmbHom.rar

Obrigado!

Prezados Ítalo e demais colegas , A imagem em anexo é da Unit PCN2\pcnRetDistDFeInt.pas, linha 290 aproximadamente. Perceba que o conteúdo de FInfZip é perfeitamente descompactado. O meu problema, é que mesmo quando este conteúdo é um resumo de nota fiscal, ele não entra em nenhuma das condições a seguir. Nem a que o cursor está parado e nem na seguinte. Eu mexi no leitor e resolvi o problema antes de atualizar os fontes pela última vez, mas não queria fazer isso de novo. Gostaria de entender qual a intenção do autor, para que eu não precise modificar mais nenhuma Unit particularmente. Se for problema no leitor mesmo, fica aqui a oportunidade de corrigi-lo diretamente no fonte. Se algum detalhe passou desapercebido por mim e eu estiver errando alguma coisa mínima, por favor, me perdoem.

Uma dúvida: Em pcnRetDistDFeInt, na linha 267 aproximadamente, tem um laço. i := 0; while Leitor.rExtrai(2, 'docZip', '', i + 1) <> '' do Eu não consegui entender a lógica por trás desse laço. Como ele vai entrar na segunda iteração se só existe uma tag "DocZip"? Acredito que tenha alguma coisa a ver com o último parâmetro da função, mas mesmo assim ainda não entendi. Pode ser também que eu não tenha entendido corretamente a NT, não sei. Em outras palavras: Como saber a quantidade de notas do lote? (até agora, recebi apenas um resumo de NFE por resposta - uma única resposta, a propósito).

Boa tarde Ítalo, Muito obrigado pela atenção dispensada ao meu problema. O Sr. tinha toda a razão. Após atualizar os fontes, tudo funcionou como esperado. Obrigado!

Bom dia, Alguém sabe me dizer porque eu não recebo retorno nenhum? O que seria esse "Action Parameter" que parece ser inválido? Como não sei colocar anexo aqui, vou colar abaixo o conteúdo do parâmetro texto da função EnviarDadosWebService. '<?xml version="1.0" encoding="utf-8"?><soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"><soap12:Header><nfeCabecMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NFeDistribuicaoDFe"><cUF>35</cUF><versaoDad os>1.00</versaoDados></nfeCabecMsg></soap12:Header><soap12:Body><nfeDadosMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NFeDistribuicaoDFe"><distDFeInt xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.00"><tpAmb>2</tpAmb><cUFAutor>35</cUFAutor><CNPJ>00573053000146</CNPJ><distNSU>< ultNSU>000011196509087</ultNSU></distNSU></distDFeInt></nfeDadosMsg></soap12:Body></soap12 :Envelope>' RESPOSTA: '<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Sender</soap:Value></soap:Code><soap:Reason><soap:Text xml:lang="en">Unable to handle request without a valid action parameter. Please supply a valid soap action.</soap:Text></soap:Reason><soap:Detail /></soap:Fault></soap:Body></soap:Envelope>'

Ótimo! Muito obrigado pela resposta e por ter nos ajudado com aquele post! Funcionou direitinho, todos os pacotes foram compilados e instalados.