Alexandre Felippeto Henzen

O de ficar nulo está correto, pois foi emitida uma nota em abril praticamente igual e deu certo. CLISOL_10661_IMPRESSA.xml

Alguém pode me ajudar com essa rejeição da NFe 719? A tag <idEstrangeiro/> está declarada no xml. CLISOL_11337_ABERTA.xml

A situação que ocorre é a seguinte anteriormente ele retornaria o "00160527662" como nosso número, porque ele trazia 10 dígitos naquela variável "TamanhoMaximoNossoNum", agora ele busca o nosso número e corta o final. Em relação a está vazio vou verificar, porém são todos os arquivos que estão assim.

Entrei em contato com o suporte do provedor SigISS e me informaram que a URL para o ambiente de homologação é essa: https://testecianorte.sigiss.com.br/cianorte/ws/sigiss_ws.php Solicito alteração no arquivo .INI [4105508] ; Incluído em 19/07/2022 Nome=Cianorte UF=PR Provedor=SigISS ProRecepcionar=https://cianorte.sigiss.com.br/cianorte/ws/sigiss_ws.php HomRecepcionar=https://testecianorte.sigiss.com.br/cianorte/ws/sigiss_ws.php ; ProSoapAction=urn:sigiss_ws

Prezados boa tarde, nós estamos tendo problemas que iniciaram com a mudança no TK-4426 que veio do topico: https://www.projetoacbr.com.br/forum/topic/74091-daycoval-ajustes-arquivo-de-retorno/#comment-479075 Vimos que foi alterada a logica para seguir um "novo" manual de 2021, porém temos clientes usando o DAYCOVAL e eles recebem o arquivo no mesmo modelo. Com as mesmas posições que foram alteradas, segue o arquivo em anexo: V131514516O.txt Com isso basicamente quando nosso cliente tenta fazer o retorno dele com esse arquivo, traz o nosso número cortado se deixarmos a FLAG "LerNossoNumeroCompleto" false e traz o nosso número em branco se marcarmos a FLAG "LerNossoNumeroCompleto" como true. Portanto precisamos de entender o que pode ser feito. Porque todos os arquivos que temos desses clientes seguem o mesmo padrão que o componente atendia antes da alteração. Arquivo enviado do dia 16/10/2023 Commit da alteração que afeta o Daycoval: Alteração no COPY que faz com que não traga mais o nosso número como deveria: Observação sobre outro possível erro de logica: Inclusive possui um IF que julgo desnecessário, pois nunca será false Só vai chamar o "DefineTamanhoNossoNumeroRetorno" se for false Porém existe a mesma validação dentro desse método que só é usado lá, portanto julgo que esse segundo IF é uma condição que nunca vai ser usada.

Olá realizamos algumas verificações quanto as credenciais... Observamos que para registrar um boleto a credencial usada é somente a X-ITAU-APIKEY e o token gerado anteriormente. Então as credenciais/certificado são usadas mesmo somente na geração do TOKEN. Pode me confirmar se essa informação está correta? Se sim, seria um problema com o token gerado pela API?

Boa tarde, fiz uma alteração na forma de passar os certificados para o componente e consegui gerar o token, porém não consigo registrar o boleto. Porque recebo 403 Authentication Failed. Segue meu Arqlog alterei o CLIENT_ID para tirar as informações sensíveis. A forma comentada é como passava antes e forma não comentada é como consegui gerar o token: No BoletoWS.RetornoBanco.CodRetorno chega como 0; No BoletoWS.RetornoBanco.Msg chega como 'HTTP_Code=403 Authentication Failed' No BoletoWS.RetornoBanco.HTTPResultCode chega como 403 ArqBoletoWS.log

