BigWings

Verifique se a impressora padrão definida no Windows está numa impressora de bobina.

Validando o XML de envio do evento 1-ped-eve.xml, no validador da SEFAZ-RS, validou normalmente: https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx Nesse caso, é preciso entrar em contato com a SEFAZ e perguntar o motivo da rejeição.

Movido.

A vírgula no logradouro do emitente faz com que o ACBr entenda que ali é o final do texto do .ini. Use a sintaxe correta: delimite o conteúdo do texto com aspas duplas: NFe.CriarEnviarNFe(" [infNFe] ... vTroco= " ,,,,COMANDA,1,,1,)

Os arquivos *-ped-eve.xml anexados além de antigos se referem a cancelamento de NFe e não de MDFe. Se a opção de salvar os arquivos enviados/recebidos está marcada, deveria ser gravado no momento da tentativa de cancelamento do MDFe um arquivo *-ped-eve.xml *-ped-eve-soap.xml contendo o XML de envio, e arquivos *-eve.xml *-eve-soap.xml com o retorno do webservice. Para descobrir o motivo do erro é preciso analisar o arquivo específico onde ocorreu o problema.

https://www.fazenda.sp.gov.br/nfe/perguntas_frequentes/respostas_VIII.asp Neste sentido também o artigo 41 da Portaria CAT 162/2008: Artigo 41 - Na hipótese em que o contribuinte credenciado a emitir NF-e exerça atividade sujeita à incidência do Imposto Sobre Serviços de Qualquer Natureza - ISSQN, poderá utilizar os campos da NF-e relativos ao ISSQN, desde que a legislação municipal assim lhe permita. Parágrafo único - O emitente deverá disponibilizar o arquivo digital da NF-e ou o respectivo DANFE a Administração Tributária municipal, conforme o disposto na respectiva legislação. http://www.sped.fazenda.mg.gov.br/spedmg/nfe/Perguntas-Frequentes/respostas_vii/index.html Na minha interpretação, sem uma autorização expressa da prefeitura, não se deve fazer emissão da NFe ou NFCe conjugada , ou apenas com serviços, em SP ou MG, e sim emitir a NFSe apenas. Omitir informação gerada em documento fiscal no SPED pode ser visto pela fiscalização como sonegação por parte da empresa.

Se o erro foi no cancelamento, você precisa analisar o XML do envio do evento de cancelamento e não o XML do MDFe (que inclusive validou normalmente aqui). Anexe o arquivo *-ped-eve.xml e *-ped-eve-soap.xml.

Que saiba a permissão de emitir NFe ou NFCe com serviços sujeitos ao ISS depende de legislação municipal. Mesmo que a SEFAZ do estado autorize uma nota contendo serviços, isso não significa que a prática é permitida pelo município. Os municípios sempre vão dar preferência à NFSe.

Além da configuração indicada pelo Italo, veja também o seu arquivo ACBrNFeServicos.ini, se contém as URL para a versão 4.00 da NFCe.

O código atual faz o esperado, caso seja configurado a versão do componente como veqr000 e usada versão 4.00 do XML, ele será ajustado para veqr100. Para usar o QrCode 2.00, basta configurar a propriedade ACBrNFe1.Configuracoes.Geral.VersaoQrCode = veqr200. Com a sua alteração fica impossibilitado o uso do QrCode 1.00 (que não é mais usado, mas mantido por compatibilidade, para recriar um XML antigo, por exemplo).

No teu XML falta a versão do evento. with ACBrCTe1.EventoCTe.Evento.New do begin infEvento.cOrgao := 41; infEvento.versaoEvento := '1.00'; Tanto cOrgao quando a configuração ACBrNFe1.Configuracoes.WebServices.UF deve ser a UF do emitente do CTe, no caso, o PR.

Está confundindo causa/efeito. O XML com a tag nfeProc é montado pelo ACBrNFe após o recebimento do protocolo de autorização, ele não é o XML enviado para o webservice. Configure o componente para gravar os arquivos de envio e retorno e anexe aqui os arquivos *-env-lot.xml e *-env-lot-soap.xml onde houve a rejeição.

