boomerdigital / spree_avatax_certified Goto Github PK
View Code? Open in Web Editor NEWImprove your Spree store's sales tax decision automation with Avalara AvaTax
License: Other
Improve your Spree store's sales tax decision automation with Avalara AvaTax
License: Other
Could you inform me why this was removed or what it was replaced with?
Why are the entity use codes not imported with the gem?
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.
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>
there are better gems for this @acreilly
please consider this when working on the previous issue
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
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?
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
The spree_core tax adjustment is not replaced when this one is created
Requiring spree/backend
and spree/frontend
CSS it is overwriting custom CSS from apps that are not using the spree default CSS.
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
.
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)?
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.
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.
Hello,
We're using:
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.
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.
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?
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
Please note I am using the 2-3-stable branch, I have not tested or compared to master branch.
Line item transactions are created in Avalara here:
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:
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.
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.
I can see two possible remedies for this:
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.
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)
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
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.
Hello, would it be possible to create a 3-3-0 stable branch?
Thanks!
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)
Running via Spring preloader in process 31
Loading development environment (Rails 4.2.9)
irb: warn: can't alias context from irb_context.
irb(main):001:0> reload!
Reloading...
TypeError: superclass mismatch for class ReturnTax
from /bundle/bundler/gems/spree_avatax_certified-f3cf18ee4928/app/models/spree_avatax_certified/request/return_tax.rb:3:in `<module:Request>'
from /bundle/bundler/gems/spree_avatax_certified-f3cf18ee4928/app/models/spree_avatax_certified/request/return_tax.rb:2:in `<module:SpreeAvataxCertified>'
from /bundle/bundler/gems/spree_avatax_certified-f3cf18ee4928/app/models/spree_avatax_certified/request/return_tax.rb:1:in `<top (required)>'
from /bundle/gems/activesupport-4.2.9/lib/active_support/dependencies.rb:268:in `load'
from /bundle/gems/activesupport-4.2.9/lib/active_support/dependencies.rb:268:in `block in load'
from /bundle/gems/activesupport-4.2.9/lib/active_support/dependencies.rb:240:in `load_dependency'
from /bundle/gems/activesupport-4.2.9/lib/active_support/dependencies.rb:268:in `load'
from /bundle/bundler/gems/spree_avatax_certified-f3cf18ee4928/lib/spree_avatax_certified/engine.rb:39:in `block in activate'
from /bundle/bundler/gems/spree_avatax_certified-f3cf18ee4928/lib/spree_avatax_certified/engine.rb:38:in `glob'
from /bundle/bundler/gems/spree_avatax_certified-f3cf18ee4928/lib/spree_avatax_certified/engine.rb:38:in `activate'
from /bundle/gems/activesupport-4.2.9/lib/active_support/callbacks.rb:446:in `instance_exec'
from /bundle/gems/activesupport-4.2.9/lib/active_support/callbacks.rb:446:in `block in make_lambda'
from /bundle/gems/activesupport-4.2.9/lib/active_support/callbacks.rb:192:in `block in simple'
from /bundle/gems/activesupport-4.2.9/lib/active_support/callbacks.rb:504:in `block in call'
from /bundle/gems/activesupport-4.2.9/lib/active_support/callbacks.rb:504:in `each'
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?
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.
@acreilly I see you have an open branch on this already; figured I'd make an issue to track it a bit more publicly.
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>
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.