Italo Giurizzato Junior

Boa tarde Mateus, Ai que esta o problema, esse endereço de consulta se refere ao mesmo ambiente para onde a nota foi enviada? Se você enviou para o ambiente de homologação, ao tentar realizar uma consulta no ambiente de produção vai ter como resposta que a chave não existe.

Boa tarde Eventon, Por favor post como anexo a unit que você alterou, para que possamos avaliar e caso esteja tudo OK enviarmos para o repositório.

Bom dia Mateus, Você esta consultando no mesmo ambiente que a nota foi enviada?

Bom dia Daniel, Me parece que alguém do fórum tinha implementado o respectivo comando e postado aqui mesmo no fórum.

Bom dia Tiago, Por favor atualize e tente compilar novamente.

Bom dia Cleonir, Favor atualizar os fontes, compilar a aplicação com a opção Build e teste novamente.

Bom dia Elton, O cancelamento de uma NF-e já faz um bom tempo que é um evento. Sendo assim, estude o programa exemplo.

Boa tarde, O problema que logo no começo existe Namespace desnecessários e a versão estra entre apostrofe e não entre aspas. Se remover os namespaces a mais e trocas os apostrofes por aspas vai funcionar.

Boa tarde Ricardo, Se eu disser a você que essas URLs atualizei nos fontes do ACBr em 01/05/2015 você acredita? Agradecemos a sua postagem, mas por favor antes de postar pesquise, pois faz 4 meses que tem pessoas no fórum comentando sobre essa mudança. Uma Dica: se você ficar esperando a contabilidade de algum cliente seu lhe passar alguma informação, vai estar perdido, como você pode ver, estão lhe avisando que as URLs antigas vão parar de funcionar daqui 20 dias. Lhe sugiro visitar diariamente os portais nacionais da NF-e, CT-e e MDF-e só assim você vai estar informado.

Boa tarde Alexandre, Disponibilizei o arquivo: Fiorilli.INI, favor atualizar os fontes e testar novamente. Não existe a garantia que vai funcionar pois o ACBrNFSe para o Trunk2 ainda esta sendo reescrito, mas acredito que o envio do lote e o retorno do recibo já esta funcionando.

Boa tarde Adriano, Pode ser problema de cedilha, vogais acentuadas ou caracteres especiais. Ou até mesmo alguma TAG que esta sendo gerada sendo que não devia.

Bom dia Adriano, A prefeitura de São José dos Pinhas/PR antes se utilizava do provedor Ginfes, provavelmente assim que terminou o prazo do contrato em vez de fazer uma nova licitação, não resolveram montar o seu próprio Web Services e diga-se de passagem usando os mesmos schemas do Ginfes entre outras coisas, como o envelopamento do XML a ser enviado ou recebido. Mudaram alguma coisa só para dizer que não copiou tudo. Onde esta o pessoal de TI da prefeitura que tiveram a brilhante ideia e que agora se escondem em vez de dar suporte aos interessados a utilizar o Web Service. O jeito é ficar no pé desse pessoal.

Boa noite José, O que esta ocorrendo é muito estranho, acredito que deva existir algum bug no comando AdicionarCTe que em vez de acionar o CTe ao lote ele esta tentando criar um novo XML. Faça o seguinte, em vez de usar o comando CriarCTe para criar o XML do CTe, utilize no lugar o comando AdicionarCTe e depois o comando para enviar o lote.

Boa noite Paulo, Sim, as sub-pastas dentro da pasta Evento só serão criadas caso a propriedade AdicionarLiteral estiver com o valor True.

Boa noite Adriano, O componente ACBrNFSe não esta pronto para o Trunk2.

Robinho, A regra é clara e essa empresa esta interpretando de forma errada. A regra diz que o grupo <infDoc> tem que ser informado, mas não diz se o documento a ser informado é o não a NF-e original. Veja se este linlk lhe ajuda: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-anulacao-e-substituicao/

