-
-
Notifications
You must be signed in to change notification settings - Fork 491
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
Add TaxRate model #1027
Add TaxRate model #1027
Conversation
756a850
to
bc20455
Compare
Codecov Report
@@ Coverage Diff @@
## master #1027 +/- ##
==========================================
+ Coverage 97.55% 97.56% +<.01%
==========================================
Files 25 25
Lines 2459 2542 +83
Branches 223 230 +7
==========================================
+ Hits 2399 2480 +81
Misses 46 46
- Partials 14 16 +2
Continue to review full report at Codecov.
|
c158de1
to
4d75d0c
Compare
Note that the ManyToMany fields that are just linking to TaxRate (and don't have an associated value) don't necessarily need to have an explicit joining table, but it seems sensible to be consistent, and having Djstripe in any internal models avoids the risk of clashing with new stripe objects down the line.
edit: I'll implement the unique as per the django default since you sensibly do get an error from Stripe if you try to attach the same tax rate twice ("You cannot attach more than one of the same tax rate."), so I think it's safe to assume they'll be unique. |
917ce3d
to
61c50af
Compare
78ec476
to
f840c19
Compare
f479910
to
eb7989f
Compare
@kavdev currently this doesn't support UpcomingInvoice - this was causing me some problems because it would mean setting (or faking) a ManyToMany field on an unsaved model. Thoughts? (do you think not supporting tax rates on UpcomingInvoices for now acceptable?) |
lgtm -- solid work. I'd expect people to expect to be able to see tax rates on upcoming invoices. How much of a pain is it to implement? |
This is to allow Invoice to use ManyToManyFields.
* Add ManyToManyField for Subscription.tax_rates, Invoice.default_tax_rates etc. We don't need to explicitly specify the joining model, but specifying the joining table name to match what would be generated if the joining table names had the prefix DjStripe, to avoid potential name clash if Stripe added models with these names.
5f85baa
to
15f94a5
Compare
I've added UpcomingInvoice.total_tax_amounts and .default_tax_rates based on the refactor from #1077, just need to add some tests. |
Added tests for UpcomingInvoice.total_tax_amounts and .default_tax_rates. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌🏼
Work in progress on TaxRate model
todo:
These are list of TaxRate objects or in the case of
Invoice.total_tax_amounts
, a list of amounts with a tax_rate id, eg:I think it'd be sensible to add ManyToMany fields to handle these, probably with the joining table models named Djstripe... following the example of DjstripePaymentMethod.
FYI @kavdev