Report: update/fix Bulk Coop - Totals by Supplier

[Kirsten]

This report is used to work out how many bulk items should be purchased, based on customer orders

It was developed prior to the more detailed work on products / variants / units etc, and so currently uses ‘weight’ as the dividing factor (e.g. unit size / (sum total * weight) = units required; with any leftover = remainder

so when the weight is zero (often), it just doesn’t work

Fix 1: Update the fields so that the report uses unit value rather than weight e.g. ‘1’ from 1 jar or 1L even if there is no weight set

Fix 2: Coops want to ‘round-up’ rather than down

Hearing that the coops / buying groups would prefer the ‘units required’ field to round up rather than down, and the ‘remainder’ field to tell them how much extra / unallocated / left they have. So this would mean that

• Units Required = Unit size / (value * sum total) and IF there is a remainder then add 1 . . . [NB. it uses whichever total is greater for the calculation, so if the max > sum total then it will use max, otherwise sum total]
• Remainder field gets renamed to ‘unallocated’ and contains (unit size - remainder)

[Kirsten]

If these are correct, same changes should be made to Bulk Coop - Allocation Report

@RohanM - perhaps we fix up the unit scaling thing on group buy for kgs/gs at the same time?

and poss. (check) to Bulk Order Management

[sstead]

Bulk Co-op - Totals by Supplier report…

1. For this Salmon product, three rows are showing, but this product is only 1 variant. It may have had 2 variants in the past- if I set timeframe of report to just this week, only 2 rows show. If I set it to far far back (when a 2nd variant may have existed), I get the 3rd row. Suggesting its a deleted variant.
2. Negative values are being displayed when there is no unit size (or it is zero).
   
   
3. This jam product has flavour variants- labels don’t show. There’s no way to distinguish which variant is which
   
   

[Kirsten]

issues picked up by @kemmyfoo detailed in email (not here because real data involved), summarised as
. . looks like three things

• most of the errors are where they have an extra 1 or 1 unit subtracted from the unallocated (i.e. they’re one less than they should be)
• one where it has subtracted 2 instead of 1 - annoying!
• when the amount order matches an exact multiple of the unit size, it is still adding on one and then getting the remainder wrong
• one (the bottom one) where it has got the num. of units wrong and all gone wrong from there . .