Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get_client_prices #842

Open
kousu opened this issue Jan 8, 2019 · 1 comment
Open

get_client_prices #842

kousu opened this issue Jan 8, 2019 · 1 comment

Comments

@kousu
Copy link

kousu commented Jan 8, 2019

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

price=quantity * MAIN_PRICE_DEFAULT if billable else 0,

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

def get_client_prices(self, client):
# TODO Use Parameters Model in member to store unit prices
if client.rate_type == RATE_TYPE_LOW_INCOME:
main_price = MAIN_PRICE_LOW_INCOME
side_price = SIDE_PRICE_LOW_INCOME
elif client.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?
@JeanFrancoisFournier
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants