[Koha] report generation-Till Reconciliation for each branchlibraries

[Joe Atzberger]

The only thing you will "lose" is the *current form* of the report complete
with the many flaws enumerated and unenumerated.  There will be a "Cash
Reconciliation" report after revision... the kind that might actually
survive an audit.  Nobody is suggesting that the purpose of the report is
useless or that it isn't important to track payments.  The point is that it
needs to be implemented correctly to be reliable for anyone.

I've advanced the argument (and the RFC's and surrounding discussions
contend) that there are technical problems with the existing implementation
of fines and payment accounting.  I appreciate that the *purpose* of the
report is important.  That's actually part of my argument, or I'd just let
it go.  But unless you want to argue that it is technically and logically
sound, we don't really have any point of disagreement.  Your impressions of
its accuracy are based on limited admittedly buggy use in an older version
and have not engaged the question of how it works in your case, or how it
will work for any other users.

--Joe

On Wed, Dec 10, 2008 at 8:22 PM, Joann Ransom <jransom at library.org.nz>wrote:

> Thanks Joe,
>
> I am in the process of configuring a Koha 3.0 install and hadn't
> realised that we would lose the ability to run till reconciliation
> reports each day. It is a matter core to our operations and I will have
> to consider that if upgrading to 3.0 will mean losing functionality -
> hence my input.
>
> cheers Jo.
>
> Joe Atzberger wrote:
> > Joann --
> >
> > Chris and Mason are still active developers here in the community and
> > their code is certainly the basis of fines operation, for example in
> > C4/Accounts.pm and members/pay.pl.  I don't think Chris, who has
> > already commented in this thread, would withhold mentioning or
> > contributing better code if he had written it for any version.
> >
> > That being said, I think both of them would also agree that the
> > existing implementation is inadequate.  For example pay.pl dates all
> > the way back to 2000!  Transaction types are hardcoded, so the user
> > cannot create new ones.  Unlike the issues table, the accountlines
> > table is never purged or rotated, so performance will inevitably
> > degrade if used over time.  The accountlines data structure lacks
> > capacity to record the operator (who received the money) and the
> > branch (where the money is).  All that (and more) needs to change.
> >
> > You are welcome to file bugs against any version of koha at
> > http://bugs.koha.org.  But I think we are talking about essentially
> > the same code.
> >
> > --Joe Atzberger
> >
> > On Wed, Dec 10, 2008 at 5:23 PM, Joann Ransom <jransom at library.org.nz
> > <mailto:jransom at library.org.nz>> wrote:
> >
> >     Hi there,
> >
> >     We use the daily reports in our existing 2.9 install - over 3
> branches
> >     and while it has a few tiny quirks we know what they are and we work
> >     around and I believe the daily til reconciliation is accurate.
> >     Chris or
> >     Mason can probably extract the code and make it available as a
> >     starting
> >     point - and I am happy to pass on the bug descriptions.
> >
> >     cheers Jo.
> >
> >     Chris Cormack wrote:
> >     > On Thu, Dec 11, 2008 at 6:53 AM, Joe Atzberger
> >     <ohiocore at gmail.com <mailto:ohiocore at gmail.com>> wrote:
> >     >
> >     >> On Wed, Dec 10, 2008 at 10:49 AM, BWS Johnson
> >     <mhelman at illinoisalumni.org <mailto:mhelman at illinoisalumni.org>>
> >     >> wrote:
> >     >>
> >     >>> Salvete!
> >     >>>
> >     >>>> That report has been discussed before and was purposefully
> >     commented out
> >     >>>> in 3.0 (I argue should have
> >     >>>> been deleted) becuase it is not reliable in a multi-branch
> >     situation. At
> >     >>>> present, the branch where the
> >     >>>> transaction took place is not logged, so you cannot possibly
> >     create a
> >     >>>> report to extract that information.
> >     >>>>
> >     >>>> Developers are fairly aware of this problem and are working
> >     to totally
> >     >>>> overhaul fines data structure.
> >     >>>>
> >     >>> I don't mean to be abrasive here, but will that overhaul include
> a
> >     >>> solution that is palatable to both single branch Libraries and
> >     multi branch?
> >     >>>
> >     >> Yes, in particular since the current implementation is neither.
> >      A Koha user
> >     >> with a single branch still doesn't want their system to become
> >     unreliable
> >     >> just because they add a second branch.
> >     >>
> >     >> But fines in Koha has enough problematic design flaws that it
> >     requires
> >     >> overhaul even for single branch setups.  The current model is
> >     not reliable,
> >     >> atomic, maintainable, extensible, documented, secure or
> >     auditable.  The
> >     >> overhaul offers most if not all those characteristics.
> >     >>
> >     >>
> >     >>> I'd rather not see things tilt towards larger institutions in
> >     terms of
> >     >>> deleting functions that used to exist.
> >     >>>
> >     >> I'd rather not provide institutions of any size with functions
> >     that are
> >     >> erroneous, unreliable or fundamentally unsound.  I am against
> >     preserving
> >     >> features that happen to work only in small or single branch
> >     setups (unless
> >     >> they are wrapped in the SingleBranch syspref).  As a different
> >     example,
> >     >> inefficient queries that "work fine" on 4,000 records and crash
> >     systems on
> >     >> 100,000 are not the kind of well-designed features worth
> >     preserving.
> >     >> Leaving those kinds of landmines for users to step on makes
> >     Koha (or
> >     >> Unicorn, or any product) look amateurish.
> >     >>
> >     >>
> >     > Wow, how defensive we developers are.
> >     >
> >     > I think its worth acknowledging that Brooke has made some valid
> >     > points. That we do need to be careful that we make Koha usable
> >     for as
> >     > many people as possible. And while Joshua is right we mostly have
> to
> >     > code what the libraries are asking for we should be careful we
> don't
> >     > undo what other libraries have already paid for also.
> >     >
> >     > If something is broke, lets fix it. Lets not just throw features
> >     out.
> >     >
> >     > Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20081210/4c2af22c/attachment.htm