[Koha] report generation-Till Reconciliation for each branchlibraries

[Joann Ransom]

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
>     > _______________________________________________
>     > Koha mailing list
>     > Koha at lists.katipo.co.nz <mailto:Koha at lists.katipo.co.nz>
>     > http://lists.katipo.co.nz/mailman/listinfo/koha
>     >
>     _______________________________________________
>     Koha mailing list
>     Koha at lists.katipo.co.nz <mailto:Koha at lists.katipo.co.nz>
>     http://lists.katipo.co.nz/mailman/listinfo/koha
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>