Re: migration to sql-ledger

Few replies to this e-mail... inside the text...

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.

But this is exactly the problem: sometimes an edit is a mistake, sometimes it's something that needs glossing over in other ways. The software won't know the difference. However, with appropriate comments in the transactions, any auditor/boss/colleague can understand the reason for the corrections. As a software engineer, I understand where they're comming from: I hate it when people find bugs in my software.

Most cases we use it as one-person system or two-person. I wrote longer about it in another e-mail.

Practical reasons:
Clients change their minds about order size, products, ask for additional discounts, want different wording for services etc etc.

Well, that's part of "life happening", so, yes, all this shouldn't be impossible to deal with. I very much like the example you gave in a later mail about the real estate rent invoicing. There are multiple tools in LedgerSMB 1.4 to deal with the situation there:

1. If you use batches and the invoices haven't been sent, the entire batch can be deleted with a single push of a button
2. If the invoices have been posted, but not sent: they can simply be voided. That's what voiding an invoice is for: it's to correct an internal failure -- nothing to be sent to whatever tax authority
3. If the invoices have been posted *and* sent, you have two options:
3a. Send a credit invoice *and* a new invoice; this is a lot of work, especially if/when you need to do separate reporting for credit invoices to the tax authorities
3b. Have a single (additional) invoice, crediting the previous invoice and debiting the new amount, resulting in an adjusted amount

Now, I realise that in order to better support your reporting uses to the tax authorities, you want to exclude voided invoices from your reporting, because there's no need to include them in the data delivered to the tax man. That's definitely one of the absolutely required changes I'm getting out of this discussion.

To complicated... takes too much time... but probably correct way to do it... but we need quick way to do it...

