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