Italo Giurizzato Junior

Favor testar com o ACBrMonitor Plus que o Régys disponibilizou em:

Só mais uma coisa, qual é a versão do monitor que você esta usando?

Realmente esta gerando com 4 casas decimais em vez de duas. Esse problema já foi detectado e foi corrigido. O que pode estar ocorrendo, essa versão do ACBrMonitor Plus que você esta usando deve ter sido compilado com o fonte sem a correção. Vou passar o caso para a equipe responsável pela compilação do Monitor.

Bom dia, Favor postar em anexo o XML da nota que foi rejeitado.

Bom dia Luis, Peço que leia a Nota Técnica 2014/002 versão 1.01 que trata sobre a Distribuição DF-e. O componente ACBrNFe possui um método chamado DistribuicaoDFe, para mais detalhes sobre esse método leia o Manual do ACBrNFe versão 1.04 que esta disponível na pasta: ...\Doctos\Manuais Não é através de uma consulta a situação atual da nota que você vai ter o que deseja e sim através do DistribuicaoDFe. Espero ter ajudado.

Boa noite Paulo, O DANFE é a representação gráfica do XML, se este não tem como imprimir o DANFE. O quem vem a ser o DANFE - Documento Auxiliar da Nota Fiscal Eletrônica, se é um documento auxiliar da nota não é nota, você concorda? Segundo a legislação - AJUSTE SINIEF 07/2005 diz: § 1º Considera-se Nota Fiscal Eletrônica - NF-e o documento emitido e armazenado eletronicamente, de existência apenas digital, com o intuito de documentar operações e prestações, cuja validade jurídica é garantida pela assinatura digital do emitente e autorização de uso pela administração tributária da unidade federada do contribuinte, antes da ocorrência do fato gerador. Esta claro que a Nota Fiscal propriamente dita é o XML e tem validade jurídica desde que esteja assinado digitalmente e contenha o protocolo de autorização. Sendo assim a guarda do XML tanto pelo Emitente quanto pelo Destinatário é extremamente importante. Se o contribuinte possui mais de uma maquina que emite as notas, no meu entendimento os XMLs devem ser salvos no servidor ou no banco de dados. Caso o contribuinte for uma empresa de pequeno porte ou micro empresa que possui apenas uma maquina que emite as notas e não possui um servidor, recomendo a aquisição de um HD externo para realizar uma cópia de segurança do banco de dados e dos XMLs. A empresa que trabalho esta isenta de emissão de notas, mas todos os dias recebemos por e-mail os XMLs das notas referente as compras que são realizadas. Todos esses XML são salvos no servidor, agrupados por <ano><mês>. Tenho uma aplicação onde você informa o caminho da pasta que contem os XML desejados, é apresentado a lista dos mesmos. ao clicar em uma da lista é apresentado o nome do emitente a data, numero do protocolo e numero da nota. Se clicar no botão [Imprimir] é apresentado na tela o DANFE, permitindo que usuário possa imprimir no papel.

Edison, Você esta com todos os fontes de todas as pastas atualizados? Compilou a sua aplicação com a opção Build? Não tem nenhum fonte cujo ícone possui uma bolinha vermelha ou triangulo amarelo?

Boa tarde Rafael, Esse seu cliente é que emite a Nota? Se sim ele, tem que possuir o XML da mesma para poder imprimir o DANFE, sendo assim não faz nenhum sentido o que você esta pensando em fazer. Como já disse o método Download é para ser utilizado pelo destinatário da nota e não pelo emitente. O método DistribuicaoDFe pode ser utilizado tanto pelo destinatário quanto pelo emitente, mas com esse método você só vai conseguir baixar as Notas emitidas contra o CNPJ do seu cliente e não as que ele emitiu. Posso ter 10 maquinas emitindo NF-e mas o XML das mesmas podem ser todos salvos no servidor sem nenhum problema, visto que a chave é diferente de cada nota, logo não corre-se o risco de sobrescrever. Por favor leia as NT: 2012/002 versão 1.02 - que trata sobre a Manifestação do Destinatário e Download 2014/002 versão 1.01 - que trata sobre o Web Service de Distribuição DF-e.

