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

[zachfeldman]

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!

[zachfeldman]

@kennyadsl here's the issue we discussed filing!

[dhonig]

This goes a step beyond the basic logic. I think we could consider a rake task that attempts a basic synch operation. Would you like to suggest the logic for how that synch would work?

…

On Tue, Jun 13, 2023 at 10:14 AM Zach Feldman ***@***.***> wrote: 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! — Reply to this email directly, view it on GitHub <#182>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZTL2YYQ2CSWDYQ6TYGL3XLBYUZANCNFSM6AAAAAAZE6GPGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kennyadsl]

If this is something done after the order is finalized, what if we extract the API call in an ActiveJob class so that we can easily push that job to a retriable background queue?

[dhonig]

Thats a good suggestion! ActiveJob would be a good way to handle this.

…

On Tue, Jun 13, 2023 at 11:42 AM Alberto Vena ***@***.***> wrote: If this is something done after the order is finalized, what if we extract the API call in an ActiveJob class so that we can easily push that job to a retriable background queue? — Reply to this email directly, view it on GitHub <#182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZTLY625P3FHK5FFJ4ZHLXLCC6LANCNFSM6AAAAAAZE6GPGM> . You are receiving this because you commented.Message ID: ***@***.***>

[zachfeldman]

Whoops @kennyadsl I forgot your suggestion!

@dhonig that would also help a lot with this problem: running the API call in a retry-able task so we can actually ensure it succeeds, or at least tries again, would go a long way.

[dhonig]

We have someone doing active maintenance on this. Expect a response on this soon ( in the open source world that is reasonably a month or so....)

…

On Tue, Jun 13, 2023 at 12:01 PM Zach Feldman ***@***.***> wrote: Whoops @kennyadsl <https://github.com/kennyadsl> I forgot your suggestion! @dhonig <https://github.com/dhonig> that would also help a lot with this problem: running the API call in a retry-able task so we can actually ensure it succeeds, or at least tries again, would go a long way. — Reply to this email directly, view it on GitHub <#182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZTLZS2B5A2KOEPSQG4CDXLCFFPANCNFSM6AAAAAAZE6GPGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[zachfeldman]

@dhonig just checking in to see if there's any movement on this one? We continue to have to manually send orders every month that don't make it through. Appreciate you considering working on it!

[dhonig]

@zachfeldman Can you elaborate more on 'manually send orders'. This should only happen if there is some other issue. If you can email me at [email protected] I can schedule sometime to consult with you ( likely next week.). Off the top of my had this sounds like its happening because of some other complication. Perhaps we can pool our heads together and see what needs to be done to resolve the issue.

[zachfeldman]

Sure @dhonig just sent you an email to schedule some time!