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.
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.
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.
This seems to still be an issue in 19.11.
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?
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
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
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.
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.
Aha.. I think you might want Bug 28640 - Add EDI order status to basket details display
> 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.
Just reviewing my calls and this is still an issue for us here. Not sure what developers have in mind. My ideal in Koha would be to get rid of baskets altogether, they serve no function other than batching orders to send out, but the reopening and closing is not a useful acquisitions function. If one order at a time needed to be modified that should be fine, perhaps a modify date added. Anyhow just want to keep this requirement on the horizon for those of us tied into Acquisitions framework agreements.