Are estimations of tax before checkout supported? I see TaxSvc#estimate_tax, but nothing else in the gem seems to be calling that method, other than TaxSvc#ping.

Changelog, cache key compatibility fix, and a bugfix for the installer:

541dfe1

88bf8f8

9753493

The spree_core tax adjustment is not replaced when this one is created

Suppose there are multiple returns (therefore multiple return_authorizations) on same order.
When i th RMA is received/processed, we are sending every single order.return_authorizations to Avalara (1st, 2nd... i th RMAs).

Expected behavior:
When i th RMA is received, i-1, i-2 th, ... RMA should not be considered since they are already committed to Avalara previously

Relevant code in avalara_transaction.rb

order_details.return_authorizations.each do |return_auth|

          line = Hash.new
          i += 1
          line[:LineNo] = "#{i}-RA"
          line[:ItemCode] = "Return Authorization"
          line[:Qty] = 1
          if invoice_detail == "ReturnInvoice" || invoice_detail == "ReturnOrder"
            line[:Amount] = -return_auth.amount.to_f
          else
            line[:Amount] = return_auth.amount.to_f

          end
          line[:OriginCode] = "Orig"
          line[:DestinationCode] = "Dest"

          if myusecode
            line[:CustomerUsageType] = myusecode.try(:use_code)
          end

          line[:Description] = return_auth.reason
          line[:TaxCode] = ""

          AVALARA_TRANSACTION_LOGGER.debug line.to_xml

          tax_line_items<<line
        end

I'm using the master branch. And this bug

Bug

avalara_finalize method updates the amount of payment to be the order total. This is not a valid update, if the order contains multiple payments (store credit plus credit card too).

def avalara_finalize
    return unless avalara_tax_enabled?

    if self.amount != order.total
      self.update_attributes(amount: order.total)
    end

    order.avalara_capture_finalize
  end

Why is this update necessary after the capture?

Would it be possible to create a 3-1-0 stable branch? I need to upgrade my app to spree 3-1-0-stable to fix a bug.

Hello, i am using spree v3.1 and i cant install this gem onto it. It raises some dependency versions mismatches and i cant find the way to fix it. Do you have any ideas whats going on?

When saving the address for the company in the configuration it is overwritten with Address1, Address2, City, etc.

I just ran into a couple problems with this. It seems like the timeouts are hardcoded to exceptionally short times (1 second): See here and here and here.

When the network is slow at all, an exception is raised which causes the second issue -- the Spree order is left in a "half-completed" state. The charge goes through and the payment is recorded, but there is no credit card transaction ID saved, and the order isn't marked as purchased, so the customer typically re-attempts making the purchase, thus being double-billed.

Can you make the timeouts a configurable parameter so they can be lengthened?
Can you make it so that in case of not being able to contact Avalara servers, orders are left is a consistent state? (Either fully purchased, or not at all).

Thanks,
John

Why are the entity use codes not imported with the gem?

on 2-3-stable commit 4a4a89a introduces this crash for me upon booting up my app:

