Besides the security hole I just patched, I think the "Till Reconciliation" report in 3.x has other serious deficiencies, mostly related to simplistic structure underlying fines. If it seems unfamiliar, it should be. I commented it out of the interface just before the 3.0 release when I started to realize the problems with it, but the report script itself was still there. Recently some of our clients found it and started trying to use it. So here's my argument that it should be removed outright. The branch of the fine payment transaction does not exist in the accountlines table. No provisions to record that information exist. Even if branchcode were recorded it would not be effective as a real P.O.S. reconciliation report, because it wouldn't differentiate between any of the various stations in the same branch. Here's the part I really don't like. In the retail world a "Till Reconciliation" report is used daily to balance out a cash drawer and total up the day's transactions before an evening deposit. This is the type of "evidence" used to fire someone when their register comes up short. The report as it stands, despite appearances, is totally useless for that purpose and should not be attributed any authority at all. Basically, Koha does not have 1-to-1 assurances for the physical location or uniqueness of the remote user, system or branch. Koha does not establish the identity of remote systems, only the remote user. In that sense it is a web application, and not a P.O.S. system. It doesn't care where on the Internet you are, as long as you remember your login. We can have multiple terminals on the same IP, mutliple browsers on the same system, the same system on multiple IPs, the same user on multiple sessions, etc. In short, we don't know what "till" any payment went to, and as it stands we don't even know what branch. IP level filtering can be used to restrict access to known networks, but that is not tracked by any internal logic. Adding the branch and operator to fine transactions, and outputting it is relatively modest refinement compared to making that data verifiable. None of the fines enhancement LibLime is currently discussing include establishing the remote system identity in a truly auditable way (like, say, client-side certificates). Please keep in mind I support the idea/workflow of this report, I just think that we cannot allow the current implementation to be mistaken for valid. Any complaints about removing it until fines is overhauled, comments or considerations? --Joe Atzberger, LibLime