Re: Error updating an old transaction

On Thu, Apr 10, 2014 at 9:14 AM, Lyle <..hidden..> wrote:

On 10/04/2014 16:11, Chris Travers wrote:

[Thu Apr 10 17:28:55 2014] [error] [client 192.168.1.40] Premature end of script headers: ap.pl, referer: http://mydomain.com/ledgersmb/ap.pl

I remember in lsmb 1.2 I had to run some code to enable old transactions to be updated. Is that this case in 1.3?

Right. You can re-enable this by granting DELETE permissions on acc_trans.

Thanks.

This will be removed in future versions (probably 1.5).

:(

The Correct Way:

The correct way to handle this is to void and re-enter the invoice. We have a void button at the bottom for this.

That's ok if you know what you are doing and don't make many mistakes. It's just not workable for a casual user from my experience.

There are two concerns here and I have some ideas on how to address the same problem in a more correct way.

The big one is transparency and auditability. The concern is that if someone can retroactively change transactions after they are a part of the books they can use this to cover all sorts of mischief (theft, embezzlement, etc). This is really not something you want to let happen and there are good reasons accountants don't treat this as correct. So for a *posted* invoice, void and re-enter is correct. Tax authorities, as Istvan points out, take a similar view in many places.

Now in 1.3 by default we also don't immediately post AR/AP/GL transactions, giving you an opportunity to review before you say "make this a part of your books." In this model you can enter, pause, review, and go "oops, that's not right." And only once you are sure it is right post it to the books.

Unposted invoices can be modified. In 1.4 we include invoices with inventory in this process. In other words, in 1.4 it is possible to enter every financial transaction in your books in a temporary form which allows you to modify transactions or delete/re-enter payments without violating this principle. Only once you sign off on its correctness does it become a part of your financial reports and immutable as far as the system is concerned. This is specifically how to keep from having to frequently void/post-as-new invoices.

In 1.5, I am hoping to have the financial logic rewritten, and it will not include a delete function. I am pondering the possibility of tracking voids against the original, so that these can be optionally hidden in reports.

So I guess my questions as I go into this process are:

1. How frequently do you find yourself having to modify a posted transaction?

and

2. How old is the transaction when you modify it? Is this something you usually catch within days? During bank reconciliation? Something else?

Best Wishes,

Chris Travers

Lyle
Lyle

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

--

Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Best Wishes,

Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more