Italo Giurizzato Junior

Boa tarde Fábio, Favor atualizar novamente e testar.

Boa tarde Bruno, Conforme o Manual, quando o tpServ for tsMultmodal não deve constar no XML o grupo infDoc. Se ao fazer isso ocorre erro de validação, isso me leva a crer que os seus Schemas (arquivos XSD) estão desatualizados, uma vez que o grupo infDoc é opcional. Você esta usando os schemas que estão na pasta: ...\Exemplos\ACBrDFe\Schemas\CTe ?

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

Bom dia Luciano, O método ConsultarSistuacao serve apenas para obter a situação do lote enviado, ou seja: 1 = Lote não recebido 2 = Lote em processamento 3 = Lote processado com erro 4 = Lote processado com sucesso. No manual da ABRASF sobre a NFS-e versão 1.0 temos na página 29 a estrutura do XML de resposta ao realizar a Consulta a Situação do Lote. Nessa estrutura temos os elementos: NumeroLote e Situação e o grupo ListaMensagemRetorno que contem 3 elementos: Codigo, Mensagem e Correção Pois bem, existe um erro, pois no manual diz que o grupo ListaMensagemRetorno sempre vai estar presente, mas na verdade ele só aparece quando ocorre um erro ao executar a consulta. Pelo menos a maioria dos provedores implementaram dessa forma. Sendo assim se a situação for 2 devemos realizar uma nova consulta, por outro lado se a situação for 3 ou 4 devemos executar o método ConsultarLoteRps. Desta forma vamos obter a lista de erros no caso da situação for 3 ou o XML da NFS-e caso a situação seja 4. Lembre-se para os provedores que seguem a versão 1 do layout da ABRASF temos que: Enviar, ConsultarSituacao e por fim ConsultarLoteRps. Por outro lado os provedores que seguem a versão 2 temos que: Enviar e ConsultarLoteRps. Não versão 2 o ConsularLoteRps traz a situação a lista de erros caso ela seja 3 ou o XML da NFS-e caso seja 4. Entendeu agora como é que a coisa funciona?

Bom dia a todos, Rogério, existe uma certa confusão, vou tentar esclarecer. O componente ACBrMDFe tem como finalidade emitir o MDF-e - Manifesto de Documentos Fiscais Eletrônicos, o MDF-e é um documento que relaciona por exemplo todos os CT-e referentes a carga de um caminhão, cujo transporte será interestadual. Como você pode ver não tem nada haver com o que o seu cliente faz. O seu cliente utiliza um programa gratuito do governo para realizar a Manifestação do Destinatário. A Manifestação consiste em duas etapas, a primeira obter a lista de notas emitidas contra o seu CNPJ e a segunda manifestar sobre cada uma delas. Complementado o que o Juliomar já disse, o componente ACBrNFe possui um método chamado DistribuicaoDFe, através deste você obtêm a lista de notas, portanto temos ai a primeira etapa resolvida. Note que escrevi lista de notas e não as notas, portanto o que temos é um resumo, ou seja, meia duzia de informações sobre a nota emitida contra o seu CNPJ. Você deve apresentar essa lista na tela para que o usuário possa selecionar individualmente cada uma delas e se manifestar, portanto temos ai a segunda etapa resolvida. A Manifestação são eventos, como a carta de correção, o cancelamento, sendo assim o que muda basicamente é o tipo de evento a ser informado. Existem 4 tipos de eventos refere a Manifestação. Resumindo você vai utilizar o componente ACBrNFe para executar as 2 etapas que compõe a Manifestação do Destinatário. Proponho que você acesse o Portal Nacional da NF-e e baixe as seguintes Notas Técnicas. NT 2014/002 versão 1.01 - Que trata sobre a Distribuição DF-e. NT 2012/002 versão 1.02 - Que trata sobre a Manifestação do Destinatário Sobre a obrigatoriedade de realizar a Manifestação do Destinatário favor ler: NT 2013/001 - Que trata sobre a Manifestação de Operação de Combustível.

Fábio, Consegui um tempo e fiz as alterações. Favor atualizar os fontes e não esqueça de usar o novo arquivo INI do provedor pois fiz alterações nele também. Agora o componente vai gerar as TAGs conforme o exemplo, apesar de eu achar que tem coisa errada nesse exemplo, pois temos a TAG Email logo após a TAG DDD e a TAG Telefone aparece no final logo após a TAG Nome, achei estranho isso. Eu inverti coloquei o Telefone logo após o DDD e deixe por último a do Email.

Boa tarde Fábio, Com o exemplo disponibilizado pelo provedor vou realizar as alterações, não prometo hoje, mas com certeza amanhã estará pronto.

