ACBrReinf - Retorno de eventos - ACBr-Reinf - Projeto ACBr
March 27, 2018 in ACBr-Reinf
Bom dia, só consegui tratar corretamente o retorno dos eventos quando realizei algumas alterações no código fonte da Unit ACBrReinfWebServices.pas (em anexo). Quando tentei usar da mesma forma que está no fonte de exemplo, não consegui recuperar as informações de retorno, nem as mensagens de inconsistências e nem o número de recibo quando a validação pela Sefaz ocorre com sucesso. Favor analisarem as alterações, as mesmas ocorreram na function TEnvioLote.TratarResposta: Boolean;
Desculpe, não vou poder aceitar a sua colaboração pois notei que o seu fonte esta muito desatualizado.
Favor atualizar todos os fontes de todas as pastas, reinstalar o ACBr novamente, e faça novos testes.
Ok, vou fazer a atualização e realizar novos testes.
Lendo com mais atenção o Manual de Orientação ao Desenvolvedor-REINF v1.3.02 notei que no retorno de um envio de evento sempre teremos o evento R5001 e este poderá aparecer "N" vezes nesse retorno e o motivo é simples, se enviarmos um lote contendo 10 eventos, teremos no retorno 10 R5001, ou seja, um para cada evento enviado no lote.
Como podemos enviar até 100 eventos por lote, o retorno poderá conter 100 eventos R5001.
Já no retorno de uma consulta sempre vai retornar o evento R5011 e ele é único no retorno.
Com base nessas informações fiz algumas modificações no que diz respeito ao retorno.
Da forma atual é preciso estanciar o R5001 e R5011 para poder ler o retorno, agora não será mais necessário.
Alterei as Units responsáveis pela leitura dos retornos e também o programa exemplo para demonstrar a leitura de alguns dados.
Essas modificações só serão enviadas para o repositório na segunda-feira dia 21.
Logo peço que façam cópias dos fontes por questões de segurança.
Outra coisa importante: O componente ainda esta em fase de desenvolvimento, apesar de ser possível o envio de eventos e a realização de consulta.
Em 18/05/2018 at 14:40, Italo Jurisato Junior disse:
Não sei se tem relação com a alteração de ontem, mas percebi a geração de leaks de memória após a leitura do retorno. Pode ser que já existisse antes e eu só percebi agora.
Comecei a investigar e buscar uma solução, mas ainda não consegui tempo pra ver em detalhes. Saberia me dizer se há alguma correção desse comportamento previsto para o componente?
Como o componente esta sendo melhorado (pelo menos estamos tentando) a cada dia, pode ser que algumas coisas acabaram ficando para traz.
Sem problemas, Italo... eu estou estudando os fontes na medida em que as demandas me permitem e se conseguir alguma solução posto no fórum pra ajudar também.
Em 23/05/2018 at 08:25, Italo Jurisato Junior disse:
Depois de uma semana agitada consegui parar para fazer mais testes. Creio que os memory leaks estavam ocorrendo por conta desse overload. Da forma como está hoje não passava no TeventoCollectionItem.destroy. Mudei para override (adicionando o inherited no corpo do método pra executar a definição ancestral) e não houve mais problemas de vazamento de memória, ao menos até onde consegui identificar.
Não sei se essa seria a melhor saída, pois não conheço tão bem os fontes como você. Portanto, coloco aqui pra tentar ajudar na melhoria do componente.
Sempre que propor alguma alteração em alguma unit, favor anexar a mesma aqui no fórum para que possamos analisar.
Favor anexar a unit alterada.
Favor atualizar os fontes mais tarde, pois foi detectados mais alguns erros e seu fonte esta desatualizado, logo contem esses erros.