Italo Giurizzato Junior

Boa tarde Marcos, Você esta carregando o XML do CT-e com o LoadFromFile antes de executar o método Consultar?

Josemar, Quando você diz finalizar esta querendo dizer enviar o evento de encerramento, correto? Se sim, faça como Fabrício estudo a rotina do botão [Encerramento] do programa exemplo e compare com a sua, pode ser que você esteja fazendo algo errado.

Josemar, O XML com final 0019.xml esta assinado e protocolado como autorizado. O XML com final 0019-mdfe.xml não esta assinado e muito menos protocolado. O XML com final 0016-mdfe.xml esta assinado e protocolado como autorizado. Quando você diz que o inicio de um é diferente do outro (vide os que estão em negritos) é pelo simples fato de um conter o protocolo e o outro não. Antes de enviar devemos gerar e assinar o XML, para tal basta alimentar o componente com os dados e executar o método Assinar. Esse método gera o XML assina e salva em disco (caso a propriedade Configuracoes.Arquivos.Salvar for igual a True). Se ocorrer algum erro após o envio a primeira coisa a fazer é carregar o componente com o XML enviado e em seguida executar o método Consultar. Esse método vai checar se o MDF-e consta ou não na SEFAZ se sim, vai retornar o resultado do processamento, caso tenha sido autorizado o XML será atualizado recebendo o protocolo de autorização. A partir dai basta imprimir o DAMDFE. Por outro lado se após a consulta retornar uma mensagem informando que o MDF-e não consta da base de dados da SEFAZ, fica claro que o erro ocorreu no envio e não no retorno. Logo devemos enviar novamente.

Boa tarde Luciano, Deve usar o teDPEC uma vez que este foi substituído pelo EPEC. Foi mantido o nome ainda por mera compatibilidade uma vez que o tipo de emissão do DPEC e EPEC é "4".

Boa tarde Marcos, Na procedure EnviarDados temos apenas duas linhas onde faz referencia ao certificado digital. N primeira é checado se o XML esta assinado ou não, mas neste caso o componente não se utiliza do certificado, apenas verifica se existe ou não a TAG Signature no XML, portanto não há motivo de se preocupar. A segunda verifica a validade do certificado: if FPConfiguracoes.Certificados.VerificarValidade and (FPDFeOwner.SSL.CertDataVenc < Now) then raise EACBrDFeException.Create('Data de Validade do Certificado já expirou: '+ FormatDateBr(FPDFeOwner.SSL.CertDataVenc)); Acredito que se alterarmos o código acima para: if FPConfiguracoes.Certificados.VerificarValidade then if (FPDFeOwner.SSL.CertDataVenc < Now) then raise EACBrDFeException.Create('Data de Validade do Certificado já expirou: '+ FormatDateBr(FPDFeOwner.SSL.CertDataVenc)); E atribuir o valor False a propriedade VerificarValidade não teremos problemas no que diz respeito ao certificado.

Boa tarde Josemar, Os arquivos são de grande ajuda, favor postar como anexo.

Bom dia Akai, Os parâmetros IncluiEncodingCab e IncluiEncodingDados serve para incluir no cabeçalho e ou no dados a linha: <?xml version="1.0" encoding="UTF-8"?> Veja o INI do Ginfes não maioria dos serviços temos: IncluiEncodingCab=0 IncluiEncodingDados=0 Já no caso do Cancelar temos: [Cancelar] IncluiEncodingCab=0 IncluiEncodingDados=1 <=== indica que a mensagem de dados vai começar com o encoding. Para alguns provedores o cabeçalho e ou dados devem ser convertidos para string neste caso temos: (...) Cabecalho=1 Se um, temos o cabeçalho e ou dados no formato string, se zero, formato XML. Dados=1 Espero ter ajudado.

