isolopak

Boa tarde. Ao enviar o CT-e em contingência (SVC-SP) para o ambiente de homologação, está sendo retornado a seguinte rejeição: <cStat>851</cStat> <xMotivo>Rejeição: Endereço do site da UF da Consulta via QR Code diverge do previsto.</xMotivo> Está sendo enviado a seguinte URL no QRCode: Aparentemente esse caso já havia um tópico aberto. No Discord foi enviado a seguinte unit pelo @Diego Foliene para realizar o teste onde o envio foi autorizado sem problemas. ACBrCTe (1).pas

Ok, obrigado realizei o teste aqui a aparentemente essa solução também resolveu esse caso.

Olá. Bom dia. Fiz umas alterações no componente para ser possível informar o boleto para o Itaú enviando para produção e sendo possível definir se o processo é simulação ou efetivação. Segue anexo o patch e unit com as alterações para facilitar o entendimento do caso. Nestas units que enviei consta uma outra alteração que realizei referente a instruções de cobrança que detalhei melhor no tópico: Neste caso, para essa alteração, segui a lógica utilizada para definir o ambiente de homologação e produção. Criando uma nova property chamada Processo nas classes TACBrWebService (Unit: ACBrBoleto) e TOAuth (Unit: ACBrBoletoWS.Rest.OAuth) com um novo enum para esse contexto. TpcnTipoProcessoBoleto = (tpNaoInformado, tpSimulacao, tpEfetivacao); Nos eventos de Create de ambas as classes inicializei elas de forma a manter o comportamento padrão do componente, onde caso não informar valor nelas terão o comportamento sem a minha implementação. Desta forma não irá impactar quem não deseje utilizar esse comportamento. E no processo de geração do JSON para envio para a API do Itaú ajuste para caso houver um valor diferente de tpNaoInformado utilizar o respectivo valor, porém caso contrário o valor será utilizado com base no ambiente: BOLETO_ITAU_SIMULACAO.patch ACBrBoleto.pas ACBrBoletoWS.Rest.OAuth.pas pcnConversao.pas

Olá, estou com problema ao emitir o boleto online com Indicador Pix informando instrução de cobrança. Onde, olhando para a lógica do componente para a geração do JSON notei que deve ser informado os dois primeiros caracteres para o código da instrução e os próximos dois para a quantidade de dias após o vencimento. Porém, não é aplicado um Trim no código. Pois neste cenário caso deseje informar o código 4 com 0 dias, por exemplo. Deveria ser informado o valor ATitulo.Instrucao1 := '4 0'; Mas neste exemplo o retorno do banco é o seguinte: { "codigo" : "400", "mensagem" : "Erro na validação de Campos", "campos" : [ { "campo" : "data.dado_boleto.instrucao_cobranca[0].codigo_instrucao_cobranca", "mensagem" : "Código da instrução de cobrança inválido", "valor" : "4 " } ] } Necessário alterar para enviar o campo etapa_processo_boleto do JSON com o valor "simulacao" conforme comentei no tópico abaixo. Pois enviado como efetivação estava sendo retornado status 500: Para resolver meu problema adicionei um Trim após o Copy no procedimento TBoletoW_Itau_API.GerarInstruCaoCobranca (Unit: ACBrBoletoW_Itau_API) Não sei se interpretei errado o comportamento, mas somente dessa forma consegui resolver meu problema. Anexado patch e unit com o ajuste necessário. BOLETO_ITAU_INSTRUCAO.patch ACBrBoletoW_Itau_API.pas

Olá, após a atualização do componente o meu processo de emissão da DAMDFE começou a apresentar a mensagem que não encontrou os arquivos de Schema. E neste contexto realmente não realizo as configurações destes, pois estou utilizado o componente em um executável na máquina do usuário onde não realizo a emissão ou consulta de DF-e (neste caso o local onde emito os documentos possui a configuração de Schema corretamente) somente carrego o XML do documento no componente e solicito a emissão do relatório com FastReport. Porém, neste processo, o componente, ao buscar a URL de consulta é gerado a exceção de não localizar os Schemas a chamada do procedimento: TACBrMDFe(ACBrMDFe).GetURLConsulta(FMDFe.Ide.cUF, FMDFe.Ide.tpAmb, FMDFe.infMDFe.versao) que irá chegar ao procedimento TACBrDFe.LerServicoDeParams que realiza a validação em questão. Porém, neste contexto nem há a utilizado do valor de retorno da versão presente no Schema. Ou seja, realiza o procedimento sem necessidade. Fiz uma alteração no componente para que neste caso não seja realizado essa validação, visto que na minha visão está realizando esse trabalho sem necessidade. Segue o patch e units alteradas. Para avaliação de uma possível alteração. Ou se há alguma maneira de prosseguir neste caso, pois, não vejo a necessidade de colocar os Schemas em todo o usuários de meu sistema para a emissão do relatório sendo que a informação buscada sequer é utilizada. Alteração realizada resumidamente foi a seguinte, adicionei um novo parâmetro boolean para definir se busca a versão do Schema com valor padrão True, e ao ser chamado pela emissão do relatório informa False neste parâmetro. MDFE-Schemas.patch ACBrDFe.pas ACBrMDFe.pas ACBrMDFeDAMDFEFR.pas

