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.

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.

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.

Olá pessoal, Estou desenvolvendo uma integração com o ACBrBoletoAPI utilizando o banco Itaú. A parte de autenticação, emissão e consulta está funcionando perfeitamente — consigo emitir boletos, consultar e validar os retornos sem problemas. Porém, notei o seguinte comportamento durante os testes: Quando o pagamento é feito via QR Code Pix de uma conta Itaú para outra Itaú, o status do boleto é atualizado quase imediatamente pela API. Já quando o pagamento é feito de um banco diferente (ex: Banco do Brasil → Itaú), a atualização do status demora bastante, mesmo o boleto já aparecendo como baixado no site do Itaú. Gostaria de saber se alguém já passou por isso e se há alguma forma de forçar a sincronização da baixa ou se essa demora é normal devido ao fluxo de compensação entre bancos. Agradeço qualquer informação ou experiência que possam compartilhar. Obrigado,

Testei em ambos, sendo que o retorno é o mesmo.

Ola, Pessoal. Ao enviar o pedido de cancelamento ao servidor Betha de Criciuma recebo o retorno de erro - faultstring E172 - faultcode env:Server. Estou utilizando o componente ACBrNFSeX. Vou deixar em anexo o xml com envelope de envio e o de retorno NfseEnvelopeEnvio.xml NfseEnvelopeRetorno.xml

Resolvido!

Boa tarde, acredito que descobri meu problema, pensei que fosse ao usar o metodo de impressão, porem é na hora que emite, sabem me dizer se tem alguma configuração para na hora de emitir não imprimir?

Ocorre, no exemplo, não tenho Fortres para testar apenas utilizo o Fast Report.

Não esta, usa a penas o método citado acima "ImprimirDANFSePDF", Quando comento ele não gera nem imprime PDF, logo se entende que ele é quem esta disparando a impressão.

O que eu devo fazer então?

Então é esse mesmo que estou usando, porem esta imprimindo mesmo assim, estou usando conforme a imagem acima.

Gostaria de saber se existe alguma configuração para o AcbrNfseX Gerar PDF na pasta especificada, sem imprimir na impressora?

Italo, vou entrar em contato com eles para fazer a correção, muito obrigado pela atenção, e rapidez nas respostas.

Italo, realmente o XML esta vindo sem finalizar a tag de endereço no tomador de serviço, o que deveremos fazer nesse caso? Já que o provedor esta mandando um XML malformado.