Boa tarde Maurício, Qual é o objetivo de gerar a chave antes? Eu nunca tive esse problema, pois o XML só gerado segundos antes do seu envio, deixo a cargo do componente gerar a chave no momento que esta gerando o XML. Depois leio a propriedade ID para obter a chave e guarda-la no banco de dados.

Boa noite a todos, Acredito que você utiliza o ACBrMonitor Plus, correto? Pois bem o Monitor se utiliza do componente ACBrNFe para realizar diversas tarefas, entre elas a consulta. O método Consultar implementado no componente ACBrNFe tem 2 finalidades. 1. Se consultar informando somente a chave da NF-e teremos como resposta a situação atual da respectiva nota. 2. Se consultar informando o XML da NF-e assinado, teremos como resposta a situação atual da respectiva nota e a atualização do XML, ou seja, o protocolo de autorização será acrescentado ao XML e caso a nota possua eventos, tais como: cancelamento, carta de correção etc, um XML com sufixo "-NFeDFe.xml" é gerado contendo o XML assinado, protocolado e a lista de eventos. Esse último arquivo somente é gerando pelo componente, no momento ainda não temos nenhuma funcionalidade no componente que o utilize. O arquivo com valida jurídica e que devemos disponibilizar ao destinatário da mercadoria e a transportadora quando esta for a responsável pelo transporte da mercadoria vendida é o XML cujo nome é: <chave>-nfe.xml desde que esteja assinado e com o protocolo de autorização. Junior, você disse que abriu ambos os arquivos e não encontrou os eventos, pois bem, seria possível você anexa-los?

Boa tarde Mario, O erro de validação é claro. O elemento Cnpj contem um valor inválido. Ele contem uma string vazia, sendo assim esta faltando informar o CNPJ.

Bom dia Luis, Já tive problemas da aplicação fechar do nada. Mas depois de reinicializar a maquina o problema parou. Mas não encontrei ainda uma resposta concreta sobre esse problema. Com relação a rejeição de duplicidade a explicação é simples, você tentou enviar o mesmo MDF-e duas vezes.

Boa tarde Cristiano, Caso a aplicação dessa empresa envia por e-mail o XML do CT-e emitido ao tomador do serviço, basta entrar em contato com eles e pedir que envie de volta o XML. Uma outra saída é solicitar junto a SEFAZ, vai dar um pouco de trabalho, mas é um caminho. Sei de um caso que a SEFAZ enviou todos os XML dentro um período.

Boa tarde Luiz, Com o programa exemplo ocorre o mesmo erro?

Bom dia Augusto, Muito obrigado pelo retorno, sendo assim vou incluir o provedor Publica na lista dos provedores que estão funcionando 100% no Trunk2.

Bom dia, Não me recordo se esse provedor chegou a funcionar com as cidades que antes o utilizavam. Pelo que sei ele segue a versão 2 do layout da ABRASF, sendo assim não acredito que será complicado fazer ele funcionar, basta acrescentar a cidade no arquivo Cidades.INI e as URLs de homologação e produção no arquivo Agili.INI

Bom dia Augusto e Luiz, Muito obrigado pela colaboração, já esta disponível no repositório. Uma pergunta por que vocês não estão validando o lote antes do envio? Sendo que existe uma pasta chamada Pronimv2 com os schemas.

Bom dia Rogério, Favor atualizar os fontes e testar novamente.

Bom dia Danilo, Muito obrigado pela colaboração, ainda hoje vou disponibilizar.

Bom dia Luciano, A sua alteração esta errada, uma vez que o método ConsultarSituacaoLote só retorna a situação do lote enviado, ou seja, retorna se o mesmo esta sendo processado ainda, ou seja foi processado com sucesso ou com falha. Sendo assim não existe nesse retorno o Notas para serem extraídas.

Bom dia ALA, Primeiro é preciso saber se a cidade de Itabira vai usar a versão 1 ou 2 do provedor Pronim. Sem essa informação não tem como alterar os arquivos necessários.

Bom dia Nelson, Esse provedor não foi implementado, se ele realmente segue o layout versão 2 da ABRASF você mesmo pode implementar basta tomar como base o provedor ABase (por exemplo). Será necessário criar um arquivo INI para o novo provedor e fazer as alterações necessárias nos fontes do componente para que o mesmo o reconheça. Nos fontes procure por proABase para ter uma ideia de quais fontes serão necessários fazer as devidas alterações.

Bom dia Arivaldo, Você se refere ao numero da nota, mas ocorre que os arquivos que você anexou se referem ao XML do RPS, do envio do lote e o seu retorno contendo o numero do protocolo.

Bom dia Luiz, Assim que você fizer os testes e estar tudo funcionando, favor anexar somente os arquivos que você alterou, para que possamos avaliar e se tudo OK enviar para o repositório.

Bom dia André, Muito obrigado pela colaboração, ainda hoje vou disponibilizar.

Bom dia Francisco, Favor atualizar os fontes e testar novamente.