Just a heads up that over the next couple weeks https://github.com/boomerdigital/solidus_avatax_certified will be going through upgrades and maintenance. Please log any feature requests/issues etc on github and I can promise they will get addressed very soon.

I think we have done something on our fork. If you plan to merge PRs we can send some work your way

That would be great

🙌 please, see https://github.com/boomerdigital/solidus_avatax_certified/pull/180

Very exciting some updates are coming, thanks! 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

captured

boolean, 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!

One additional consideration I'd like to throw into the ring - currently, the

avalara_transaction

class has hardcoded behavior which returns

totalTax: 0.0

if the network response is an error. It might be nice to make this behavior configurable with a simple override or hook. For example, in our application, we wanted to monkey patch this so that we could add error reporting when this occurred to monitor it. That meant we had to patch the whole

post_order_to_avalara

method, which is obviously slightly more invasive!

that’s a very good point, a customizable class that returns that amount would be ideal

Right - just some better way to hook into the system and allow stores to customize the fallback behavior would be useful. Returning 0 is a perfectly sane default, but might not be reasonable in all cases.

We would also use this great suggestion! Btw I filed my comment as an actual issue here per @kennyadsl’s suggestion https://github.com/boomerdigital/solidus_avatax_certified/issues/182