Giter VIP home page Giter VIP logo

solidus_avatax_certified's Introduction

solidus_avatax_certified

CircleCI

solidus_avatax_certified is the only officially certified AvaTax solution that integrates with Solidus. With this extension, you can add instantaneous sales tax decisions to your store.

From Avalara's own explanation of the certification program:

Relax. It’s certified.

Our “Certified for AvaTax” Program features integrations that perform at the highest level, providing the best possible customer experience.

Avalara’s partners who have created certified integrations for AvaTax have demonstrated that those integrations contain elements which are essential to providing customers with easy-to-use software that gives accurate sales tax calculations. The certification criteria used to demonstrate these elements are based on Avalara’s years of experience integrating into ERP, ecommerce and point-of-sale applications.

For Installation and Setup instructions, please visit our wiki.

Installation

1. Install the gem

First of all, install the gem:

$ gem 'solidus_avatax_certified', github: 'boomerdigital/solidus_avatax_certified'
$ bundle install
$ bundle exec rails g solidus_avatax_certified:install

2. Configure the gem

Once you're done with the setup, you have to configure the gem. You can do this via an initializer or, for some option, via environment variables. The defaults are shown below:

# config/initializers/avatax.rb
Spree::Avatax::Config.configure do |config|
  config.company_code = ENV['AVATAX_COMPANY_CODE']
  config.license_key = ENV['AVATAX_LICENSE_KEY']
  config.account = ENV['AVATAX_ACCOUNT']
  config.environment = ENV['AVATAX_ENVIRONMENT'].presence || (Rails.env.production? ? :production : :sandbox)
  config.log = true
  config.log_to_stdout = false
  config.address_validation = true
  config.address_validation_enabled_countries = ['United States', 'Canada']
  config.tax_calculation = true
  config.document_commit = true
  # The origin MUST be a JSON string. An example is shown below:
  # { line1: '915 S Jackson St', line2: '', city: 'Montgomery', region: 'AL', postalCode: 36104, country: 'US' }.to_json
  config.origin = '{}'
  config.refuse_checkout_address_validation_error = false
  config.customer_can_validate = false
  config.raise_exceptions = false 
end

3. Seed the DB

Then, load all seeds:

$ bundle exec rake solidus_avatax_certified:load_seeds

The line above will:

  • Create the entity use codes given to us by Avalara
  • Destroy the Default tax category
  • Create the Clothing and Shipping tax categories
  • Add the Shipping tax category to all shipping methods
  • Add the Clothing tax category to all products
  • Destroy the North America tax rate
  • Create tax rates for Clothing and Shipping
  • Populate the default stock location with a random address

You can also run the following if you only want to load Avalara entity use codes:

$ bundle exec rake solidus_avatax_certified:load_use_codes

4. Adjust your tax categories

AvaTax has a list of tax codes. You should create a tax category for each tax code used by your store.

The solidus_avatax_certified:load_seeds tax creates two tax categories: Clothing and Shipping. We invite you to check that the tax categories make sense for your store and that they have the appropriate tax codes.

If you need to adjust the tax categories or create new ones, the process is:

  1. Create a new tax category, using the appropriate tax code
  2. Create a tax rate for the tax category, use 0.0 as the rate and the Spree/Avalara Transaction calculator
  3. Assign products (or shipping methods) to the tax category

Usage

solidus_avatax_certified will automatically calculate sales taxes for any products that belong to an AvaTax-backed tax category.

Assigning entity use codes to users

If any of your clients require a special entity use code, you can assign it to them from their profile page in the Solidus backend.

Testing

To run the tests, install the bundle and run rake, which will generate a test app and run all tests against it:

$ bundle
$ bundle exec rake

License

Copyright (c) 2016-∞ Boomer Digital LLC, released under the New BSD License.

solidus_avatax_certified's People

Contributors

acreilly avatar aldesantis avatar cedum avatar danielepalombo avatar dhonig avatar elia avatar ericsaupe avatar garciajordy avatar kennyadsl avatar massimilianolattanzio avatar mfrwdesign avatar tmtrademarked avatar waiting-for-dev avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

solidus_avatax_certified's Issues

Order.avalara_tax_enabled isn't respected in tax calculator

It looks like there may be a slight design flaw here - but before I open a PR to attempt to fix this, I'm curious whether or not this is truly intentional. So I figured I'd open an issue and see what others thought.

