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

Re: restart or fix

Erik Huelsmann <..hidden..> wrote:
    > 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.

If you have an automated way to do this, it would be a great thing to do.
It seems that such a thing might also let one move 1 year's worth of history
to a new database...  I'm mostly concerned about various auxiliary tables
being wrong.  (Like why I have only Employee Contacts...?)

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

I'm at 1.4.12.

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

yes, the whole set of services and parts is valuable, and why I usually

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

Several buttons... even better would be that I could set for a given
transaction what the primary button is, and have that also "copied"...

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

Thank you so much for this, because it will mean that the rest of us can help
out more.   I'm quite willing to put in several days/year towards this, but
my problem is that I have to be actually running the latest version...

    > 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'm thinking that we want to have a way to fix it right on the reconciliation
page.  Of course, it should create a new transaction.. but how many times do
I get it wrong, and then have to reverse it twice...

    > 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)?

I haven't tried 1.5 yet.  I will upgrade to 1.4.23, and then to 1.5/git in a new
VM.  I'm gonna have to go through Jan2015 books with the idea that I might
have to throw it away and do it again... which is hard to do.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     ..hidden..  http://www.sandelman.ca/        |   ruby on rails    [

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