[Koha-bugs] [Bug 13220] Shipment date not saved when creating an invoice which has a duplicated number

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13220

simith.doliveira at inlibro.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33373|0                           |1
        is obsolete|                            |

--- Comment #2 from simith.doliveira at inlibro.com ---
Created attachment 33461
  -->
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33461&action=edit
Bug 13220 - Shipment date not saved when creating an invoice which has a
duplicated number

When creating an invoice which has a duplicated number, if the user chooses to
'Create new invoice anyway', previously entered shipment date (todays date by
default) is not being saved, because the date value is passed to the script in
the wrong format (acqui/parcels.pl expects shipmentdate parameter to be in the
system-configured date format, but what it's getting in such cases is
ISO-formatted date instead). As a consequence (when receiving orders from
invoice whith empty shipment date) 'datereceived' field in order records are
also not being populated. Here and there, Koha is using datereceived field to
establish if the order was received or not received, so such not-quite-complete
orders:

- can be cancelled from the basket (even when they are de facto already
received),
- it's not possible to cancel receipt of those orders from the invoice (because
Koha is considering them as not yet received).

To reproduce:

1) Make sure you have some system date format configured in your test
environment which is different from ISO format (e.g., DD/MM/YYYY) and the
AcqWarnOnDuplicateInvoice syspref is enabled
2) Create some invoice with e.g. '11111' number,
3) Create another invoice with the same number (using 'Create new invoice
anyway' button)
4) Try to create yet another invoice with the same number; observe that already
existing invoice created in step 3) does have empty shipment date.
5) Optional: create some orders and receive them from the invoice with empty
shipment date; observe that such orders are not being treated as received in
all places (e.g. it's not possible to cancel receipts of such orders, and the
message displayed is not in any way helpfull to determine why not).

To test:

1) Apply patch
2) Retest
3) Ensure that the issue is no longer reproductible, and that there are no
apparent regressions of any kind.

Works as expected.
Signed-off-by: simith <simith at inlibro.com>

-- 
You are receiving this mail because:
You are watching all bug changes.