You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
# TODO Use Parameters Model in member to store unit prices
ifclient.rate_type==RATE_TYPE_LOW_INCOME:
main_price=MAIN_PRICE_LOW_INCOME
side_price=SIDE_PRICE_LOW_INCOME
elifclient.rate_type==RATE_TYPE_SOLIDARY:
main_price=MAIN_PRICE_SOLIDARY
side_price=SIDE_PRICE_SOLIDARY
else:
main_price=MAIN_PRICE_DEFAULT
side_price=SIDE_PRICE_DEFAULT
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?
The text was updated successfully, but these errors were encountered:
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.
While reviewing #839 I noticed
get_client_prices()
. It is a little shim to handle differently-billed clients but whereas it's called inauto_create_orders()
andcreate_batch_orders()
, inadd_item()
, which I believe is function called when entering orders manually,MAIN_PRICE_DEFAULT
is used directlysous-chef/src/order/models.py
Line 402 in 396f86d
so I theorize it won't properly bill low-income clients if they call in an order.
sous-chef/src/order/models.py
Lines 136 to 146 in 396f86d
Related issues:
auto_create_orders()
andcreate_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 thatauto_create_orders
is whatmanage.py generateorders
ends up running, so does that mean thatcreate_batch_orders()
is dead code?The text was updated successfully, but these errors were encountered: