[Koha] report generation-Till Reconciliation for each branchlibraries

[Joann Ransom]

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> wrote:
>   
>> On Wed, Dec 10, 2008 at 10:49 AM, BWS Johnson <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
> http://lists.katipo.co.nz/mailman/listinfo/koha
>