BigWings

O cNF não pode ser igual ao nNF, isso causa rejeição. Você tem que alimentar o componente com todas as tags iguais as da nota original, com exceção do cNF que não pode ser igual a 0 pois nesse caso o ACBr altera pra um número aleatório conforme exigido pelo manual. Se todos os dados da nota forem exatamente os mesmos, a chave também será a mesma, e você não terá erro de digest value ao consultar o protocolo.

Informando a chave de acesso, a função retorna o cNF.

É um input do usuário no exemplo do componente... xUF := ''; if not(InputQuery('Prestação de Serviço em Desacordo:', 'UF do Emitente do CT-e', xUF)) then exit; // Salva a UF configurada no componente xUFOld := ACBrCTe1.Configuracoes.WebServices.UF; // O evento tem que ser enviado para a UF do Emitente do CT-e ACBrCTe1.Configuracoes.WebServices.UF := xUF; ACBrCTe1.EventoCTe.Evento.Clear; with ACBrCTe1.EventoCTe.Evento.New do begin // Para o Evento: nSeqEvento sempre = 1 infEvento.nSeqEvento := 1; // Devemos informar a UF do Emitente do CT-e InfEvento.cOrgao := UFtoCUF(xUF); <------ converte a sigla da UF para código da UF Provavelmente não informou a sigla da UF, ou informou o código, ou informou uma sigla de UF inválida.

Sim, ele é um inteiro de 8 posições, e deve ser salvo no banco de dados, junto com todas as informações da NFCe pra justamente poder gerar novamente o XML se necessário. Se você tem a chave de acesso pode usar o método ExtrairCodigoChaveAcesso da unit pcnAuxiliar.pas.

Não, o que você pode fazer é gerar novamente o XML da NFCe informando exatamente os mesmos dados, gerar o XML, e usando o mesmo certificado, assinar, validar e depois fazer a consulta pelo componente, que se estiver tudo Ok o XML vai ser atualizado com o protocolo.

Pela mensagem, foi informado um valor inválido para a tag cOrgao ao preencher os dados do evento.

Corrigido no SVN. Atualize novamente os fontes, por favor.

Você vai usar o envio de evento do componente ACBrCTe. Veja:

As URL estão no arquivo ACBrNFeServicos.ini e são agregadas como recurso no executável no momento da compilação. De acordo com o modelo de documento, UF, ambiente, versão do layout e do qrcode (no caso da NFCe) são lidas as URL do arquivo. No caso dos eventos existem os eventos que são enviados para a SEFAZ da UF e os eventos que são enviados para o ambiente nacional que é o caso do evento de ator interessado, isso já é feito automaticamente pelo componente.

Já sim.

A diferença parece ser apenas no byte de geração mesmo. https://acbr.sourceforge.io/ACBrLib/Particularidades.html

Veja:

Basta usar duas &&. Label1.Caption := StringReplace(Path, '&', '&&', [rfReplaceAll]);

Não, mas você pode tentar contactar um consultor aqui: https://www.projetoacbr.com.br/forum/companies/category/2-consultores/

Os erros que vi é estar informando o valor unitário no lugar do valor total no registro C170, e estar informando a alíquota nos campos de base de cálculo e valor do ICMS no registro C190. Também tem o CST 010 nos registros C170 que não foi informado no C190. Lembrando que por ser nota de entrada são informados os valores do ponto de vista do declarante, ou seja, só é informado ICMS que a empresa tem direito a crédito.

Nesse caso você não usa o cancelamento normal, e sim o cancelamento por substituição, nesse cancelamento o prazo é de 168 horas, e você precisa informar a chave da NFCe emitida em contingência que substituiu.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

A condição pra gerar é essa tag estar preenchida. Veja se é o caso.

Acabei de testar e está funcionando.

Só precisa estar usando o Fast Report com suporte a scripts e estar abrindo um XML sem o protocolo de autorização.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Você pode gerar novamente o XML, corrigindo o NCM errado, assinar novamente, e enviar. Alterar um NCM não vai alterar a chave de acesso, isso realmente não pode.

Antigamente na NFe 3.10 existia a tag indPag = (à vista, a prazo, outras) geral da nota, o ACBr mesmo imprimia dessa forma no grupo fatura. Agora ela é informada para cada meio de pagamento, no ACBr não é mais impressa: Me parece que esse DANFE está desatualizado. Se você for implementar, não estará errado, desde que use a informação da tag indPag, só note que pode haver mais de um pagamento e consequentemente mais de um indicador.

Sim, nas regras de validação do tipo de emitente, pág. 62 do MOC visão geral.

O erro impediria a geração do XML assinado, e o seu XML parece correto inclusive com as URL de consulta e QrCode. Também testei aqui o seu .ini e gerou normalmente, bastou a configuração da versão do QrCode para 2.