Italo Giurizzato Junior

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.

De forma simplificada eu faço o seguinte: 1. Alimento o componente com os dados da nota; 2. executo o método Assinar; (este se encarrega de gerar o XML, assinar e salvar o mesmo em disco) 3. executo o método Validar; (este submete o XML assinado ao validado, caso tenha erros será abortado) 4. executo o método Enviar; (este se encarrega de enviar a nota para SEFAZ e atualizar o XML com o protocolo de autorização caso tenha sido autorizada) Não executo GerarNFe, GravarXML ou outra coisa aparecida apenas os 3 métodos acima.

Boa tarde Akai, Muito obrigado pela colaboração. Já esta no repositório.

Boa tarde ELJAK, Fiz algumas alterações pretendo disponibiliza-las ainda hoje. Quem sabe esse erro no cancelamento serja sanado. Quando ao consultar lembre-se que o XML da NFS-e é sempre retornada pelo provedor. O componente só gera o XML do RPS, portanto se o XML da NFS-e esta faltando alguma coisa, o problema é no provedor e não no componente.

Gabriel, Agora entendi o seu problema. Concordo com você, ao consultar uma Nota o XML tem que receber o protocolo de autorização caso a mesma tenha sido autorizada, independente se posteriormente tenha sido cancelada. Lembrando que o cancelamento é um evento. Se não me falha a memória não existe um consenso entre as SEFAZ, algumas no retorno sempre retorna o protocolo de autorização (caso tenha) e depois a lista de eventos, caso a nota senha sido cancelada o evento de cancelamento vai aparecer nessa lista. Outras retorna o protocolo de cancelamento no lugar de autorização (caso a nota tenha sido cancelada) e depois a lista de eventos. Se possível post como anexo o XML de retorno da SEFAZ ao consultar uma nota que foi autorizada e posteriormente cancelada.

Boa tarde Douglas, Vamos simplificar: Alimentar o componente >> Assinar >> Enviar >> Gravar XML no Banco O método Assinar já se encarrega de gerar e gravar o XML em disco. Você tem o retorno da SEFAZ que acusa que a nota foi denegada para que possamos analisar? Se sim, post como anexo.

Boa tarde Gabriel, Você atribuiu o valor True a: Configuracoes.Arquivos.Salvar ?

Boa tarde, Você esta atribuindo o valor True a propriedade de configuração: Configuracoes.Arquivos.Salvar? Outra coisa o GravarXML não grava o XML protocolado.

Bom dia Nilton, O seu entendimento não confere. A ideia é salvar todos os arquivos (envio, retorno, fiscais protocolados ou não, inutilização, eventos) em uma unica pasta definida em PathSalvar ou organiza-los em pastas definidas em PathCTe, PathInu e PathEvento.

Bom dia a todos, Martins, preste atenção onde esta postando pois o tópico se refere ao componente ACBrMDFe que não tem nada haver com emissão de NF-e. Será fechado.

Bom dia, Favor atualizar os fontes e testar novamente.

Bom dia Nilton, No meu entendimento devemos ter em disco o XML Assinado protocolado ou não. Antes do envio temos o XML Assinado se após o envio esse arquivo continuar sem o protocolo quais são os motivos? 1. Ele pode ter sido rejeitado e neste caso você tem controle, pois é possível capturar o status e a mensagem e apresentar para o usuário para que o mesmo tome as providencias. 2. Ele pode ter sido denegado e neste caso você tem controle, pois é possível capturar o status e a mensagem informando que o CT-e foi denegado. 3. Ocorreu uma falha que no primeiro momento não se sabe se foi no envio ou no retorno, mas é possível detectar que ocorreu uma falha, sendo assim devemos no primeiro momento carregar esse XML assinado que esta salvo e executar o método Consultar, se foi uma falha no retorno e o CT-e foi autorizado pela SEFAZ, o método Consultar se encarrega de atualizar o XML acrescentando o protocolo de autorização, ou teremos a situação de rejeitado ou denegado e nestes casos temos as soluções nos itens 1 e 2. Agora se ao Consultar obtermos a resposta acusando que o CT-e não consta na base de dados, fica claro que a falha foi no envio, portanto devemos carregar o XML assinado e envia-lo novamente. Quanto ao Geral.Salvar, até onde sei essa propriedade ficou definida que se o valor dela fosse True seria salvo em disco os arquivos não fiscais, ou seja, os arquivos de envio e de retorno. Por outro lado o Arquivos.Salvar se o seu valor for True é salvo em disco os arquivos fiscais.

Boa tarde Oteniel, Não existe correria nenhuma. As alterações promovidas pela NT 2015/003 já podem ser testadas no ambiente de homologação. A partir do dia 01/12/2015 já podem ser enviadas para o ambiente de produção. E se não enviar o que vai ocorrer? Absolutamente nada. Uma vez que somente a partir de 01/01/2016 é que as regras de validação da SEFAZ vão começar a checar se o XML esta em conformidade com a NT ou não. Sendo assim meu caro você tem o mês de dezembro inteiro para atualizar os seus clientes.

Bom dia a todos, Eljak acredito que você esta se referindo ao componente ACBrNFSe. Se sim, lembre-se que agora os provedores são arquivos INI, você pode se basear nos que já existem. O provedor ISSCuritiba segue o padrão ABRASF versão 1.00 e somente o Lote é assinado como é o caso do Ginfes. Sendo assim a principio basta criar o arquivo INI para o provedor e iniciar os testes.

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