ACBrSintegra bug quando há mais de uma Redução Z mesmo dia

[EMBarbosa]

Pessoal,

Detectei um erro na geração do arquivo Sintegra pelo ACBrSintegra quando há mais de uma Redução Z no mesmo dia.

O componente não consegue ordenar corretamente caso criemos os registros e deixemos que ele próprio relacione os registros 60A e 60M devidos. Assim é necessário fazer esse relacionamento manualmente. Mas caso usemos as propriedades existentes para isso, o componente não cria os registros 60A.

O mesmo ocorre com os registros 60D, 60I e 60R.

Fiz uma alteração no componente para corrigir esse erro, mas estou ainda testando para ter certeza que não vai alterar o comportamento para quem já faz uso do componente.

Foi necessária alteração no modo de criação e destruição interna dos registros para que não houvesse leak de memória, mas isso não deve alterar em nada o código dos usuários atuais do ACBrSintegra. Apenas quem precisar atender o caso de mais de um registro 60M no mesmo dia é que deverá alterar o código.

Achei por bem avisar a todos que, assim como eu, talvez não tenham percebido essa limitação no componente.

Devo terminar os testes amanhã e fazer o commit.

[EMBarbosa]

Tivemos um problema com a internet aqui na cidade... Só conseguiram resolver hoje.

O problema da ordenação do registro 60M foi resolvido verificando, além da data, também o CRZ.

Já para organizar os filhos de reduções no mesmo dia, foi necessário utilizar de forma manual as propriedades internas do Registro60M a saber Regs60A, Regs60D e Regs60I. Assim, ao invés de, por exemplo, criar um registro 60A e adicioná-lo no Registros60A do ACBrSintegra, a pessoa cria os registros para aquele 60M específico, e o adiciona no Registros60M.Regs60A.

O mesmo vale para Registros60D e Registros60I.

[Daniel Simoes]

Oi Elton,

Em qual situação poderiamos ter duas Reduções Z no mesmo dia ? Ela não deve se basear na Data de Movimento ?

Em relação a modificação... agora é necessário liberar manualmente alguns Objetos ? eles não são eliminados quando o componente ACBrSintegra é destruído ou em LimparRegistros ?

[EMBarbosa]

Oi Elton,

Em qual situação poderiamos ter duas Reduções Z no mesmo dia ? Ela não deve se basear na Data de Movimento ?

Só acontece quando o ECF vai para intervenção e volta no mesmo dia para o cliente. É um caso muito específico pois se o ECF for pra intervenção e não voltar no mesmo dia, ou se mesmo quando voltar no mesmo dia, o cliente não o utilizar, não há problema algum. Tivemos um caso desse no mês de setembro passado.

O registro 60M e a redução continua a se basear na Data de Movimento. Mas quando há mais de uma Redução no mesmo dia, o componente estava ordenando os registros de forma aleatória. As vezes punha um na frente, as vezes outro, dependendo da ordem de entrada e do número de registros...

Em relação a modificação... agora é necessário liberar manualmente alguns Objetos ? eles não são eliminados quando o componente ACBrSintegra é destruído ou em LimparRegistros ?

Não é necessário liberar nada manualmente. O funcionamento dessa parte para o usuário do componente continua do mesmo modo, tanto na destruição do TACBrSintegra como no método LimparRegistros. A única diferença é que agora, ele controla os registros filhos internos do 60M ao invés dos externos.

O comentário que coloquei no código que deve ter gerado essa confusão. É só um lembrete que o componente deve fazer a limpeza daqueles registros enquanto o OwnObjects for False.

Esclarecendo: Quem não quer se preocupar com o caso de duas reduções Z no mesmo dia não precisa alterar nada no código. Pode continuar usando da mesma maneira. O código continua o mesmo como no exemplo para registros 60A abaixo:

//Exemplo código Redução Z..

wregistro60M:=TRegistro60M.Create;

wregistro60M.Emissao:=ACBrSintegra.Registro10.DataInicial;

wregistro60M.NumSerie:='000000987456';

wregistro60M.NumOrdem:=1;

wregistro60M.ModeloDoc:='2D';

wregistro60M.CooInicial:=1000;

wregistro60M.CooFinal:=1050;

wregistro60M.CRZ:=1;

wregistro60M.CRO:=1;

wregistro60M.VendaBruta:=1050;

wregistro60M.ValorGT:=10000;

ACBrSintegra.Registros60M.Add(wregistro60M);

wregistro60A:=TRegistro60A.Create;

wregistro60A.Emissao:=ACBrSintegra.Registro10.DataInicial;

wregistro60A.NumSerie:='000000987456';

wregistro60A.StAliquota:='F';

wregistro60A.Valor:=500;

ACBrSintegra.Registros60A.Add(wregistro60A);

wregistro60A:=TRegistro60A.Create;

wregistro60A.Emissao:=ACBrSintegra.Registro10.DataInicial;

wregistro60A.NumSerie:='000000987456';

wregistro60A.StAliquota:='I';

wregistro60A.Valor:=550;

ACBrSintegra.Registros60A.Add(wregistro60A);


i := 0;

wregistro60M:=TRegistro60M.Create;

wregistro60M.Emissao:=ACBrSintegra.Registro10.DataInicial;

wregistro60M.NumSerie:='000000987456';

wregistro60M.NumOrdem:=1;

wregistro60M.ModeloDoc:='2D';

wregistro60M.CooInicial:=1000;

wregistro60M.CooFinal:=1050;

wregistro60M.CRZ:=1;

wregistro60M.CRO:=1;

wregistro60M.VendaBruta:=1050;

wregistro60M.ValorGT:=10000;

ACBrSintegra.Registros60M.Add(wregistro60M);

//Registros filhos do 60M que acabamos de inserir...

wregistro60A:=TRegistro60A.Create;

wregistro60A.Emissao:=ACBrSintegra.Registro10.DataInicial;

wregistro60A.NumSerie:='000000987456';

wregistro60A.StAliquota:='F';

wregistro60A.Valor:=500;

ACBrSintegra.Registros60M[i].Regs60A.Add(wregistro60A); //

wregistro60A:=TRegistro60A.Create;

wregistro60A.Emissao:=ACBrSintegra.Registro10.DataInicial;

wregistro60A.NumSerie:='000000987456';

wregistro60A.StAliquota:='I';

wregistro60A.Valor:=550;

ACBrSintegra.Registros60M[i].Regs60A.Add(wregistro60A); //

inc(i);

//Próximo registro 60M



Esse é o tipo de coisa que a lei não nos prepara para fazer de antemão.