https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23049 --- Comment #64 from Martin Renvoize <martin.renvoize@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.