Bom dia a todos, Não existe mais o DPEC e nem o SCAN. Eles foram substituídos pelo evento EPEC e pela contingência SVC. Favor lerem as Notas Técnicas 2014/001 versão 1.10 que trata sobre o evento EPEC e a 2013/007 versão 1.03 que trata sobre o SVC.

Bom dia, Muito obrigado pela colaboração, já esta disponível.

Bom dia, Post como anexo o XML de envio referente ao evento e o de retorno. Primeiro configure o componente para salvar os arquivos soap. Configuracao.WebWervices.Salvar := True;

Bom dia Moacir, Que tal usar os Schemas da pasta: ...\Exemplos\ACBrDFe\Schemas\NFe

Bom dia a todos, No que diz respeito ao PIS / COFINS segundo um contador que conheço diz que: se o CST do PIS for 01 do COFINS também é, o que muda é o percentual de cada um.

Bom dia Wellington, Veja a estrutura de pastas através do Explorer. No meu caso a pasta principal é ACBrTrunk e dentro desta temos as pastas: DLLs, Doctos, Exemplos, Fontes, Pacotes, Projetos e Testes. O caminho para chegar até a pasta que contem o programa exemplo do ACBrNFe é: C:\ACBrTrunk\Exemplos\ACBrDFe\ACBrNFe\Delphi O que esta em negrito pode ser diferente na sua maquina, mas o resto é igual.

Bom dia Douglas, Quando escrevi que precisa estudar mais, eu estava me referindo a mim e não a você, pois a alteração no componente para que o mesmo incluísse o protocolo de denegado ao XML foi feita por mim. Eu que devo desculpa por não ter me expressado de forma clara. Quando enviamos uma nota a SEFAZ podemos ter 3 tipos de respostas: 1. Autorizada, neste caso a nota é registrada no banco de dados da SEFAZ, sendo assim o XML tem que ser atualizado com o protocolo de autorização. 2. Rejeitada, neste caso a nota não é registrada no banco de dados da SEFAZ, sendo assim devemos efetuar as devidas correções e enviar novamente. 3. Denegada, neste caso a nota é registrada no banco de dados da SEFAZ, sendo assim no meu entendimento o XML tem que ser atualizado com o protocolo de denegação. Uma nota denegada não pode ser corrigida e enviada novamente, uma vez que ela esta registrada na SEFAZ, portanto não cabe uma correção. Acredito eu que também não cabe cancelamento, apesar da nota ter sido registrada, ela não foi autorizada, sendo assim a venda não pode ser realizada, não foi autorizada pela SEFAZ. Em um primeiro momento achei que no caso de uma denegação deveríamos alterar o nome do XML de <chave>-nfe.xml para <chave>-den.xml, mas da forma que esta as rotinas hoje esta gerando os dois arquivos com o protocolo de denegação. Estou chegando a uma conclusão que o melhor seri manter o nome <chave>-nfe.xml Se esse XML estiver apenas assinado podemos concluir que o mesmo foi gerado assinado e não foi enviado ainda ou se foi enviado não foi autorizado, ou seja, rejeitado ou ocorreu um erro no retorno, neste caso cabe uma consulta. Por outro lado se o XML estiver assinado e protocolado devemos ler os dados desse protocolo para saber se a nota esta autorizada ou denegada.

Bom dia Agnaldo, Não sei não, se você enviar um lote com 3 notas os números dos protocolos não serão sequenciais? Algo do tipo 100, 101 e 102. Se depois você vier a cancelar a primeira o numero de protocolo de cancelamento não seria 103? Seguindo desta forma uma sequencia na numeração dos protocolos?

Bom dia ncc, Estou achando que seria a solução, ter dois schemas uma para OpenSSL e outro para o Capicom.

Bom dia José, Segundo a NT 2015/003 a data prevista para o ambiente de produção seria 03/11/2015 se esta ocorrendo a rejeição: Falha no Schema XML do CT-e isso significa que a SEFAZ não esta preparada para processar o CT-e com as novas TAGs publicadas na NT. Ou você espera até que eles implemente ou entre em contato e questione para saber quando vai ser liberado.

