Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Fix tax calculation arguments, other tax fixes #4811

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.

Sign up for GitHub

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

Jump to bottom
Merged
nnnnat merged 9 commits into from
Nov 21, 2018
Merged

Fix tax calculation arguments, other tax fixes #4811

nnnnat merged 9 commits into from
Nov 21, 2018

Conversation

@aldeed
Copy link
Contributor

@aldeed aldeed commented Nov 19, 2018 •
edited
Loading

Resolves #4807
Impact: minor
Type: feature

Changes

The order data being passed to tax calculation functions was not consistent due to differences between Cart and Order schemas. This PR introduces a new schema CommonOrder, which represents one actual or potential order for one shop. New transforms allow a cart fulfillment group or an order fulfillment group to be converted to a CommonOrder. Tax calculation functions only need to understand and deal with CommonOrders.

This was implemented in a generic way because we expect to need this same transformation for shipping restrictions, surcharges, and other similar calculations that do not need to care whether they're calculating for a Cart or an Order.

Breaking changes for custom tax plugins

There are breaking changes only within the current RC7 release, since prior PRs were merged. Custom tax plugins should do the following:

  • Change function name from calculateOrderGroupTaxes to calculateOrderTaxes
  • Expect that calculateOrderTaxes will be called with { context, order } rather than { context, group }, where order is similar to what group was, but is guaranteed to be in the new CommonOrder schema, whether being called for a Cart or an Order. Among other things, a common order has originAddress and currencyCode properties, and the items are guaranteed to have price property set.
  • Expect calculateOrderTaxes to now be called even when shippingAddress is null. Return null if you cannot calculate taxes. In most cases, tax plugins will immediately check whether shippingAddress is null and if so, return null.
  • A calculateOrderTaxes function may now set calculatedByTaxServiceName property in the taxSummary that is returned. Set this to the name of your tax service (same as in taxServices array in registerPackage). One good reason to set this is to determine whether tax was calculated by your tax service after the order is placed. Depending on the type of tax integration, you may need to inform the third-party tax service that the order was placed. Use referenceId to store the corresponding calculation ID from the third-party system if necessary.

Testing

  • Test all aspects of taxation. Primarily, test adding taxable items to your cart and checking them
    out.
  • To test the specific bug fix, you can log in calculateOrderTaxes function for the included "custom rates" service and verify that the order argument is the same whether being called for a cart (such as when adding items) or for an order (such as when completing checkout).

@aldeed
fix: reconcile slightly different order objects
e69aadb 
being passed to calculateOrderTaxes function

Changes for tax plugins to be aware of:
- Will now be called even when there is not yet a shipping address.
Return `null` if you are not able to calculate due to no
shipping address or any other missing information.
- Called with a stable order-like schema, which now includes
`originAddress`, `currencyCode`, `fulfillmentPrices`,
and `price` on every item
- Change function name from `calculateOrderGroupTaxes`
to `calculateOrderTaxes`
@aldeed
refactor: set price and compareAtPrice on cart items
cd7a74f 
better than recalculating whenever we query those fields
@aldeed
refactor: set subtotal on cart items at write-time
bf71f3f
@aldeed
chore: migration for new required cart item props
3e43b81
@aldeed
feat: add optional calculatedByTaxServiceName to tax summary
f834826
@aldeed
fix: handle null compareAt when adding to cart
b14742c
@aldeed
feat: move tax util functions and schema to generic CommonOrder
eb7603a 
We expect other plugins to need the same transformations
@aldeed
test: update tests
bb14873
@aldeed aldeed self-assigned this Nov 19, 2018
@aldeed aldeed added this to the Redcloud milestone Nov 19, 2018
@aldeed aldeed requested review from Akarshit and nnnnat November 19, 2018 22:18
@aldeed
Copy link
Contributor Author

aldeed commented Nov 19, 2018

@Akarshit Please test your plugin against this branch, and note the changes you'll need to make described in the PR description.

@Akarshit
Copy link
Contributor

Akarshit commented Nov 20, 2018 •
edited
Loading

@aldeed Would it make sense to add the following in the CommonOrder:

  1. cartId- some kind of a id, that can be used to relate the cart/order and request to get the tax, should be sent with the request.
  2. billingAddress - this is needed by the tax API's
  3. title - the product title. Not required but maybe we should add this.
  4. discount - I don't see it in the order or the items.

@aldeed
Copy link
Contributor Author

aldeed commented Nov 20, 2018

@Akarshit

  • I can add cartId and orderId but either one might be null most of the time. Orders can be created without any cart, too.
  • Billing address will generally never be available when it runs for a cart, and some payment methods may not even collect a billing address, in which case it will be null when it runs for an order, too. But I can try to include it if we have one.
  • I can add item titles and applied discounts

@aldeed
Copy link
Contributor Author

aldeed commented Nov 20, 2018

I was curious why billing address would be required, but this quote from the Radial docs explains it.

The tax API requires an address to properly assess charges. In nearly all cases, the shipping address is used to determine taxes. However, there are certain cases when shipping address is not available, such as the purchase of a online gift certificate or an eBook. In cases where a shipping address is not available, the billing address should be used instead. For this reason, billing address is required.

@aldeed
Copy link
Contributor Author

aldeed commented Nov 20, 2018

@Akarshit I added all except discounts because the current discounts handling is janky and not calculated by item or by group. A proper promotions engine is on the roadmap very soon, so we can make sure the new promotions get added to CommonOrder at that time, and then tax plugins can be updated to handle them.

@Akarshit
Copy link
Contributor

Akarshit commented Nov 21, 2018

@aldeed While checking this, I found that billingAddress is always null.
I checked this on the classic Meteor app, testing it in the starter-kit now.

@aldeed
Copy link
Contributor Author

aldeed commented Nov 21, 2018

@Akarshit I can't reproduce that. Tested with example and Stripe payment from classic UI, and billingAddress is correctly set when order.sourceType is "order" (when it's called when you place the final order). Prior to that, it's called from a Cart, and billingAddress will always be null for a cart.

If Radial requires billingAddress and you want estimated taxes calculated for carts, I'd just pass the shipping address as the billing address.

nnnnat
nnnnat approved these changes Nov 21, 2018
View reviewed changes
Copy link
Contributor

@nnnnat nnnnat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 LGTM

@nnnnat nnnnat merged commit 91dfee6 into release-2.0.0-rc.7 Nov 21, 2018
@nnnnat nnnnat deleted the fix-4807-aldeed-tax-calc-arguments branch November 21, 2018 20:51
@Akarshit
Copy link
Contributor

Akarshit commented Nov 22, 2018

Yes, I realized that and typed something similar but forgot to press enter. :(

@spencern spencern mentioned this pull request Jan 8, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Akarshit Akarshit Akarshit approved these changes

+1 more reviewer

@nnnnat nnnnat nnnnat approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

@aldeed aldeed

Labels

None yet

Projects

None yet

Milestone

Redcloud

Development

Successfully merging this pull request may close these issues.

5 participants

@aldeed @Akarshit @nnnnat @brent-hoover