2011/4/1 Robin Sheat <robin@catalyst.net.nz>:
Ian Walls schreef op do 31-03-2011 om 10:01 [-0400]:
One comment: $type should be user-definable, not hardcoded values. More extensible that way, since libraries are always good at coming up with new ways of doing things. This would allow for statistical reports on Accounts to a library-specific level of granularity; I just know if we do it hard-coded, someone is going to complain that they can't differentiate fine types at all get lumped into 'M'.
There's no logic behind the type, except perhaps 'F' to indicate fines that should be forgiven/removed when in dropbox mode. What I'll do for now is make sure I don't put anything in that's restricting them (except perhaps 'F',) and this will allow a future enhancement that could, say, pull the possible options from an authorised value or some such.
On that note, what would people suggest for handling fines that should be cancelled in an accounting-sorta way? So far in my design, the only way to reduce/remove a charge is to attach a payment to it. The two options I can see are: 1) create an offset that doesn't link to a payment that cancels out the charge (this seems like it'll make things unbalanced) 2) add a 'cancelled' flag on the transaction.
I'll probably go for 2, unless someone has opinions.
There definitely needs to be an easy way to write off a charge. It happens a lot, The way it is done now is with a writeoff payment. But as long as however it is done allows the same functionality I'm happy Chris