Re: restart or fix

On Mon, Feb 1, 2016 at 3:23 PM, Michael Richardson <..hidden..> wrote:

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.

Well, not at the moment, but I guess various regulatory requirements (at least here in the EU) may require companies to drop specific information on customers after a specific period. One of the ways to achieve that is by "compressing" historic data into various month-end balances, or failing that, by compressing everything into a starting balance and discarding information no longer required.

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

Ok. That's a different story. I don't think any amount of ledger-compression will resolve this 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.
I'm at 1.4.12.

I'll set up a 1.4.12 instance myself and see if I can produce the "employee" issue there. If so, then I would expect the problem to be resolved by 1.4.23, because I'm not having it at the moment and I'm not aware of any other users of recent versions that may have it. I'll get back to you about this in a few hours. If I need to send screenshots, I may need to do that off-list (to prevent excess list traffic; there's only a limited size per list directed e-mail).

> 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
copy-as-new.

Ok. Assuming your service+parts identifiers stay the same between the old and the new system, importing of invoices should be doable. Do you (or anybody else) have any specific requirements as to the XML format to use? If we are going to implement this, we may just as well use a format that helps our integration with other systems/regulations.

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

In the 1.5 UI it would be relatively easy to add a "drop down" section to the Copy button. E.g. that you have a "+" on the right of the button. If you click on the left (on the "Copy" text), the transaction copies, but if you click on the "+", then you get the "Copy-with-payments" and "Copy-with-dates-advanced" buttons. In the 1.4 UI this is much harder to add. Would that feature in the 1.5 UI help your use-case "enough"?

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

For now, yes. But once 1.5 hits GA, I'm expecting it to be possible to develop test scripts on older versions which then can be used against the most recent (1.5) version, maybe even 'master'. If not the latter, then I'll happily forward port the test scripts to 'master', if you're not in a position to do so.

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

Hmm. Hadn't thought about it that way, but I absolutely get your point: The only way you can be efficient is if you are able to correct any issues you're finding right on the reconciliation screen. I'm trying to come up with the desired enhancement here; maybe we can have it soon enough -- after all, we're in the year where we want to listen to our users and improve the user experience. In my experience, these are causes for differences:

a. AR/AP Transactions (with payments)/GL transactions have been saved but not posted

b. Transactions have been posted on the wrong date

c. Transactions have been posted with the wrong amount (your example)

d. Transactions plain missing (transaction *should* have been posted but wasn't copied from last month yet, e.g. utilities bill)

Here "transactions" can mean any of three types:

1. Payment transactions (single and batch)

2. Receipt transactions (single and batch)

3. GL transactions

I guess helping people find not-yet-posted transactions (and post them) as well as "moving" transactions from one date to another, should be doable (items (a) and (b)).

I'm imagining it to be really hard to provide a "short-cut" screen to add missing transactions (category (d)), because it basically (really quickly) starts to duplicate the functionality in the transaction entry screens.

For all types of corrections, I'm trying to figure out how the functionality should interact with "Separation of duties".

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

Doesn't sound very attractive, indeed. Maybe it's an option to "patch" the database to move all your customers/vendors from "Employee" to customers/vendors?

Bye,

Erik.

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

Robust and Flexible. No vendor lock-in.