Italo Giurizzato Junior

Antonio, Não. 1. Alimentar o componente; 2. Executar o método Assinar; 3. Executar o método Validar; 4. Executar o método Enviar;

Antonio, Na minha aplicação depois que o componente é alimentado com os dados pertinentes a venda, executo o método Assinar e depois o Validar e por fim o Enviar. Desta forma se a minha aplicação chegar a enviar eu tenho certeza que o XML foi gerado assinado e validado. Caso ocorra algum problema no retorno da SEFAZ, ou seja, queda de conexão com a internet ou timeout, o procedimento a ser feito é: carregar o XML assinado e depois executo o método Consultar. Se o problema realmente foi no retorno e se nessa consulta tudo ocorrer bem com a conexão e a nota foi autorizada, o componente se encarrega de acrescentar o protocolo de autorização ao XML. Desta forma o XML fica completo, ou seja, assinado e protocolado, portanto passa a ser um documento fiscal eletrônico com validade jurídica. Desculpe, mas um XML de uma NF-e sem assinatura não serve para nada. Não serve para ser enviado para SEFAZ e nem para realizar a consulta em caso de falha no retorno. Pois para ser enviado precisa estar assinado e um XML sem assinatura e com protocolo de autorização também não serve para nada, pois não tem validade.

Rodrigo, O emitente do CT-e, no caso a transportadora, mais o tomador do serviço, ou seja, quem vai pagar o frete, mais o contador devem ter os seguintes arquivos: <chave>-cte.xml ===> XML referente ao CT-e, assinado e com o protocolo de autorização, esse XML é um documento fiscal eletrônico valido juridicamente. <tipoevento><chave><seq>-procEventoCTe.xml ===> XML referente ao processamento de um evento, esse XML contem a solicitação do evento, esta assinado e com o protocolo acusando que o evento foi registrado e vinculado ao CT-e, portanto também é um documento fiscal eletrônico valido juridicamente. Esses dois arquivos tanto o emitente quando ao tomador do serviço devem possuir e guarda-los pelo tempo estabelecido na legislação. O contador vai utiliza-los para fazer a escrita fiscal, etc. O *-procEventoCTe.xml que devemos enviar para o contador até onde sei é somente o de cancelamento, mas é bom conversar com ele.

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

Boa tarde Mateus, Porque você acrescentou zeros a esquerda para que o CPF ficasse com 14 dígitos? Tem que deixa-lo com 11 dígitos.

Boa tarde Fernandes, Faça o seguinte teste: Em ACBrCTeWebServices altere a linha 2429 de: Leitor.Arquivo := FPDadosMsg; Texto := '<' + ENCODING_UTF8 + '>' + para: Leitor.Arquivo := FPDadosMsg; Texto := // '<' + ENCODING_UTF8 + '>' + Depois compile a sua aplicação com a opção Build e faça um novo teste.

Antonio, Pelo que eu entendi o XML referente a NF-e esta sendo salvo em duas pastas distintas, correto? Se sim, acho que encontrei o motivo: Quando você utiliza o GravarXML você acaba setando uma propriedade chamada NomeArq. O componente ao atualizar o XML com o protocolo de autorização executa as seguintes linhas: // Salva o XML da NF-e assinado e protocolado if NaoEstaVazio(NomeArq) and FileExists(NomeArq) then FPDFeOwner.Gravar( NomeArq, XML ); // Atualiza o XML carregado GravarXML; // Salva na pasta baseado nas configurações do PathNFe No IF ele checa se a propriedade NomeArq esta vazia ou não, no seu caso não esta, portanto o XML é salvo com a assinatura e protocolo de autorização. Depois é executado o GravarXML que vai salvar o XML com a assinatura e com o protocolo na pasta definida em PathNFe. Agora caso você queira manter o XML sem assinatura (não sei para que?) e sem protocolo na pasta "GERADOS" será preciso após executar o GravarXML(Nome_do_Arquivo) atribuir uma string vazia a propriedade NomeArq. Por exemplo: ACBrNFe1.NotasFiscais.Items[X].NomeArq := ''; Onde X é a posição da nota dentro da lista, caso você tenha apenas uma nota o valor de X é zero.

Boa tarde, No meu entendimento a lógica esta correta. Mas aconselho você procurar um bom contador.

Boa tarde Antonio, Se você configurar o componente para salvar os arquivos fiscais, ou seja: Configuracoes.Arquivos.Salvar := True; Antes de enviar basta executar o método Assinar. Desta forma você vai ter o XML salvo em disco e já assinado. Caso falhe o retorno da SEFAZ, basta carregar esse XML com o LoadFromFile e mandar executar o método Consultar. No meu entendimento o XML assinado mesmo que esteja sem o protocolo de autorização tem muito mais utilidade do que o XML sem a assinatura. Pois é preciso ter o XML assinado para poder realizar a consulta, no caso de uma falha.

Boa tarde, Não precisa atualizar todos os clientes no dia 01/12/2015. O Ambiente de produção vai passar a aceitar o XML com as TAGs novas a partir dessa data, mas a SEFAZ só vai fazer criticas sobre essas informações somente a partir de janeiro de 2016. Portanto você vai ter UM mês para atualizar os seus clientes.

