Hi John,
On Sun, Feb 16, 2014 at 1:46 AM, John Locke <[email protected]> wrote:
> Hi, Eric,
>
> Oh, interesting. I think you and I are after exactly the same thing, but
> we're starting with a different report.
>
> I use AR -> Reports -> Transactions (summary).
>
> I'm guessing you use AR -> Reports -> Outstanding (detail).
>
Yup. That's interesting indeed, because as you, I never noticed there's a
similar report!
> A summary report on the first is almost exactly the same as a details
> report on the second. Almost, but not quite...
>
>
> So yes, I see AR -> Reports -> Outstanding -> summary as not something I
> need all the time -- and if it's misleading, that should get fixed.
>
>
> AR -> Reports -> Transactions -> detail has too much detail -- it expands
> all of the line items on invoices, so it's now much longer.
>
Right. I usually don't need that view either. And when I do, I can run
something similar through the GJ -> Reports menu.
I'm seeing one difference between the two: Transactions is showing
> transactions that are out of balance by a fraction of a cent (the old
> invoices with calculated sales tax) while Outstanding omits them.
>
That's interesting as well: they should be considered closed, so, I'd say
that the Transactions view is incorrect.
In general, I must say that all these combinations make it way too easy for
inconsistencies to creep in!
Otherwise we often are using Transactions to get a customer invoice
> history, by selecting the "closed" checkbox. For that reason alone, I would
> like to preserve the summary default there, though I can have people switch
> to the Outstanding report for the more typical use...
>
>
Sure. I think that's a logical selection that I do use occasionally as
well.
I wonder if it might make sense to actually split these into 3 reports?
> Seems like it would be confusing to have two reports lead to pretty much
> the same thing -- both with "summary" and "detail" options that do
> different things. What we have here are four different reports with two
> that are the same. How about splitting into something like:
>
> - Invoices/Transactions (with options for open and closed, the report both
> you and I use)
> - Customer outstanding totals (outstanding summary, hopefully fixed to
> only include open transactions)
> - Items (Transaction detail report)
>
> Not sure the second one is necessary, with the aging report also
> available...
>
>
Right. I think the aging overlaps with the customer outstanding totals,
when selecting "open" invoices. If you select open and closed, they differ,
but I can see myself wanting to add a column for "closed invoices" to
address that use case within the aging report.
Also, I wonder if the third item is required, since the GJ -> Reports
selection can be used to create a nearly equal report. The only difference
is that the GJ->Report interface doesn't allow selecting open and/or closed
invoices. I wonder if that's an issue in practice though.
I think it would make sense to rethink these reports as part of the 1.5
rewrite.
However, for now: what's our next action? I can see that I might need to
retrain users to use Transactions instead of Outstanding (Details), that
way we don't have to change the defaults in a release that's been going for
so long.
However, then I do think we need to work on the sub-cent issue, because
that's a regression from where I stand :-)
@Chris: can we re-wire the transaction report to use the Outstanding
(details) logic? after all, they should be the same report: they have the
same columns, I think and allow for the same columns to be added, right?
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
