Bug 21791 - Add payment type on Cash register report (cash_register_stats.pl)
Summary: Add payment type on Cash register report (cash_register_stats.pl)
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Reports (show other bugs)
Version: 18.05
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 18786
Blocks:
  Show dependency treegraph
 
Reported: 2018-11-08 16:39 UTC by Marjorie Barry-Vila
Modified: 2020-01-30 20:24 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
UNTESTED patch (4.71 KB, patch)
2020-01-29 23:46 UTC, Eric Phetteplace
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Marjorie Barry-Vila 2018-11-08 16:39:14 UTC
Hi,

Tested on 18.05.03, payment type (see bz 18786) are not display on cash register statistics (cash_register_stats.pl).

Regards
Marjorie
Comment 1 Marjorie Barry-Vila 2019-12-20 16:19:01 UTC
+1
Comment 2 Eric Phetteplace 2020-01-29 23:46:58 UTC
Created attachment 98104 [details] [review]
UNTESTED patch
Comment 3 Eric Phetteplace 2020-01-29 23:53:29 UTC
I took a pass at adding this field but I'm not sure if it will work; I didn't test on a sandbox instance. One question I had: the values of accountlines.payment_type come from the PAYMENT_TYPE authorized values. Should the report show the field's literal value (the code) or its (more readable) associated Description? I lean towards showing literal values as they tend to be more consistent over time but I'm not sure if there's a standardized approach for Koha.
Comment 4 Martin Renvoize 2020-01-30 07:49:52 UTC
I would say for an inbuilt report like this one then translating codes to descriptions is the preferred approach.. however this is a great start.

Just to note, however, I am currently considering a patch to merge payment_type into credit_types as I'm not sure that having two levels of 'type' makes sense now that we have a clearer distinction between 'credit' and 'debit' lines.

I'd be interested in feedback for that approach.. are there really times when one would want `pay` + `cash` or `credit` + `beans` vs just having `cash`, `card` and `beans` as a top-level credit type?
Comment 5 Eric Phetteplace 2020-01-30 20:24:06 UTC
Ah OK I will hold off working on this then. For what it's worth, I agree that the payment type/credit type setup seems redundant, but I'll ask our staff what they think about it, too.