Re: migration to sql-ledger

One thing that I think needs to be said at the outset is that we are committed to both accepted accounting practices and solid usability. So in some cases, what we need to figure out is what to do to make these problems easy to solve within the context of proper accounting procedures.

On Thu, May 19, 2016 at 11:32 AM, Peeter Pärtel <..hidden..> wrote:

Hi everyone...

So I explain why we need to change invoices... there are many reasons...

Let's start from big one:
Accountants are perfectionist. I have seen many very stressed out accountants, almost burned out, who use software where they can't make changes. Every mistake is visible and reminds itself to them and also their clients / bosses, who ask about those mistakes as they see these as well.

In paper books you always write a reversing entry and then a correcting entry. And you are always supposed to keep books on indelible media (i.e. pen and paper, never pencil and paper). One of the difficulties is that electronic storage is never indelible in the same way. So one problem you have is that we are trying to live up to the golden standard. Now that does not mean that

When we moved over to first SQL-Ledger and then LedgerSMB, this was the big relief and accountants are much more relaxed and happy persons because they know it's ok to make mistakes and fix them. And the best... nobody knows that there even was a mistake.

Ok so the question is, basically how does one both ensure that mistakes don't clutter the books and on the other hand that you don't open up an ability for someone to cover theft by, say, taking money out and entering bogus invoices from a supplier.

Practical reasons:
Clients change their minds about order size, products, ask for additional discounts, want different wording for services etc etc. Today I just change the invoice according to their wiches and I do it in LedgerSMB. Then resend. If this would not be possible I would have to use Word or LibreOffice and remake the invoice there as client wants one clear invoice. And yes, clients even want to change invoice receiving company after they have paid it (as private person).

So normally the work flow is you start off with an order. When the order is shipped and now billable you enter an invoice. Orders can be edited without a problem so until it is shipped there is no issue. Then after it is shipped, you bill. If they return it and want a different one, you process an invoice with the return and the new item (and it will probably have a net 0 unless there is restocking fee).

It seems to me we have a gap here in functionality which is that overpayments are not tied to orders. In those cases, it becomes harder to manage payments before the items are shipped. Would better prepayment tracking address this scenario? Or are there other reasons why this approach won't work for you?

Now in 1.4 you don't have to post invoices immediately either. You can save the invoice in a batch or as a draft, review, change etc. However you cannot pay the invoice until it is posted. So you can have time to check, etc. between entry and when it becomes a part of the permanent record.

Another big one:
I have developed a script for 1.2 version which generates for me .csv file which I upload to Estonian Tax Authorites. It includes invoice information both sales and purchases with partners where we have had more than 1000 eur worth of invoicing in a given month. It must include also credit invoices, so total might be less than 1000. There are some other rules to follow as well. It means I cannot have random back and forth invoicing in the system or this report would include them which by the end of day means I would need to do this report manually or check it manually line by line as I cannot upload information about invoices which actually didn't happen. Estonian Tax Authorites check that both parties declare the same information and it would not match if I have there some voided invoices etc.

This is an interesting one. Again I think we should be able to ensure that the data for reporting purposes can avoid this issue. It seems to me like we need a way of storing in the db that the invoice has been voided (or voids another invoice) so that these can be hidden from some reports and data exports. Would that help?

And if all this changing means that inventory is messed up in the end, so be it... so far I have made once a year on 31st of December a correction into ledger based on the inventory report value and the difference in balance sheet. So it matches at this point.

Also from regulatory point of view... we are talking about small / medium companies... trust level between people is very high, so we are not afraid of fraud by employees. Also I have nightly backups and few times a year when somebody really messes up something I restore the old copy and compare... and find the mistake.
From Estonian Tax Authorities perspective... they have never asked for audit log or something like that. Just the list of invoices which include VAT, or whats inside cash account. That's pretty much it. Banks want balance sheets and income statements. Nobody really cares how many mistakes there were or how they got corrected.

I understand this might not be the case in all countries, but we need a stress free working environment which is flexible and allows correction of everything as needed.

Before using SQL-Ledger / LedgerSMB I used HansaWorld and back then there was no way to correct changes... only way was to make a text backup copy and then search from there where the mistake is and correct and then reimport the backup copy... with bigger database it toke like a day or more... and I had to do it couple of times. I had enough, that's why we changed. Nowadays it's much easier with HansaWorld as well because I can give changing rights to a specific user who can open old documents, change them and close them. Yes this person needs to know what he or she is doing and correct manually some other things as well, so everything balances but once You learn what needs to be done, it's doable.

I really hope this helps the developers and You will develope some userfriendly way to make changes into existing documents, so I can finally upgrade from 1.2 to a newer version.

Right now I think the proposals have boiled down to:

1. Allow trial balances, gl searches, etc. to include or exclude drafts. Note drafts don't have COGS yet so that will need to be documented

2. I think we will want to list unapproved transactions (though without the possibility to pay or reconcile them) on payment and cash recon selection screens. It is nice to know th difference may be due to a transaction not being approved yet

3. A way to hide voids and voided transactions from payment, recon, and report screens.

4 To this, I would add a way to tie prepayments to an order, for easy payment of related invoices.

Remember that things go from entered draft or voucher (editable) to posted (permanent, can only be voided and re-entered) on approval. 1.4 makes major strides in this regard. The question is how to address the usability issues.

After the above issues are in place would it be enough to just add a "void and re-enter" button that does that in one click?

All the Best,

Peeter Pärtel

Best Wishes,

Chris Travers

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

http://www.efficito.com/learn_more