Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Now that #2981432: Extract the tax-exempt price logic from LocalTaxTypeBase, into TaxOrderProcessor has landed, TaxOrderProcessor has a protected method for getting the default rates for an order item. This is useful logic that should live in its own service.
Proposed name: StoreTaxes.
Proposed method: getDefaultTaxRates($order_item, $store).
We could also have a getDefaultTaxTypes($store).
Open question on whether there should be a single "default tax type" (first tax type that matches the store's address) or multiple "default tax types" which means any tax type that matches the store's address.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 2981436-5-add-store-tax-service.patch | 21.46 KB | bojanz |
| |||
Comments
Comment #3
bojanz CreditAttribution: bojanz at Centarro commentedAttacking this after #3113768: Fatal error when resolver are called by the chainRateResolver without a taxType set. Crediting flocondetoile for this test work in the other issue, which will be relevant here.
Comment #4
flocondetoileMost of all shops must have a single default tax type. But with tax there is always complex use cases belong the country you are. Why not a new settings on the Store, setting checked by default (to keep current behavior) ? Or by default a logic with only one default tax type, but easily swappeable / overrideable (a boolean parameter set on the service for example).
Comment #5
bojanz CreditAttribution: bojanz at Centarro commentedThis is as fancy as I could make it for the 2.17 release. Anything more would need to wait for a future one.
Comment #7
bojanz CreditAttribution: bojanz at Centarro commentedExpanded the tests a bit more and committed. See you in followups!