Boa tarde. Estava com alguns problemas que estava acontecendo comigo ao utilizar a geração de boleto para o Itaú em homologação. Atualmente utilizo uma integração realizada pela nossa equipe. E estamos migrando para o componente. Notei que no componente não é possível enviar para produção um boleto como simulação. Gostaria de saber se não é possível essa implementação no componente. Para casos onde realizamos as simulações com as credenciais de produção. E conforme a documentação, é possível enviar no body informando que é simulação para que o mesmo seja validado, mas não será gerado o boleto e/ou pix. Com isso é possível validar a comunicação com as credenciais e arquivos de certificado em produção sem a necessidade de gerar um novo boleto efetivo.

Boa tarde. Realizei os teste em homologação e produção e em ambos o erro não aconteceu. Aparentemente deu certo a alteração. Caso eu encontrar alguma nova situação entro em contato novamente. Obrigado pela atenção.

Realizei o teste aqui e o cenário que te enviei está acontecendo. O JSON está enviado da seguinte forma (Somente removi o endereço, mas não há caráteres especial e erro para ao trocar o APÓS para APOS): "mensagens":["ENDERECO DO BENEFICIARIO: ","APÓS 06 DIAS DO VENCIMENTO, SUJEITO A","PROTESTO."]

Bom dia. Enviado no e-mail o arquivo ini com as credenciais e o log da execução gerando o caso para facilitar o entendimento.

Sim, pode me informar o e-mail para enviar as credenciais?

Bom dia, desculpa a demora do retorno, estava aguardando a homologação voltar a responder e em produção tive que aguardar a autorização para realizar o teste. Mas consegui realizar o teste tanto em homologação quando em produção em ambos tive o mesmo retorno. Utilizei a unit que enviou, conforme solicitado. Retorno da requisição: 400 BAD_REQUEST "Failed to read HTTP message"; nested exception is org.springframework.core.codec.DecodingException: JSON decoding error: Invalid UTF-8 middle Há mais algo que posso testar?

Boa tarde, troquei a unit que me passou, mas desde manhã acredito que a homologação não está respondendo. Pois estou recebendo o seguinte retorno: Falha na Autenticação: HTTP_Code=503 Erro=<html> <head><title>503 Service Temporarily Unavailable</title></head> <body> <center><h1>503 Service Temporarily Unavailable</h1></center> <hr><cen Irei tentar novamente mais tarde ou na segunda, caso não estabilizar irei verificar se será possível realizar o teste em ambiente de produção. Assim que tiver um retorno aviso aqui.

Boa tarde. Desculpa a demora do teste, acabei tendo outras prioridades. Mas realizei o teste e não resolveu o problema. Neste caso o problema está sendo gerado no envio e não na tratativa do retorno (não sei se pode ter no retorno também, mas o meu caso é caracteres especiais no JSON de envio). Acredito que o problema está no procedimento TBoletoW_Sicredi_APIV2.RequisicaoJson da unit ACBrBoletoW_Sicredi_APIV2 Que está gerando o JSON da seguinte forma (removi alguns dados sensíveis): { "tipoCobranca": "HIBRIDO", "codigoBeneficiario": "", "especieDocumento": "DUPLICATA_MERCANTIL_INDICACAO", "nossoNumero": "", "seuNumero": "/1 ", "dataVencimento": "2024-07-01", "valor": 1, "multa": 2, "pagador": { "tipoPessoa": "PESSOA_FISICA", "documento": "", "nome": "", "endereco": "", "cidade": "", "uf": "", "cep": "" }, "mensagens": ["ENDERECO DO BENEFICIARIO: ", "APÓS 06 DIAS DO VENCIMENTO, SUJEITO A", "PROTESTO."] } Se trocar a palavra "APÓS" para "APOS" o envio é realizado normalmente.

Utilizo Delphi.

Bom dia. Atualizei o componente há alguns dias atrás, e após essa atualização comecei a receber o seguinte erro ao registrar o boleto online para o Sicredi: 400 BAD_REQUEST "Failed to read HTTP message"; nested exception is org.springframework.core.codec.DecodingException: JSON decoding error: Invalid UTF-8 middle. O caso está sendo gerado quando há caracteres especiais em "mensagens" do JSON enviado, onde o mesmo não está tratando, após a troca para utilizar ACBrJSON.