…tement

Let's assume the following order of bank statement:
1 - 2 - 3 - 4
and now we change the date of statement 2 to be at the end
1 - 3 - 4 - 2

Changing the date triggers the recompute on record 2, that will correctly change it's
previous_statement_id to 4, however we also have to change to value of record 3 so that
it points towards record 1. This was previously done inside the recompute function by use
of a simple search and an assignation on record 3. However this caused some random issues
as if we try to access the record 3 value just after having change record 2 value, the ORM
might not have yet call the method to recompute record 2 (this is called when we try to
access record 2 value but we didn't do it in this case). Therefore the value in record 3
might not have changed yet. Hence the error spotted. The reason why this error only
happen some of the time is probably due to some method inside the ORM where we read the value
on record and those value are in a set meaning that it is not ordered and sometimes when
we were lucky the recompute happened before we tried to read the value of the other record.

The solution to this problem is to move the logic of other statements to recompute (in the
example record 3) inside the create/write method. And instead of assigning the value directly
only mark those record as needing to be recompute. That way whenever we try to access the value
of such record (record 3 in this case), if it was not yet recomputed, it will be done at that time