Italo Giurizzato Junior

Boa noite a todos, Vou fechar este tópico pois já esta atingindo quase 380 postagens. Por favor criem um novo tópico tratando somente do NFeDistribuicaoDFe e se for o caso um outro sobre o NFeDownloadNF para que possamos separar as postagens uma vez que se tratam de Web Services diferentes e funções diferentes. Lembre-se que a função do NFeDistribuicaoDFe é fornecer uma lista que a principio são resumos de notas ou eventos, para que a empresa possa realizar a manifestação do destinatário, por exemplo. Se a empresa realizar a manifestação do destinatário e posteriormente realizar uma nova consulta no NFeDistribuicaoDFe vai constar na lista a nota completa, que neste caso o componente se encarrega de descompactar e salvar em disco automaticamente. Por outro lado a função do NFeDownloadNF é simplesmente retornar o XML completo de uma nota que foi previamente manifestada. O problema é a SEFAZ alterou a forma de retorno, ou seja, agora o XML completo da nota esta vindo compactado como ocorre no NFeDistribuicaoDFe, a diferença é que o NFeDownloadNF ainda não foi alterado para realizar a descompactação. Se alguém tiver afim de regaçar as mangas e realizar essa alteração toda a equipe ACBr agradece. Desde já agradeço a compreensão de todos pelo fechamento deste tópico.

Boa noite a todos, Estamos estudando fazer com que a exceção só seja levantada caso o retorno não seja válido. Lembrando que uma rejeição é um retorno válido.

Boa noite Nilton, Favor atualizar os fontes e testar novamente.

Boa noite a todos, Acredito que nesse primeiro momento a dica é paciência. Quando esgotar, ou seja, retornar todos os milhares de NSU depois a quantidade será muito pequena caso a consulta seja feita umas duas vezes ao dia.

Boa noite Ricardo, Por favor, quais são as URLs de homologação e de produção a serem informadas no QR-Code para o Estado de Piauí?

Boa noite Ademar, Sim, a SEFAZ alterou a forma de retornar. Veja o que fizemos com o retorno do Web Services NFeDistribuicaoDFe. E tenta fazer igual para poder descompactar.

Boa noite Nilton, Atualiza os fontes e testa novamente.

Boa noite Fabio, Entendo perfeitamente que o nItemPed não tem utilidade nenhuma para a SEFAZ. Para esta empresa o pedido dela não deva ultrapassar mais de 99.999 itens, mas e se o seu cliente passar a ter um cliente cujo pedido possa a chegar a ter uma quantidade maior do que 99.999 e exigir que no XML da nota seja informado o numero do item. Como você vai resolver o problema?

Boa noite Antonio, Esse já é o segundo post seu fazendo a mesma pergunta, por favor, post somente uma vez e aguarde que alguém lhe responda.

Boa noite, Vou lhe afirmar que o seus fontes estão desatualizados, visto o que o seu fonte possui varias function comentadas, function estas que foram movidas para uma nova unit. Eu mesmo removi os códigos comentados. Outra coisa o seu fonte não possui as URLs do novo Web Services NFeDistribuicaoDFe e que esta disponível no SVN contem as referidas URLs. Sugiro você excluir a pasta que contem os fontes ACBr e baixar novamente.

Silvius, Você vai ter que copiar a unit do provedor Ginfes com outro nome e fazer as devidas alterações nessa unit. Depois criar o nome para o componente e relacionar a cidade a esse provedor na unit pnfsConversao. Depois incluir a unit nova em ACBrNFSeConfiguracoes e ACBrNFSeWebServices. Outras Units deve ser alteradas, para que tudo funcione, você pode achar complicado, mas você tem que tentar, pois desta forma você começa a conhecer como funciona realmente o componente.

Boa tarde Roger, Muito obrigado pela colaboração, já esta disponível.

