django-getpaid/django-plans

Exception Value: 'module' object has no attribute 'EUTaxationPolicy'

wildd opened this issue · 2 comments

wildd commented

Hi! I am trying out your app, I have successfully configured all, but I keep getting this error, while pressing "Change" button to any of my defined plans.

In settings file:
PLANS_TAXATION_POLICY = 'plans.taxation.EUTaxationPolicy'

Traceback ..
Exception Value: 'module' object has no attribute 'EUTaxationPolicy'
/home/user/workspace/env/local/lib/python2.7/site-packages/plans/importer.py in import_name

def import_name(name):
components = name.split('.')
mod = import('.'.join(components[0:-1]), globals(), locals(), [components[-1]] )
return getattr(mod, components[-1])
...

▼ Local vars
Variable Value
name: 'plans.taxation.EUTaxationPolicy'

components: ['plans', 'taxation', 'EUTaxationPolicy']

mod: module 'plans.taxation' from '/home/user/workspace/env/local/lib/python2.7/site-packages/plans/taxation/init.pyc'

It seems wrong to me to use init.py, if "EUTaxationPolicy" is defined in eu.py, or maybe I don't understand something (still learning Python & Django).
Thanks!

wildd commented

Does solution is to change?
PLANS_TAXATION_POLICY = 'plans.taxation.EUTaxationPolicy'
to
PLANS_TAXATION_POLICY = 'plans.taxation.eu.EUTaxationPolicy'

And one more question if I can ask.

Is it really designed so that at the start we need to "Change" the plan, in the next step we see change of plan with amounts of 0, and then again we need to press "Buy" on plan we selected before, and only then pay the amount? Why not the "Buy" buttons for every plan/period already at the start?

@wildd There is many different ways how you can implement users contract for which plan he have. Here is how it is implemented in django-plans.

  • User can only have one and only one plan selected at a given time and this plan has set expiration date.
  • If you want to extend the account and change plan there are two edge cases: a) user has already expired - you can extend his account with any plan from current offer b) user has already X days of the service enabled that he paid for - by switching his plan now there is no clear thing what to do, should we give him back some amount for not used X days (too complicated and also not business wise), should we just vanish X days (user will lost money he already paid, not good) etc..
  • To deal with edge case b) there is a rule hardcoded in the system that for non-expired account you cannot extend account and change plan at the same time, you can make one of two actions - extend it with the same plan (so only expiration date is sumed up) or change plan - so now this simpifies how we deal with everything
  • For changing plan there is a class that represents a policy of how you want to deal with this extra X days when user decided to switch plan. So you can customize this to your business needs. The default ChangePlanPolicy implements strategy that we take the closest pricing plan that you have, and want to switch plan, we calculate price difference per a day of service, we multiply this by X, and we inflate this by 10% (to put discourage people of buying small plans in the beginning and then immedietly switching them up, we want them to buy bigger plan already ;) The amount that will appear is going to be charged as new order for switching plan. However, there are cases when there will be no payment required, e.g. when you switch from more expensive plan to cheaper one. Obviously if you use less resources in the same X days, we are not going to extra charge you for that. Also there is a condition if the payment is very small, we do not require it to be paid - to avoid silly orders for 0.11$ just because you clicked something. This is why you can see sometimes when plan is switching and order for 0$ and you only need to confirm it.

I hope this is answering your question in detail.