Boa tarde Rodrigo, Talvez o seu exemplo esteja correto, mas o melhor é confirmar com um contador e vamos esperar se sai uma nova NT.

Boa tarde Eleandro, Primeiro precisamos compreender a rejeição. A sua nota foi rejeitada pelo simples fato de que existe uma diferença no calculo da assinatura. O seu XML esta assinado, a SEFAZ ao receber esse XML faz um calculo e compara com o da assinatura se for igual ótimo se for diferente a nota é rejeitada. Quando ocorre essa diferença? Quando o XML assinado sobre uma alteração. Outra coisa notei que as TAGs dhEmi e dhSaiEnt só contem a data a hora esta aparecendo zerada. Isso esta errado, devemos informar a data e hora de emissão da nota, logo você deve usar Now em vez de Date.

Boa tarde Bruno, Após realizar a alteração no INI você executou o Compila_RES antes de compilar a sua aplicação com o Build?

Boa tarde Paulo, Você quer usar o método Download para baixar o XML que foi emitido por você só para imprimir novamente o DANFE, é isso? Se sim, esta confundindo as coisas. O método Download é para ser utilizado pelo Destinatário da nota e não pelo Emitente. Para imprimir novamente o DANFE basta carregar o XML usando o LoadFromFile e depois executar o método Imprimir. Outra coisa o Emitente é obrigado pela legislação a guardar o XML assinado e protocolado pelo tempo legal. O XML pode ser salvo em disco ou no banco de dados, mas tem que ter o mesmo.

Boa tarde Robson, Mas o XML que o André postou foi enviado para o ambiente de produção, dai a rejeição.

Pessoal, Quanto mais pessoas entrarem em contato e relatar o problema, mas chances deles se mexerem para arrumar. Exponham o problema de forma clara, digam que a SEFAZ esta recusando o CT-e pela falta da TAG CST dentro do grupo ICMSSN, mas não existe nenhuma NT que apresenta essa alteração na estrutura do XML. E digam também que no ambiente de produção esta OK.

Boa tarde Edison, Utilize os schemas que estão na pasta: ...\Exemplos\ACBrDFe\Schemas\NFe

Boa tarde Delmar, O nome do campo é CEST, o programa exemplo é um exemplo e não uma aplicação acabada para ser usada pelo seu cliente. É para você aprender como o componente funciona. Temos a obrigação de garantir que o componente esteja em conformidade com os Manuais e Notas Técnicas.

Boa tarde a todos, Renan, note que na mensagem de erro consta que a TAG CST era experada, mas foi encontrado primeiro a TAG indSN. Outra coisa o CT-e autorizado foi enviado para o ambiente de produção, por outro lado o que foi rejeitado foi enviado para o ambiente de homologação. Chegou até ser disponibilizado um novo schema que constava a TAG CST dentro do grupo ICMSSN, mas nenhuma Nota Técnica foi publicada sobre essa alteração e o schema foi corrigido. Não sei se essa alteração vai realmente ocorrer ou não, mas o fato é que o ambiente de homologação esta pedindo essa TAG. Favor entrar em contato com a SEFAZ e expor o problema.

Tony, Acho que você ainda esta fazendo confusão, se estivéssemos usando um Schema errado o XML de solicitação de cancelamento não seria validado antes do seu envio. Caso você tenha o XML ( *-ped-eve.xml ) de um cancelamento gerado pela sua aplicação quando usava os fontes do Trunk compare com o mesmo arquivo de um cancelamento gerado agora com os fontes do Trunk2. Desta forma você vai saber se com o Trunk2 o XML esta sendo gerado de forma incorreta ou não.

Bom dia Andre, Você leu o que lhe pedi? Ao informar 9 em indIEDest, você esta dizendo que o destinatário não é contribuinte e segundo o seu XML o destinatário possui CNPJ e IE. Outra coisa leia atentamente a regra NA01-30 que esta na página 11 da Nota Técnica 2015/003 versão 1.40, é essa regra que gera a rejeição: Informado indevidamente o grupo ICMS para a UF de destino. Existem vários campos que são checados para que a nota seja rejeitada ou não, uma delas diz respeito a data de emissão. A data de emissão da nota que você postou é 14/12/2015, agora veja qual é a data que esta na regra.

