Bug 8417 - date acquired is shipping date
Summary: date acquired is shipping date
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Jonathan Druart
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 24277 29175
  Show dependency treegraph
 
Reported: 2012-07-11 13:04 UTC by Nicole C. Engard
Modified: 2021-10-05 13:44 UTC (History)
6 users (show)

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


Attachments
Bug 8417: Make the order receive date editable (6.49 KB, patch)
2015-03-31 12:20 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 8417: Make the order receive date editable (6.49 KB, patch)
2015-04-21 15:02 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 8417: Make the order receive date editable (6.54 KB, patch)
2015-04-22 04:03 UTC, Biblibre Sandboxes
Details | Diff | Splinter Review
Bug 8417: Make the order receive date editable (6.58 KB, patch)
2015-09-22 11:17 UTC, Jonathan Druart
Details | Diff | Splinter Review
[PASSED QA] Bug 8417: Make the order receive date editable (6.62 KB, patch)
2015-10-16 15:13 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8417: Fix test (971 bytes, patch)
2015-10-20 15:36 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2012-07-11 13:04:22 UTC
When receiving orders, Koha is using the shipping date as the date acquired but it should probably be using the date you're actually adding the items (which might be after the shipping date).
Comment 1 Jonathan Druart 2015-03-31 12:20:03 UTC Comment hidden (obsolete)
Comment 2 Nicole C. Engard 2015-04-21 14:33:04 UTC
37404 - Bug 8417: Make the order receive date editable

Apply? [(y)es, (n)o, (i)nteractive] y
Applying: Bug 8417: Make the order receive date editable
fatal: sha1 information is lacking or useless (acqui/orderreceive.pl).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Bug 8417: Make the order receive date editable
When you have resolved this problem run "git bz apply --continue".
If you would prefer to skip this patch, instead run "git bz apply --skip".
To restore the original branch and stop patching run "git bz apply --abort".
Patch left in /tmp/Bug-8417-Make-the-order-receive-date-editable-OHt7MP.patch
Comment 3 Jonathan Druart 2015-04-21 15:02:40 UTC Comment hidden (obsolete)
Comment 4 Biblibre Sandboxes 2015-04-22 04:03:14 UTC
Patch tested with a sandbox, by Aleisha <aleishaamohia@hotmail.com>
Comment 5 Biblibre Sandboxes 2015-04-22 04:03:32 UTC Comment hidden (obsolete)
Comment 6 Katrin Fischer 2015-04-22 23:13:58 UTC
I like the idea of this!

1) Should we hide the field for AcqCreateItem = 'cataloguing'? And maybe also 'receive'? (normal)

2) I wonder if there is a use case a library might want to keep the initial order date instead. The way this patch works they can't see the initial date and they can't keep it. (question)

3) Currently the field is named 'Date received', maybe we should use the description of the item field it updates - 'Date acquired' to make the use more clear?
Comment 7 Jonathan Druart 2015-04-23 13:29:15 UTC
(In reply to Katrin Fischer from comment #6)
> I like the idea of this!
> 
> 1) Should we hide the field for AcqCreateItem = 'cataloguing'? And maybe
> also 'receive'? (normal)

It's not a new field, and it needs to be filled.
I think we should keep it.

> 2) I wonder if there is a use case a library might want to keep the initial
> order date instead. The way this patch works they can't see the initial date
> and they can't keep it. (question)

They can manually change it. We could fix this workflow later if someone ask for it.

> 3) Currently the field is named 'Date received', maybe we should use the
> description of the item field it updates - 'Date acquired' to make the use
> more clear?

I am not sure to understand, the date is used to fill aqorders.datereceived. "Date received" seems to fit quite well :)
Comment 8 Katrin Fischer 2015-04-23 13:32:53 UTC
Oh! I thought in my tests it influenced the items.dateaccessioned. Is that possible?
Comment 9 Jonathan Druart 2015-04-23 13:45:40 UTC
(In reply to Katrin Fischer from comment #8)
> Oh! I thought in my tests it influenced the items.dateaccessioned. Is that
> possible?

I think this is set to today before and after the patch. But I didn't test.
Comment 10 Jonathan Druart 2015-09-22 11:15:24 UTC
Sending back to the Needs QA queue.
Comment 11 Jonathan Druart 2015-09-22 11:17:45 UTC Comment hidden (obsolete)
Comment 12 Kyle M Hall 2015-10-16 15:13:01 UTC
Created attachment 43527 [details] [review]
[PASSED QA] Bug 8417: Make the order receive date editable

Currently the date of the order reception is the date of shipping date,
which is wrong.
This patch makes this date editable (with default is today).

Test plan:
1/ Create an order and receive it
2/ Confirm that you can edit the reception date and it's take into
account as the datereceived.

Signed-off-by: Aleisha <aleishaamohia@hotmail.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 13 Tomás Cohen Arazi 2015-10-19 17:54:35 UTC
Patch pushed to master.

Thanks Jonathan!
Comment 14 Jonathan Druart 2015-10-20 15:36:44 UTC
Created attachment 43652 [details] [review]
Bug 8417: Fix test

ModReceiveOrder now excepts a date formatted following the dateformat
pref.
If nothing is given, default is now.