lucasborges8068

Ajuste no retorno de consulta em lote do Asaas - LerListaRetorno Identifiquei um problema na unit ACBrBoletoRet_Asaas, no método TRetornoEnvio_Asaas.LerListaRetorno. Na consulta de cobranças do Asaas, a API retorna uma estrutura de lista, onde os dados gerais da paginação ficam no JSON raiz, e os dados de cada cobrança ficam dentro do array data[]. No método LerListaRetorno, dentro do loop do array data[], alguns campos da cobrança estavam sendo lidos a partir do objeto raiz LJSON: ListaRetorno.DadosRet.TituloRet.ValorDocumento := LJSON.AsFloat['originalValue']; ListaRetorno.DadosRet.TituloRet.ValorDocumento := LJSON.AsFloat['value']; ListaRetorno.DadosRet.TituloRet.ValorAtual := LJSON.AsFloat['value']; ListaRetorno.DadosRet.TituloRet.ValorPago := LJSON.AsFloat['value']; ListaRetorno.DadosRet.TituloRet.ValorRecebido := LJSON.AsFloat['netValue']; Porém esses campos não existem no objeto raiz. Eles pertencem ao objeto da cobrança atual, obtido por: LJSONObject := LJSONArray.ItemAsJSONObject[I]; Com isso, em consultas de retorno/listagem, os valores de ValorDocumento, ValorAtual, ValorPago e ValorRecebido podiam vir zerados, mesmo a API retornando value/netValue corretamente dentro de data[]. A correção foi alterar a leitura desses campos para usar LJSONObject. Motivo da alteração: - LJSON representa a resposta completa/lista/paginação. - LJSONObject representa a cobrança atual dentro de data[]. - Os campos value, netValue e originalValue são propriedades da cobrança, não da resposta raiz. Com esse ajuste, a consulta em lote do Asaas passa a preencher corretamente os valores da cobrança retornada, permitindo processar baixas/retornos com os valores corretos. ACBrBoletoRet_Asaas.pas

Cliente (transportadora) reportou que o campo CIOT não estava sendo impresso no campo MDF-e. Ao analisar o arquivo FR3, identifiquei que o campo utilizado (rodo.CIOT) não correspondia ao valor esperado. Realizei a alteração para utilizar o campo Rodo.infANTT.infCIOT, garantindo que o CIOT gerado pelo cliente seja exibido corretamente na impressão do MDF-e. Segue o arquivo FR3 ajustado para avaliação e possível inclusão na versão oficial do ACBr. DAMDFe_Retrato.fr3

Não. Nenhum dos arquivos soaps bate com a chave que o sefaz retorna como duplicidade.

Está acontecendo comigo também. Tanto modelo 65, quanto 55. No modelo 55 eu acompanho no debug todo o processo de geração do código numérico e chave, e no erro de duplicidade no primeiro envio ele retorna que já existe no sefaz só que com outro código numérico. Consegui reproduzir o erro forçando Time Out, como citado acima pelo colega.

Na impressão da NFe com o modelo Paisagem, a quantidade de folhas está saindo com a contagem errada. Segue exemplo de uma nota que tem 2 folhas: Utilizando Fast Report.