[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: restart or fix

Hi Michael,

On Sun, Jan 31, 2016 at 8:59 PM, Michael Richardson <..hidden..> wrote:
As I finish off my 2015 books, with my database file that is now ~13 years
old, through numerous versions of smb-ledger and ledgersmb, and many bugs and
database migrations, and lots of problems that may well be due to data-rot,
I am considering starting from a fresh database.

That's an option of course. Do you ever look back all those years? Or do you simply look back 1 or 2 years? If the latter, it might make sense to compress everything from before that period into a starting balance and try to migrate the transactions, invoices, etc as of that start date. That might eliminate a lot of very old data that could now be the cause of problems.
Of course, starting from scratch makes me also think if I should look
Yes. That's fair enough.
  I need a web-browser based accounting system that ideally I can
self-host a VM, and works with *nux desktops (my Amiga 2000 was replaced with
a Sun3... then NetBSD/x86...)
(So "ACCPAC", etc. are just out)...  Freshbooks has been on my list, but they
still don't really support bank accounts (i.e. reconciliation), just invoices
and expenses.

If/when I restart on LedgerSMB, then I would like to be able to export my
contact list and import it.  This probably the major issue.
You'll be going from 1.3 to 1.4, right? That's no problem. One solution here would be to cut the 1.3->1.4 migration script down to the bits that are just for contacts. That'd basically just seed your database with customers/vendors and other contacts.

Along the same lines, if you want a minimal 1.3->1.4 migration, it shouldn't be too hard to migrate an ending balance. It's a bit harder to migrate the ending-balance-and-open AR/AP-transactions, but even that wouldn't be impossible. Yet it'd greatly reduce the amount of data in the system and thereby also greatly reduce the chances for problems caused by old(er) data.
Copy-As-New is my most used button, and it would be awesome if I could bring
samples along, but I think that will fail...
Well, Chris is working to get template transactions in working order. With template transactions, we actually have something that would allow exactly this: set up samples/prototypes which can be adjusted and posted.
If only there was some kind of XML export of an invoice that could be
imported/emailed/signed. (I've wanted to 2 months on this problem for at
least 10 years now)
I'm thinking the export part is actually pretty simple. The import part is a bit harder due to the need to catch all possible error conditions that can arise. However, are you expecting to use the same definition of services and parts (same codes)? That'd be a prerequisite, but if that's an option, then even importing might not be too hard (we already have CSV imports of AR/AP transactions).
I'd really like to extend Copy-As-New to include Copy-As-New-and-include-payments,
Ok. As a second button? Anyway, this isn't hard: there's code explicitly removing payment data in the copy-as-new code path (I think); so all we need is a bit of code which allows to skip that code...
and also "copy-as-new-but-add-1-month-to-dates" [for the mobile bill, or the
CC interest charges which changes each month, so recurring transactions can't
capture this...]

Since 1.3.x and non-editable transactions, I still don't have a reasonable
flow for making changes.  1.4 locked down transactions in the reconciliation
report, and won't include new ones without a delete... so what's the flow to
fix something?
This is considered to be a bug. Unfortunately, we haven't had time to work on this yet. Having grown tired of fixing bugs that I introduced because I fixed a bug, I have been working on building more testing infrastructure over the last month. Yes, I also did a similar exercise last year which then helped to coax out syntax problems and similar issues from the entire 1.5 and 1.4 code bases. This time, I'm building tests from the end-user perspective. I know you have seen my reports on that. This infrastructure hasn't been backported (yet) to 1.4 though, but should help me stay sane when we further work to stabilize 1.5.
Just now, I entered a purchase as 35.52, when in fact it was 32.52. Off my $3
That's what reconciliation is for... okay, now what?  We need a flow to *FIX* this.
Yes. And the fix is an entry of a new/additional transaction which gets included in the reconciliation. (Which due to the bug you mentioned, doesn't work, I'm well aware).
I am still on 1.4.12, I mostly try to avoid upgrading except at the end of
the year, when I'll move to the .23 (sometime later tonight), and see.
I actually wanted to have .24 out by now, but with all the work on the testing framework, I'm affraid that didn't materialize. I'm expecting to be able to work on it in the 2 weeks to come.
I'm still sick with the problem that I can't create new Contacts.
(I have several other ledgers for other orgs, but they have fewer issues. I'm
the guinea pig before I upgrade them)

I sure hate the Dojo Toolkit, which I understand has gone away in 1.5.
If I start a fresh database, shall I start with 1.5?
What aspect of the Dojo Toolkit do you hate? The toolkit hasn't been completely removed in 1.5, but many of the negative side effects have: page generation and rendering have tremendously improved (speed) and the fact that you could use the back-button in 1.3 but not in 1.4 has largely been addressed in 1.5 as well. But saying that the toolkit has gone, no, that wouldn't be speaking the truth. Is there something we should do in 1.5 to make the toolkit even more supportive of your work (instead of being in the way as it was in 1.4)?




http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
Ledger-smb-devel mailing list