Jéter Rabelo Ferreira

Rotina é simples: Somente de enviar o boleto para o Ws do Itaú. Nada mais do que isso

Anexo log do MadExcept bugreport.txt

Segue log do FastMM4 do problema no programa exemplo do ACBr AcbrBoletoDemo_Fortes_MemoryManager_EventLog.txt

Bom dia. A correção que você fez não alterou em nada o problema, visto que, ao efetuar o fListaBoletos.free, eu destruo o ítem da lista, Portanto, estamos dando voltas num problema, tentando resolver o problema, cuja a causa não está no destroy, mas onde a referência é feita? Efetuei um debug e encontrei o local do problema. Vocês estão simplesmente atribuindo o ítem da listaretornoWeb no objeto RetornoWeb do títulos. Ao efetuar o free da lista do título, automaticamente essa referência é destruída, aí estoura a exception. Segue imagem onde essa atribuição do objeto está sendo feita. Atenciosamente.

Eu fiz mais um vídeo demonstrado o problema.

Boa tarde. Nos meus testes, eu estava enviando sempre com juros/mora. Porém, fui fazer um teste sem e estourou um exception, codigo de mora não informado. Efetuei a alteração na unit do ACBrBancoItau. Segue anexa a mesma. Atenciosamente. ACBrBancoItau.pas

Boa tarde. Fiz um vídeo mostrando, Ficou sem o áudio, mas dá para verificar o problema. Atenciosamente

Boa tarde. Efetuei o teste no programa do ACBr e o erro é o mesmo. Ao fechar o programa, estoura exception. Fui verificar esse problema, e ele é recorrente em commit's de retira e coloca o .free. 20/07/Commit: 22415 Foi criada a property: fRetornoWeb: TRetEnvio;, colocado no Create/Destroy do ACBrTitulo. 25/08/Commit: 22775 - Destroy comentado 26/08/Commit: 22791 - Linha do destroy excluída 01/10/Commit: 23129 - Linha adicionada novamente - Problema de Access Violation Em suma, o problema existe e está ocorrendo, mesmo no programa do ACBr de exemplo. Atenciosamente.

Boa tarde. No momento eu não consigo fazer esse teste, mas segue a imagem da linha adicionada no commit em questão. Até dia 30/09, que foi quando terminei os testes com a homologação do Banco Itaú WS estava tudo normal, sem problemas. No sábado atualizei meu ACBr, e hoje fui fazer o teste na UNIT disponibilizada por você no outro POST a respeito disso, e me deparei com esse erro. Ao depurar, encontrei onde estourava a exception, mas não ocorria semana passada. Fui no LOG do SVN e encontrei um COMMIT adicionando a linha (imagem anexa), que, nesse caso, destrói o objeto que está na lista (ACBrBoleto.FListaRetornoWeb - Imagem anexa). Nesse COMMIT, foi enviado apenas uma unit com apenas essa alteração (Imagem anexa) Atenciosamente. ),

Bom dia Referente ao Commit acima referenciado, após ele, começou a estourar exception. Exception passa a ocorrer ao destruir o objeto fListaRetornoWeb do ACBrBoleto (linha 2762). Atenciosamente.

Bom dia. Acabamos de efetuar um novo teste e está ok. Informamos que já recebemos o retorno da homologação OK do Banco Itaú. Atenciosamente.

@Juliana Tamizou, boa tarde. Eu tinha enviados dois arquivos no meu POST original, mas, na realidade, basta apenas zerar o contenttype do arquivo da unit do Itau. Dessa forma, a alteração do ACBrBoletoWS não é necessária. Estou enviando novamente a unit corrigida, bem como comentando mais 3 property's opcionais. Atenciosamente, ACBrBoletoW_Itau.pas

Bom dia. Ontem fomos fazer homologação junto ao Itaú com boleto WS, ocorreram vários erros. Fizemos uns ajustes nas unit's do Banco Itaú de acordo com as exigências do banco. Eles não aceitam content-type no header (RAW). Não tinha um método para colocar o código das carteiras, como BB e CEF possuem. Ajustamos a geração do JSON para que, campos opcionais, que não possuem valores, não sejam informados no JSON. Em suma, efetuamos os ajustes e o envio está OK.ACBrBoletoW_Itau.pas Ainda não testamos o retorno, pois não temos dados para isso. Assim que tivermos testado, caso haja algum ajuste, postamos aqui Seguem as unit's modificadas. Atenciosamente ACBrBoletoWS.pas

Boa tarde. Só para avisar, continuamos na mesma.

Bom dia. Sefaz de MG com problemas desde Quinta-feira (02/09) a tarde E ainda hoje continua igual.

Boa tarde. Tudo parado.

Boa tarde. Sim, zeramos todos os problemas. Obs.: Entraram em manutenção agora. Atenciosamente.

Bom dia. Mesmo com todos os problemas com a SEFAZ, conforme post anterior, mudando para síncrono o envio das NFC-e's, os chamados aqui diminuíram em mais de 90%. Atenciosamente.

Bom dia. Sefaz de MG agora.

Bom dia. Funcionou como síncrono. Atenciosamente

Pelo jeito o problema é por causa do assincrono Fiz uma modificação num cliente e os cupons foram transmitidos Atenciosamente.

Enviamos somente síncrono. Está com problema desde ontem após o almoço.

Boa tarde. Alguns clientes nosso com o mesmo problema. Atenciosamente

Elton, Boa tarde. Fazia tempos que não compilava meu projeto para Android, por isso nem voltei a esse tópico. Hoje fui compilar e vi que estava com problemas. Voltei os dados da library (Android32 somente) conforme meu backup, atualizei o ACBr e fui verificar, os erros ainda continuam. Porém, agora que eu vi que você pediu para verificar no registro e no arquivo antes de atualizar se encontravam iguais. Eu não fiz isso antes de atualizar. Aí eu refiz todo o processo, colei meu backup, verifiquei nos dois arquivos (iguais) e reinstalei o ACBr. Os problemas continuam. (Porém, agora não adiciona aspas '' no inicio, agora adiciona um ; ) Atenciosamente.

Bom dia. MG está offline desde ontem na parte da tarde. Temos vários clientes com cupons de contingência de ontem que não foram enviados.