Italo Giurizzato Junior

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.

Bom dia Egon, Você costuma visitar o Portal Nacional da NF-e? Pelo jeito não, pois se visitasse diariamente iria ver que foi publicado uma nova Nota Técnica prorrogando o prazo para dezembro o ambiente de produção. Isso explica que uma nota enviada para o ambiente de produção é rejeitada com as notas TAGs.

Bom dia Régys, Você já pensou que maravilha se todas as cidades fizessem um convenio com a SEFAZ para aceitar a NF-e ou NFC-e somente com serviços? Iria acabar com essa zorra que é a NFS-e.

Boa tarde Cleyton, Com a NFC-e isso não será possível, como você já sabe. A saída que vejo é emitir a NFC-e no decorrer do mês e no fechamento emitir uma Fatura relacionando todas as notas e o valor total. Essa fatura com certeza terá um boleto para o pagamento, pois tudo indica que o pagamento é mensal.

Boa tarde a todos, Quando alimentar um campo do componente com o CNPJ ou CPF, favor informa-lo sem a mascara.

Boa tarde shdw, Tudo indica que você pode ter um NFC-e conjugada, ou seja, produtos mais serviços. Pois não encontrei nenhuma regra que rejeite uma NFC-e com item de serviço. Mas lembre-se que deverá ter no minimo um item de produto e tem que haver um acordo firmado entre o município e a SEFAZ do Estado.

Boa tarde a todos, No que diz respeito a numeração sequencial do evento, devemos levar em consideração o seu tipo. Cada tipo de evento tem a sua numeração sequencial iniciada em 1, sendo assim vamos a um exemplo: Foi solicitado uma CC-e para uma NF-e a numeração sequencial do evento CC-e é 1 pelo simples fato dela ser a primeira. Caso tenhamos uma segunda CC-e a numeração sequencial será 2. Suponha que em seguida essa mesma NF-e venha ser cancelada, qual será o numero sequencial do evento de cancelamento? A resposta é simples: 1 Porque? Leia novamente a linha acima em negrito. Complementando o que Régys escreveu, também não existe mais o PathCan.

Bom dia Agnaldo, Entendo perfeitamente o seu desabafo. Mas note que a NT 2015/002 versão 1.00 no final da página 2 consta as seguintes datas: 01/10/2015 para homologação e 03/11/2015 para produção. Eu baixei essa NT no dia 28/07/2015 portanto 2 meses antes do inicio para homologação, prazo este suficiente para que nós fizéssemos as devidas alterações no componente e depois mais um mês para realizar os testes de envio com a nova TAG em ambiente de homologação. Já a NT 2015/002 versão 1.10 no final da página 3 consta que a data para o ambiente de produção foi prorrogada para 01/12/2015 e no final da página 2 diz que as regras de validação na SEFAZ vão começar a valer somente a partir de 01/01/2016. Isso significa que se você pode gerar ou não o XML com a nova TAG depois de 01/12/2015 sem nenhum problema, uma vez que a validação da mesma só vai ocorrer a partir de 01/01/2016, portanto ganhamos mais 2 meses para deixar tudo redondo. Eu baixei a versão 1.10 da NT no dia 19/10/2015, portanto quase 15 dias antes do previsto para entrada em produção informada pela versão 1.00 da mesma NT. Sendo assim não vejo nenhuma falta de respeito por parte do ENCAT, pois informou com antecedência que o prazo seria prorrogado. Não estou defendendo ninguém apenas sendo justo. Não sei quanto a você, mas eu, todos os dias de manhã visito os Portais Nacionais da NF-e, CT-e e MDF-e em busca de algum Manual, Nota Técnica ou Schemas novos. Tenho todos os PDFs baixados desta forma sei se tem algo novo ou não, caso afirmativo, baixo e leio para saber do que se trata. Se você não fizer isso, sempre será pego de surpresa.