Re: migration to sql-ledger

Hi,

Welcome to our mailing list!

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?

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.

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.

Will there be any fork of ledgersmb where repair
of transactions is possible like it was in 1.2? Probably not?

No, I'm affraid that's impossble, as it completely messes up inventory registration in all versions before 1.3 (a property we inherited from SQL Ledger). Reversing the transaction adjusts inventory with the reverse impact of the purchase/sale; reposting does then the correct thing on inventory again. While that may not matter to you, we can't have a function to "repair" transactions which works for every scenario.

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?

In this
case, Is there any simple solution to migrate from ledgersmb 1.4 to
sql-ledger 3.2? I think sql-ledger is best choice for me, as I am
familiar with it. This question is probably asked a lot,

To be honest, I really think you're the first to ask this question. You're definitely the first that *I* know of who asks this question. (Mind you, I've been asked to improve LedgerSMB workflows quite often, change reports, etc, before people would migrate *to* it, but no, I've not have anybody ask me this question yet.)

but I could not find anything on ledgersmb web.

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!

Kindest regards,

Bye,

Erik.

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

Robust and Flexible. No vendor lock-in.