Variable Weights on Line Items - Carrying into Reports?

sstead · August 5, 2015, 1:22am

We now have the ability to adjust the weight (and hence cost) of products in customer orders. - Variable Weights on Line Items
But we need to check that adjustments are carried into the appropriate reports.

@lin_d_hop I’ve done a test case scenario with a product called “Large Whole Pumpkin”. It was the only product in an order cycle, and purchased by 4 customers. It’s initial weight and price were 1000g, and $10. I’ve adjusted orders to reflect the actual pumpkin’s weights (in BOM) and looked to see if the adjusted weight and cost carry into reports. I’m not 100% certain about how people are using each report, so haven’t made recommendations for which reports need to be displaying the adjusted weight (I’ll leave that to someone more familiar with how reports are being used).

4 Customers ordering the 1kg pumpkin:
Customer Name, Actual Weight (adjusted in BOM)
Barb, 1000g
Lucinda, 500g
John, 2000g
Wang, 3000g

Orders and Distributors
The cost in this report is correctly calculated based on adjusted weight.

Bulk Coop Reports
The ‘Customer Payments’ report is the only one of these 4 reports that uses the adjusted weight.
Totals by Supplier:

Allocation:

Packing Sheets:

Customer Payments:

Itemised Payment Totals
Correctly showing adjusted weight and cost.

Payment Totals
Correctly showing adjusted weight and cost (Would be $40 if calculating based on 4 x original $10 pumpkin).

Order Cycle Supplier Totals
In this report the total cost is correct. But the ‘Curr Cost per Unit’ is not correct - one customer’s pumpkin was $20, but not all. And the original product is still $10.

… and (By Distributor report)… the same.

… and (By Supplier report)… the same.

Order Cycle Customer Totals
In this report, the Item ($) is accurately reflecting the adjusted weight and price. But it’s not easy to interpret why different customers are charged different prices- there’s no mention of the adjusted weight- which could be useful if this report is used for packing sheets.

Payment Methods Report and Delivery Report
These reports does not include the adjusted weight and price. They’re saying that all customers owe $10 for their order of the original 1000g pumpkin. (* Not sure why ‘Balance’ is reading -25)

Pack by Customer
This report isn’t showing the adjusted weight information. Could be useful to know which pumpkin to pack for each customer.

Pack by Supplier
This report isn’t capturing adjusted weights. It’s also chosen 1 of the 4 customers in this order cycle who ordered the pumpkin and attributing all pumpkins to her - an unrelated error in the report? Or is this correct/of no consequence?

Sales Tax
This report is using the correct weight and price (post adjustment). No tax applied to item though, so need to check tax is being calculated correctly… Eeek having a tax calculation hickup Github #645… sorry can’t check this now in Aus production

Xero Report
Is using adjusted weights.

Kirsten · September 24, 2015, 4:11am

@lisahill - according to the most awesome @sstead’s analysis above the xero reports are already using the adjustable weights, so I’m going to quickly test and hopefully push the xero details - which should then give you what you need for immediate use.

In the meantime, @oeoeaio is checking through the above and seeing how easy to fix across the other things.

@lin_d_hop - have you made any changes around this in your reports branch that is in testing at the moment?

oeoeaio · September 24, 2015, 5:32am

@lin_d_hop @sstead

Just having a look at Sally’s awesome analysis, and it seems that the last major hurdle to this work being completed is that line items whose weight/volume has been changed really need some new logic around naming, so that the new weight/volume is reflected in the name, rather than simply continuing to read from the naming logic on the original variant. This is the root cause of most if not all of the issues noted above.

I have had a bit of a think about a quick solution to this and came up with the following:

Add an option_value to each line_item in the system to store the new options text (1h)
Generalise the existing OptionValueNamer class to allow it to name option values for both variants and line items (3-4h)
Update a line_item’s option_value when its weight/volume is changed. (1h)
Generalise and extract the naming logic on the variant model so that the same logic can be applied to line items. (3-4h)
Go through the codebase and switch all references to line_item.variant.full_name to line_item.full_name (for example). (1-2h)

Total Time: 9-12h.

Thoughts?

sstead · September 30, 2015, 6:38am

Testing Notes - September 30th

Same things as above…

Same again…

sstead · September 30, 2015, 7:02am

The ‘delivery report’ also showed $30 for all three customers.

Sales Tax…

Xero report has same error as the Sales Tax above. $20 instead of $15.

oeoeaio · October 1, 2015, 1:58am

Ok, I’ve been through all of these and as far as I can tell main issues are quite technical.

Issue 1: Large Pumpkin changed to 2kg not appearing as separate line item.

I can’t replicate this: hence a bit scary. After doing some investigation I believe the issue was due to the option types associated with the line_item not having been updating correctly when the final_weight_volume was changed. Therefore the line_item in question wasn’t being recognised as a distinct entity from the unchanged line_item, so they were being mashed together in all of the reports. Seems like an issue with the rails callback that updates units when a line_item changes. I went back and changed the final_weight_volume on the relevant line_item to 1000 and then back up to 2000 and everything seems fine now, couldn’t see anything going wrong anywhere that I looked. Would be good to get a consistent way of breaking it in this way…

Issue 2: Price for 0.5 Box of Wine has somehow gotten out of sync with the final_weight_volume

I can replicate this. I think it is an issue with the Javascript. When the final_weight_volume field has an invalid amount typed into it, the price field dies and fails to send anything to be updated, meaning that the final_weight_volume changes but the price does not. The irony is that the most likely cause of invalid data being entered is the logic that prevents the field from being cleared, which is considered invalid data itself.

I found myself accidentally typing in a number with two decimal places (“1.0.5” clearly invalid - hence causing price to die), just so that I could enter the final_weight_volume that I wanted (0.5).

This is more of a usability problem. The inability to clear the field and enter a completely new value is problematic. I suggest we get rid of this live validity checking functionality and rely on validity checking on blur, and on submit.

We also need the price field to be more robust with regard to invalid entries.

I think this is a good general rule across the project: user entered data should never be “magically” changed due to invalid data, we need to communicate errors to the user and rely on robust validation logic to prevent submission of invalid data to the server.

Issue 3: Payment totals aren’t updated when the total value of the order is changed

This means we get the unchanged payment totals in the payment method reports. Not sure if this is actually a problem, I suppose we have a couple of options for resolving this:

Do nothing (and allow payments to be adjusted manually by the hub user)
Update any un-captured payments or create new payments automatically to reflect the changes.
Have a button that allow manual, but possibly in-bulk updating/creation of payments to reflect any changes.

Not sure how urgent this is: any thoughts?

lisahill · November 10, 2015, 8:56pm

Hey Gang, this is now getting higher on our list of dreams for fixing.

We’re currently using the adjustments section of each order to do half boxes (e.g. simply reduces the price but in no way reflects the reality of the fact that only half a box was taken out of inventory/sold/sent).

Seemed like a fine work around to begin with but now we are having taxation issues. Because adjustments don’t link or apply directly to any one product, we are technically giving the customer the discount required for what they didn’t receive, however if that product happens to attract gst - we can’t seem to find a way to manually edit that amount to reflect the true half box.

I presume if everything did talk to each other, and a half box weight & price & name altered when the order was edited - then so too would the tax? Something to think about.

Kirsten · November 12, 2015, 3:01am

this should be sorted in the bunch of stuff that @oeoeaio is working on I think . .