Italo Giurizzato Junior

Boa noite Rafael, Eu preciso dos arquivos que contem a palavra soap no nome, por exemplo: 1-rec-soap.xml Os que você anexou não terá muita utilidade.

Boa tarde Fabio, Muito obrigado pela colaboração, já esta disponível no repositório.

Bom dia Luis, Essa NT foi publicada em Novembro e em Dezembro foi republicada com algumas correções. O componente ACBrCTe desde de novembro já contempla as novas TAGs referente ao Fundo de Combate à Pobreza.

Simples, vai constar um resEvento para cada evento vinculado a nota.

A propriedade indCont não existe mais. Por favor leia o Manual do ACBrNFe que encontra-se na pasta: ...\Doctos\Manuais

Bom dia Rodrigo, Você esta com os schemas atualizados? Você esta usando os schemas disponibilizados em: ...\Exemplos\ACBrDFe\Schemas\NFe ?

Esse método nada mais é do que o DistribuicaoDFe que esta no ACBrNFe.

Bom dia a todos, É preciso fazer muitos testes para que não ocorra erro de validação. Quero deixar claro que erro de validação é uma coisa e Rejeição é outra. Se informarmos o CPF do consumidor com menos de 11 dígitos temos um erro de validação. Por outro lado se eu informar um CPF com 11 dígitos mas com um dígito errado não temos erro de validação mas a nota será Rejeitada pois o CPF é inválido. O correto é, se a nota for rejeitada devemos imediatamente fazer a correção enviar novamente para obter o protocolo de autorização, imprimir o DANFE para que seja entregue ao consumidor e assim dar a venda como encerrada. Mas isso com certeza vai demandar tempo e a fila vai crescer. Como contornar isso? Se uma nota é rejeitada devemos trocar o tipo de emissão para Offline, informar o motivo e a data/hora de entrada em contingência, gerar novamente o XML com esses novos dados, assinar e imprimir o DANFE, para ser entregue ao consumidor e assim dar a venda como finalizada. O seu sistema tem que ter um controle das notas emitidas em contingência e alguém que monitore essas ocorrências. Essa pessoa precisa saber o que ocorreu com cada nota, por exemplo, a nota de numero 1500 a rejeição foi o CFOP do item 4. Medida a ser tomada, corrigir no cadastro desse item o CFOP para que mais nenhuma nota seja rejeitada por esse motivo quando esse item for vendido. Gerar novamente o XML, assinar e enviar (detalhe não se deve altear o tipo de emissão e nem remover o motivo e data e hora de contingência), esse novo XML tem que conter o CFOP correto uma vez que foi ele que provocou a rejeição. Se a SEFAZ retornar que a nota foi autorizada podemos dar a venda como encerrada.

Bom dia, Para que você não fique batendo cabeça, lhe convido a ler a Nota Técnica 2014/002 versão 1.01 Na página 5 você vai encontrar o layout do XML retornado, desta forma você vai saber quais são as informações que são retornadas após executar o método DistribuicaoDFe. Vai descobrir por exemplo que o campo indCont não existe nesse método.

Bom dia Léo, Muito obrigado pela colaboração, já esta no repositório.

Boa tarde Tony, Esta correto, e todos os schemas necessários se encontram em: ...\Exemplos\ACBrDFe\Schemas\NFe.

Boa tarde Antonio, Se o cliente foi informado é preciso também trocar o nome dele pela frase padrão.

Se mesmo assim esta acusando esse erro significa que existe algum fonte do ACBr em alguma pasta que o Delphi tem acesso, por exemplo a pasta que esta os fontes da sua aplicação ou você tem uma partição do HD.

Boa tarde Allan, Primeiro vamos corrigir a sua primeira frase: onde você diz "Será que inutilizar nota rejeitada..." o correto é dizer: "Será que inutilizar o numero da nota rejeitada..." Para que outras pessoas não confunda as coisas. Não vejo com bons olhos a inutilização de numeração, uma vez que a SEFAZ diz que se a nota for rejeitada a mesma deve ser corrigida e enviada novamente. Segundo o Manual versão 5.00 da NF-e - página 43 Item 4.1.10 trata sobre o processamento do lote de notas enviadas. Rejeição – a NF-e será descartada, não sendo armazenada no Banco de Dados podendo ser corrigida e novamente transmitida; Apesar de estar escrito "podendo ser corrigida" veja o quadro abaixo, temos a coluna Consequência para o contribuinte diz "Corrigir NF-e" quando a situação da mesma for: Rejeição. Se tratando da NFC-e o procedimento é o mesmo, só que para que o cliente não fique esperando, imprima o DANFE, faça a correção e envia.