Boa tarde Luan, O primeiro CT-e sempre vai ser Normal. O segundo poderá ser Redespacho ou Redespacho Intermediário, isso vai depender se vai existir uma terceira transportadora ou não. O Expedidor só vai aparecer no CT-e de Redespacho ou Redespacho Intermediário. O Recebedor terá que ser informado no Redespacho Intermediário ou no Normal quando é sabido que o vai ocorrer o redespacho e sabe-se quem é a transportadora.

Boa tarde, Dentro da pasta ...\Exemplos\ACBrNFSe\Delphi\Schemas\Ginfes você encontra os Schemas para o provedor Ginfes.

Fabio, Primeiramente, essa empresa esta agindo de forma errada, obrigando a gerar um XML que nem sequer tem o tamanho estabelecido no manual é 6 dígitos e não 5. Você deve alterar a unit pcnNFeW, alem de altear o tipo tem que alterar o tamanho minimo e máximo deixando ambos com o valor 6.

Daniel, O Terceiro parâmetro sempre tem que ser o último NSU retornado, devendo parar de realizar a consulta com base no Status. Se você manifesta uma Nota cujo NSU é 35, não significa que o XML completo da mesma o NSU será 36, uma vez que ao consultar podemos ter 50 resumos. O jeito é depois de manifestar aguardar alguns minutos e realizar uma nova consulta, poderemos ter nessa nova consulta novos resumos mais o XML da nota manifestada. Se esta retornando mais XML alem da que você manifestou, verifique se outro não esta manifestando também, por exemplo o escritório de contabilidade.

Boa tarde Silvius, Se todas as cidades resolverem ter o seu próprio Web Service estaremos perdidos, o componente vai ter mais de 5000 provedores. Mas a solução é você pegar a titulo de exemplo o provedor Ginfes para implementar um provedor para a cidade em questão.

Boa tarde Michel, Muito obrigado pela colaboração, já esta disponível.

Boa tarde Nilton, Envia para o provedor o arquivo 1-env-lotS-soap.xml e questione a eles se o arquivo esta em conformidade. Se sim, ai é preciso checar os endereços dos Web Services e SoapAction.

Boa tarde, Se você teve que informar as URLs, isso significa que os seus fontes estão desatualizados. Favor atualizar todos os fontes de todas as pastas.

Boa tarde Junior, Post como anexo o XML de retorno ao realizar a consulta.

Boa tarde Daniel, Ao realizar a consulta você informou o NSU = 39 como sendo o terceiro ou quarto parâmetro no método? O correto é informar como sedo o terceiro e no quarto informar uma string vazia.

Verifique a posição do caminho dentro do Library Path. O caminho do ZLibExGZ deve estar antes do PCN2.

Boa tarde Mauricio, Muito obrigado pela colaboração e já esta disponível.

Boa tarde Fabio, Se compararmos os campos: #126 - nSeqAdic tipo Numérico cujo tamanho é: 1-3, ou seja, varia de 1 até 3 dígitos. #128n - nItemPed tipo Numérico cujo tamanho é 6. Baseado nas informações acima chego a seguinte conclusão: 1. Por ser campo numérico o conteúdo só pode ter dígitos. 2. Se o tamanho esta definido como sendo 6 e não 1-6, isso significa que o campo tem que ser preenchido com 6 dígitos. Mas se analisarmos o schema temos: <xs:element name="nItemPed" minOccurs="0"> <xs:annotation> <xs:documentation>Número do Item do Pedido de Compra - Identificação do número do item do pedido de Compra</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:pattern value="[0-9]{1,6}"/> </xs:restriction> </xs:simpleType> </xs:element> Note que o elemento nItemPed é opcional e o seu valor é formando somente por dígitos [0-9] e cujo tamanho é variável {1,6}. Resumindo: Segundo o manual o conteúdo da TAB nItemPed é um número com 6 dígitos, mas segundo o schema o conteúdo é um número com tamanho variável de até 6 dígitos.