O fórum é voltado a desenvolvedores, o ACBr não lida com usuários finais, nem desenvolve software destinado a usuários finais, e sim uma suíte de componentes e um aplicativo de integração (ACBrMonitorPLUS). Sugiro que direcione essas questões para o suporte da aplicação usada pelo teu cliente.

O método GerarXML gera o conteúdo do arquivo apenas internamente, o arquivo XML de envio de evento é gerado caso você use o método EnviarEvento. Para visualizar o XML como é feito no demo do componente, usando o GerarXML, experimente trocar as linhas acima por: ACBrCTe1.EventoCTe.GerarXML; MemoResp.Lines.Text := ACBrCTe1.EventoCTe.Gerador.ArquivoFormatoXML; LoadXML(MemoResp, WBResposta); Se estiver usando EnviarEvento: ACBrCTe1.EnviarEvento(1); MemoResp.Lines.Text := ACBrCTe1.WebServices.EnvEvento.RetWS; LoadXML(MemoResp, WBResposta);

A tag deve ser xJust e não xJus.

Erro de grafia aqui:

@Daniel Simoes @Vitor JR Eu tive um problema recente com um certificado de cliente com essa mesma cadeia, mas acessando pela SVRS. Usando OpenSSL ocorria o erro HTTP 403 em qualquer operação, com WinCrypt a consulta de status funcionava mas ao tentar emitir a NFCe retornava a rejeição "Certificado Transmissor erro no acesso a LCR". Após vários contatos com a certificadora que dizia que estava tudo certo com o certificado, a resposta veio da SEFAZ-RS: Isso foi no dia 08/04/2019. Depois de contatar novamente a certificadora com essa informação, eles admitiram o problema e foi solucionado no dia seguinte com a publicação da cadeia no ITI e atualização das mesmas pela SEFAZ-RS. Então creio que a SEFAZ-SP deve fazer o mesmo. Infelizmente o certificado que tinha do cliente foi revogado e emitido um novo com ICP-Brasil v2. Testei mesmo assim (usando o certificado revogado) a consulta de status: GO em homologação passou a funcionar. Em SP continua o erro 403 mas ele acontece com WinCrypt também.

Verifique a configuração das margens no componente DANFE.

É um problema conhecido. Quando você não define o espaçamento entre linhas o PosPrinter usa o espaçamento padrão da impressora, mas o componente não conhece esse valor. Então na impressão do QRCode lateral e informação do consumidor, é usado a altura do QRCode como altura máxima dessa região. Como o QRCode agora está reduzido acaba cortando as informações do consumidor + NFCe. Para resolver você só precisa informar um espaçamento entre linhas: ACBrNFeDANFeEscPos1.PosPrinter.EspacoEntreLinhas := <xxx>; Alterar a disposição das informações do consumidor e identificação da NFCe vai contra o manual de especificações do DANFe NFCe e QrCode.

Já tentou o "Find in files" do Delphi?

Consegui replicar, realmente fica bem lento. Pelo log de alterações do svn não notei nada que pudesse fazer diferença de março pra cá...

Se a pasta de Schemas está correta verifique a versão das DLLs OpenSSL/XmlSec na máquina do usuário.

Parece ter uma confusão aí. As tags vBCST, pICMSST e vICMSST se referem ao destaque do ICMS-ST e não se aplicam ao CST 60. Se você quer informar o ICMS-ST retido anteriormente deve informar vBCSTRet, pST, vICMSSTRet e vICMSSubstituto.

@MFincotto No caso da BA já está correto, não constam no arquivo as URL para o QR-Code 2.00, nesse caso são usadas as URL de versão anterior que são as mesmas citadas por você. Para GO e MG, chamo atenção para o trecho do tópico citado pela Juliana: Como não tivemos relatos de problemas desde o dia 20, exceto nos casos de usuários com o arquivo desatualizado, tudo leva a crer que as URL estão corretas no arquivo. Aguardamos novos feedbacks.

Sua NFe é para consumidor final. Nesse caso a configuração não se aplica, ou seja, a tag vICMSSubstituto será gerada apenas se o valor for maior que zero.