Italo Giurizzato Junior

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.

Bom dia Antonio, Se tratando da NF-e, ou seja, nota modelo 55 o envio no modo assíncrono, portanto só sabemos se a nota foi autorizada ou não após realização da consulta. Ao enviar o que temos como resposta é o numero do recibo, ao consultar informado o numero do recibo sabemos se a mesma foi autorizada ou não. Por outro lado a NFC-e, ou seja, nota modelo 65 o envio pode ser pelo modo assíncrono (funcionamento igual ao da NF-e) ou pelo modo síncrono. Se o envio ocorrer pelo modo síncrono o que temos com resposta logo após o envio já é o resultado do processamento, ou seja, autorizada ou não. O método Enviar possui 3 parâmetros sendo que o último se não for informado o valor padrão é False, isso significa que o envio será pelo modo Assíncrono. Se formos enviar NF-e o terceiro parâmetro sempre deverá ser False a não ser que alguma SEFAZ venha disponibilizar o modo Síncrono para a NF-e. Se formos enviar NFC-e o terceiro parâmetro deverá ser False caso o lote tenha 2 ou mais notas ou True caso o lote tenha somente uma nota.

Bom dia Antonio, Atribua o valor False a propriedade de configuração chamada SepararPorModelo.

Bom dia José, A SEFAZ realiza uma consulta no servidor do Ambiente Nacional para saber se existia um registro de evento de passagem. Esse tipo de evento é gerado automaticamente pela própria SEFAZ quando esta detecta que a mercadoria esta em transito. Se existe esse tipo de evento significa que a mercadoria já foi despachada portanto a nota não pode ser cancelada. A mensagem diz que ao tentar realizar a consulta para saber se um registro desse tipo evento, ocorreu uma falha, portanto a SEFAZ não tem condições de autorizar ou não o cancelamento da nota. Como é dito na própria mensagem é preciso aguardar um determinado tempo e tentar efetuar o cancelamento novamente.

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 Robinho, No exemplo que você postou, você concorda que a informação "pesoB" esta em uma lista, correto? Sendo assim é prudente antes de ler essa informação checar a quantidade de itens que essa lista possui, caso a quantidade for zero não devemos ler. if ACBrNFe1.NotasFiscais.Items[0].NFe.Transp.Vol.count > 0 then DMCTE.TBCTEQCARGA.Value:= ACBrNFe1.NotasFiscais.Items[0].NFe.Transp.Vol.Items[0].pesoB Espero ter ajudado.

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.

Boa noite José, Note que no XML o código do Órgão (UF) de solicitação do pedido de cancelamento é exatamente o mesmo do retorno que coincide com os 2 primeiros dígitos da chave da NF-e. Isso é uma prova que o evento de cancelamento foi enviado para a SEFAZ-Autorizadora e o retorno foi dela. A minha duvida agora é com relação a data/hora do evento, este tem que ser posterior a data/hora de emissão da NF-e. Você poderia postar em anexo o XML da respectiva nota?

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.

José, O componente não realiza dois cancelamentos: um no Ambiente Nacional e outro na SEFAZ-Autorizadora. A sua nota foi cancelada somente na SEFAZ-Autorizadora. Agora volto a lhe perguntar, você checou os arquivos de envio e de retorno da SEFAZ referente ao evento de cancelamento?

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.

Boa tarde José, Quanto ao Erro de rejeição apresentado na tela, você chegou a conferir os XMLs de envio e de retorno da SEFAZ referente ao evento de cancelamento? É interessante checar eles. Outra coisa a SEFAZ-PE é uma autorizadora, portanto as notas são enviadas para ela. Depois ela compartilha as notas recebidas bem como os eventos com o Ambiente Nacional. Sendo assim é aceitável que na SEFAZ-Autorizadora existe a nota e no Ambiente Nacional não. Uma vez que esse compartilhamento não é instantâneo.

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?