BigWings

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:

Uma URL de homologação no grupo de produção? De qualquer forma, a URL atual do arquivo é: URL-ConsultaNFCe_2.00=www.sefaz.es.gov.br/nfce/consulta Foi corrigida por alterações recentes no webservice da SVRS que começou a validar a URL de consulta. Você chegou a alterar o arquivo ACBrNFeServicos.ini e fez testes pra saber se a NFCe é autorizada?

Se foi retornado o resumo da NFe, o destinatário é o CNPJ informado no pedido. Para os outros interessados, inclusive terceiros constantes na tag autXML, não é retornado resumo, mas o XML completo da nota.

Analisando o cabeçalho do XML de retorno: <resNFe xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" versao="1.35" xmlns="http://www.portalfiscal.inf.br/nfe"> Está sendo retornado na versão 1.35. Isso não é usual se você estiver usando ACBr com os Schemas disponibilizados pelo projeto NFe e constantes na pasta Schemas do ACBr, que está na versão 1.01. Essa versão 1.35 é usada pelo aplicativo gratuito de manifestação da SEFAZ-SP, ela não é pública e não tem documentação disponível pra ela, por isso não foi incluído no componente. Um usuário do fórum conseguiu via engenharia reversa esses Schemas, conforme post abaixo: Se você tiver esses arquivos da versão 1.35 na sua pasta de Schemas, o ACBr vai gerar nessa versão, e vai retornar o cSitConf, mas o componente não encapsula essa tag como propriedade. Você também perderá funcionalidade, como o método DistribuicaoDFePorChaveNFe que deixará de funcionar nessa versão dos Schemas.

Estranho... pode anexar o XML? E também esse arquivo foi obtido via ACBr ou via aplicativo gratuito da SEFAZ?

Essa tag era do serviço antigo de consultar notas destinadas NFeConsultaDest, já desativado pela SEFAZ e substituído pelo DistribuicaoDFe pela NT 2014.002. O serviço também já foi removido do componente.

Não existe evento de manifestação para MDFe. Eles são exclusivos para NFe.

Basicamente o mesmo erro, mas do lado da SEFAZ agora. Está exigindo o vICMSSubstituto sendo que ele é opcional no layout, desde a NT 2018.004 v.1.20. Validando o XML pelo validador da SEFAZ-RS não ocorre problema: O ACBr tem a configuração ForcarGerarTagRejeicao938 que você pode tentar usar para forçar a geração da tag vICMSSubstituto.

Experimente desativar o anti-vírus. Por estar baixando um binário executável, pode ser que o ele esteja interferindo no processo e bloqueando a operação.

Para NFe de emissão própria, pode-se obter apenas os eventos de Cancelamento, Carta de Correção e EPEC, pelo método ACBrNFe.Consultar. É facultado à UF, entretanto, retornar a lista completa de eventos, coisa que nenhuma UF faz, até onde sei.

O correto é 1 sim, mas isso vai contra o que está sendo gerado no XML. Como disse, é preciso debugar.

Você deve conseguir obter os eventos de manifestação emitidos por terceiros, para as NFe de emissão própria. Os eventos de manifestação de emissão própria, para as NFe de terceiros destinadas, não são retornadas pelo método DistribuicaoDFe. O webservice também não retorna a situação atual da manifestação de uma NFe destinada.

A única coisa que me chamou atenção no trecho de código é você estar manipulando dois objetos ACBrNFe na mesma rotina, um na classe FrmA003Hk e outro na classe TFrmM005HK. Fora isso não identifiquei o que possa estar causando o problema, será necessário debugar. Tente analisar o valor de ACBrNFe.EventoNFe.Evento.Count antes da chamada ao método ACBrNFe.EnviarEvento. O demo do componente tem um exemplo de cancelamento funcionando.

Você está enviando dois eventos no seu arquivo 0-ped-eve.xml, um deles não tem justificativa, por isso o erro de schema. Provavelmente é algo errado na sua rotina, e está chamando o método ACBrNFe.EventoNFe.Evento.Add mais de uma vez, ou faltando chamar ACBrNFe.EventoNFe.Evento.Clear antes de iniciar a rotina de cancelamento.

