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.

Segue abaixo um xml pego via debug pois não chegar a jogar na pasta da erro antes. Por segurança dos dados do meu cliente informei com pontos de interrogação = "?????????????". obs nesses campos não possuía nenhum caracter especial que pudesse causar uma mal formação no XML. teste.xml

Vou tentar, pois tem muitos caracteres, e esta cortando, daqui a pouco eu te retorno

Acredito que encontrei o problema, na variável "AxmlDocument", esta a informação que eu preciso e esta retornando porem quando me gera a exception acredito que o retorno se perde, retornando a variável vazia, quanto aos arquivos que mandei eu peguei via debug e não pelo processo de salvar do acbr, até mesmo por que nem sei onde é nem como configurar, o que podemos fazer para corrigir esse erro? pois o xmlParseDoc não esta compreendendo o retorno que foidado pelo provedor que no caso é a betha.

Fui debugando os códigos internos do ACBR e cheguei a seguinte mensagem, acredito que não esta conseguindo montar o xml da forma correta.

Alguns xml que usei nos meus testes, um deles simulei um protocolo errado só para ver o retorno, e no caso me retorna erro, logo acredito que quando o protocolo esta correto o retorno é vazio porem preciso de um metodo que me informe o numero da nota para que posteriormente possa cancelar. Segue abaixo anexos. ConsultarLoteRps.xml ConsultarLoteRpsEnvio.RETORNO.XML ConsultarLoteRpsEnvio.XML ConsultaSituacao.RETORNO.XML ConsultaSituacao.XML

Vamos la, vou tentar explicar melhor: 1 - Estou fazendo a Configuração do componente; 2 - Depois alimento O componente com as informações da NFse 3 - Tenho retorno positivo que o RPS foi enviado pois recebo o protocolo e armazeno em um arquivo. 4 - Com o protocolo e o lote que foi gerado pelo envio do RPS fico tentando consultar a situação. 5 - Quando retorna o codigo 4 na situação sei que o RPS foi aceito e a Nota esta ok (verifico no site de homologação e a nota realmente esta la tudo certinho). 6 - Preciso CANCELAR a nota e para isso preciso do numero que foi gerado para ela pela betha. 7 - Então preciso armazenar essa informação caso meu cliente queira futuramente cancelar via ERP. 8 - Ai então que vem meu problema, quuando utilizo o protocolo e lote armazenado anteriormente para consulta do lote o meu retorno é um XML vazio. 9 - Se o xml ta vazio não consigo depois cancelar a nota via ERP, meu cliente tera que entrar no site para cancelar. 10 - Não sei se realmente a beta não devolve o numero da nota que foi gerada por eles ou se falta alguma configuração no componente. 11 - Estou tentando de tudo e falta apenas isso um simples retorno do numero da nota para que eu possa seguir com o projeto e finalizar.

O de retorno é justamente o que eu queria que viesse, porem não vem, só vem se eu mandar o protocolo errado, ai me retorna um XML com erro dizendo que o protocolo não esta na base de dados, acredito que só não esta me devolvendo o XML com informações da nota, mais quando da erro ele me retorna.

Segue em anexo o XML gerado pelo método "ConsultarLoteRps", utilizado para Consultar o Lote RPS a partir do protocolo, que esta ok pois retorna o cod. = 4 quando consulto a situação do RPS. ConsultarLoteRps.xml

Utilizei os exemplos para me basear no meu projeto, no meu ultimo teste que estou fazendo, notei que o protocolo gerado só da de usar uma vez quando o retorno é = 4, quando emito armazenei o protocolo para futuras consultas, quando vou utilizar do mesmo para consultar ele me retorna 4 apenas na primeira consulta que faço depois não me retorna mais nada, quando vou utilizar o método consultar RPS com o mesmo protocolo também não me retorna nada nem da primeira vez, logo não consigo consutar o numero a nota para armazenar para um futuro cancelamento, entrei na interface web de homologação da betha e a nota esta la gerada como deveria poram não tenho o retornos de forma correta por parte do componente acbr, não sei se estou esquecendo alguma configuração mais estou seguindo os mesmos passos que estão no Exemplo da nfse - ACBR.

No caso seria esse método abaixo, que devo utilizar para pegar o numero da nota? "ConsultaLoteRps(Protocolo,Lote);"