taxjar/taxjar-magento-extension

Magento Sales Tax Extension by TaxJar

taxjar-magento-extension's Issues

Backup Rates error

As long as I can remember, Texas has shown an error:

I've tried updating the address (it does have a zip code), but it never works.

Backup rates shipping origin and per store config bugs

It seems that most (or all) of the code that has to do with backup rates configuration and sync always uses the global default shipping origin setting (Current Configuration Scope: Default Config), instead of the per store configured value. This prevents the use of backup rates feature for international Magento stores that are based outside of USA but have a store in USA.

(The backup rates feature was one of the reasons for choosing TaxJar over the alternatives, so I hope this can be fixed.)

Example:

International Magento store based in Sweden. Default shipping origin in Sweden. One website/store per country. Default store has TaxJar disabled among with backup rates.

The USA store has a shipping origin set properly in the USA. TaxJar enabled and backup rates enabled for it. But the button for "Sync Backup Rates" does not show here, and no backup rates are ever synchronized to Magento.

In the extension code I could see the following reason for this: The code that checks the origin address is executed in the admin settings scope (store id 0, default), and not at the USA store level which is currently selected in the settings configuration scope. The same thing happens when the backup rates sync cronjob i executed, it is running in the store id 0 scope (and only for that store).

(As you have made the backup rates setting available per store, with possible different shipping origin addresses, I'm not sure how you have thought that backup rates would work in such cases.)

Using extension version 2.2.1 on Magento CE 1.9.2.3.

Tax applied to shipping even if "Tax Class for Shipping" is set to None

Hello,

I experience an issue with the tax calculation. It seems that the tax is applied to shipping cost as well, even if in "System > Configuration > Tax > Tax Classes > Tax Class for shipping" is set to none.

Regards,
Peekmo

Tax not getting set on newly added quote items (without ID)

When connected to TaxJar and adding a new item to the cart (when the address information is already set), the tax is not set on this new item, which leads to the items and the total tax, and the grand total being wrong. This error is persisted until the cart is saved/updated again (or till another quote collectTotals and save is made, like in the checkout).

The bug is caused by the way the TaxJar API call is made. (If not connected to TaxJar, eg using backup rates, then the bug does not occur.)

The API call uses the $item->getId() to identify the items between call (see 1 and 2). This (database) ID is not set for newly added quote items until the quote is saved, and the tax calculations (collectTotals) is made right before quote save.

Illegal mix of collations error

Just figured I'd report this in case there is a problem to be fixed...

SQLSTATE[HY000]: General error: 1271 Illegal mix of collations for operation 'in', query was: SELECT main_table.tax_calculation_rate_id, main_table.tax_calculation_rule_id, main_table.customer_tax_class_id, main_table.product_tax_class_id, rule.priority, rule.position, rule.calculate_subtotal, rate.rate AS value, rate.tax_country_id, rate.tax_region_id, rate.tax_postcode, rate.tax_calculation_rate_id, rate.code, IF(title_table.value IS NULL, rate.code, title_table.value) AS title FROM tax_calculation AS main_table
INNER JOIN tax_calculation_rule AS rule ON rule.tax_calculation_rule_id = main_table.tax_calculation_rule_id
INNER JOIN tax_calculation_rate AS rate ON rate.tax_calculation_rate_id = main_table.tax_calculation_rate_id
LEFT JOIN tax_calculation_rate_title AS title_table ON rate.tax_calculation_rate_id = title_table.tax_calculation_rate_id AND title_table.store_id = '1' WHERE (customer_tax_class_id = 3) AND (product_tax_class_id IN ('2')) AND (rate.tax_country_id = 'US') AND (rate.tax_region_id IN(0, 32)) AND (rate.zip_is_range IS NULL) AND (rate.tax_postcode IS NULL OR rate.tax_postcode IN('', '', 'Glór', 'Glór', 'Gló*', 'GlÃ*', 'Gl*', 'G*')) ORDER BY priority ASC, tax_calculation_rule_id ASC, tax_country_id DESC, tax_region_id DESC, tax_postcode DESC, value DESC

Trace:
#0 /html/lib/Varien/Db/Statement/Pdo/Mysql.php(110): Zend_Db_Statement_Pdo->_execute(Array)
#1 /html/app/code/core/Zend/Db/Statement.php(291): Varien_Db_Statement_Pdo_Mysql->_execute(Array)
#2 /html/lib/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)
#3 /html/lib/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SELECT main_ta...', Array) #4 /html/lib/Varien/Db/Adapter/Pdo/Mysql.php(504): Zend_Db_Adapter_Pdo_Abstract->query('SELECT main_ta...', Array)
#5 /html/lib/Zend/Db/Adapter/Abstract.php(737): Varien_Db_Adapter_Pdo_Mysql->query('SELECT `main_ta...', Array)
#6 /html/app/code/core/Mage/Tax/Model/Resource/Calculation.php(358): Zend_Db_Adapter_Abstract->fetchAll(Object(Varien_Db_Select))
#7 /html/app/code/community/Taxjar/SalesTax/Model/Calculation.php(43): Mage_Tax_Model_Resource_Calculation->_getRates(Object(Varien_Object))
#8 /html/app/code/core/Mage/Tax/Model/Resource/Calculation.php(99): Taxjar_SalesTax_Model_Calculation->_getRates(Object(Varien_Object))
#9 /html/app/code/core/Mage/Tax/Model/Calculation.php(282): Mage_Tax_Model_Resource_Calculation->getRateInfo(Object(Varien_Object))
#10 /html/app/code/core/Mage/Tax/Model/Sales/Total/Quote/Subtotal.php(512): Mage_Tax_Model_Calculation->getRate(Object(Varien_Object))
#11 /html/app/code/core/Mage/Tax/Model/Sales/Total/Quote/Subtotal.php(210): Mage_Tax_Model_Sales_Total_Quote_Subtotal->_totalBaseCalculation(Object(Mage_Sales_Model_Quote_Item), Object(Varien_Object))
#12 /html/app/code/core/Mage/Tax/Model/Sales/Total/Quote/Subtotal.php(184): Mage_Tax_Model_Sales_Total_Quote_Subtotal->_processItem(Object(Mage_Sales_Model_Quote_Item), Object(Varien_Object))
#13 /html/app/code/core/Mage/Sales/Model/Quote/Address.php(1013): Mage_Tax_Model_Sales_Total_Quote_Subtotal->collect(Object(TM_FireCheckout_Model_Quote_Address))
#14 /html/app/code/local/TM/FireCheckout/controllers/IndexController.php(518): Mage_Sales_Model_Quote_Address->collectTotals()
#15 /html/app/code/core/Mage/Core/Controller/Varien/Action.php(418): TM_FireCheckout_IndexController->saveBillingAction()
#16 /html/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(254): Mage_Core_Controller_Varien_Action->dispatch('saveBilling')
#17 /html/app/code/core/Mage/Core/Controller/Varien/Front.php(172): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#18 /html/app/code/core/Mage/Core/Model/App.php(381): Mage_Core_Controller_Varien_Front->dispatch()
#19 /html/app/Mage.php(689): Mage_Core_Model_App->run(Array)
#20 /html/index.php(151): Mage::run('', 'store')
#21 {main}

Call to undefined method _roundTotals()

Fatal error: Call to undefined method Taxjar_SalesTax_Model_Sales_Total_Quote_Tax::_roundTotals() in /app/code/community/Taxjar/SalesTax/Model/Sales/Total/Quote/Tax.php on line 130

Does this module support Magento EE 1.12.0.2?

Upgrade to use API 2022-01-24 before 2022-08-31

Email from TaxJar:

Beginning August 31, 2022, the API will be upgraded for all TaxJar users. It's important you take the time before then to add logic and test your configuration to prevent service interruptions.

https://developers.taxjar.com/api/reference/#api-version

Refunds sync to TaxJar with the Credit Memo Increment ID instead of the Order Increment ID

This one may not be a bug necessarily, but it doesn't seem like the right way to handle it.

When an order is invoiced it's created in TaxJar with the Order's increment ID.
But when a refund is applied (credit memo created), it's created with the Credit Memo's increment ID.

Example
Order ID: 600005122
Refund for this order: 600000157-refund

So with the data in TaxJar, there is no way to know that those two transactions are related.

I think the best fix would be to use the order's increment ID instead, and increment a count if there are multiple refunds...

Example
Order ID: 600005122
Refund 1 for this order: 600005122-refund-1
Refund 2 for this order: 600005122-refund-2

This could be done by the API, or the module could easily do it by checking how many previous credit memos exist for the order.

The "transaction sync" setting can be defined at store level, but only the global setting is checked

While the transaction sync can be enabled/disabled per store, this setting is always checked globally. PR at #45

Notice: Undefined offset: 1561820 in /<installpath>/.modman/taxjar-magento-extension/app/code/community/Taxjar/SalesTax/Model/Smartcalcs.php on line 228

This notice is flooding the logs - seems there should be some isset checking on $parentQuantities[$parentId]. Looks like this will always throw the notice in cases where the parent item is seen first in the items array.

Scope transaction sync store configuration to the current store

On branch "transaction sync", ensure the taxjar* configuration values are scoped to the local store.

https://github.com/taxjar/taxjar-magento-extension/blob/transaction-sync/app/code/community/Taxjar/SalesTax/Model/Transaction/Comment.php#L32

Wrong tax with Magentos Bundle SKUs

We recently started using TaxJar. We noticed that TaxJar has problems with handling multiple Magento bundle-products. So if debugged the extension and added a fix to the file app/code/community/Taxjar/SalesTax/Model/Smartcalcs.php

The issue is that only the parent-bundle item has the correct quantity, the children-items are showing the quantity configured in Magento (so if 1 bundle consists of 1 screwdriver, 1 hammer, and 5 screws ) and you order 10 of them, TaxJar only calculates tax for 1 screwdriver, 1 hammer, and 5 screws instead of 10 screwdrivers, 10 hammers, and 50 screws.

I implemented a fix, to save the quantity for each parent and check multiplied the quantity for each child with the parent quantity.

I'm going to create a pull request against your git repo.
Guido

Refund transaction - wrong line items processing for Bundle

Hey guys!

We have an issue when in Magento make a refund, TaxJar might not receive the line item for some parts of Bundle product.

I took a look extension code and look like found an error in refund items processing.

You are using the method buildLineItems in Transaction model to prepare items to export for both orders and refunds.

It works fine for order items, but there is an error when processing refund items for Bundle:

Model/Transaction.php:108-110

foreach ($items as $item) {
  $itemType = $item->getProductType(); // $itemType = 'simple' - simple inside bundle
  $parentItem = $item->getParentItem(); // $parentItem = null - bundle was not loaded

Parent item was not bound because item was loaded through the model:

Model/Transaction/Refund.php:54-56

foreach ($creditmemo->getAllItems() as $item) {
  $items[] = Mage::getModel('sales/order_item')->load($item->getOrderItemId());
}

Looks like we don't need to load order_item there, because order with all items already loaded in creditmemo instance.
We can use method getOrderItem in Creditmemo_Item to receive order_item:

foreach ($creditmemo->getAllItems() as $item) {
  $items[] = $item->getOrderItem();
}

Andrey, Budsies Dev Team

Issue recalculating tax rate when using custom price in Admin Create Order page

Because we sell high value products on our website, the majority of our orders are taken over the phone and our sales team creates the order through the admin area.

On creation of an order, when custom prices are entered, the taxes are still based on the original prices and are not being recalculated.

It took me some time hunting down the issue in the code, but it looks like in the file "app/code/community/Taxjar/SalesTax/Model/Smartcalcs.php" on line 233 it is pulling the price from the wrong column in the database. The column it's currently pulling from doesn't change when a custom price is entered. Instead it should be pulling from the base price column.

I changed:
$unitPrice = (float) $item->getPrice();

To:
$unitPrice = (float) $item->getBasePrice();

This change worked for me. Now sales tax is recalculating correctly when custom prices are entered.

Incorrect Case Convention Used in Some Classnames

Hey there

There are three observer classes using incorrect class name conventions (based on every other class in the module). Basically rather than Taxjar_SalesTax_xxx they are TaxJar_SalesTax_xxx (not the capital J in Jar).

The affected classes are

TaxJar_SalesTax_Model_Observer_AdminNotifications
TaxJar_SalesTax_Model_Observer_AdminMenuItems
TaxJar_SalesTax_Model_Observer_ConfigReview

These should be renamed To Taxjar_SalesTax_xxx.

Happy to submit a PR if you like.

Best
Aaron.

Doesn't work with 2.3.3

When I go to Sales - Tax I get a white screen.
And error log says we are trying to setLabel on null.
Seems to be a problem with some attribute