From what I can tell, there's a method on an order called avalara_tax_enabled? defined here which seems to be used in a few places to help determine whether or not tax should be calculated for a given order. But... in the tax calculator, this method is not used, and instead we just check the overall tax configuration.

It seems like this method is intended to be a hook for applications to write code that allows for saying "disable taxes for this order", but that obviously won't work as written. I'm not sure if this is an intentional choice in the gem, or an oversight, or a bug, or some combination of all three!

avalara_response[:totalTax] is always nil

The conditional return 0 if avalara_response[:totalTax] == 0.0, but not as intended, as avalara_response[:totalTax] always returns nil because it will not be found in the hash.

Should be...

module Spree
  class Calculator::AvalaraTransaction < Calculator::DefaultTax
    # ...

    def tax_for_item(item, avalara_response)
      prev_tax_amount = prev_tax_amount(item)

      return prev_tax_amount if avalara_response.nil?
      return 0 if avalara_response['totalTax'] == 0.0

      avalara_response['lines'].each do |line|
        if line['lineNumber'] == "#{item.id}-#{item.avatax_line_code}"
          return line['taxCalculated']
        end
      end
      0
    end
  end
end

Solidus 2.0 and Rails 5

The Solidus core team is updating all of their core gems because Solidus 2.0 with support for Rails 5 is on the horizon. In addition to that they have a pre-release for 1.4. Are you guys going to support these versions as well?

Test mode

It would be useful to have a test mode that returns dummy taxes and dummy results for address validations.

Can't edit credentials in Admin without an Address

After running the PreferenceSeeder I tried to edit credentials in the Spree Admin but was met with a 500. I had to run Spree::AvalaraPreference.origin_address.update(value: {"Country": "US", "Region": "UT"}.to_json) to get there.

Shipment Discounts Double Counted in Solidus 2.4

We're seeing this issue in Solidus 2.4, but it may exist in other versions as well.

Reproduction Steps

  1. Configure a flat rate shipping rate for any number larger than $0.
  2. Add a promotion that automatically applies and makes all shipments on an order free.
  3. Place an order.
  4. The tax will be calculated as if the subtotal is: (subtotal) + (shipment cost - discounts) - (all discounts, including shipment discounts)

I think that's related to this line:

https://github.com/boomerdigital/solidus_avatax_certified/blob/master/app/models/solidus_avatax_certified/line.rb#L61

Which is the (shipment cost - discounts).

and this line:

https://github.com/boomerdigital/solidus_avatax_certified/blob/master/app/models/solidus_avatax_certified/request/get_tax.rb#L9

Which includes order adjustments and shipment adjustments.

I think the best way to handle this will be to exclude shipment adjustments from the line in get_tax.rb. However, there may be better ways to handle this in the Avatax API that I am not aware of. My assumption is based on assuming that when we offer free shipping we want to make sure the shipment total is $0 to make sure that tax is not calculated against this value.

Remove PreferenceSeeder

Since preferences aren't read from the DB anymore, this class is basically useless. This should probably be done in conjunction with or after #123.

Multiple Payments

self.update_attributes(amount: order.total)

When there are multiple payments on an order (Credit Card, Gift Card). This line will mess up checkout by changing the actual amount on the payment, to the order total.
For example:
Order total is $19

1st Payment is $10 (gift card)
2nd Payment is $9 (credit card)

See https://github.com/solidusio/solidus/blob/master/core/app/models/spree/order/payments.rb#L42 for below context.

1st Payment:

  • process! then purchase! is called
  • $10 captured on first payment
  • payment.complete! called
  • oops, payment.amount now $19

Now 2nd payment is getting processed:

  • payment_total reflects total we break which causes checkout to fail
  • Customer goes through checkout again
  • Completed payment shows for $19
  • Complete order and all is well even though customer was only actually charged $10

Adjust Locked Transaction Error

From what i understand, it is common for avatax users to lock their committed transactions after a set time period. I am trying to figure out what is the best way to go about catching a locked transaction error, having it display the error on the admin order interface, and not allowing the user to be able to adjust the order contents.

@skukx @ericsaupe

Locked Transaction Error Message:
{ "error"=> { "code"=>"CannotModifyLockedTransaction", "message"=>"", "target"=>"AvaTaxApiServer", "details"=> [{"code"=>"CannotModifyLockedTransaction", "number"=>1100, "message"=>"", "description"=>"290244256", "helpLink"=>"http://developer.avalara.com/avatax/errors/CannotModifyLockedTransaction", "severity"=>"Error"}] } }

