Besides the security hole I just patched, I think the &quot;Till Reconciliation&quot; report in 3.x has other serious deficiencies, mostly related to simplistic structure underlying fines.&nbsp; If it seems unfamiliar, it should be.&nbsp; 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.&nbsp; Recently some of our clients found it and started trying to use it.&nbsp; So here&#39;s my argument that it should be removed outright.&nbsp; <br>
<br>The branch of the fine payment transaction does not exist in
the accountlines table.&nbsp; No provisions to record that information exist.&nbsp; Even if
branchcode were recorded it would not be effective as a real P.O.S.
reconciliation report, because it wouldn&#39;t differentiate between any of
the various stations in the same branch.&nbsp; <br><br>Here&#39;s the part I really don&#39;t like.&nbsp; In the retail world a &quot;Till Reconciliation&quot; report is used daily to balance out a cash drawer and total up the day&#39;s transactions before an evening deposit.&nbsp; This is
the type of &quot;evidence&quot; used to fire someone when their register comes
up short.&nbsp; The report as it stands, despite appearances, is totally useless for that purpose and should not be attributed any authority at all.<br><br>Basically, Koha does not have 1-to-1 assurances for the physical
location or uniqueness of the remote user, system or branch.&nbsp; Koha does
not establish the identity of remote systems, only the remote user.&nbsp; In
that sense it is a web application, and not a P.O.S. system.&nbsp; It
doesn&#39;t care where on the Internet you are, as long as you remember
your login.&nbsp; 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.&nbsp; In short, we don&#39;t know what &quot;till&quot; any payment went to, and as it stands we don&#39;t even know what branch.&nbsp; <br><br>IP level filtering can be used to restrict access to known networks, but that is not tracked by any internal logic.&nbsp; <br>
<br>Adding
the branch and operator to fine transactions, and outputting it is
relatively modest refinement compared to making that data verifiable.&nbsp; 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). <br>&nbsp; <br>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.&nbsp; Any complaints about removing it until fines is overhauled, comments or considerations?<br>
<br>--Joe Atzberger,<br>LibLime<br>