Boa tarde a todos, Por favor aguardem até amanhã, pois estarei disponibilizando algumas alterações que visam resolver o problema do XML ficar sem o protocolo após o envio.

Boa tarde Ricardo, Pela sua rotina você ainda esta usando os fontes do Trunk, correto? Pois bem sugerimos que você mude para o Trunk2.

Boa tarde a todos, Lucas, você sofre por antecedência, calma rapaz. Vocês vão ver no dia 01/11/2015 quantos vão perguntar no fórum se já foi implementado.

Boa tarde Rubens, Você esta usando o ACBrNFe para realizar o download após a manifestação do destinatário? Se sim, deve ter notado que o componente salva alguns arquivos são eles: *-ped-down-nfe.xml <== pedido de download de NF-e. *-down-nfe.cml <== retorno do pedido. *-nfe.xml <== NF-e extraída do retorno. O problema é que você esta pegando o retorno do pedido e querendo ler como se fosse o XML da NF-e, isso esta errado. O retorno do pedido contem o grupo <retDownloadNFe> logo no inicio indicando exatamente isso. O componente se encarrega de extrair a NF-e que dependendo da SEFAZ pode vir compactada ou não. O componente possui uma propriedade para definir o path onde os downloads serão salvos.

Bom dia Claudio, O comando ConsultarNFe é para consultar a situação atual emitida por você. Suponho que você envia a nota, esta é recebida pela SEFAZ, processada, mas no momento de retornar o protocolo de autorização ocorre um erro, por exemplo, time out. Como resolver esse problema? Simples, basta executar o ConsultarNFe, este comando vai realizar uma consulta na SEFAZ para saber o resultado do processamento, como retorno vem o protocolo de autorização e o mesmo é adicionando ao XML. Portanto o comando ConsultarNFe não server para saber se a nota emitida pelo seu fornecedor esta autorizada ou não.

Bom dia Fabrício, Os componentes ACBrNFe, ACBrCTe e ACBrMDFe tiveram os seus fontes alterados para os novos endereços em 01/05/2015. Quem fez essas alterações foi eu. O ACBrNFeMonitor se utiliza dos componentes. Levando em consideração que o Monitor é compilado com a última versão dos fontes disponíveis no repositório, podemos concluir que as compilações do monitor realizadas após a minha alteração, já contempla os novos endereços. No que diz respeito aos fontes dos mesmos componentes disponíveis no novo repositório (Trunk2), afirmo que os novos endereços também foram alterados 01/05/2015. Como o ACBrMonitor Plus se utiliza dos componentes que estão no Trunk2, conclui-se que este também já contempla os novos endereços.

Bom dia Almeida, Só pela chave notei que se trata de uma NFC-e (modelo 65) e não uma NF-e (modelo 55). Sendo assim, você esta ciente que a NFC-e é uma Nota Fiscal ao Consumidor Eletrônica, portanto os dados do destinatário são opcionais e quando desejamos informar o consumidor final normalmente é uma pessoa física. Lhe peço que procure pelos campos apontados pela validação que você fez na Nota Técnica 2013/005 versão 1.22 e veja o que deve ser atribuído quando for uma NFC-e.

Boa tarde Alencar, A rejeição acusa que a versão dos dados não é suportada, mas se você abrir o arquivo 1-ped-eve-soap.xml vai notar que a versão informada na tag versaoDados é 1.00 bem como as demais versões que aparecem pelo XML todas são 1.00 como tem que ser. Inclusive no retorno a versão que aparece também é 1.00 e a versão do aplicativo que processa a recepção dos eventos no caso da SEFAZ-SP é: SP_EVENTOS_PL_100, ou seja 1.00 Concluo que o problema esteja na SEFAZ agora.

Bom dia Arce, Na tabela que você postou esta escrito: Resumo de Eventos CTe Autorizado / Cancelado Sendo assim o que temos é um resumo de um evento gerado pela SEFAZ que informa que a NF-e em questão esta vinculada a um CT-e que foi autorizado ou que foi cancelado. Infelizmente a NT não apresenta todos os Layout dos resumos.