[Koha-bugs] [Bug 23049] Replace MANUAL_INV authorised value with a dedicated table

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23049

--- Comment #85 from Kyle M Hall <kyle at bywatersolutions.com> ---
(In reply to Marcel de Rooy from comment #61)
> This is a quite fundamental one:
> 
> UPDATE accountlines SET debit_type_code = accounttype, accounttype = NULL
> WHERE accounttype IN (SELECT code from account_debit_types)
> 
> Hmm. I do not really like this at first glance (and second too ;). I would
> prefer one account type and not a separate debit code. If I would be
> scrolling through account lines, I think it is weird to have to look at two
> columns to determine the type of this transaction.
> But might understand this choice from the perspective to keep this patch set
> a bit smaller and narrow it down to the old MANUAL_INV stuff.
> 
> So, my problem actually goes a bit beyond this report too and is also about
> the design of accounts. We should have added an accounts type table in the
> first place. Now we are doing it for a subset of our account types. And I am
> wondering if this step will bring us closer to that goal of integrating
> these types or will just hinder us along the way. I am inclined to think
> that we should not separate the two now.
> And I understand that this creates new problems. The account types would be
> partially controlled by the debit codes list. So we could not (yet) put a FK
> on it. But it might be a better starting point for controlling the other
> account types?
> 
> Since this is an important design choice, I would suggest to discuss this on
> the dev list or within the QA team, or dev meeting? We need some more
> consensus on that decision.

I agree that having one set of values pulled from a dedicated table and having
the other set of values pulled from Authorised Values is a less than preferable
situation. I *do* like having separate fields for the debit and credit type
because A) it makes it crystal clear if an account line is a credit or a debit
and B) it allows for FK constraints.

I think the solution is to follow this bug quickly with a second bug that moves
credit types into a dedicated table as well. As long as those come together
quickly ( definitely within the same release ), I believe this will be a big
step forward!

-- 
You are receiving this mail because:
You are watching all bug changes.