`get_client_prices`

[kousu]

While reviewing #839 I noticed get_client_prices(). It is a little shim to handle differently-billed clients but whereas it's called in auto_create_orders() and create_batch_orders(), in add_item(), which I believe is function called when entering orders manually, MAIN_PRICE_DEFAULT is used directly

https://github.com/savoirfairelinux/sous-chef/blob/396f86d696fd1dc541b6556dacea8a621e2b7420/src/order/models.py#L402

so I theorize it won't properly bill low-income clients if they call in an order.

https://github.com/savoirfairelinux/sous-chef/blob/396f86d696fd1dc541b6556dacea8a621e2b7420/src/order/models.py#L136-L146

Related issues:

• I think "SOLIDARY" is a typo; it should be "SOLIDARITY", as in, "prix solidaire" or "prix de solidarité"
• Apparently there are no clients using solidarity pricing at this time, so that part is dead code. Maybe it would be better just to remove it?
• auto_create_orders() and create_batch_orders() might be duplicates; I haven't traced the codebase yet to find out, but they sure sound like they are doing the same; I know that auto_create_orders is what manage.py generateorders ends up running, so does that mean that create_batch_orders() is dead code?

[JeanFrancoisFournier]

Not sure but create_batch_orders() could be related to the ability within the UI to select multiple dates when creating an order manually. This would allow the user to speed up the order taking by applying the same items and prices to multiples individual orders. Also it might speed up the computing instead of running the price check for every individual order when doing this in batch? Not sure...

Related issues: Solidary rate was not a typo, it's the way they used to call that higher braket in the 2015 sliding scale introduction. It's not used at this point but could allow us to add a 3rd level to our existing sliding scale when we get there.

Does this help?