c2c-oerpscenario team mailing list archive

[James Jesudason <james.jesudason@xxxxxxxxxxxxx>]

Public bug reported:

The account_reverse module is intended to allow a financial journal to
be reversed, with the reversal occurring on a date and period specified
in the wizard. This module has a number of issues:

1. If the date and period are changed an error occurs:
"Error occurred while validating the field(s) line_id: You cannot create entries on different periods/journals in the same move"
To reproduce the error, find an old journal entry (ideally one in a past period) and run the reversal wizard. Enter a reversal date for today (or the future) and change the period accordingly. Click OK and the error will be generated.

The error is caused because the date is now on the account.move and
account.move.line records, and the move is cloned and then an attempt to
update it is made. When this is done, the date of the account.move is
different from the account.move.line records and so the update fails.
The way to fix this is to update both record types at the same time.
That said, it does seem odd that the date is on both the account.move
and the account.move.line. Perhaps the date field on the
account.move.line records should be changed to related fields.

Also, there is a "Repeat params" checkbox - unticking this field creates an exception:
"IntegrityError: null value in column "date" violates not-null constraint"
I don't really understand what the purpose of unticking this checkbox would be. To me, this should not be an option.

2. The module allows journal entries to be posted into the future, and those journals affect the account balance for today.
Accounting systems typically have one of two ways to deal with future-posted journal entries:
a. Allow future dates, but the system automatically filters balances based on the current date, so future account moves do not affect the current balance.
b. Create a schedule record for future moves (instead of a financial journal), and have a daily scheduled process run to convert the schedule record into an account move on the relevant effective date.

I think that option b is simpler to do and will provide a good solution.

** Affects: openobject-addons
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/793665

Title:
  [account_reverse] Changing the date of the reverse generates error

Status in OpenERP Modules (addons):
  New

Bug description:
  The account_reverse module is intended to allow a financial journal to
  be reversed, with the reversal occurring on a date and period
  specified in the wizard. This module has a number of issues:

  1. If the date and period are changed an error occurs:
  "Error occurred while validating the field(s) line_id: You cannot create entries on different periods/journals in the same move"
  To reproduce the error, find an old journal entry (ideally one in a past period) and run the reversal wizard. Enter a reversal date for today (or the future) and change the period accordingly. Click OK and the error will be generated.

  The error is caused because the date is now on the account.move and
  account.move.line records, and the move is cloned and then an attempt
  to update it is made. When this is done, the date of the account.move
  is different from the account.move.line records and so the update
  fails. The way to fix this is to update both record types at the same
  time. That said, it does seem odd that the date is on both the
  account.move and the account.move.line. Perhaps the date field on the
  account.move.line records should be changed to related fields.

  Also, there is a "Repeat params" checkbox - unticking this field creates an exception:
  "IntegrityError: null value in column "date" violates not-null constraint"
  I don't really understand what the purpose of unticking this checkbox would be. To me, this should not be an option.

  2. The module allows journal entries to be posted into the future, and those journals affect the account balance for today.
  Accounting systems typically have one of two ways to deal with future-posted journal entries:
  a. Allow future dates, but the system automatically filters balances based on the current date, so future account moves do not affect the current balance.
  b. Create a schedule record for future moves (instead of a financial journal), and have a daily scheduled process run to convert the schedule record into an account move on the relevant effective date.

  I think that option b is simpler to do and will provide a good
  solution.