Bug 36029 - Add the ability to backdate a transaction in POS
Summary: Add the ability to backdate a transaction in POS
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Point of Sale (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Martin Renvoize
URL:
Keywords:
Depends on: 23354
Blocks:
  Show dependency treegraph
 
Reported: 2024-02-08 00:31 UTC by Barbara Johnson
Modified: 2024-08-13 20:59 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Barbara Johnson 2024-02-08 00:31:38 UTC
We've been using the POS (Point of sale) feature since August 2023. During that time we have encountered some issues that we believe could be solved by adding the ability to backdate a POS transaction.

Here is our use case:

Sometimes staff forget to enter the sale in POS. This usually happens for credit card sales when the staff member does the credit card transaction, the patron signs, a receipt is given and then the staff member is interrupted by someone/something else causing the sale to never be entered into Koha.

We have a large number of funds because our library takes care of not only fees for copies, ILLs, faxes, etc. but also Friends & Foundation sales for earbuds, flash drives, tote bags, book sales, pumpkins, event tickets, to name a few. Each of these sales goes to a different account per our City Finance dept. Staff will sometimes select the wrong debit code which is especially bad when the funds collected should have gone to a different entity, such as the Friends. 

The Finance dept. wants an exact recording of sales on the day they happened. However, these issues are often not detected until staff reconciles the drawer each morning. At that time they have to enter the missed/incorrect sales into the POS. That can cause issues with reporting since these transactions are now being entered on the wrong date. Being able to enter a transaction and backdate it would help solve this problem for the library, keep our Finance staff happy and make our reports accurate.    

I think this would need to be covered by a permission since we would only want certain staff to be able to do this.
Comment 1 Katrin Fischer 2024-02-08 08:59:14 UTC
Hi Barbara, thanks for explaining the use case in detail!
Comment 2 Mwoo 2024-02-08 17:28:00 UTC
This change would make the accounting process so much easier. Looking at Bug 28599 adding the ability to void a transaction would also be helpful and I think would solve some of reporting issues. However, if the error is not discovered until the next day, the reporting would still not reflect accurate information. Currently, we use the "refund" function for correcting mistakes which works but when the mistake is found the next day while reconciling the sales the reporting doesn't account for this change until the following day.
Comment 3 Martin Renvoize 2024-02-08 17:44:41 UTC
That's a really interesting development idea... Could you envisage where in the UI this might fit/how it should be exposed to the end user?

I'd love to continue refining point of sale again. I can't promise to get to this any time soon however with all the funded work we have on the books already taking priority.