An error occurs when receiving the order. This happens if the user does not change the "Quantity received" field value, thereby not triggering the "OnChange" event. By default, the "Quantity received" field value is set to 1 by JS, but there is a row.quantity_received variable which serves as a shadow value which sent in a POST Ajax request after clicking "Confirm", yet row.quantity_received stays undefined despite the fact that we changed the form value by JS. row.quantity_received is expected to be updated on the "onChange" event for the form field, but that event does not fired when JS changes the form field value to 1. So if the user does not change the form field, it has a value of "1" but the form sends an empty value from the shadow value. This leads to an error from the backend which says "No quantity to receive set. No items will be created." in the popup. To test: 1. Add a new basket. 2. Create an order line 3. Receive shipment and create an invoice 4. Start receiving your order: Verify: - Quantity ordered: X - Quantity received: 1 (pre-filled, don't touch or change it) 5. Click "Confirm" 6. Observe the Receive error popup: "Order ZZZ: No quantity to receive set. No items will be created." 7. Verify that "Order receive" was not happen (received orders remains empty)
Created attachment 156634 [details] [review] Bug 35004: Set row.quantity_received to 1 if row.quantity_received is empty and we're in 'cataloguing' mode Before the code changes only field value was set to 1, but "row.quantity_received" still had an undefined value. After correction row.quantity_received set to 1 if it is empty, but only when effective_create_items == 'cataloguing', and after that its value assigned to the form field. To test: 1. Add a new basket. 2. Create an order line 3. Receive shipment and create an invoice 4. Start receiving your order: Verify: - Quantity ordered: X - Quantity received: 1 (pre-filled, don't touch or change it) 5. Click "Confirm" 6. Observe the Receive error popup: "Order ZZZ: No quantity to receive set. No items will be created." 7. Verify that "Order receive" was not happen (received orders remains empty) 8. Apply the patch and make sure your order is received correctly after step 5.
Hi Slava, did you test on latest master? This reads like bug 34880. + $("#creator").html(__("Account has been deleted")); This won't work, the __ is only for .js files, not for JavaScript in general.
In your test plan, which value did you set for creating items?
(In reply to Katrin Fischer from comment #3) > In your test plan, which value did you set for creating items? Standing order? Subscription order?
(In reply to Katrin Fischer from comment #2) > Hi Slava, > > did you test on latest master? This reads like bug 34880. Hi Katrin, Yes, I checked this on the latest master. (In reply to Katrin Fischer from comment #4) > > In your test plan, which value did you set for creating items? > > Standing order? > Subscription order? The basket was closed before receiving items. It wasn't "Orders are standing" or "Subscription order".
I am sorry, to be late here. I just confirmed this bug in the recent 23.05, possibly in master as well.
Created attachment 158334 [details] [review] Bug 35004: Set row.quantity_received to 1 if row.quantity_received is empty and we're in 'cataloguing' mode Before the code changes only field value was set to 1, but "row.quantity_received" still had an undefined value. After correction row.quantity_received set to 1 if it is empty, but only when effective_create_items == 'cataloguing', and after that its value assigned to the form field. To test: 1. Add a new basket. 2. Create an order line 3. Receive shipment and create an invoice 4. Start receiving your order: Verify: - Quantity ordered: X - Quantity received: 1 (pre-filled, don't touch or change it) 5. Click "Confirm" 6. Observe the Receive error popup: "Order ZZZ: No quantity to receive set. No items will be created." 7. Verify that "Order receive" was not happen (received orders remains empty) 8. Apply the patch and make sure your order is received correctly after step 5. Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
I have amended the patch removing this change: $("#creator").html(_("Account has been deleted")); $("#creator").html(__("Account has been deleted")); The double undescore for translations is only used in .js files. In .inc and embedded JavaScript code it doesn't work. We still need the single underscore there. Continuing testing.
Did a lot of testing, hopefully not missing anything this time: Items in cataloging * ordered 1, receive 1 * ordered 5, receive 2 * standing order, received on multiple invoices * subscription* * subscription + standing order* Items on receive * ordered 1, receive 1 * ordered 5, receive 2 * standing order, received on multiple invoices * subscription* * subscription + standing order* Items on order * ordered 1, receive 1 * ordered 5, receive 2 * standing order, received on multiple invoices * subscription (no items, because it's a subscription order)* * subscription + standing order (no items, because it's a subscription order)*
Created attachment 158336 [details] [review] Bug 35004: Set row.quantity_received to 1 if row.quantity_received is empty and we're in 'cataloguing' mode Before the code changes only field value was set to 1, but "row.quantity_received" still had an undefined value. After correction row.quantity_received set to 1 if it is empty, but only when effective_create_items == 'cataloguing', and after that its value assigned to the form field. To test: 1. Add a new basket. 2. Create an order line 3. Receive shipment and create an invoice 4. Start receiving your order: Verify: - Quantity ordered: X - Quantity received: 1 (pre-filled, don't touch or change it) 5. Click "Confirm" 6. Observe the Receive error popup: "Order ZZZ: No quantity to receive set. No items will be created." 7. Verify that "Order receive" was not happen (received orders remains empty) 8. Apply the patch and make sure your order is received correctly after step 5. Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Pushed to master for 23.11. Nice work everyone, thanks!
Thanks for the quick push!
*** Bug 35296 has been marked as a duplicate of this bug. ***
Pushed to 23.05.x for 23.05.06