[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 #64 from Martin Renvoize <martin.renvoize at ptfs-europe.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.

Actually, as it currently stands you already have to look at two columns to
ascertain whether the accountline is a debit or credit, so having these two
fields next to each other is clearer in my opinion.  I would like to rename
accounttype to credit_type but didn't want to do that here and make the bug
even bigger.

> 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.

Correct, I was trying to make this patch a bit more manageable.  Bug 17702
became inpenetrably large by doing it all in one hit.

> 
> 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?

The aim was to have a similar treatment for credit_types in a second bug..
although presently I see no use case for user-definable credit_types at this
time.  I strongly believe one of the major strengths of this bug is that we're
introducing better DB design including FK constraints. One cannot point a
single field at multiple tables for such constraints at this time and I don't
believe there is any plan for such support in SQL.

> 
> 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'm happy to attempt something else if you can come up with any suggestions,
but I don't really want this to go back to discussion again (this is just a
reimplementation of bug 17702 which I believe has already been discussed). 
I've already saught support for this from those most closely in touch with
accounts and thats how I arrived at this design (Tomas, Kyle, Josef).

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