• Registered: 12/25/2007
  • Posts: 2,447

Topic: Planned changes in journal transaction reversing.

In Journal Entry form there is 'Reverse Transaction' option available. When this option is used, in additon to the journal entry just defined by user, duplicate  transaction with negated amounts is created in next month. This option has been designed log time ago AFAIK to make easier correcting previously existing journal entries, in case they were posted in improper accounting period.

We plan to remove the Reverse Transaction option, and supersede it by following mechanism:

. new 'Reverse transaction' option icons column will be added on Journal Inquiry page;
. when the option in journal inquiry is clicked, the selected journal transaction is presented in read-only mode, with only two editable fields: reversal date and target date of reversed transaction, followed by submit button.
. when new dates are entered and form is submited, the two journal transactions are generated,  reverting the original transaction and effectively moving the GL postings to selected target date.

This way the workflow for transaction reversal is much less error prone. Currently you have to enter manually all the reversed
transaction line by line. After the change only the two dates will be required to reverse selected GL transaction.

What do you think about the planned change?

Janusz

  • From: Netherlands, Amsterdam
  • Registered: 03/06/2011
  • Posts: 111

Re: Planned changes in journal transaction reversing.

itronics wrote:

What do you think about the planned change?

Sounds ok Janusz!

  • elax
  • Senior Member
  • Offline
  • From: UK
  • Registered: 05/17/2011
  • Posts: 326

Re: Planned changes in journal transaction reversing.

To be fair, I never understood what this 'Reverse Transaction' checkbox was for, and even after reading this, I'm still not sure.
The new version seems better, even though it's behavior is still obscur : If I click on a reverse transaction button why would it generate 2 transcation instead of just reversing the initial one ?

/Elax

  • Registered: 12/25/2007
  • Posts: 2,447

Re: Planned changes in journal transaction reversing.

The original 'Reverse Transaction' option was implemented long time ago, and later never revised. When removal of this option was discussed in the past, some FA user argued that GL records once posted should never be removed from journal. Therefore the only way to move any GL transaction from one accounting period to another is posting them again twice: in proper period and in the previous period with negated sign.

I personally don't like 'reversal' adjustment method, as such an operation fixes only total accounts balances, leaving side balances (Cr/Db) for the period still biased. But I can understand that in some countries alternative journal transaction voiding can be forbidden, so I proposed alternative workflow described above, which is at least a little less error prone.

If this thread discussion would lead to the conclusion that nobody is interested in the 'reverse transaction' option, I would be happy just to remove it instead wink.

Janusz

  • alvin
  • Senior Member
  • Offline
  • From: USA, Guatemala, Honduras
  • Registered: 05/20/2008
  • Posts: 301

Re: Planned changes in journal transaction reversing.

I think reverse or delete of any transaction is good. However it is a must to maintain a user audit log.  You should always be able to see what users are doing in the system.

"The roots of education are bitter, but the fruit is sweet."  - Aristotle.
  • xero
  • Member
  • Offline
  • Registered: 04/11/2013
  • Posts: 11

Re: Planned changes in journal transaction reversing.

For what it's worth, the plan sounds OK to me too........

  • From: Malta
  • Registered: 04/06/2012
  • Posts: 123

Re: Planned changes in journal transaction reversing.

Hi Janusz,
This method of reversal you are proposing is very good.
The International Financial Reporting Standards (IFRS) require that no transaction is deleted from the journal but instead a mistaken transaction should be reversed.
Therefore by adding the functionality you mention just improved the level of standard for Frontaccounting.

Perhaps while you are at it, you might also visit the voiding method of Invoices and other similar transactions.

It is quite tedious to notice that you had the date wrong after entering a batch of invoices. Voiding each one and re-entering them again. In this case, enabling only a change of date (as long as the period has not been closed) might save a ton of work correcting date mistakes.

Cheers, Carmelo