Re: migration to sql-ledger

Hi Raido,

I have used sql-ledger for years and migrated to ledgersmb 1.2 in 2010.
I started to use ledgersmb 1.4 half a year ago with one company and

Thanks for using LedgerSMB all that time! Your 1.2 experience was pretty good, then, I assume. Is that correct?

You are right, the best of available choises :).

Ok. Well, I hope this discussion help us become your best choice for the next 6 years (or more)!

We have tried also commercial bookkeeping software, but ware not able to afford any yet. I have tried to migrate to 1.3 also several times, but have not managed.

That's pretty unfortunate. Have you tried getting in contact with other users to get your problems resolved, like you have now? If not, maybe we can help you get your migration issues resolved this time (to 1.4, that is)? I'd be really interested in helping you out, because we really need real-world data (lots of it!) to test the migration programs. Unfortunately, we have only (very) limited amounts.

I do not remember exact cause. Was it perl errors because of wrong perl libraries or database conversion problems or both. That's why I used 1.2 so long.

Also, in case of 1.4 I still am not able to migrate. I installed new vm and got 1.4 working, but was unable to import v1.2 databases, so I started from clean database again. I also could not import chart of accounts. I managed somehow to export coa from 1.2 to csv but unable to import to 1.4.

Would you mind me helping you get the migration done? It'd be for free, but it might take me a while: I'd like to test the 1.2 migration programs with your data and improve them in such a way that your data can be migrated. That way, everybody benefits. Lets get in contact off-list to discuss the details (your data won't need to leave your VM for this, but I would need access to it).

planned to migrate others to from ledgersmb 1.2 to 1.4, but I am afraid
I can not. I make mistakes quite often and as transactions and invoices
repair is not possible in 1.4. The correct way of doing reversal
transactions and invoices may be good for big companies, but I have
mostly one person companies.

Actually, the behaviour to require reversing/reposting transactions instead of overwriting them has very little to do with big versus small companies. It has to do with software that is compliant with generally accepted anti-fraud measures in the accounting process.

You are right. But as I am doing bookkeeping myself, I am not so much worried about fraud :).

Right :-) But the tax authorities still might: you could be sending out an invoice at a certain amount, get paid in cash, then edit the invoice to be at a lower amount and not file the remaining amount. That's good for you, but bad for the tax man, because now your counterparty has nicely high deductions, while your administration has low payments. This too counts as fraud, I'm affraid, a type of fraud that benefits the owner of the company -- so, not *internal* fraud where usually the owner of the company is kind-of the "victim". Not implying you're using the transaction editing for this, of course!

I have repaired records and invoices using
directly sql prompt or with dump-modify-restore sequence, but this is
also quite frustrating.

I can imagine. May I ask why you choose to use this workflow? I make my share of errors (believe me!), but I use this workflow:

* Open the faulty transaction

* Put a minus in front of all the numbers, f it's an AR/AP transaction, add "-VOID" to the invoice number

* Post the transaction

* Reopen the faulty transaction

* Correct the mistake

* Post as a new transaction

Is there any reason why you couldn't use this workflow? It's completely compliant and probably less error prone and faster than correcting in the SQL dump/window.

Right again. But the reports look much cleaner and easier to read without the old transactions and their reversals. If there would be possible to get reports without wrong invoices and their reversals it might also be the solution.

Yes, I think as soon as we have the functionality to "post a replacement transaction", we should also implement reports which allow to exclude the transactions which have been voided and those which void others.

Most common mistake is putting wrong account to transaction. For example in case of vendor invoice I put the cost of good to assets but later decide to change to expense. I would need to change just the number of account in vendor invoice without any mess in balance sheet and income statement (if I would need to reverse the invoice as a whole). For example in HansaWorld it is possible to change account number in transactions later.

There is this:

I have an open request from a customer who would like me to implement the automated workflow above, but with the push of a button. The idea is that the user does not need to execute all the steps above, but instead, posts the reversal with the same push which posts the correcting transaction. Then, it will work with the same number of pushes on buttons as LedgerSMB 1.2 and SQL Ledger *and* the underlying recording stays compliant.

Would that be a solution for you too?

This sounds great, but it would not resolve the mess in reports as I described above. Of course I name it "mess" but you probably name it "correct".

Ok. As you proposed above yourself, I can fully agree to implementing the reports to allow in- or excluding the reverse-related transactions. I think that should solve it.

Another solution I have thought, would be append only auditing log, where all the changes are written, so the fraud would not be possible, but reports ware clean.

Yes, that would, in the sense that it'd solve the "mess" in the reports. However, it doesn't solve the "mess" with the inventory getting "messed up". But if excluding the transactions from the reports helps you, then we'd effectively achieve the same thing: you wouldn't normally see the transactions while it's still possible to show them to any auditors, etc.

Thanks for taking the time to mail us! I hope we can learn from it and maybe we can improve the software in a way that you don't need to migrate to SQL Ledger and everybody gets to benefit? I hope we can discuss your reasons to dump/edit/restore versus the workflow I'm proposing!

I am glad if my thoughts help to improve the program. Another problem is also my poor knowledge of English accounting terminology which makes it especially hard to learn all the possibilities of LedgerSMB.

May I ask what your native language is? (I can't tell by the extension on your e-mail: .eu) I'm asking because translations exist for LedgerSMB. Not all translations are complete yet, but the site hosting the translation access Transifex(https://www.transifex.com/ledgersmb/ledgersmb/) can help find translators. Maybe that helps, or maybe you can find a few other users from the same language who together want to sponsor a translator?

Some things would be much easier if I would know which button to press :).

Well, I personally find the English you're using to mail this list just fine, so, don't hesitate to mail this list with your questions. I'll do my best to find the answers, as long as the questions are about using the program (I can't answer any accounting questions, I'm affraid).

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.