Eduardo Santana
-
Total de ítens
87 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Eduardo Santana
-
-
-
resolvido, foi o CSC que eu nao tinha posto o de homologação
-
2
-
-
estou fazendo teste no ambiente de homologação e estou recebendo essa rejeição.
-
Em 18/05/2019 at 15:26, Gabriel Franciscon disse:
Boa tarde, @Eduardo Santana!
Nota fiscal emitida pelo seu próprio cliente: não tem como recuperar apenas com a chave de acesso. É necessário carregar o componente ACBrNFe com todos os dados da nota fiscal novamente.
Vou deixar um outro tópico aqui embaixo onde eu explico melhor sobre essa questão, com exemplos:
Entendido. obrigado!
-
1
-
-
Como faço para recuperar um xml consultando apenas a chave? tipo assim :ACBrNFe.WebServices.Consulta.NFeChave :=
ACBrNFe.NotasFiscais.Assinar;
ACBrNFe.Consultar; -
2 horas atrás, lesf disse:
Quando for emitida uma NF-e e PELO MENOS UMA das situações abaixo estiverem descritas na Operação da NF-e e FOR INFORMADO o Grupo de ICMS para a UF de Destino (ICMSUFDest), será retornado a rejeição "695 - Informado indevidamente o grupo de ICMS para a UF de destino":
-
Operação Estadual (idDest = 1) ou com Exterior (idDest = 3);
-
Operação com Consumidor Normal (indFinal = 0);
-
Operação com Contribuinte (indIEDest = 1) ou com Contribuinte Isento (indIEDest = 2);
-
Operação de prestação de serviços (ISSQN);
-
Operação com combustível (comb) derivado de petróleo. Código ANP diferente de: 820101001, 820101010, 810102001, 810102004, 810102002, 810102003, 810101002, 810101001, 810101003, 220101003, 220101004, 220101002, 220101001, 220101005, 220101006, 560101001;
- Data de Emissão anterior a 01/01/2016, em Produção.
Será que o item 5 não seria o seu problema Eduardo ? Tem um item (1) na sua NF que é derivado de petróleo.
Obrigado pessoal, no meu caso, foi o codigo ANP que estava invalido!
-
1
-
Operação Estadual (idDest = 1) ou com Exterior (idDest = 3);
-
Não conseguir identificar o erro
-
Ignorem, por favor!
-
20 horas atrás, BigWings disse:
O cancelamento por substituição pode ser feito em até 168 horas.
Obrigado pessoal , as dicas me ajudaram muito!
-
1
-
-
Apos uma consulta
ACBRNFCe.Consultar;
obtenho o arquivo de retorno em anexo, gostaria de capturar a tag chnfe desse xml.
Ja tentei , ACBRNFCe.WebServices.Consulta.chnfe , e não vai
-
15 horas atrás, BigWings disse:
Você precisa comparar a chave da NFe que está enviando com a chave da NFe retornada na mensagem de rejeição.
No caso a NFe que está enviando tem a chave:
29190415914452000237650550000010479000010477
Onde ocorreu a rejeição de duplicidade com diferença na chave, sendo a chave já autorizada:
29190415914452000237650550000010471000010471
A diferença é o tipo de emissão da NFe, ela foi autorizada no tipo de emissão normal e você está tentando enviar a mesma numeração com tipo de emissão em contingência off-line.
Provavelmente tem algo errado na sua rotina para ter gerado duas chaves diferentes para a mesma numeração, veja este tópico para dicas de como tratar a contingência:
Envie a nfc-e de numero 20, não tive retorno, deu timeout, então gerei off-line a 21, a internet voltou 24hr depois, agora consigo enviar a 21, porem a 20 não consigo mais cancelar. Como fica essa questão?
-
34 minutos atrás, Juliana Tamizou disse:
Boa tarde,
Verifique se seu problema não tem relação aos valores passados na propriedade cNF, conforme explicação dada a outro usuário pelo @Italo Jurisato Junior.
Att.
pelo que me consta não é isso , pois ainda estou passando o numero da nota no campo cnf, como posso identificar se é realmente isso?
-
10 minutos atrás, EMBarbosa disse:
Se você está recebendo rejeição de duplicidade, o mais certo é que a NF-e já está nos servidores da SEFAZ.
Você chegou a consultar a nota para conferir se ela já foi transmitida?
Não sei se conhece, mas pode ser interessante ver os vídeos relacionados com esse tema, como o segundo vídeo relacionado a contingência:
"NFC-e e SAT - Como tratar a contingência - Segundo Encontro"
Sim, ja consultei e constatei que ele ja foi transmitida, só que o meu xml local esta sem protocolo de autorizacao. Como faço para atualizar meu xml. Já assistir aos vídeos e não identifiquei como resolver e sim como evitar.
-
Estou recebendo a rejeicao 539 ao tentar enviar uma nfc-e que foi emitida off-line
1047-pro-lot.xml 29190415914452000237650550000010479000010477-nfe.xml
-
Ao enviar uma nfc-e emitida anteriormente off-line estou recebendo a Rejeição 204
O que fazer nesse caso?
293065070699289-pro-rec.xml 29190405603617000115650010000001279000001273-nfe.xml
-
Após o envio de nfc-e em contingencia , como faço para pegar o Cstat do xml de evento?
-
13 minutos atrás, Juliana Tamizou disse:
Boa tarde.
O CFOP dos itens 3,4 e 6 se inicia em 6, creio que está ai o problema.
Att.
Realmente o CFOP deveria ser 5405
Obrigado a todos!
-
1
-
-
alguem pode me ajudar a identificar, estou com essa rejeição ao enviar essa contingencia
-
Alguem pode ajudar a identificar esse erro?
-
A contadora ("pouco disposta") me instruiu a fazer uma nota de devolução onde irá anexar no livro de ocorrência da empresa.
Vou dar encaminhamento, e assim que tiver um desfecho, compartilho o resultado.
-
2
-
-
Uma hipótese. Um funcionario mal intencionado ou até mesmo por ignorancia fez uma nfc-e no valor de 1.000.000,00 em um estabalecimento que custuma faturar 20.000,00 mês e só notou essa emissão 30 dias após. o que fazer?
-
Pessoal bom dia!
Identifiquei que minha aplicação esta a aproximadamente 30 dias gerando xml (nfc-e) com erro e mesmo assim esta autorizado:
O erro é o seguinte, exemplo
produto bala, preco de venda 2,00
vendi 5 balas e alterei na tela do pdv que o preco de venda unitario de venda seria 1,00
sendo assim o sistema deveria registrar 5,00 de desconto e 5,00 pagos, porem como podem ver no xml em anexo não multipliquei o desconto pela quantida e o desconto ficou como apenas 1,00 total a pagar 9,00 valor pago 5
O detalhe é que um clientes fez procedimentos semelhantes a estes , só que com valores muito autos.
Por favor me orientem do que posso fazer pois para reverter os xmls ja emitidos, pois a aplicação ja esta corrigida, mas o que fazer agora que os impostos ja foram calculados?
valor aproximado que o clientes custuma pagar de imposto é 2.000,00 e veio quase 10.000,00
-
1 hora atrás, Italo Jurisato Junior disse:
Boa tarde Eduardo,
Se esta ocorrendo esse erro de duplicidade com diferença de chave a explicação é simples.
Ao enviar novamente o XML esta sendo gerado também novamente, mas como o valor de cNF esta com o valor zero o componente se encarrega de gerar um condigo aleatório, pois o valor de cNF faz parte da composição da chave.
E por orientação da SEFAZ o valor de cNF tem que ser um numero aleatório.
Caso aja a necessidade de gerar novamente o XML, é prudente que ao gerar pela primeira vez o XML o valor de cNF seja um numero aleatório e armazenado no banco de dados, desta forma ao gerar o XML novamente devemos atribuir a cNF o valor que consta no banco de dados, assim não ocorre esse erro.
Olá ìtalo, tudo bom? obrigado por sua atenção! mas como pode observar no arquivo em anexo o campo cnf esta armazenado no banco e é o mesmo que estou utilizando para o envio e consta no xml
-
Estou fazendo uns testes no modo de homologação e ao tentar enviar as contingencias tambem no modo homologação esta dando a rejeição:
duplicidade de nf-e com diferença na chave de acesso
Falha na validação dos dados (infMDFeSupl)
em ACBrMDFe
Postado
Resolvido, minha pasta Schema estava desatualizada