Um erro comum é a justificativa menor que 15 caracteres. Mas precisa conferir o XML gerado pra tentar identificar o problema. Configure o componente pra gravar os arquivos de envio e retorno e anexe aqui o *-ped-can.xml e *-ped-can-soap.xml.

Veja este tópico:

Uma coisa que não está no manual é que provavelmente será necessário usar o cancelamento por substituição nesse cenário que tem o prazo de até 168 horas. No cancelamento por substituição além da chave e protocolo de autorização você precisa informar a chave da NFCe substituta que foi emitida em contingência para acobertar a NFCe que está sendo cancelada. O prazo de 30 min do cancelamento normal é impraticável nesse cenário.

Você pode configurar a porta como "RAW:Nome da impressora no Windows", mas não tenho certeza se a gaveta funciona dessa forma.

Tem algum decreto ou norma técnica para essa proibição? Foi entregue um documento fiscal inválido para o consumidor. A empresa vai ter que se explicar. Em contingência não há rejeição por data e hora atrasada, o correto é transmitir como contingência e não no modo normal. O melhor é seguir a legislação.

Esse parece um erro de validação local e não retorno da SEFAZ. A mensagem está exigindo o preenchimento do vICMSSubstituto, pelos schemas atualmente o campo vICMSSubstituto é opcional no layout, então o erro não deveria acontecer. Veja se sua pasta de Schemas está atualizada.

A NT 2018.004 que entrou em vigor em 29/04/2019 reduziu o prazo de cancelamento normal da NFCe para 30 minutos. Então se a UF em questão não tinha exceção para esse prazo e apenas seguia a NT, significa que houve a redução.

Não existe mais de um emitente ou destinatário numa nota, então não faria sentido usar um Collection. Como o próprio nome diz, é uma coleção, que comporta N objetos. Para emitente ou destinatário você tem uma classe, TEmit e TDest respectivamente. É bem simples descobrir as classes pela IDE, com Ctrl+Clique no código ou apenas movendo o mouse sobre ele.

Fiz confusão com a pergunta mas a resposta é a mesma... Verificar se existe essa opção pelo driver da impressora. Caso contrário terá que implementar via PosPrinter mesmo...

Se entendi bem, você quer algo como: ACBrNFe1.NotasFiscais.Items[x].NFe.Ide.xJust ACBrNFe1.NotasFiscais.Items[x].NFe.Ide.dhCont Cada método Add cria um item numa lista e retorna o objeto, você pode armazenar numa variável sem precisar de with no código. O demo do ACBrNFe já tem um exemplo do uso sem with: Var NotaF: NotaFiscal; ... begin NotaF := ACBrNFe1.NotasFiscais.Add; NotaF.NFe.Ide.cNF := StrToInt(NumNFe); //Caso não seja preenchido será gerado um número aleatório pelo componente NotaF.NFe.Ide.natOp := 'VENDA PRODUCAO DO ESTAB.'; NotaF.NFe.Ide.indPag := ipVista; NotaF.NFe.Ide.modelo := 55; Também poderia ser: var NFe: TNFe; begin NFe := ACBrNFe1.NotasFiscais.Add.NFe; NFe.Ide.cNF := StrToInt(NumNFe); ... Tendo o objeto criado você pode facilmente passar ele pra um outro método para preencher os dados. var NFe: TNFe; Produto: TDetCollectionItem; begin NFe := ACBrNFe1.NotasFiscais.Add.NFe; NFe.Ide.cNF := StrToInt(NumNFe); ... Produto := NFe.Det.Add; CarregarDadosProduto(Produto); ... procedure CarregarDadosProduto(AProduto: TDetCollectionItem); begin AProduto.Prod.nItem := 1; AProduto.Prod.cProd := '123456'; AProduto.Prod.cEAN := '7896523206646'; ...

O ACBrNFeDANFCeFortes usa o spooler do Windows para impressão, então o controle fica a cargo do driver de impressora instalado. Veja se nas preferências de impressão da impressora do Windows existe a opção de corte após a impressão.