Remove preferences form

Preferences are not stored in the DB anymore, but the admin panel still provides a form for people to edit preferences that doesn't really do anything.

Faraday standard error being trapped

Ran into this error:

NoMethodError: undefined method `body' for #<Hash:0x00007f83c0310fd8>
  from solidus_avatax_certified/response/base.rb:13:in `result'
  from tax_svc.rb:49:in `handle_response'
  from tax_svc.rb:43:in `validate_address'
  from solidus_avatax_certified/address.rb:53:in `validation_response'
  from solidus_avatax_certified/address.rb:46:in `validate'
  from models/solidus_avatax_certified/spree/order_decorator.rb:47:in `validate_ship_address'

I have not been able to reproduce it again as it seems related to an error being raised from avatax api that is no longer happening. From what I can see, validate_address is trapping the exception and changing the request to point at a Hash.

  def validate_address(address)
    begin
      request = client.addresses.validate(address)
    rescue StandardError => e
      logger.error(e)

      request = { 'error' => { 'message' => e } }
    end

    response = SolidusAvataxCertified::Response::AddressValidation.new(request)
    handle_response(response)
  end

Then handle_response calls response.result

  def handle_response(response)
    result = response.result
    begin
      if response.error?
        raise SolidusAvataxCertified::RequestError, result
      end

      logger.debug(result, response.description + ' Response')
    rescue SolidusAvataxCertified::RequestError => e
      logger.error(e.message, response.description + ' Error')
      raise if raise_exceptions?
    end

    response
  end

This calls faraday.body but now faraday is pointing at a Hash and we get this error:

 def result
   @result ||= faraday.body
 end

Let me know if this makes sense. Thx.

Updating preferences only updates them on the current server

When updating the preferences, the changes are saved to the database and the Spree::Avatax::Config options are updated. If this is in an environment where there are multiple servers running the application, only the server that actually updated the options has the config updated. The other servers only load config options on initialize, so they do not receive the updates until the servers are restarted.

Universal Branch

I like how Solidus gems have the master branch work for all versions. In Solidus v2.1, there were some significant changes to tax, where the only way I could think of making it work was to either bring over all that new code, or just put v2.1 on a new branch.

v2.2 just came out and it appears that it will work fine on the v2.1 branch, but I wanted opinions on how I should handle this, maybe find a better solution. Ideally it would be great to get it all on one branch.

@ericsaupe @skukx @jasonfb @dhonig

Sandbox documentation warning

I'm new to Avatax and did not understand from your documentation (or the Avatax developer docs) that a seperate sandbox account is required before the gem will work in development. Adding a line at the top of the setup wiki would potentially save another developer from spending an entire morning trying to understand what is going on as they build their knowledge of the service and your gem.

Thanks for all the time you've invested in this, I'm sure when the client sets up the Sandbox account, I'll very much appreciate it.

Preferences

Awhile back I was told that Solidus was looking into removing Spree::Preferences in the future, that is why I created Spree::AvalaraPreference. I was misinformed and they will not be removing it.

I would like to go back to using Spree::Preferences rather than holding them in the database.

Javascript not formatted correctly

We tried to deploy using the installed javascript to our production servers and got V8::Error: SyntaxError: Unexpected token: operator (>) when we tried to compile the assets. After removing the solidus_avatax_certified javascript from our project all was well again. I ran some of the JS files through jslint.com and it came up with a number of errors. Looks to only be a problem on Ubuntu since our local OSX machines weren't picking it up.

Discount doesn't take manual adjustments into account

SolidusAvataxCertified::Request::GetTax does not seem to be taking manual adjustments into account when sending the discount property:

discount: order.all_adjustments.promotion.eligible.sum(:amount).abs.to_s

This means that creating an adjustment via the backend to grant the customer a discount will not have any effect on sales tax calculation, which doesn't seem right.

Is this a bug or are we doing something wrong?

Make environment configurable w/o environment variable

Users should be able to do this, without having to set the AVATAX_ENVIRONMENT environment variable:

Spree::Avatax::Config.environment = :production # or :sandbox

This allows people to use other sources for configuration (e.g. settings.yml/secrets.yml).

This can be easily accomplished by adding preference :environment, :boolean, default: ENV['AVATAX_ENVIRONMENT'] and removing .environment from Spree::AvataxConfiguration. This also maintains backwards compatibility.

undefined local variable or method `default_environment' for Spree::AvataxConfiguration:Class (NameError)