Today I just change the invoice according to their wiches and I do it in LedgerSMB. Then resend.
This is actually the classic example of "How and Why to use a credit invoice" (http://www.paychex.com/articles/finance/how-when-to-use-a-credit-invoice).

With your process, the customer now has 2 documents with different amounts, but with the same number. What happens if they put the one with the high numbers in their books (allowing high tax deductions) while you have the last one in your books (with the low tax numbers to be paid)? Isn't that a reason to start auditing the both of you? This isn't just about high belief in your trust-worthiness of your employees. This is also very much about the tax authorities thinking they might not be receiving what they're entitled to and your ability to explain that to them.

Tax audit is OK. We have enough experience with those. At least in Estonia tax audit is in most cases quick and easy process. They just compare information from both sides and if there is difference we provide explanation. Few e-mails and that's it.

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.
Ok. But before we go in that direction, I'm hoping we can come to some common understanding of why the other options have to be rejected as completely unusable.

People (clients) want the same invoice just changed. That's it. If I can't 'do it in accounting software I have to do it elsewhere. Common practice in this part of the world. My job is to make clients happy, not to argue with them. And make the sales happen :-)

And yes, clients even want to change invoice receiving company after they have paid it (as private person).
No problem. LedgerSMB supports that by copying the invoice, putting the company on it, reversing the payment on the original invoice and putting it on the new invoice.

I need the same number for this invoice not a new invoice and it has to be with the old dates, even when this change gets done months later.

While I understand that's a lot of work, it may also not be the best way to the result. What I heard some time ago is that processing invoices in Spain takes a lot of time (sounds a bit like your situation, really). As a result, people tend to send each other orders, pay to the order and only then send invoices as a confirmation of the payment. LedgerSMB supports that really well: you can have as many orders as you want. You can have them changed as often as you want too. The only thing it doesn't have (yet!) is to be able to accept payment to an order (and have it be used as a payment on the final invoice).

I use this approach now in one of my companies with WooCommerce. But there also I have a PDF Invoice plugin which creates invoices as PDF (not changeable). If changes are needed I do them later in LedgerSMB and send them a new invoice (same number, same date, different information). Mostly the change is needed in description of service they bought or receiver of the invoice needs to be some other company.

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.
Nice! Maybe you can share that script, so other Estonian users can benefit from it too? I'd happily include it in our tools/utilities directory in the main repository.

It has some mistakes, so I rather not. I have not had time to clean the code or repair those mistakes, but my accountants are aware of them and know how to get around.

I'm really not a programmer... I just copy & pasted together different stuff to get the result I needed.

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.
Ok. So, if you were able to void unsent invoices *and* were able to exclude these from the "1000 euro report", then your reporting problem would be limited. And since we already agreed LedgerSMB should grow an indicator "this transaction has been voided / this transaction is voiding", we're headed in the right direction, not?

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.
Ok. This is why I like to think of workflows and requirements rather than system functionalities: system functionalities exist to support requirements and workflows. In the *current* system, there's no way to exclude invoices which were voided. But as has become crystal clear to me, you have a requirement which isn't supported by LedgerSMB at this point: you need to be able to extract a list of /invoices actually sent/. And if we have the "this has been voided" indicator, we can support your reporting workflow.

Estonian Tax Authorites check that both parties declare the same information and it would not match if I have there some voided invoices etc.
Correct. That's why the *voided* invoices should be absolutely filtered out, there's no dispute about that. Absolutely none.

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.
That's great and I'm glad it worked for you. However, I think we can agree that you wouldn't be using LedgerSMB today if it wouldn't be able to generate a good balance at the end of the year, unless you would be an inventory-maintaining company. My point being: all types of users expect LedgerSMB to do the correct thing for them. And it should. Which is why I'd rather implement solutions that have a broad likelihood of being mostly acceptable to everybody.

Here is once again difference between one-user system and many users system.

But generally yes, I prefer also to have right values for inventory in balance sheet.

At the same time most companies I deal with don't use inventory or there we use some other program like HansaWorld.

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.
At the moment, there are talks in the EU about ways to prevent VAT declaration fraud. "VAT carousel" it's called and you can get caught in the middle of it, if you're being careless. Now, having good accounting hygiene will help you not getting caught in the middle. E.g. by issuing new invoices instead of re-using existing numbers. This is definitely not only about your own personnel.

That's why Estonia implemented declaration of over 1000 eur partners. So You can't do it in a big level anymore. Anyway I don't see that your mentioned "hygiene" would help me in any way with that. Only thing that helps is background checks of partners and even not that always. When people do these "VAT carousels" all documentation is perfect. I have heard about some small cases. Those could not be prevented they way You are talking now...

We have even found out ourselves VAT manipulation by checking if companies where our customers get invoices from have VAT number. Some times they don't even though they add VAT to invoice.

So this could be a helpful function is LedgerSMB - automatic check of VAT number and if it's still active.

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.
And that's how it's going to stay, or so I hope. But what if you have to prove that you were *not* the source of the VAT fraud that your customers and/or vendors apparently were part of? Then you become part of a criminal investigation for economic delinquencies and you need *very* good accounting to prove that the source wasn't you. Not practical accounting, no, fool-proof accounting.

I don't agree here. I don't see how it helps.

But it comes back to one-user vs a lot of users cases.

Banks want balance sheets and income statements. Nobody really cares how many mistakes there were or how they got corrected.
True. Up to the moment where you hope never to end up: in a fraud investigation due to taxes/vat/etc.

Why not? It's a interesting process. Don't be afraid of tax man, just know how to deal with them. Know the rules, know the laws and teach them some too in a friendly manner.

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.
I'm wondering what to say to this remark. It feels like you're telling me I'm not cooperative enough, yet I feel like I'm completely respectful for your position and openly discussing your requirements with you to determine a fit with current LedgerSMB functionalities and the options I see for the future.

I was not talking about You Erik. It's a general remark with the idea that I need a software with editing capabilities. That's it.

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.
If that were the only way to deal with it, sure, I would have changed too. No doubt.

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.
Ok.

I hope you can see from the above that I'm taking your problem seriously and that I'm seriously trying to find a solution together with you, within the bounds of what is deemed acceptable in the world of accounting. We want to support your processes the best way we can and to do so, we really need to know all there is to know about your processes and reporting requirements. Thank you for taking the time to write up that description for me.

Sure I understand it. But please don't take life too seriously... it's get You stressed up...

All the Best,

Peeter

--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Ledger-smb-users mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users