Boa tarde Gabriel, Obrigado pelo arquivo. Se você abrir ele com um navegador teremos logo no inicio a informação que a nota se encontra cancelada. Mas em seguida temos um grupo chamado <protNFe> que consta os dados da autorização da mesma. Por fim o grupo <procEventoNFe> que traz a solicitação do cancelamento a assinatura do emitente e o protocolo acusando que o evento foi registrado e vinculado. Maravilha isso sim é uma resposta descente a uma consulta sobre a situação de uma NF-e. Caso o XML da NF-e esteja sem o protocolo de autorização, ou seja, apenas assinado devemos extrair o grupo <protNFe> desse retorno a atualizar o XML da NF-e. Se conseguir um tempo este final de semana vou estudar os fontes e ver o que pode ser corrigido para que o componente realize essa operação.

Boa tarde Douglas, Note que ambos os arquivos estão com o protocolo de Denegação e possuem o grupo <infProt>. Estou achando melhor estudar essas questões de nota autorizada, rejeitada e denegada.

Bom dia Toninho, Página 150 do Manual CT-e versão 2.00a diz: Informações dos Motoristas - Só preenchido em CT-e rodoviário de lotação. E no seu caso não é lotação. Rodo.Lota:= ltNao;

Bom dia, Você se refere ao ACBrMonitor Plus ou ao componente ACBrNFe?

Bom dia a todos, Até quando vou ter que dizer que não se deve ler o arquivo XML cujo inicio é: <retDownloadNFe versao="1.00" xml Pois esse XML não é a nota retornada pelo método DownloadNFe e sim o retorno da SEFAZ. Pelo amor de Deus veja o nome da TAG inicial começa com ret, isso significa retorno. O método DonwloadNFe se encarrega de extrair do retorno a NF-e que pode inclusive estar compactada (depende da SEFAZ) e salvar em disco (se configurado) com o nome padrão, ou seja, <chave>-nfe.xml Para aqueles que desejam salvar a nota no banco de dados basta salvar o conteúdo retornado por: ACBrNFe.WebServices.DownloadNFe.retDownloadNFe.retNFe.Items[0].procNFe (extraído da postagem do Tiago) A propriedade procNFe contem o XML da nota propriamente dito e já descompactado caso tenha sido retornado desta forma pela SEFAZ. Favor ler mais as NT?

Bom dia Anderson, Já tentou obter essa informação da prefeitura? Se na cidade em questão a prefeitura exige do seu contribuinte a NFS-e as chances dela aceitar uma NF-e ou NFC-e conjugada é quase zero.

Bom dia Gabriel, E o arquivo de retorno? *-sit.xml Outra coisa o arquivo *-nfe.xml não contem o protocolo de autorização.

Bom dia, Nas minhas postagens a dica que dou é o seguinte: Se ocorrer falha após o envio, não devemos enviar a nota novamente, uma vez que não sabemos se a falha ocorreu de fato no envio ou no retorno da SEFAZ. Sendo assim o que devemos fazer é carregar o componente com o XML assinado usando o LoadFromFile e em seguida executar o método Consultar. Exemplo: ACBrNFe1.NotasFiscais.Clear; ACBrNFe1.NotasFiscais.LoadFromFile(XmlNFe); // o XML da NF-e a ser carregado esta assinado ACBrNFe1.Consultar; Se obtivermos uma resposta da SEFAZ informando que a nota não existe no banco de dados dela, isso significa que a falha ocorreu no envio, portanto devemos envia-la novamente. Por outro lado se a nota foi enviada e processada com sucesso vamos ter como resposta o protocolo de autorização, neste caso o método Consultar se encarrega de atualizar o XML deixando-o completo, ou seja, assinado e protocolo, pronto para ser enviado ao destinatário. Como você pode ver em nenhum momento foi necessário usar o GerarNFe e GravarXML.