Erro 452 no envio nota sincrono

[jhony2507]

Bom dia pessoal,

Estou com o seguinte problema/dúvida.

hoje (13/10/25) , do nada, começou a aparecer o erro 452: Solicitada resposta assíncrona para Lote com somente 1 (uma) NF-e em um cliente da BA.  Ocorre que já estou enviando a nota em modo sincrono a mais de 60 dias, sempre usando:
              ...WebServices.Enviar.Sincrono :=true;
              ...WebServices.Envia(dmgeral.sp_p_nota.FieldByName('idnota').Asinteger, false, true);

 

Depois de alguns testes, percebi que se mudar o 2o. parâmetro para true a nota é enviada sem nenhum erro (...WebServices.Envia(dmgeral.sp_p_nota.FieldByName('idnota').Asinteger, true, true); ). Porém, isso não faz muito sentido, visto que segundo o manual, o 2o. parâmetro define se a nota será impressa ou não, ou seja, sem relação alguma com o envio.

 

Alguém saberia porque isso acontece? Houve alterações não listadas no manual??

Att

[BigWings]

Parece que você está confundindo o método ACBrNFe.WebServices.Envia com o ACBrNFe.Enviar, eles tem assinaturas diferentes.

function TWebServices.Envia(ALote: Int64; const ASincrono: Boolean;  AZipado: Boolean): Boolean;

function TACBrNFe.Enviar(ALote: Int64; Imprimir: Boolean = True; Sincrono: Boolean = False; Zipado: Boolean = False): Boolean;

Como pode ver, o segundo parâmetro do método Envia é o tipo de envio síncrono ou assíncrono, nele não tem o parâmetro referente a impressão.

[Dercide Alvarez]

Mas acho que é instabilidade na SEFAZ, aconteceu com clientes essa mensagem, apenas tentamos enviar novamente e foi envida.

Ja aconteceu com umas 3 notas no mesmo cliente, e todos enviadas.

[jluizsc]

Estou com mesmo problema em alguns CNPJs, outros estão ok! Será que estão atualizando aos poucos os servers e vai travar todos? Ou seria um erro que vai ser corrigido no SEFAZ?

[Eduardo Faria Nazario]

Olá, pessoal.

Também, estamos enfrentando problemas no ambiente de produção da SEFAZ, afetando vários clientes.
Ao tentar enviar as notas em modo síncrono pelo ACBr, estamos recebendo a seguinte rejeição:

Rejeição: 420 – Solicitada resposta assíncrona para lote com somente 1 (uma) NF-e.

Ou seja, mesmo o envio sendo feito corretamente pelo modo síncrono, a SEFAZ está retornando essa rejeição de forma indevida.
O problema está ocorrendo desde hoje e atinge diferentes clientes e UFs.

Parece se tratar de uma instabilidade no ambiente da SEFAZ, pois até então o mesmo procedimento funcionava normalmente.

Gostaríamos de confirmar se mais usuários estão enfrentando essa mesma situação e se há alguma recomendação do ACBr para contornar o problema momentaneamente.

[BigWings]

3 minutos atrás, Eduardo Faria Nazario disse:

Ao tentar enviar as notas em modo síncrono pelo ACBr, estamos recebendo a seguinte rejeição:

Rejeição: 420 – Solicitada resposta assíncrona para lote com somente 1 (uma) NF-e.

Estranho que o cStat dessa rejeição é a 452:

Não encontrei no MOC o que seria a 420.

[Eduardo Faria Nazario]

26 minutos atrás, BigWings disse:

Estranho que o cStat dessa rejeição é a 452:

Não encontrei no MOC o que seria a 420.

Você está correto, o código de rejeição mencionado anteriormente estava errado; o correto seria 452.

No entanto, nesse caso, o código em si não é o ponto principal, já que a mensagem retornada pelo WebService explica claramente a situação:

"Solicitada resposta assíncrona para lote com somente 1 (uma) NF-e."

Ressalto que estamos enviando em modo síncrono, mas o ACBr não está respeitando essa configuração.

Ou seja, a rejeição indica que o envio está sendo interpretado como assíncrono, mesmo quando o modo síncrono é usado. Isso sugere que o ACBr pode não estar montando o envelope SOAP corretamente para esse cenário.

[BigWings]

Agora, Eduardo Faria Nazario disse:

Ressalto que estamos enviando em modo síncrono, mas o ACBr não está respeitando essa configuração.

Porque diz que é o ACBr que não respeita? Me parece mais um problema na SEFAZ em questão.

[Eduardo Faria Nazario]

Agradeço o retorno, mas vale esclarecer que não estou afirmando categoricamente que o ACBr seja o responsável.

O ponto é que, mesmo configurando o envio em modo síncrono, a SEFAZ está retornando a mensagem:

"Solicitada resposta assíncrona para lote com somente 1 (uma) NF-e."

Isso indica que o WebService está interpretando o envio de forma assíncrona, independentemente da configuração do ACBr.

Para entender a causa real do problema, seria necessário analisar com calma tanto o componente ACBr quanto o comportamento do ambiente da SEFAZ.
Pela pressa na resposta anterior, essa análise não foi feita.

Não podemos presumir que o problema esteja apenas no SEFAZ, pois, se não for solucionado, amanhã nossos clientes não conseguirão emitir notas.

[BigWings]

A tag <indSinc> é gerada no XML de lote de envio (*-env-lot.xml), se estiver gerando <indSinc>0</indSinc> é porque provavelmente tem algo errado na rotina de envio.

Se for o caso veja o tópico abaixo e siga as instruções.

 

[jhony2507]

10 horas atrás, BigWings disse:

Parece que você está confundindo o método ACBrNFe.WebServices.Envia com o ACBrNFe.Enviar, eles tem assinaturas diferentes.

function TWebServices.Envia(ALote: Int64; const ASincrono: Boolean;  AZipado: Boolean): Boolean;

function TACBrNFe.Enviar(ALote: Int64; Imprimir: Boolean = True; Sincrono: Boolean = False; Zipado: Boolean = False): Boolean;

Como pode ver, o segundo parâmetro do método Envia é o tipo de envio síncrono ou assíncrono, nele não tem o parâmetro referente a impressão.

Na verdade não, foi erro de digitação ao postar o problema... Estou usando enviar() mesmo