Italo Giurizzato Junior

Boa tarde Rodrigo, Quando foi a última vez que você atualizou os fontes? Que eu me recordo estava ocorrendo esse problema mas já foi resolvido a um bom tempo. Você configurou o componente para salvar em disco? Configuracoes.Arquivos.Salvar := True;

Bom dia, Você testou? Foram feitos diversas alterações visando corrigir o problema.

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

Bom dia, O DistribuicaoDFe por ser uma mera consulta você pode realiza-la no ambiente de produção.

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

Bom dia Paulo, Sim, isso era de se esperar, apesar de constar na NT 2015/003 que a SEFAZ a partir do dia 03/11/2015 vai aceitar o XML com o grupo <ICMSUFFim> isso não significa que o CT-e será rejeito caso não tenha, pelo simples fato que as regras de validação desse grupo nos servidores das SEFAZ só serão ativadas em janeiro de 2016.

Boa tarde Cleber, Favor ler a Nota Técnica 2015/001 - versão de Abril - Item 8 - página 4.

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

Boa tarde Juh, Tente o seguinte, abra o arquivo ACBrNFeServicos.INI e procure pelas seções [NFe_PR_P] e [NFe_PR_H] Acrescente um ponto e virgula no inicio da linhas linhas: NfeConsultaCadastro_3.10=..... das duas seções mencionadas acima, por exemplo: ;NfeConsultaCadastro_3.10=https://nfe.fazenda.pr.gov.br/nfe/CadConsultaCadastro2?wsdl Isso vai fazer com que a linha se transforme em um comentário. Por fim execute o BAT: Compila_RES que encontra-se na mesma pasta. Compile a sua aplicação com a opção Build e tente novamente.

Bom dia a todos, Pelo amor de Deus, por favor leiam as notas técnicas. José o seu XML se refere a uma NFC-e e consta nela a TAG qrCode conforme a NT 2015/002 pois bem, para o ambiente de homologação somos obrigado a criar essa TAG caso contrario ela será rejeitada, por outro lado se gerarmos ela e enviar para o ambiente de produção a nota será rejeitada, uma vez que esse ambiente ainda não esta preparado para receber um XML com a TAG qrCode. Resumindo, devemos gerar a TAG para fins de testes, ou seja, enviar para o ambiente de homologação e não gerar ao enviar para o ambiente de produção. Esse procedimento teremos que tomar até que seja liberado o ambiente de produção.

Bom dia Fernando, Cada um interpreta da sua forma. Alterar o arquivo INI compila-lo para gerar um novo RES que será carregado para dentro do EXE durante a compilação da aplicação ou configurar o componente conforme dito pelo Daniel para que a aplicação se utilize do INI alterado, para mim não significa que o código do componente foi alterado. De todos os Estados brasileiros que emitem NFC-e somente PB quis ser diferente. O código do componente esta em conformidade com os manuais e notas técnicas. Todas as URLs de todos os web services de todos os Estados agora estão no arquivo ACBrNFeServicos.INI Se você seguir a sugestão do Daniel, devera distribuir junto com a sua aplicação o arquivo INI acima mencionado. Por outro lado se amanhã alguma SEFAZ resolver alterar alguma URL, basta você efetuar essa alteração no INI e enviar a todos os seus clientes. Agora se você achar por bem que deve gerar um novo RES e compilar a sua aplicação e por fim atualizar os seus clientes, isso é uma decisão sua. Volto a afirmar a minha interpretação, gerar um novo RES para mim não significa alterar o código do componente.

Bom dia Daniel, De uma olha na estrutura do grupo <comb> páginas 59 e 60 da Nota Técnica 2013/005 versão 1.22

Bom dia Volmir, Não há necessidade, pois se o consumidor consultar pela chave vai constar a informação que a mesma esta cancelada e no caso da consulta via QR-Code vai aparecer um carimbo vermelho em cima da imagem do DANFE escrito Invalida, isso significa que a nota esta cancelada. Por favor leia: Especificações Técnicas do DANFE NFC-e QR-Code Versao 3.4