When working through the setup instructions, after installing the gem and running the migrations, I'm getting the following error when attempting to start my application:

undefined local variable or method `default_environment' for Spree::AvataxConfiguration:Class (NameError)

I've created an initializer that looks like the following:

# frozen_string_literal: true

Spree::Avatax::Config.configure do |config|
  config.company_code = ENV['AVATAX_COMPANY_CODE']
  config.license_key = ENV['AVATAX_LICENSE_KEY']
  config.account = ENV['AVATAX_ACCOUNT']
  config.environment = ENV['AVATAX_ENVIRONMENT'].presence || (Rails.env.production? ? :production : :sandbox)
  config.log = true
  config.log_to_stdout = true
  config.address_validation = true
  config.address_validation_enabled_countries = ['United States']
  config.tax_calculation = true
  config.document_commit = true
  config.origin = '{}'
  config.refuse_checkout_address_validation_error = false
  config.customer_can_validate = false
  config.raise_exceptions = false 
end

But from what I can tell, the problem seems to be that Spree::AvataxConfiguration is attempting to call default_environment as a class method, when it is defined as an instance method. Am I misunderstanding something here?

I'm using Solidus 3.1.4, Ruby 3.0, and Rails 6.1.4.4.

Errors Being Ignored

Errors returned from Avatax are being ignored.

See: https://github.com/boomerdigital/solidus_avatax_certified/blob/master/app/models/tax_svc.rb#L23
See: https://github.com/boomerdigital/solidus_avatax_certified/blob/master/app/models/spree/avalara_transaction.rb#L101

This isn't very good practice to swipe errors under the rug. At the least the logger should use warn instead of debug and info. Ignoring these errors could potentially lose a company money by not charging the correct taxes. Another idea could be created an avalara_events table which keeps track of all the avatax events. So if #get_tax fails, order.avalara_events would show the response returned from avalara.

In my opinion, custom error classes should be created and allowed to bubble to the application so that the application can handle to error. Or possibly provide a callback the application can tie into so that the application has a choice on what to do about the error.

AvataxLog doesn't have an error method

When trying to process a return and I click "Refund," I get this error:
NoMethodError in Spree::Admin::RefundsController#create undefined method 'error' for #<SolidusAvataxCertified::AvataxLog:0x0056501a48dd78>

VCR cassettes not up to date

I'm trying to refresh this gem's cassettes locally (using our customer's account), in the response I always get "nonTaxable":20.0 and I can't get a taxable amount greater than zero. I'm using the same avatax account successfully in the development environment.

Also, what do you think about using VCR's filter_sensitive_data allowing other developers to compare requests/responses easily?

Limit itemCode to 50 characters

While investigating an issue with our tax responses coming back as bad we received this in the response. We should limit the itemCode field to 50 characters as requested. We should also look into any other fields that have limits.

{
    "error" => {
           "code" => "ModelStateInvalid",
        "message" => "Field 'itemCode' has an invalid length.",
         "target" => "HttpRequest",
        "details" => [
            [0] {
                       "code" => "MaxStringLengthError",
                     "number" => 14,
                    "message" => "Field 'itemCode' has an invalid length.",
                "description" => "Field 'itemCode' must be no more than 50 characters in length.",
                  "faultCode" => "Client",
                   "helpLink" => "http://developer.avalara.com/avatax/errors/MaxStringLengthError",
                   "severity" => "Error"
            }
        ]
    }
}

Affected lines

Query Avatax after orders are sent to ensure they actually arrived, record this somewhere, re-send if needed

We have a problem where something like 5 or 10% of orders a month do not make it in to Avalara and we have to manually send them over with avalara_capture and avalara_capture_finalize called on each instance to re-send. This is due to various issues, us being down, Avalara being down, validation issues with an order maybe (just a theory), etc. It seems the gem's sending is only best effort.

If there was a new column added for actually checking if an order made it over after transmission to the avalara_transaction table, something like a capturedboolean, and a Rake task you could run daily to check for orders that didn't make it and re-send them, that would be incredibly helpful.

I think we really have to check after sending with a subsequent API call looking for the order in Avalara and then mark captured as true only if we double checked with Avalara after the fact. We're going to have to build something like this ourselves in the next few months if it isn't a part of the lib.

Thanks for your consideration!

1.3 Progress?

Hey everyone,

I saw 1.2 was certified by Avalara, congrats 🎉! Any update on the 1.3 branch? I see there is one for solidus 1.3 and I was just wondering about an update for when we can start using it in our solidus 1.3 application.

Thanks!

Remove prev_tax return if state check

On this line here https://github.com/boomerdigital/solidus_avatax_certified/blob/master/app/models/spree/calculator/avalara_transaction.rb#L17 you are checking if the order is in the address or the cart state. But solidus computes taxes on transitions from the address step. This is causing issues in the admin where the taxes are not getting calculated until after a payment is added.

Is there any reason to have this line? I think it should be removed so that the solidus state machine transitions are respected for creating taxes.

Address transiton (this is broken using Avatax certified): https://github.com/solidusio/solidus/blob/v1.3/core/app/models/spree/order/checkout.rb#L93
Payment transition:
https://github.com/solidusio/solidus/blob/v1.3/core/app/models/spree/order/checkout.rb#L81

401 unauthorised issue from test connection in admin

Hi all,

I am using this gem with Solidus 2.10.0 and configured with the Avatax trial account. Below are the app details.
Rails version: 5.2.4
Ruby version: 2.6.0

Once it is configured, from the admin portal of Solidus, whenever I try to check the "Test Connection", it is always showing the below error.
Selection_743

Also, I am not getting the sales tax value while doing the checkout. ANy thoughts, what could be the issue or share your thoughts.

Previous Tax Amount when recalculated to 0

Why is prev_tax_amount returned if the avalara_response[:TotalTax] is 0? Shouldn't it respect that new calculation?

The use case we have is we get to the payment step, taxes are calculated.
A promotion is applied, making the promo total the price of the item, and taxes are recalculated.
The recalculated tax is 0 but it instead keeps the old tax amount calculated previously.

Previous Versions No Longer Available

I've been developing a site using Solidus 1.4.1, which was also using the solidus_avatax_certified gem on the same branch. Today I made a PR and noticed that my Travis build failed. It failed when trying to do a git reset on the cache for solidus_avatax_certified.

Taking a closer look at the repo, it appears that the branches for previous versions have been removed, even though the wiki states to reference the branch in the installation instructions. It doesn't look like the gem is distributed anywhere, this is causing issues for me since there doesn't seem to be a good way to access older versions of the gem.

Was this done intentionally? What is the best way for me to go about continuing to use this gem? Is there any chance of actually getting the gem on RubyGems where users could just reference any version of the gem that they need?

Thanks, any help is appreciated.

Taxes no longer calculated (most of the time) after upgrading to Solidus 2.6 + solidus_avatax_certified 3.0.0

I apologize for the vagueness of this, but that's essentially problem: I can't figure out why something isn't happening.

We have an existing production site current running Solidus 1.4 with solidus_avatax_certified v1.1.0. Taxes are recalculated at all the expected times, provided an address is on the order:

  • Whenever an item is added or removed
  • Whenever discounts are applied or removed
  • Whenever the ship address is changed
  • etc...

After a long upgrade process culminating in Solidus 2.6 + solidus_avatax_certified 3.0.0, taxes are no longer being calculated in many of these situations. The most confusing part is that sometimes they are calculated.

It's not a simple Avatax configuration issue. Our license key and account have not changed, and when the solidus_avatax_certified actually calls the Avatax API everything works. I can see the calls via the Avatax logs, specifically tracing to order_decorator.rb#avalara_capture:

def avalara_capture
logger.info "Start avalara_capture for order #{number}"
create_avalara_transaction if avalara_transaction.nil?
line_items.reload
avalara_transaction.commit_avatax('SalesOrder')
end

This method just doesn't get called at all many of the times we expect it to. Sometimes when I proceed from delivery to payment states, avalara_capture fires, sometimes it doesn't. Sometimes when I add or remove a line item avalara_capture fires, sometimes it doesn't.

I can see that new functionality in solidus_avatax_certified introduced since v1.1.0 would explicitly avoid recalculating taxes in cart, address, or delivery state:

module SolidusAvataxCertified
class OrderAdjuster < Spree::Tax::OrderAdjuster
def adjust!
if %w(cart address delivery).include?(order.state)
return (order.line_items + order.shipments)
end
super
end
end
end

# Tax Adjustments are not created or calculated until on payment page.
# 1. We do not want to calculate tax until address is filled in and shipment type has been selected.
# 2. VAT tax adjustments set included on adjustment creation, if the tax initially returns 0, included is set to false causing incorrect calculations.
def can_calculate_tax?(order)
address = order.tax_address
return false unless Spree::Avatax::Config.tax_calculation
return false if %w(address cart delivery).include?(order.state)
return false if address.nil?
return false unless calculable.zone.include?(address)
true
end

...but I don't know if this is actually what is preventing the taxes from being calculated, or whether this is functionality we even want.

So, have others reported similar challenges updating from earlier Solidus and solidus_avatax_certified versions?

In short, I expect taxes to always be recalculated when any applicable change to the order occurs, but observed behavior is that they are only calculated sporadically.

Zeitwerk LoadError after upgrading to `32d487f`

Ruby version: 3.1.1
Rails version: 6.1.4.7
Solidus version: 3.1.5

After upgrading the gem to rev 32d487f when running Avatax initializer:

Spree::Avatax::Config.configure  do |config|

I get this LoadError:

LoadError: Unable to autoload constant Spree::Avatax::Config, expected /usr/local/lib/ruby/gems/3.1.0/bundler/gems/solidus_avatax_certified-32d487f45097/lib/spree/avatax/config.rb to define it

@DanielePalombo It's probably related to this change
https://github.com/boomerdigital/solidus_avatax_certified/pull/172/files#diff-dab461c0e0e21d28bfcd91eb14a7ebbc04540b8f1d761853183ac80a77676c84R10

Do I have to update the initializer in some way to make it work?

Merge setup.md and readme.md?

Is there a reason for these two to be separated or can we merge them together? It seems like readme.md is a much better place to describe setup instructions.

Finalized Tax Adjustments Being Altered

When tax is finalized, it is still getting changed when adding a new adjustment.

The expectation would be that when tax is finalized it doesn't change. However if it is not finalized, it should change.

To recreate:

  • Create and complete an order
  • Go to admin and view the adjustments on the order
  • Adjustments should all be finalized
  • Create a new adjustment for any amount.
  • Save and finalize
  • The tax adjustment changed.

I realize this is nice because if the order total changes then so does tax. However I think it is unexpected behavior for an adjustment to change value if it is finalized.

Error in #tax_included_in_price?

rates_for_item(item).try(:first).included_in_price || false

 def tax_included_in_price?(item)
   rates_for_item(item).try(:first).included_in_price || false
 end

Should be changed to

 def tax_included_in_price?(item)
   !!rates_for_item(item).try(:first)&.included_in_price
 end

It is possible for the try to fail resulting in a nil object which will cause an error when trying to call the method included_in_price

Feature request - allow customization of network failure behavior

Currently, in AvalaraTransaction#post_order/return_to_avalara, the method handles an error response by returning totalTax: 0.0. It would be great if there were a way for stores to customize this behavior. Perhaps having a configurable class like AvalaraErrorHandler which would be given the response object would make this simpler? That way, stores could replace the error handler with their own implementation as needed to create more advanced behaviors (like hooking into error reporting tools or raising errors or even implementing retries, etc).

New release?

There's been a fair amount of development on this gem in the past few years, but no official releases. Is there any chance of getting an update on the future release plan for this gem? It would be nice to not have to rely on various random SHAs for integrations and be able to have actual versioned releases published. (Obviously not the most important, since we can continue to work around it! But since this gem is used for financial calculation, I figured I would at least ask the question)

Discounts on `Spree::Shipment` cause `NoLinesDiscounted` Response, Failing Tax Calculation

This issue occurred using Solidus 2.4 and a version of this gem with the following changes.

When using a Spree::Promotion that contains the "Make all shipments free" action that automatically applies to orders that meet the Rules, it causes the following error response to be logged and no tax to be applied to the order. This might be limited to orders that contain no other discounts.

[AVATAX] Get Tax Error {"error"=>{"code"=>"NoLinesDiscounted", "message"=>"Transaction has no lines which are discounted.", "target"=>"IncorrectData", "details"=>[{"code"=>"NoLinesDiscounted", "number"=>190, "message"=>"Transaction has no lines which are discounted.", "description"=>"The CreateTransactionModel object with discount amount set must have at least one line which is discounted.", "faultCode"=>"Client", "helpLink"=>"http://developer.avalara.com/avatax/errors/NoLinesDiscounted", "severity"=>"Error"}, {"code"=>"NoLinesDiscounted", "number"=>190, "message"=>"Transaction has no lines which are discounted.", "description"=>"The CreateTransactionModel object with discount amount set must have at least one line which is discounted.", "faultCode"=>"Client", "helpLink"=>"http://developer.avalara.com/avatax/errors/NoLinesDiscounted", "severity"=>"Error"}]}}

Here's the corresponding request hash:

[AVATAX] get_tax request hash {:createTransactionModel=>
  {:code=>"R378534300",
   :date=>"2018-09-27",
   :discount=>"9.99",
   :commit=>true,
   :type=>"SalesInvoice",
   :lines=>
    [{:number=>"1702304-LI",
      :description=>"The Rover Jacket",
      :taxCode=>"PC040100",
      :itemCode=>"148834",
      :quantity=>1,
      :amount=>298.0,
      :discounted=>false,
      :taxIncluded=>false,
      :addresses=>
       {:shipFrom=>
         {:line1=>"123 Main St",
          :line2=>"",
          :city=>"Columbus",
          :region=>nil,
          :country=>"US",
          :postalCode=>"20001"},
        :shipTo=>
         {:line1=>"161 Sussex Street",
          :line2=>nil,
          :city=>"Sydney",
          :region=>nil,
          :country=>"AU",
          :postalCode=>"2000"}},
      :customerUsageType=>nil,
      :businessIdentificationNo=>nil,
      :exemptionCode=>nil},
     {:number=>"1137240-FR",
      :itemCode=>"Australia + UK",
      :quantity=>1,
      :amount=>0.0,
      :description=>"Shipping Charge",
      :taxCode=>"FR020100",
      :discounted=>false,
      :taxIncluded=>false,
      :addresses=>
       {:shipFrom=>
         {:line1=>"123 Main St",
          :line2=>"",
          :city=>"Columbus",
          :region=>nil,
          :country=>"US",
          :postalCode=>"20001"},
        :shipTo=>
         {:line1=>"161 Sussex Street",
          :line2=>nil,
          :city=>"Sydney",
          :region=>nil,
          :country=>"AU",
          :postalCode=>"2000"}},
      :customerUsageType=>nil,
      :businessIdentificationNo=>nil,
      :exemptionCode=>nil}],
   :customerCode=>9999999,
   :companyCode=>"COMPANYINC",
   :customerUsageType=>nil,
   :exemptionNo=>nil,
   :referenceCode=>"R378534300",
   :currencyCode=>"USD",
   :businessIdentificationNo=>nil}}

Note: the above shipFrom address has been modified.

In the request hash there is a discount set at the highest level, however all of the items show that discounted is set to false. This value seems to be hardcoded to false for all shipments sent to AvaTax.

In the above order in Solidus, the Spree::Shipment itself had a before promo total of 9.99 with a 9.99 discount applied by the Free Shipping promotion.

Looking at SolidusAvataxCertified::Line, I'm unsure if #shipment_line should be updated to reflect itself being discounted, or if the the discount key should have its calculation updated in SolidusAvataxCertified::Request::GetTax – or something else entirely.

All Preferences lost when server restarts

I'd very much like to use the gem for a site already in production, however all preferences are lost when the server restarts, address, countries, boolean values.

solidus (2.4.2)
  solidus_api (= 2.4.2)
  solidus_backend (= 2.4.2)
  solidus_core (= 2.4.2)
  solidus_frontend (= 2.4.2)
  solidus_sample (= 2.4.2)

solidus_avatax_certified (3.1.0)
 avatax-ruby
 json (~> 1.8)
 logging (~> 2.0)
 solidus_core (>= 2.3.0, < 3.0.0)
 solidus_support

Capybara::Poltergeist::JavascriptError (TypeError: undefined is not a function)

Master branch is failing due to poltergeist errors. I updated the version but the errors still occur. Need some guidance.

https://travis-ci.org/boomerdigital/solidus_avatax_certified/jobs/304816095

       One or more errors were raised in the Javascript code on the page. If you don't care about these errors, you can ignore them by setting js_errors: false in your Poltergeist configuration (see documentation for details).
       TypeError: undefined is not a function (evaluating 'Object.keys(this.lineHash).find(function(key){ return this[key] === value}.bind(this.lineHash))')
       TypeError: undefined is not a function (evaluating 'Object.keys(this.lineHash).find(function(key){ return this[key] === value}.bind(this.lineHash))')```

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.