Não, o certificado não possui nenhum tipo de senha, temos 4 certificados aqui. Um arquivo ".CRT", ".KEY", ".PFX", ".CSR"; Key e Csr foi gerado pelo cliente e os demais retornados pelo ITAU junto do client id e client secret: Pelo postman consigo gerar os tokens de produção passando o ".CRT" e o ".KEY": Porém pelo postman não consegui registrar um boleto, tive o: Com autenticação do tipo bearer token.

Olá temos alguma novidade sobre esse cenário?

É importante ressaltar também que no postman conseguimos gerar o acesstoken do itau: Passamos o certificado fornecido o .CRT e foi possível fazer a requisição no postman

Olá boa tarde, estamos ativando o primeiro cliente em produção utilizando o ITAU via API para registro de boletos. Estamos tendo problemas quanto a autenticação ao tentar autenticar sem o certificado recebemos o seguinte json: que não é considerado no tratamento da mensagem do ACBr Seguindo um pouco mais ao preencher o "ACBrBoleto.Configuracoes.WebService.ArquivoCRT" com o meu .CRT que foi fornecido pelo ITAU O retorno que eu tenho é esse: Informações adicionais: Scope := 'boletoscash-boletos-consulta_titulo'; Ambiente: Produção WebService.VersaoDF := 'V2'; ArqBoletoWS.log

Bom dia, teria como me encaminhar os arquivos do provedor alterado para eu realizar testes aqui?

Ao enviar os dados pro ambiente de testes de CIANORTE/PR - provedor SIGISS - está retornando erro mas o acbr não está tratando. A variável 'aMensagem' está vazia e não retorna como erro. 2005-ger-nfse.xml 2005-ger-nfse-soap.xml 2005-lista-nfse-ger.xml 2005-lista-nfse-ger-soap.xml

Fala pessoal, boa tarde! Novamente testei após as modificações e resolvido o problema, muito obrigado!

Essa em específico nós utilizamos a biblioteca MadExcept com a propriedade de Resource Leaks ativa. Certo, sobre isso vamos tentar reproduzir aqui desta forma.

Não, são na minha própria aplicação. Nunca utilizei o programa exemplo, mas posso tentar se for o caso... O objeto em questão que apresenta o leak é este, que é criado e nunca destruído na unit ACBrReinfLoteEventos: Segue outro print para visualizacao do mesmo sendo criado e destruído em outros momentos.

Bom dia, pessoal! O mesmo acontece quando enviamos um lote do evento 4020, a principio.

Boa tarde! Estou utilizando o ACBr para envio de lotes de Reinf, e ao realizar testes de memory leak, percebi um vazamento no objeto TLeitor na unit ACBrReinfLoteEventos, criado na linha 401 e aparentemente nunca liberado. Os metódos que estou chamando são respectivamente: FACBrReinf.Configuracoes.Arquivos.Salvar := true; FACBrReinf.Configuracoes.Geral.Salvar := true; FACBrReinf.AssinarEventos; >>> o leak acontece a partir desta função.... Result := FACBrReinf.Enviar; Segue em anexo os prints do call stack do memory leak.

Está tudo correto a configuração pra gerar os arquivos de soap e para esse caso específico não gerou nada mas o rps chegou ao portal, oq será que aconteceu?

Tá certo Ítalo, tem mesmo, pode me confirmar na programação onde salvar os arquivos Soap? Por não ter salvo, só posso entender que teve perda de conexão, não vejo outra coisa...

Infelizmente não vou conseguir debugar porque esse problema é esporádico e pro portal de ISSCuritiba não tem mais o ambiente de testes. Alguma outra ideia?

Não recebi o protocolo, não retornou nada, esse é o problema, quando retorna eu consulto depois com o protocolo, isso já faço. Vi que alguns provedores tem tratamento pra retorno vazio, não seria o caso de fazer pra Curitiba também?

Bom dia SSLConfig: TLS12 Não usa proxy

Como eu disse anteriormente, o ACBr não gerou arquivos de XML (soap) de retorno, e o timeout está com 60000.

Você acha que essa situação de retornar vazio seria algum problema no portal da prefeitura?