Hi Peeter,
Thanks for taking the time to reply!
Now, I'm not sure if I'm going to sound condescending or ridiculing you.
I'll assure you, I'm not; it's merely me trying to understand the general
accounting processes and your use of the software.
> 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.
>
Ok. Well, there's a very good answer they can give their bosses, I would
say. You provided it elsewhere: making errors is human and "life happened".
> 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.
> 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.
> 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.
> 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.
> 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.
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).
> 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 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.
> 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.
> 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.
> 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.
> 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.
> 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.
--
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
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
