Bug 14083 - Make it possible to record the date the order was placed/sent to the vendor
Summary: Make it possible to record the date the order was placed/sent to the vendor
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement with 41 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-29 20:41 UTC by Nicole C. Engard
Modified: 2021-12-22 16:36 UTC (History)
8 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2015-04-29 20:41:02 UTC
It would be nice if there were another date field in Acq.  There is no field to enter the date the item was actually ordered from the vendor. There is the date the basket was created in Koha and the date the item shipped and was received - but not the date you placed the order with the vendor.
Comment 1 Katrin Fischer 2015-04-29 20:42:40 UTC
Hi Nicole, I think the aqorders.closedate is the one you are looking for. The moment you close the basket the status switches from new to ordered and the date is set.
Comment 2 Nicole C. Engard 2015-04-29 21:49:49 UTC
Nope, that's not the date I placed the order with the vendor. So the way it works is this:

1. go to vendor site and place order
2. go to koha and enter order info again 
3. close the basket

So there is no way to get the date I ordered from the vendor.
Comment 3 Holly 2020-02-19 09:21:47 UTC
This seems to still be an issue in 19.11.
Comment 4 Katrin Fischer 2020-05-23 12:20:58 UTC
There is a bit of a gap here in what Koha thinks the vendor date is and what will happen if you use an automated process I think.

In Koha closing the basket will switch the status from new to ordered and we record this date in aqbasket.closedate. So for the system, closing the basket indicates things were ordered and we do display the close date as ordering date at least in some places already.

It makes sense to me to tie the status change to the date in some way. But maybe it should be possible to edit the ordering/closing date if necessary to allow backdating and similar?
Comment 5 Daphne Hoolahan 2021-07-09 09:39:17 UTC
I agree that it makes sense to link updating the closed date to closing the basket, but we cannot reliably use this date as the date the order was placed with the vendor.  If you re-open the basket to make any modifications you lose the date that the order was placed with the vendor.  
If we had a second date column for 'Date order placed with vendor' we could update both this new column and the orders.closedate when the basket was first closed, but any further opening and closing of the basket would only update orders.closedate
Comment 6 Maura Stephens 2021-08-03 11:16:17 UTC
For us, the order date needs to be set and not amendable. Many institutions will have vendor agreements in place with follow up timeframes and reports need to display the initial date the order was sent to the vendor. 
We had a report in place in 19.11 that could bypass the reopening of a basket for amending a price or switching a fund, but this is no longer the case in 20.11 and this causes major issues now with vendor follow up.
Can we please get this bug resolved as a matter of priority.
Thanks
Comment 7 Katrin Fischer 2021-08-06 14:39:07 UTC
Not a final solution, but there is now logging of closing the basket that would probably allow for a workaround in reports (AcquisitionLog).

Maura, would you agree with the behavior Daphne suggested or did you have something else in mind?

But please keep in mind that we can discuss a good solution and make that public, which will certainly help, but the development will probably still need funding to actually happen.
Comment 8 Maura Stephens 2021-08-06 14:58:05 UTC
Hi Katrin,
What is needed is a reportable 'order date' and this needs to be the date the order is sent to the vendor. This cannot change. I need to be able to make adjustments to funds, and pricing subsequent to this, if updates come from the vendor, without it changing the initial 'order date'.
I can't see why Koha developers do not prioritise financial functions in Acquisitions. Most libraries (both public and academic) use framework agreements which our purchasing must adhere to. The vendors have a set number of weeks to respond to our orders and this is a legal requirement. We have reports set up in Koha to compile all our transactions and 'order date' is key to many, if not all of these. 
We use EDIFACT ordering for all our orders.
Comment 9 Martin Renvoize 2021-08-06 16:08:48 UTC
Aha.. I think you might want

 Bug 28640 - Add EDI order status to basket details display
Comment 10 Katrin Fischer 2021-08-06 16:10:42 UTC
> What is needed is a reportable 'order date' and this needs to be the date
> the order is sent to the vendor. This cannot change. I need to be able to
> make adjustments to funds, and pricing subsequent to this, if updates come
> from the vendor, without it changing the initial 'order date'.

Yes, I understand. Daphne described a solution in comment#6 that would have us have an additional database field recording the first time the order was closed. And use this for the purpose you describe.

> I can't see why Koha developers do not prioritise financial functions in
> Acquisitions. Most libraries (both public and academic) use framework
> agreements which our purchasing must adhere to. The vendors have a set
> number of weeks to respond to our orders and this is a legal requirement. We
> have reports set up in Koha to compile all our transactions and 'order date'
> is key to many, if not all of these. 
> We use EDIFACT ordering for all our orders.

I am not saying that your bug is not valid. I was only pointing out that most changes in Koha happen as funded developments. Some support companies might prioritize developments like this on demand of their customers or have hours for it included in support contracts, but I cannot tell about that. So far this bug is not assigned to anyone for development, so at the moment I don't see a fix coming.