BigWings

Nos arquivos anexados a chave está diferente, provavelmente digitação incorreta.

Pela mensagem você não está enviando o SoapAction nos headers da requisição, ou está enviado um SoapAction não mapeado pelo webservice. Não, precisa ter um certificado ICP-Brasil válido, no CPF ou raiz do CNPJ que fará a consulta. Para o serviço DisbribuicaoDFe, não.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

No caso da Toledo sempre usei o código 1 para venda por unidade, que seria o tvpUnidade.

A última versão do instalador é essa que está no print do Juliomar, do dia 13/06. Provavelmente era a configuração do Windows sim, e faltou algum passo, por exemplo, reiniciar o PC ou reverter o arquivo ACBr.inc para a codificação original.

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

Teve uma correção. Veja se após atualizar, executou o ACBrInstall_Trunk2.exe pra recompilar os fontes. E após isso, recompilou a sua aplicação.

Está com os fontes atualizados?

Veja se a dica abaixo resolve o seu problema:

Tenta também um revert ou resolve, pelo Tortoise, no arquivo ACBr.inc.

Precisa apontar ACBrNFe1.DANFE para um dos componentes de impressão de NFCe em bobina. ACBrNFeDANFCEFR -> impressão, visualização, PDF, depende do Fast Report instalado ACBrNFeDANFCeFortes -> impressão, visualização, PDF, depende do Fortes Report instalado ACBrNFeDANFCeFPDF -> apenas PDF, sem dependências ACBrNFeDANFEEscPos -> apenas impressão, sem dependências

Enviei uma correção para o SVN, rev. 33966. Por favor atualize, e teste novamente, com o tipo toRemessaAlterarDesconto.

Coloquei ali, está informando cNF diferente. Se cada vez que você gera o XML informar um cNF diferente a chave consequentemente vai mudar. O cNF é um campo que deve ser aleatório, você gera o número aleatório, grava no seu banco de dados, e quando for gerar o XML deve sempre informar esse cNF, pra essa nota.

A tag indSinc faz parte do lote de envio de NFe e não da NFe em si. Se você está usando o comando NFE_EnviarNFe é o sexto parâmetro: PS: Que saiba a Bahia, assim como SP, não aceita modo síncrono para NFe, apenas assíncrono.

A diferença entre as duas chaves é a tag cNF (Código Numérico) que está sendo informada diferente do que a da nota autorizada na SEFAZ.

Já rodou o recompile.exe?

Da NT 2023/004: Se está tendo a rejeição indica que a UF em questão está com a regra ativada. Para pagamento PIX precisa informar se foi pagamento integrado ou não (tag: tpIntegra). Caso seja pagamento integrado, por exemplo usando a API de PIX, informar tpIntegra=1 e os demais dados da operação.

Você não é o desenvolvedor do sistema? A numeração é controlada pela aplicação, então só quem tem acesso aos fontes do teu sistema pode responder.

Precisa configurar o componente. A mensagem é por falta de definir as configurações de SSLLib.

Por isso não se deve alterar o tpEmis, ele faz parte da chave de acesso da nota. Essa é a chave de uma NFe emitida em contingência EPEC (O evento EPEC em si não tem chave). Essa é a chave da uma NFe com o mesmo número, emitida em modo normal. Se tiver as duas chaves autorizadas você tem um duplicidade de chave natural.

Precisa gerar novamente o XML da nota sem alterar o tpEmis, e informando a justificativa. Consultado com sucesso? Então a nota foi emitida em modo normal?

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);

Só corrija o que causou rejeição.