/Users/jason/Projects/Mack-Weldon/spree_avatax_certified/lib/spree_avatax_certified/engine.rb:36:in `block in class:Engine': uninitialized constant SpreeAvataxCertified::Seeder (NameError)

Requiring spree/backend and spree/frontend CSS it is overwriting custom CSS from apps that are not using the spree default CSS.

there are better gems for this @acreilly

please consider this when working on the previous issue

Shouldn't this gem be using a TaxCalculator to make the calls to Avalara and apply taxes so that the basic Spree concepts of Tax are adhered to? In this gem's current state it seems to just be creating arbitrary adjustments to the order but not necessarily taxing the items correctly.

This other gem seems to do it well and could be a model for the rewrite, https://github.com/spree-contrib/spree_tax_cloud. Unless I am missing something in the way that things work in this gem but it just seems a bit backwards and against the Spree core Tax ideas.

Is spree 3.0 BC enough for this to work? And if not are there plans of updating for 3.0?

After initial setup, trying to go to the Avalara configuration in Admin results in no implicit conversion of Hash into String.

<%= render :partial => 'spree/admin/shared/configuration_menu' %>
  <% origin = JSON.parse(Spree::Config.avatax_origin) || {} %>
  <h1><%= "Avalara Settings" %></h1>

  <table>

writing to disk doesn't work on Heroku. the logs should pass through Logplex or be otherwise accessible in a stateless environment.

(Also I'm not sure how a disk-based logging mechanism would work in a cluster environment with multiple servers? Seems like you'd get log transactions spread across different servers. A central log solution would fix this)

@acreilly & I discussed this and I will give it some thought as to a good architecture for Heroku. this issue is a to-do for myself.

Could you inform me why this was removed or what it was replaced with?

Hello,

We're using:

• rails 4.2.2
• ruby 2.1.2
• spree_avatax_certified 3.0.2

We're running into an issue where the tax code is not being sent in API calls for returns. As a result, the default code P0000000 is being assigned by Avalara on their end, resulting in tax amounts that don't necessarily align with the taxes charged in the initial transaction (within which the correct tax code is being sent originally).

This has happened for NJ purchases where the original product's tax amount was $0.00 (the tax code was passed through and Avalara said that category has no tax), but then when that item is returned without a tax code passed, Avalara uses P0000000, which resulted in a greater-than-zero tax amount due back in the refund quoted.

@acreilly I see you have an open branch on this already; figured I'd make an issue to track it a bit more publicly.

We've noticed that we are getting pretty regular timeouts both on development and production when trying to commit to Avalara. I've narrowed it down to at least the AvalaraTransaction#post_order_to_avalara method thanks to the logs that are created.

Is anyone else experiencing this? It's basically unusable for us right now.

I'm maintaining an older Spree 2.4 app which uses spree_avatax_certified. The app depends on a specific version of the gem, the Gemfile entry looks like this:

gem 'spree_avatax_certified', github: 'railsdog/spree_avatax_certified', branch: '2-4-stable', ref: 'cb518cfe'

This used to work flawlessly until yesterday, but since today I cannot install the gem anymore...

I noticed that the railsdog/spree_avatax_certified repo is now redirected to boomerdigital/spree_avatax_certified and that this repo does not have a 2-4-stable branch anymore.

Was this version/branch removed on purpose? Is it possible to get it back?

I can currently work around the issue by using the NationalProstaff/spree_avatax_certified fork of the repo which has the 2-4-stable branch, but I think it would be good if the official repo for the gem also has it.

Howdy!

I've spent a bunch of time this morning trying to get this extension working with Spree 2.3.4 and Rails 4.1.7.

I tried using the 2.3.4 branch of this extension (which looks to be under active development) and couldn't get the generators to run.

Installing from the master branch gets me further, but chokes when appending / inserting the JS / CSS. After toying with that, I'm able to get the migrations to run, but when attempting to hit the config page in the admin, I get a 500 error.

Completed 500 Internal Server Error in 442ms
ActionView::Template::Error (no implicit conversion of Hash into String):
1: <%= render :partial => 'spree/admin/shared/configuration_menu' %>
2: <% origin = JSON.parse( Spree::Config.avatax_origin )  %>
3: <h1><%= "Avalara Settings" %></h1>
4:
5: <table>

Any ideas? Thanks!

Avalara Tax adjustment should always be in closed state.
Otherwise, spree will try to re-calculate its amount when update is called.

The most common way that Avatax adjustment might be opened is spree admin users going to admin interface and manually opening adjustment in order adjustment page.

order.update!

NoMethodError: undefined method `compute_amount' for #<Spree::AvalaraTransaction:0x0000000fb3af38>

Please note I am using the 2-3-stable branch, I have not tested or compared to master branch.

