Sales tax

[thenewguy]

Need a mechanism to determine appropriate sales tax and add it to the amount charged for an order. It should also be recorded for display.

[SteveChurch]

On this note it would also be appropriate to offer two methods for calculation.

• Line item tax calculations
• Total checkout calculations

[JamesRamm]

Is overriding the price getter on the ProductVariant helpful here?:

https://jamesramm.github.io/longclaw/docs/tutorial/products#dynamic-pricing

[thenewguy]

I feel like it could be made to work there but it would be more complicated than adding it in that one place.

Sales tax in the USA needs to know origin and destination addresses to be calculated. And it needs to know if the items are taxable. And in some cases customers are tax exempt on some things they buy... however this could probably be solved after the common cases are solved.

Sales tax is also typically displayed on invoices separate from the price of goods so the template would need access to it in some form separate from the price.

It might be worthwhile to create a method dedicated to determine tax amount.

[thenewguy]

Perhaps a general method that is intended to return a dictionary or ordered list of three tuples could be called for all line items, fees and discounts on an order.

The fields for displaying any fee I can think of this moment would be as follows: fee name, normal price, charged price.

The normal price and charged price is important in the template for being able to show discounted line item prices.

[JamesRamm]

Yes I think this is the best way to go. A new method at checkout which can be overridden, which will know both the customer address(es) and everything in their basket.

This sounds like a more generic version of the basic proposal for custom shipping in #204.

So this function would return (somehow) potentially:

• Multiple 'fee items' per BasketItem
• An overall 'checkout fee' item(s) This would provide all the info to display each item separately to the customer, but the total amount charged would simply be the sum of all this (plus actual price of the ProductVariant being bought)

[thenewguy]

I've let this stew in the back of my mind for a few hours and I still think shipping needs to be separate from this in my opinion because the user needs to be able to select which shipping rate to use.

Here is why:

• the user enters shipping address
• the system requests quotes for all available shipment options
• the applicable shipment options and rates (USPS flat rate, UPS Ground, UPS Overnight, FEDEX Ground, Common Carrier LTL, etc) are presented to the user
• the user selects which shipping rate they will pay for
• the user is then presented with the order summary that shows all line items, discounts, shipping, taxes, etc.

Shipping rates could be selected at this time but I am pretty sure there are cases where shipping rates are taxable in the US. Not for me, but I think it is potentially something that the project would want to support.

[JamesRamm]

In that case, I think we need (for a first implementation) a basic calculate_tax function somewhere on the checkout. It should:

1. Be possible to set a single (or per-country) tax rate in the admin which is applied by default
2. Be possible to override the function with your own more complex implementation