BigWings

Como já respondi em outro tópico, alguns comandos pedem um arquivo INI. Se você já tem o XML não vai usar os comandos Criar... Leia novamente o manual.

https://acbr.sourceforge.io/ACBrMonitor/NFECriarEnviarNFe.html

Se houve rejeição por duplicidade é porque já foi enviado o mesmo tpEvento com o mesmo nSeqEvento para a mesma chave. Fez a consulta completa? Tentou consultar também no portal da SEFAZ estadual autorizadora? Esse parâmetro é pra informar o número de lote de envio, serve apenas pra controle da sua aplicação, é irrelevante pra SEFAZ. Na consulta no portal vai mostrar como um evento, mas ele não segue o layout de evento descrito no manual, então, na minha opinião, não. Não existe informação de número de evento, não existe informação sobre qual a sequência gerada na consulta por chave, provavelmente é pela data de autorização.

Sim, depois de carregar o XML no componente, fazer as alterações necessárias, gerar, assinar, validar o XML e enviar novamente.

A contingência está ativada até amanhã: https://www.sefaz.rs.gov.br/NFE/NFE-SVC.aspx

Nem mesmo o portal nacional da NFe vai retornar esses eventos, se o CNPJ não está autorizado ao download do XML. Talvez o que você precise seja este projeto específico para empresas de recebíveis: https://www.placsvba.ba.gov.br/ A descrição do projeto menciona o monitoramento dos eventos de NFe. Mas não há nada nesse sentido implementado no ACBr.

Favor não duplicar tópicos.

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

Significa que não está alimentando o componente com o CFOP, e preenchendo zeros no autXML.CNPJCPF. Alguma relação com o assunto deste tópico? Não está havendo atribuição do CFOP aí, apenas da NFe referenciada, caso o CFOP seja 5202 ou 6202. Caso seja outro problema favor abrir novo tópico.

Ainda não. Vou fechar o tópico porque o assunto é versão anterior da NT.

OpenSSL não tem suporte a certificados A3, nesse caso use libWinCrypt e selecione o certificado pelo número de série.

Se tiver um certificado digital de uma empresa habilitada pra emissão de NFe, sim. Tem o parâmetro pra imprimir o DANFE no final, sim.

É mais ou menos isso, apenas a data de 05/04/2021 é uma previsão, as SEFAZ podem não ter aplicado ainda a NT em produção nessa data. E já saiu a NT 2020.006 v1.20, algumas coisas mudaram de novo:

E gerou o CFOP no XML?

Não é possível, você vai precisar saber a UF e CNPJ da transportadora, data de emissão, série, número e código aleatório do CTe pra poder montar a chave. Principalmente o código aleatório que existe justamente como segurança contra terceiros não autorizados. Sem mencionar que uma NFe pode ter "N" CTe vinculados.

Precisa copiar todas as DLLs da pasta https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/LibXml2/x86 ou https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/LibXml2/x64 - De qual pasta vai copiar vai depender da arquitetura do seu executável, e não do S.O. - O ideal é copiar para a mesma pasta do executável, pra evitar conflitos com outras aplicações.

Sim, o CNPJ de quem consulta precisa estar autorizado na NFe, nesse caso seria na tag <autXML>. Analisando melhor a NT 2014.002, os eventos de CTe autorizado e MDFe autorizado são retornados apenas em forma de resumo, então talvez não seja retornada a chave...

Quando é emitido um CTe é gerado um evento pelo fisco vinculado aquela NFe, que você pode receber pelo serviço DistribuicaoDFe da NFe. Nesse evento deve constar a chave do CTe emitido.

Como você está obtendo o valor? Essa propriedade é do tipo TpcnCstICMS, que é um enumerado declarado em pcnConversao: TpcnCSTIcms = (cst00, cst10, cst20, cst30, cst40, cst41, cst45, cst50, cst51, cst60, cst70, cst80, cst81, cst90, cstPart10, cstPart90, cstRep41, cstVazio, cstICMSOutraUF, cstICMSSN, cstRep60); //80 e 81 apenas para CTe Veja que o índice 1 corresponde ao CST 10. Você pode usar a função CSTICMSToStr, também da pcnConversao pra obter o código '10'.

Precisa revisar a rotina. O erro indica que não foi informado CFOP.

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

Isso devia bastar. No seu XML de teste a uCom é diferente da uTrib?

Tem no componente ACBrNFeDANFeFR, por isso meu questionamento inicial. No caso do componente pra NFCe os meios de pagamento sempre são impressos. Mas você está usando um FR3 muito antigo, talvez precise de ajustes nele.

Esse é um projeto paralelo, não tem relação com o ACBr. Em breve deve ser disponibilizado o ACBrNFSe em modo de DLL na ACBrLib: https://projetoacbr.com.br/acbrlib/

O layout, manual e schemas é o mesmo para NFe e NFCe, a NFCe é mais simplificada, alguns grupo NÃO podem ser informados, algumas tags tem valor pré-definido, por exemplo NFCe é sempre para consumidor final não contribuinte, e não se informa a IE do destinatário. Também os dados do destinatário são opcionais na NFCe (ninguém quer ter que cadastrar CPF pra emitir NFCe). O mais complicado é o tratamento da contingência, faça uma busca no fórum, se não me engano tem até vídeo pra quem é usuário SAC.