https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23049
--- Comment #64 from Martin Renvoize <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