Boa tarde, A Carta de Correção é um evento, alias foi o primeiro evento criado pela SEFAZ. Na época o pessoal criou um path exclusivo para a CC-e. Mas acontece que depois veio os eventos: Cancelamento, Manifestação do Destinatário entre outros. Para não ficar criando um path para cada tipo de evento, ficou decido que seria criado um Path exclusivo para eventos. E dentro da pasta definida por esse path é criado uma pasta chamada Evento e dentro desta uma pasta com o nome do evento. Por fim dentro de cada pasta referente ao evento, os XMLs de envio, retorno e processamento.

Boa tarde Werner, Desculpe não entendi direito quais são as informações que deseja alimentar no componente ACBrCTe.

Bom dia Rodrigo, Não entendi o final da sua rotina. Para que você gera o CTe novamente, assina, valida e consulta? Isso já foi feito se você vai cancelar é de se esperar que você já tenha o XML gerado, assinado, validado e com o protocolo de autorização. Com o envio do evento do cancelamento você terá o XML (*-procEventoCTe.xml) que contem a solicitação do cancelamento a assinatura digital e o retorno da SEFAZ acusando que o evento foi registrado e vinculado ao CT-e bem como o protocolo de cancelamento. E é esse arquivo que você deve enviar para o tomando do serviço bem como para a contabilidade a fim de que eles fiquem ciente que o CT-e foi cancelado.

Bom dia Felipe, Apesar de constar na Nota Técnica que podemos incluir essa TAG no XML e envia-lo para o ambiente de homologação a fim de testes, uma vez que consta que foi liberado no dia 01/10/2015, a SEFAZ pode não ter feito todas as alterações necessárias para aceitar essa TAG. Ou existe alguma outra coisa errada no XML gerado.

Bom dia Antonio, O protocolo é acrescentado no XML somente depois do seu envio a SEFAZ. Se após alimentar o componente com os dados da venda você executar o método GravarXML será salvo em disco o XML sem assinatura e sem protocolo como é de se esperar. Por outro lado se após alimentar o componente, você executar o método Assinar será salvo em disco o XML com a assinatura e sem o protocolo como é de se esperar. Um detalhe importante, antes de alimentar o componente com os dados da primeira nota (uma vez que podemos ADD até 50 notas) devemos executar o seguinte linha: ACBrNFe1.NotasFiscais.Clear;

Bom dia, O arquivo ACBrNFeServicos tem as URLs para a NF-e e para NFC-e. Existe as seções: [NFCe_AM_P] NfeAutorizacao_3.10=https://nfce.sefaz.am.gov.br/nfce-services/services/NfeAutorizacao NFeRetAutorizacao_3.10=https://nfce.sefaz.am.gov.br/nfce-services/services/NfeRetAutorizacao (...) e [NFCe_AM_H] NfeAutorizacao_3.10=https://homnfce.sefaz.am.gov.br/nfce-services-nac/services/NfeAutorizacao NFeRetAutorizacao_3.10=https://homnfce.sefaz.am.gov.br/nfce-services-nac/services/NfeRetAutorizacao (...) Agora fica a pergunta, você esta configurando corretamente o componente (ModeloDF := moNFCe) ?

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;

Antonio, Mas a chave do XML que acaba de ser gerado é a mesma que consta nos dados do protocolo?

Boa tarde José, Noite que você esta atribuindo somente a Data em vez de Data/Hora ao alimentar os campos dhEmi e dhSaiEnt ficando o XML desta forma: <dhEmi>2015-10-27T00:00:00-03:00</dhEmi> <dhSaiEnt>2015-10-27T00:00:00-03:00</dhSaiEnt> Outra coisa, esta nota foi autorizada em: <dhRecbto>2015-10-27T10:17:17-03:00</dhRecbto> Por outro lado a solicitação de cancelamento foi: <dhEvento>2015-10-28T16:55:11-03:00</dhEvento> O prazo para o cancelamento não é de UM dia e sim de 24 horas a contar do momento que a nota é autorizada. Sendo assim o cancelamento deveria ter ocorrido até as 10:17:17 do dia 28/10/2015, mas foi solicitado as 16:55:11, portanto mais de 6 horas após o prazo. Acredito que a SEFAZ errou ao gerar a mensagem de rejeição. Regra de validação especifica do evento Cancelamento de NF-e - GA06: Verificar se NF-e autorizada há mais de 1 dia (24 horas), considerando também a exceção de prazo definida em legislação estadual.

Boa tarde Antonio, Se o XML ainda não foi enviado para a SEFAZ é impossível que o mesmo já tenha o protocolo de autorização. Agora após gerar o XML (eu preciso verificar) pode ser que o mesmo venha ser automaticamente assinado.

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

Antonio, No envio Síncrono não se faz necessário realizar uma consulta, pois ao enviar o lote contendo apenas UMA nota a SEFAZ já retorna o protocolo de autorização caso a mesma tenha sido autorizada. Dai o motivo de ler o status do Enviar em vez do de Retorno. Desculpe não entendi direito a sua segunda pergunta, reformule ela novamente.

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.