Boa tarde, Uma coisa é você baixar os fontes do repositório Trunk2, outra coisa é usar o instalador errado. Para instalar os componentes do Trunk2 é preciso usar o instalador: ACBrInstall_Trunk2. Outra coisa tem antes de executá-lo é preciso executar o BAT: ApagarACBr para que o mesmo remova BPL, DCU dos fontes do Trunk perdidas no HD da sua maquina.

Bom dia Antonio, Posso lhe dizer que o XML esta correto. O que esta errado é o DANFE.

Bom dia Allan, Cancelar não tem como pois você só pode cancelar uma nota autorizada, e no caso ela foi rejeitada. Inutilizar o numero não acredito ser uma solução viável, pois o fisco amanhã pode lhe questionar sobre isso. Emitir em Offline talvez seja a solução e depois fazer as devidas correções e enviar novamente pode ser a saída. Lembre-se que o prazo para autorizar uma nota emitida em Offline é de 24 horas.

Bom dia Cleiver, Favor atualizar novamente.

Bom dia Antonio, No meu caso todas as DLLs que você mencionou e coloco na mesma pasta da aplicação e registro as que tem que ser registradas. E funciona.

Bom dia Igor, Seria interessante você pegar essa sua postagem e enviar para a SEFAZ, pode ser um erro deles.

Weriton, A procedimento é simples, corrigir a informação errada, gerar novamente o XML, assinar, validar e enviar. Com certeza o erro a ser corrigido não vai afetar o valor final da nota, então qual é o problema?

Bom dia Allan, Primeiramente, quem disse a você que o XML assinado e protocolado pode ser alterado? Quem disse que você pode trocar o protocolo de autorização pelo de cancelamento? Cancelamento é um evento vinculado a uma nota autorizada, sendo assim é necessário você possuir o XML da nota com o protocolo de autorização mais o XML do evento de cancelamento da mesma. Quem disse a você que existe inutilização de nota fiscal? Você inutiliza um numero e não a nota, quando você solicita a SEFAZ a inutilização do numero 150 (por exemplo) esta informando a SEFAZ que não existe a nota de numero 150. Se por algum motivo o XML assinado da nota enviada para SEFAZ esta sem o protocolo de autorização pois ocorreu um problema na conexão, o procedimento é, carregar o componente com o XML e depois executar o método Consultar, desta forma você terá o XML com validade jurídica, ou seja, assinado e protocolado. Se o componente estiver configurado para salvar em disco (Configuracoes.Arquivos.Salvar := True) ele será salvo e se desejar poderá obter o mesmo para salvar no banco de dados ledo a seguinte propriedade: ACBrNFe.NotasFiscais.Items[ x ].XMLAssinado Reveja os seus conceitos, eles estão errados.

Bom dia a todos, Weriton, como assim o consumidor já levou o DANFE? O DANFE só pode ser impresso em duas situações: 1. Se a nota for autorizada pela SEFAZ. 2. Se a nota for impressa em Offline. Uma nota rejeitada tem sim que ser corrigida e enviada novamente. Alguém tem que ficar monitorando todas as notas enviadas para saber quais as que foram rejeitadas, qual foi o motivo para efetuar as devidas correções, gerar novamente o XML, assinar e por fim enviar novamente. Dependendo da informação que fez com que a nota tenha sido rejeitada não consta no DANFE sendo assim não existe problema algum fazer a correção para enviar novamente.

Bom dia Zanutto, O consultar não baixa nada, apenas retorna a situação atual do CT-e. O consultar age de duas formas diferentes: 1. Se for informado somente a chave do CT-e é retornado a situação atual do mesmo. 2. Se o componente for carregado com o XML do CT-e a ser consultado, alem de retornar a situação atual o XML será atualizado, deixando-o com validade jurídica, ou seja, assinado e protocolado, isso se ele tenha sido autorizado pela SEFAZ.

Bom dia Ciomar, Você não esta usando o ACBrInstall em vez do ACBrInstall_Trunk2? Pois no caso do Trunk2 o pacote se chama ACBr_OpenSSL.