ACBrReinf - Retorno de eventos

[Paulo Alves N Junior]

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;

ACBrReinfWebServices.pas

[Italo Giurizzato Junior]

Bom dia Paulo,

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.

[Paulo Alves N Junior]

3 minutos atrás, Italo Jurisato Junior disse:

Bom dia Paulo,

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.

[Italo Giurizzato Junior]

Boa tarde a todos,

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. 

Espero contar com a compreensão de todos.

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.

 

[Luis Lambranho]

Em 18/05/2018 at 14:40, Italo Jurisato Junior disse:

Boa tarde a todos,

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. 

Espero contar com a compreensão de todos.

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.

 

Boa tarde, Italo.

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?

 

 

 

[Italo Giurizzato Junior]

Bom dia Luis,

Como o componente esta sendo melhorado (pelo menos estamos tentando) a cada dia, pode ser que algumas coisas acabaram ficando para traz.

[Luis Lambranho]

13 horas atrás, Italo Jurisato Junior disse:

Bom dia Luis,

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.

Obrigado!

[Luis Lambranho]

Em 23/05/2018 at 08:25, Italo Jurisato Junior disse:

Bom dia Luis,

Como o componente esta sendo melhorado (pelo menos estamos tentando) a cada dia, pode ser que algumas coisas acabaram ficando para traz.

Boa noite, Italo.

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.

 

[Italo Giurizzato Junior]

Bom dia Luis,

Sempre que propor alguma alteração em alguma unit, favor anexar a mesma aqui no fórum para que possamos analisar.

Desde já muito obrigado pela colaboração.

Favor anexar a unit alterada.

[Luis Lambranho]

Maravilha... segue a unit pcnReinfRetEventos.pas

[Italo Giurizzato Junior]

Bom dia Luís,

Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Favor atualizar os fontes mais tarde, pois foi detectados mais alguns erros e seu fonte esta desatualizado, logo contem esses erros.

[Luis Lambranho]

Legal, Italo.

 

Obrigado!