reports: need workstation tracking for all payment types

[Chris Sharp]

Currently in Evergreen, there is no link between the payment types of "work", "forgive", and "goods", and the workstation where the "payment" was taken. While these types do not involve actual money, there is a need for staff to be able to track which payments happened where. The only available path between a payment of these types and a specific organizational unit is via the staff user's home library, which is not necessarily the same as the staff user's working location.

We need some sort of database-based linkage between these payment types and the workstation where they are applied.

Evergreen 2.5.1
OpenSRF 2.2.1
PostgreSQL 9.1
Ubuntu 12.04 LTS

[Chris Sharp (chrissharp123)]

I'll mention that there is a convoluted path from the Workstation reports source back to Payments via circulations linked to the workstation, but I still think there needs to be a more direct link between these payment types and the workstation.

[Chris Sharp (chrissharp123)]

Scratch my last comment (see http://irc.evergreen-ils.org/evergreen/2014-08-08#i_116259 for discussion). There does not appear to be any way to get the information I'm after.

[Josh Stompro (u-launchpad-stompro-org)]

Hello, we just ran into this problem while trying to grab stats for a "food for fines" program that we had instructed staff to use the Goods payment for. Now we are just realizing that the workstation where the goods were accepted isn't stored. We have accounts for subs that move from branch to branch that will make it difficult to account for all of the transactions without correlating with individual staff schedules.

So I would second recording the workstation/cash drawer for every payment time when the info exists.

Josh

[Jason Stephenson (jstephenson)]

Basically, receiving_workstation should be added to the payment tables. It will need to be nullable to accommodate the existing payments where the workstation cannot be guessed.

Payment code will be needed to add the workstation to payments.

Question is, do we add the workstation id or name to the payments? I can see that going either way, but there has been talk here of deleting old workstations. Going with the id and making the FK relationship would complicate removing old workstations. Storing just the workstation name would probably get everyone what they want, but would violate principles of non-duplication and normalization.

My preference? Use the name.

[Jeff Godin (jgodin)]

I'd like to see us store the workstation ID.

If you want to delete workstations, have you considered one of:

1) wait until you've purged any transactions referencing the workstation
2) set columns that reference the workstation to null or a placeholder workstation
3) add support for a deleted flag on actor.workstation

Investigation of options for deletion of workstation objects might be a matter for another ticket.

Payments aren't the only place where there's a FK relationship actor.workstation(id). :-)

[Jason Stephenson (jstephenson)]

I did consider making the FK relationship nullable, though I didn't mention it above. My preference is still for storing the name, but if there's consensus or otherwise compelling reasons to use the id, I'm fine with that.

What we have brought up briefly here is deleting all workstations at some point and having staff register new ones in a future upgrade. Naturally, the delete would be done in the database.

I'll look for the other FK relationships on actor.workstation.id. That may just put an end to such chatter.

I think I'd forego the deleted flag on actor.workstation. We have more than enough deleted fields already. :)