BigWings

Quando você chama o ACBrNFe.Validar o componente deve fazer a validação do XML contra os schemas, antes de transmitir para a SEFAZ. Se transmitir um XML inválido em relação aos schemas para a SEFAZ vai ter essa rejeição. No caso do NCM com mais de 8 dígitos é a libxml2.dll que não faz o tratamento. Teve algum outro caso? Uma solução é, após validar, verificar se o ACBr não gerou algum alerta (vai gerar no caso do NCM): ACBrNFe1.NotasFiscais.Assinar; ACBrNFe1.NotasFiscais.Validar; if ACBrNFe1.NotasFiscais[0].Alertas <> '' then raise Exception.Create(ACBrNFe1.NotasFiscais[0].Alertas);

No MDFe tem havido o problema caso esteja usando o modo de envio assíncrono, o webservice não retorna o número do recibo e quando o componente tenta fazer a consulta com recibo em branco dá a rejeição. Talvez na NFe esteja acontecendo a mesma coisa... precisa analisar os XML de envio e retorno.

SPED e Sintegra não passam de arquivos texto, qualquer linguagem pode criar arquivo texto. Aí você teria que gerar um arquivo texto pra essa lib criar outro arquivo texto, não teria muita utilidade.

Pra configurar por número de série, sim. Você pode também deixar a configuração do número de série em branco, e apontar por ArquivoPFX (path do arquivo), DadosPFX (conteúdo do certificado) ou URLPFX (arquivo PFX a partir de uma URL http).

A mensagem do print indica que o certificado que estava configurado com esse número de série não foi localizado no repositório do Windows. Talvez tenha sido excluído, não esteja conectado (A3) ou tenha algum problema com ele.

Usar o DANFe NFe para NFCe está em desacordo com o manual, então os teus clientes podem ser autuados por isso. Se quer imprimir em A4 tem o DANFeNFCeA4.fr3 na pasta Obsoletos, que você pode tentar ajustar, ou pode usar o componente para Fortes Report.

Esse modelo é pra NFe, não deve ser usado com NFCe.

No modo síncrono não é usado o ACBrMDFe.WebServices.Retorno, altere pra ACBrMDFe.WebServices.Enviar. Também não é retornado número de recibo, que é desnecessário no modo síncrono.

No log do SVN consta como já corrigida essa questão. Então atualize novamente os fontes, e teste.

Veja também o ACBrConsultaCNPJ com a API CNPJws agora também traz a IE.

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

As tags são as mesmas que você já gera para os demais cadastros. Só informar código, nome, CNPJ, endereço... dos bancos. Mais fácil ainda seria cadastrar os bancos no seu banco de dados.

Não entendi a dúvida, a imagem mostra apenas registros 0150 com o cadastro de bancos.

Certifique-se de que: - Está com os fontes atualizados, e executou o ACBrInstall_Trunk2.exe após a atualização. - Se existe um arquivo ACBrCTeServicos.ini desatualizado no diretório da aplicação. Se tiver, remova.

Se a sua aplicação não é 64 bits não tem porque copiar as DLLs de 64 bits da OpenSSL. Remova elas e remova também a legacy.dll que também só funciona em 64 bits conforme o tópico que citei anteriormente. O erro provável que é a aplicação está localizando as DLLs da OpenSSL versão 3 em algum lugar no PATH da máquina do seu cliente, e tentando carregar também a legacy.dll que é de 64 bits portanto a aplicação de 32 não consegue carregar.

Vai precisar depurar então o código na unit pcnNFeW.pas pra saber onde está o problema. Se você está carregando o XML para envio em vez de alimentar o componente, veja este tópico que pode estar relacionado:

O problema é justamente estar usando as novas DLLs (OpenSSL versão 3) com um certificado não compatível. Tentou fazer o indicado no tópico?

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

Configure a página de código para pcUTF8 ou pc1252.

Para Win64 informe o path dos fontes, não dos .dcu. Os .dcu são compilados apenas em 32 bits.

Provavelmente é incompatibilidade do certificado com a versão 3 do OpenSSL. Veja:

Também não teve alterações no código do ACBr nessa parte, como você pode ver pelo "Blame" do SVN. Veja se não tem algum valor informado para a tag CNPCPF ou IdEstrangeiro. Um espaço em branco que seja pode causar isso.

No modo síncrono de envio o ACBrMDFe.WebServices.Retorno não é usado, porque a resposta vem no próprio envio, sem necessidade de consulta de retorno. Estude o programa exemplo do componente pra ver como tratar a resposta no modo síncrono.

Talvez só tenha na versão comercial. A minha é a Standard, e versão anterior a do @Helder Jr e tem o TfrxExportSVG.

Leitura obrigatória da NT que trata do serviço DistribuicaoDFe: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=VgPuhtPApQo= Pra enviar o evento de manifestação só precisa saber a chave da nota. Com as informações do resumo (chave, data de emissão, dados do emitente, valor da nota) o serviço entende que já é possível o destinatário saber qual a manifestação deve enviar. Se o destinatário sabe que fez a compra, pode fazer a Ciência da operação, caso tenha certeza que não fez, já pode manifestar como Desconhecimento. Quando a mercadoria chegar manifesta como Confirmação da operação. Caso tenha havido algum problema na entrega e não recebeu a mercadoria, manifesta como Operação não realizada. Manifestando como Ciência, Confirmação ou Operação não realizada, e fazendo nova chamada ao método DistribuicaoDFe, vai eventualmente receber o novo NSU com a nota completa. Enviar a Ciência de operação é opcional, e tem até 10 dias após a autorização pra isso, depois, só enviando uma manifestação definitiva (Confirmação, Desconhecimento, ou Operação não realizada).