| Age | Commit message (Collapse) | Author |
|---|
|
|
|
When validating addresses, it may happen that the address
has no country, so trying to fetch the country ISO raises
an unnecessary error. Using ruby safe navigation prevents
this to happen. Of course, the address will still result
invalid eventually.
|
|
This new calculator allows to retrieve tax rate information starting
from a `Spree::Address` model.
It shares some logic with the tax calculator, for example the ability
to handle exceptions using `SolidusTaxJar.exception_handler` lambda.
|
|
When calculating tax rates, the recommended endpoint from TaxJar
support for live calculations is `/v2/taxes`, the same used for
calculating order taxes, as it accounts for all factors like
sourcing or nexus, while the `/v2/rates` endpoint will return
the full combined rate for the queried location.
|
|
This helper converts a `Spree::Address` to address params that can be
used to retrieve the tax rate for that location.
|
|
|
|
This just uses the taxable order check configuration added in the parent
commit to provide a hook to short circuit order tax checks.
|
|
This will allow apps to use properties of an order to determine whether
an order is taxable.
|
|
|
|
1-space?????
|
|
This is required to support per-customer exemptions through the TaxJar
API.
|
|
I like sorted things.
|
|
I have a plan for how to handle these better in v1.0 though!
|
|
|
|
If an order is adjusted to zero, we don't want to subtract the tax from
it... because that don't make no sense.
A better solution that properly factors in order level adjustments will
be coming eventually, this is just a hack to process some orders
immediately.
|
|
|
|
|
|
This sends the full list of line items in the order with their SKUs and
tax codes when creating/updating transactions in TaxJar.
|
|
When an order doesn't have a tax_address, it will rely on the order's
store to build a "TaxAddress" for use as the "tax address which in an
ideal world would be much more address-like... but unfortunately it's
not.
|
|
From Solidus Documentation:
An order's tax_address can – through duck typing – be a
Spree::TaxLocation instead of the shipping address.
This adds a guard clause that validates if the tax_address is a
TaxLocation, in this case we know that the address is incomplete.
|
|
Solidus has deprecated the `empty?` method on
https://github.com/solidusio/solidus/pull/1686 . This adds a private
`incomplete_address?` method for avoid future problems and remove the
deprecation warning in projects that uses this gem.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This removes the logic from the API class and moves all the calls to the
order_params method to our new module.
|
|
This leaves the API class to just be resonsible for calling the right
methods on the TaxJar gem.
|
|
|
|
This extracts the functionality of calculating the discount for a line
item in the interest of making this behaviour configurable for stores
that would like to factor in order level adjustments in some way.
|
|
TaxJar API is not keen on orders with no line items and will throw
errors.
|
|
|
|
|
|
|
|
|
|
It's not necessary because we're sending line items.
|
|
Oops, was grabbing the total shipping tax for the order and using that
as the tax, instead of grabbing the collectable tax from the breakdown.
That makes more sense.
|
|
|
|
This is partially a refactor, and also handles the unlikely scenario
where there is a shipping tax, but no breakdown.
|
|
|
|
This adds the functionality to the calculator required to map per line
item taxes coming from the TaxJar API to the taxes required for each
line item in an order.
The calculator does not yet support shipping taxes.
|
|
|
|
Because I hadn't set up database cleaner, there was some junk in my
local test database that was causing tests to pass.
|