Bug

Line item transactions are created in Avalara here:

https://github.com/railsdog/spree_avatax_certified/blob/2-3-stable/app/models/spree/avalara_transaction.rb#L295

Notice that the field used is 'pre_tax_amount', which is a field directly on the line_items table.

The table contains fields for quantity, price, and adjustment_total. The price column holds the pirce of the item before it is discounted, so the acutal price before the discount is quantity * price.

The discounted price is (quantity * price) + adjustment_total. (Note that adjustment_total is stored here in a negative values, as the total amount of adjustment that this line item has applied to it.)

Note that Spree stores pre_tax_amount as the result of the equation (quantity * price) + adjustment_total, so pre_tax_amount contains the price of the items after they have received their discount.

When the total transaction is passed to Avalara, one of the global (top-level) fields passed is "Discount", seen here:

https://github.com/railsdog/spree_avatax_certified/blob/2-3-stable/app/models/spree/avalara_transaction.rb#L419

Because all_adjustments scoops up both the order-level adjustments and the line item adjustments, this appears to create additional discounts in Avatax, thus the Avatax system is recording discounts on top of already-discounted prices, reducing the taxable amount to below the actual taxable amount.

Affected

This problem appears to only affect line items that have per-line item adjusments (feature introduced in Spree 2.2). As far as I can tell, other kinds of adjustments (whole order adjustments and shipping adjustments) are not affected by this problem.

Suggested Fix

I can see two possible remedies for this:

1. pass the before-discount line item price to avalara in the transactions. in avalara_transaction.rb#L295 change line_item.pre_tax_amount.to_f to (line_item.quantity * line_item.price). If the origional design intentaiton was to pass the full line item price, before discounts, this is probably the solution that will bring the implmentation correclty in line with the original design.

2. As an alternative fix continue to pass the discounted line items in the Line item transactions, but change the Discount that is passed to only include order-wide adjustments and not line item adjustments. For this fix, avalara_transaction.rb#L419 changes from order_details.all_adjustments to order.adjustments

(however, I'm not sure if this may remove the shipping adjustments which are needed? If so, maybe (order.adjustments + order.shipment_adjustments)

The updated spree_2_2 backend is not picking adding the order item adjustment to the items total, need to review the backend and spree store front code to see why this is occurring.

@acreilly
More of a question than an issue.
What was the purpose of 8812ffe

This seems largely unnecessary to me. Is there any use case for this?
It seems like order transition callbacks will naturally take care of re-calculating tax after promotions are applied.

Hello, would it be possible to create a 3-3-0 stable branch?
Thanks!

I'm evaluating this gem for our integration between Spree & Avalara. Is this gem ready to be used on a 2.2 store? How about for a store on master (2.3)?

I have my account setup in Avatax (working well with our Magento sites). The credentials are setup in the configuration properly, however the extension is not attempting to communicate with Avatax. Could you please advise as to anything I could check that would help with connection to Avatax? Thanks in advance, Kyle

Hi,

I am using this on a Spree 3.0 store. I have the setting for "Enable Avatax Document Committing" set to true, however the transactions are marked as uncommitted in the Avalara backend and need to be manually updated to "Committed".

How can I get the transactions to be submitted to Avalara as "Committed"? It seems as though this setting should do the trick, however it is not.

Thanks

We're launching an international store front, and whist Avatax seems to be doing what we need for US and Canada, the gem is causing pre-tax figures to be reported incorrectly in all other regions.

I think the discrepancy is due to an assumption that the list price is the same as the pre-tax price - Whilst this is true for US & Canada, the same does not hold in the rest of the world.

For example for a UK product the list price is £100 and the VAT rate 20% so we'd expect the pre-tax amount to be £83.33. Avatax seems to be setting this back to £100 even though we're not using it for this store. This is causing tax liability to be incorrectly reported upstream.

We'd appreciate some help figuring this one out.