On Mon, Feb 1, 2016 at 3:23 PM, Michael Richardson <m...@sandelman.ca> wrote:
> Erik Huelsmann <ehu...@gmail.com> 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.
------------------------------------------------------------------------------
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!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
