The accountno is smallint(6) with no constraints. It is not guaranteed unique, and it is not even indexed! It cannot be used as a substitute for a true primary key.
Is there any reason we can't change it to an int(8) and make it the primary key?
This is not dependent on the data representation having an amountoutstanding field. The same information would be represented by combining the amount of a fine with any payment lines that reference it. In fact, that will be the authoritative version of the amount still owed, right?
That is an excellent point. I hereby withdraw my support for the amountoutstanding column!
I would prefer that the fine line, once in the table is NEVER updated (i.e., updated as little as possible, ideally NEVER), and that the authoritative version of how much is outstanding is the ONLY version. That makes a more atomic, auditable process. Multiple incongruent representations of the same data leads to the kind of mess seen in early versions of Koha fines.
Agreed.
It sounds here like you are mostly agreeing with me. I'm not saying get rid of amountoutstanding features, just make sure we pick one consistent data model.
Your argument against it makes perfect sense to me, and seems to be the optimal solution. Kyle