Bom dia, Quando você cancela uma NF-e é preciso que no banco de dados você tenha um campo que indique que a nota de numero 500 esta cancelada, bem como a data/hora e o numero do protocolo de cancelamento. É desta forma que você sabe se a nota foi cancelada ou não, quando foi e o protocolo de homologação da SEFAZ. Segundo não se deve alterar o XML da nota, ou seja, remover as informações referente a autorização e colocar no lugar as informações referente ao cancelamento. Esse procedimento não existe não consta nos manuais e notas técnicas publicadas pelo ENCAT e disponibilizadas no Portal Nacional da NF-e. O XML da NF-e deve conter apenas os dados da venda, a assinatura digital do emitente e as informações referente a autorização de uso retornada pela SEFAZ-Autorizadora. Esse XML deve ser armazenado pelo emitente e disponibilizado ao destinatário. Ocorrendo o cancelamento deve-se disponibilizar ao destinatário o arquivo *-procEventoNFe.xml este arquivo contem a solicitação de cancelamento, a assinatura digital do emitente e as informações referente a homologação do cancelamento retornada pela SEFAZ-Autorizadora. O emitente também deve armazenar esse arquivo. Temos então 2 arquivos XML com validade jurídica que o emitente deve armazenar e disponibilizar ao destinatário, são eles: *-nfe.xml (nota fiscal propriamente dita) *-procEventoNFe.xml (processamento de Evento de NF-e) que pode ser um cancelamento ou CC-e Observação: caso exista uma transportadora envolvida no trasporte das mercadorias relacionadas na nota, ela também deverá receber os arquivos mencionados acima. Para enviar por e-mail os arquivos acima para o destinatário / transportadora utilize os métodos: EnviarEmail para a nota; EnviarEmailEventos para os eventos.

Bom dia Edson, Se deseja realizar testes com a NFC-e sugiro usar a SEFAZ-AM.

Bom dia Gilson, Muito obrigado pela colaboração. Já esta no repositório do Trunk2.

Boa noite, Verifique se o componente esta configurado para salvar o XML: Configuracoes.Arquivos.Salvar := True;

Boa noite Marcos, O CSC e o idCSC que você utilizou se refere ao mesmo ambiente que foi enviado a nota? Algumas SEFAZ fornecem um CSC e idCSC diferentes para o ambiente de homologação e de produção.

Edson, Em nenhuma das 4 tabelas de endereços que você postou fazer referencia a MS. Porque você quer utilizar o arquivo INI em vez do RES? No caso do INI você vai ter que disponibilizar ele junto com a sua aplicação, por outro lado o RES vai estar dentro do executável.

Guto, Sendo assim, peço que aguarde mais um pouco até terminarmos a questão da assinatura e os 3 métodos que mencionei.

Boa tarde Fernando, Pelo contrario, sobre esse problema na URL da SEFAZ-PB estou ciente a um bom tempo. Acontece que você propôs uma alteração no código do componente que ao meu ver não ser necessário, pois bastaria alterar a URL no arquivo INI. De uma forma ou de outra, você esta ciente que o problema não esta resolvido? Pois bem, não adianta montarmos uma URL para o QR-Code que seja validada pelos schemas e depois ao tentar ler o QR-Code impresso no DANFE nos é apresentado uma mensagem de erro. Essa alteração é apenas um paliativo para que você possa realizar os seus testes. Sendo assim, volto a afirmar que vocês devem infernizar a SEFAZ-PB até ela consertar essa mercadoria que fizeram na URL.

Edson, A sua intenção é emitir Nota Fiscal ao Consumidor Eletrônica ou Nota Fiscal Eletrônica? Pois até onde seu ainda não temos as URLs dos WebServices da NFC-e para o Estado de MS. Você tem alguma informação?

Boa tarde Wether, Vamos por parte: 1. O XML esta sendo gerado, assinado, valido e enviado para SEFAZ. 2. A SEFAZ rejeita a sua nota informando que o motivo é falha no schema. Pois bem, isso não tem nada haver com os schemas que você tem e que são utilizados para validar a nota antes do envio. Você notou que a sua nota foi gerada com o tipo de ambiente produção? Você esta enviando a nota para o ambiente de produção? Depois que você alterou o NCM você gerou o XML, assinou, validou e enviou para SEFAZ?

Boa tarde Edson, Quais são os valores que você esta passando para as propriedades: ModeloDF e VersaoDF? Propriedades estas de configuração do componente ACBrNFe.

Boa tarde Veríssimo, Então você entendeu errado. Pois segundo a NT 2015/003 versão 1.10 - página 4 diz que o elemento pai da TAG CEST é o I01. O elemento I01 nada mais é que a TAG prod conforme consta na página 53 na NT 2013/005 versão 1.22 Na verdade prod é um grupo que contem todos as TAGs referentes a um produto. Sendo assim a TAG CEST vai aparecer em todos os itens contidos na nota, ou seja, se a minha nota tiver 30 itens vou ter um CEST para cada item, portanto essa TAG vai aparece no XML 30 vezes.