Renato Rubinho

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Referência do discord https://discord.com/channels/798697718800318484/800037988335353896/1131032331306680331

Essa mensagem parece ser da sua aplicação. Tente o método ConsultarLote para obter o retorno do provedor. Marque a opção para salvar os SOAPs, analise os xmls e o retorno do provedor a respeito do lote. Configuracoes.WebServices.Salvar := True;

Boa tarde, Teste com o programa de exemplo. Confirme também se está preenchendo o Scope. Se o mesmo problema acontecer no programa de exemplo, cola o print das abas com as configurações que você preencheu, protegendo os dados sensíveis.

Boa tarde, A OpenSSL não suporta certificado A3. Utilize winCrypt, conforme as instruções do tópico a seguir.

Boa tarde, Obrigado pela contribuição. Criada TK-4217 para análise e envio ao SVN.

Provavelmente terá que abrir um fale conosco na Sefaz para analisarem. Outra sugestão de teste, envie a IE formatada ao invés de somente números.

Boa noite, No gmail você deve criar uma senha de aplicativo, não é a senha padrão do e-mail. Veja o tópico a seguir. Veja a parte referente ao gmail deste tópico.

Boa noite, Com esta resposta está claro que o problema está do lado deles. 124-can.xml <CancelarNfseReturn xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" type="soapenc:string">Serviço indisponível no momento.</CancelarNfseReturn> O provedor está respondendo com a informação: Serviço indisponível no momento. Entre em contato com o provedor, envie está xmls e confirme se existe previsão para normalização do serviço.

Você compilou uma lib ou está usando as versões demo distribuídas pelo ACBr? Algumas libs demo possuem limitações para funcionar apenas em homologação. Não tenho certeza, mas talvez o @Diego Foliene e o @antonio.carlos possam confirmar se as demos da ACBrNFSeLib funcionam em produção. Sim, diversas pessoas tem interagido com dúvidas e informando que estão utilizando. Pode ser um bug no WS do provedor que não ocorre no site.

Como estão suas configurações de ssl/tls? Confirme se está utilizando SSLType com TLS 1.2 Revise conforme o tópico a seguir.

Boa tarde, Verifique com o provedor se precisa habilitar a integração via WS e se o usuário e senha são os mesmos para ambos os serviços. Obs: editei seu post para remover os dados sensíveis que postou na url para sua segurança.

Boa tarde, Confirme se emitiu via lib no mesmo ambiente que testou no site, pode ser uma inconsistência no cadastro. Se o problema persistir, configure para salvar os xmls e envie ao provedor para que analisem se pode ser um erro interno via WS.

Boa tarde, Tente preencher também a IE de GO com 13 dígitos, com zeros à esquerda. Pode ser um bug de MG esperando sempre com 13, assim como na origem.

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

Boa tarde, Veja este tópico.

Boa noite, O ACBrNFSe é o componente antigo, que já não recebe manutenção há mais de um ano. Você deve migrar para a versão atual, o ACBrNFSex. Veja o tópico a seguir com instruções para migração.

Boa noite, No ano passado houve um problema na Sefaz de SP que ocorria aparentemente apenas com certificados A3. Foi um grande período até a sefaz identificar o problema, conforme este tópico. Abram chamados na Sefaz, documentando está informação para ver se não estão com o mesmo tipo de problema.

Boa tarde, No modelo da documentação a seção IdentificacaoNFSe está comentada como Provedor Infisc - Layout Proprio Essa seção será considerada por este provedor. Teste o número e a série na IdentificacaoRps

Boa tarde, Confirme sempre no MOC a hierarquia dos campos, o ACBr sempre que possível segue as nomenclaturas. Tentou preencher a cUFOrig, conforme o exemplo deste tópico?

Boa tarde, Tente instalar os runtimes do C++ https://github.com/abbodi1406/vcredist/releases

Isso, se houve o mesmo tratamento em outros registros, parece estar ok. Aparentemente faltou tirar o zero do LFill LFill( intIND_PROC ) Faça esse ajuste também, reinstale os componentes e veja se o arquivo é gerado corretamente com o campo em branco. Estando ok, por favor anexe a unit alterada para análise e envio ao SVN.

Boa tarde, No validador você consegue deixar este campo em branco e validar? Confirme no manual se existe a hipótese de ficar em branco mesmo, pois o opNenhum não está previsto no componente. ../trunk2/Fontes/ACBrTXT/ACBrSPED/ACBrSPEDFiscal/ACBrEFDBloco_E_Class.pas procedure TBloco_E.WriteRegistroE112(RegE111: TRegistroE111) ; var intFor: integer; intIND_PROC: integer; begin if Assigned( RegE111.RegistroE112 ) then begin for intFor := 0 to RegE111.RegistroE112.Count - 1 do begin with RegE111.RegistroE112.Items[intFor] do begin case IND_PROC of opSefaz: intIND_PROC := 0; opJusticaFederal: intIND_PROC := 1; opJusticaEstadual: intIND_PROC := 2; opSecexRFB: intIND_PROC := 3; opOutros: intIND_PROC := 9; else intIND_PROC := 9; end; Caso tenha a documentação confirmando que pode ser em branco e funcionar aí no validador, você pode fazer o ajuste nesta unit e anexar aqui para análise e envio ao SVN.

if (ACBrTEFD1.RespostasPendentes[i].Rede = Venda.Pagamentos[IndicePagto].Rede) and (ACBrTEFD1.RespostasPendentes[i].NSU = Venda.Pagamentos[IndicePagto].NSU) and (RoundABNT(ACBrTEFD1.RespostasPendentes[i].ValorTotal,2) = RoundABNT(Venda.Pagamentos[IndicePagto].ValorPago,2)) then Result := ACBrTEFD1.RespostasPendentes[i]; Teste novamente este mesmo valor e confirme se ele sempre apresenta o problema. Depois teste colocando o RoundABNT() Confirme também a sugestão do Daniel, verificando se o NSU está vindo com a mesma máscara.

Essa condição com Double também é "perigosa", pois algum valor irrisório mas casas decimais pode estar gerando uma diferença. Talvez um RoundABNT aí seria interessante.

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