Bom dia Claudio, Você estudou para ser capaz de interpretar o que o cliente quer e desenvolver um software. O contador estudou para ser capaz de interpretar a legislação no que diz respeito a tributação e saber colocar no papel como devem ser feitos os cálculos. Agora se o contador do seu cliente não consegue fazer isso, ou ele troca de contador ou intima o mesmo a procurar a resposta.

Bom dia Fernandes, Lembre-se que ao enviar uma NFC-e podemos realizar esse envio no modo Assíncrono (quando o lote tem 2 ou mais notas, máximo de 50) ou no modo Síncrono (quando o lote tem apenas 1 nota). Quando enviamos no modo Síncrono a SEFAZ em vez de retornar o numero do recibo para realizarmos a consulta, ela já retorna o protocolo de autorização, caso a mesma tenha sido autorizada. Por outro lado no modo Assíncrono a SEFAZ retorna o numero do recibo, sendo assim devemos utiliza-lo para realizar a consulta. Eu não sei qual é o modo de envio que você esta usando, se for o Síncrono pode ser o motivo de ao realizar a consulta você esta obtendo um retorno vazio, visto que no envio Síncrono você não tem o numero do recibo.

Bom dia Rafael, É nestes casos que devemos ter uma opção de configuração na aplicação que permite salvar os arquivos soap, ou seja: Configuracoes.WebServices.Salvar := True; Com essa configuração os arquivos de envio e de retorno serão salvos em discos exatamente como são enviados para SEFAZ e o respectivo retorno. Podemos identificar esses arquivos através da palavra soap no nome do XML. Analisando os arquivos de retorno podemos com mais facilidade descobrir o que esta ocorrendo.

Bom dia Murilo, Ao utilizar o método DistribuicaoDFe temos vários tipos de retornos, tais como: resNFe, resEvento, nfeProc e procEventoNFe. Em resNFe temos apenas um resumo da nota e neste resumo temos a data e hora de emissão da nota e para obter essa informação basta ler a propriedade dhEmi da seguinte forma: dhEmissaoNFe := DistribuicaoDFe.retDistDFeInt.docZip.Items[ X ].resNFe.dhEmi; Em resEvento temos apenas um resumo do evento e neste resumo temos a data e hora de emissão do evento e para obter essa informação basta ler a propriedade dhEvento da seguinte forma: dhEmissaoEvemto := DistribuicaoDFe.retDistDFeInt.docZip.Items[ X ].resEvento.dhEvento; Em nfeProc temos a nota completa inclusive com a assinatura e protocolo de autorização e para obter a data e hora de emissão basta ler a propriedade dhEmi da seguinte forma: dhEmissaoNFe := DistribuicaoDFe.retDistDFeInt.docZip.Items[ X ].resNFe.dhEmi; Em procEventoNFe temos o evento completo, ou seja, a solicitação e o retorno da SEFAZ acusando que o mesmo foi registrado e vinculado a nota e para obter a data e hora de emissão do evento basta ler a propriedade dhEvento da seguinte forma: dhEmissaoEvemto := DistribuicaoDFe.retDistDFeInt.docZip.Items[ X ].procEvento.dhEvento; Dica: abra o fonte pcnRetDistDFeInt.pas para saber quais são as informações disponíveis em cada tipo de retorno.

Bom dia Tony, O componente não gera o XML com base no XSD e sim utiliza este último para validar o XML gerado. Se o XML gerado ao ser confrontado com o Schema (arquivo XSD) o componente para acusando erro de validação. O seu problema é outro, trata-se de uma rejeição. Isso significa que o XML foi gerado, validado e enviado, mas a SEFAZ esta recusando-o. Como as SEFAZ estão passando por um processo de mudanças, pode muito bem ter ocorrido algum problema nas rotinas deles que esta provocando essa rejeição.

Boa tarde ALA, Apesar de constar na NT que a regra NA11-10 só será colocada em pratica a partir de 01/01/2016 pode ser que a SEFAZ tenha habilitado essa regra sem querer querendo. Favor entrar em contato com a SEFAZ.