Tax Provider methods and Order administration

[nickc]

I'm building a tax provider for Avalara AvaTax and have the basic shopping experience working, handling multiple shipment sources, destinations, discounts, coupons (including per product/shipment application), etc. - so far so good ...
but ...
changes made in order admin do not call any of the methods in the tax provider implementation. I suspect that these methods are only invoked by a Basket object. Before I get started on building a reconciliation tool for admin changes to orders - is there a way to (easily) bind TaxProviderBase Calculate/Commit/Cancel methods to operations on Order objects?

Any and all speculation encouraged.

Thanks,
-Nick

[Logan Rhodehamel]

Is the intent for redistribution to others, or just for your own purpose? This might affect some of the suggestions.

It might be a good idea to extend our interface to include versions of those methods that accept orders as parameters. In fact I'm going to log a bug so we can think about that in the future.

[nickc]

It's entirely possible that we would make the provider available to others - so encapsulation in a single .dll would be nice. I've built private methods that build up tax lines, get tax codes, update Able tax Items, etc. to be object agnostic - they'll work with either Basket or Order - so adapting the public methods would not take much.
That said, I want this implemented in a couple of weeks, so for now consider this a private effort.

[Logan Rhodehamel]

If it's distributable, I wouldn't recommend trying to modify TaxProviderBase and/or ITaxProvider interface.

I would say in the modifications to the admin order pages, try to directly cast the tax provider as your custom class. Then access the methods using the strongly typed variable. You can see examples of this in our shipping gateway admin pages.

Something like:

MyTaxProvider myProvider = acITaxProviderInstance as MyTaxProvider;
if (myProvider != null) ...

Your customizations to the files will be needed to make the integration work, and they will be specific to your provider, so it isn't necessary to stay too generic.

Does this make sense?

[nickc]

There is no instance of a tax provider operating in EditOrderItems.aspx.
I'm guessing the tax calculation is called during _Order.Save(), or in my case not at all, as no tax rules are bound to tax codes in the database.
As there is no final "save changes to this order" operation in admin order editing, I'm thinking a separate "reconciliation" page that aggregates all changed orders in a grid and allows selective commits is the way to go at this time. Thoughts?

[Logan Rhodehamel]

Tax calculation takes place in Basket.Recalculate method, and the ITaxProvider.Commit method is called by Basket.Checkout.

Off the top of my head you can do something like

Code: Select all

MyTaxGateway mtgw = null;
foreach (StoreTaxGateway tgw in Token.Instance.Store.TaxGateways)
{
if (tgw.Name == "MyTaxGateway") mtgw = tgw.GetProviderInstance() as MyTaxGateway;
}
if (mtgw != null) ...

if you need to obtain the configured instance of your custom tax gateway.

[nickc]

Tax calculation takes place in Basket.Recalculate method, and the ITaxProvider.Commit method is called by Basket.Checkout.

There is no spoon^H^H^H^H^Hbasket.

That's the problem in this context - only the Order object is present.

[Logan Rhodehamel]

That's the problem in this context - only the Order object is present.

That's why ITaxProvider interface won't be useful to you here. Instead you want to cast your tax provider instance to the strongly typed custom class you are creating. On that class, you would define versions of Calculate and Commit that can work against an order reference. Then those can be called from the edit order items page (or your reconcilation page, etc.)

We do similar things within the Shipping Gateway configuration pages. Some tasks (usually with regard to registration) are not generic. We cannot get what we need from IShippingProvider interface. So we have to work with the integrated provider class directly, then we can access specific methods that are not part of the interface.

[nickc]

Ah. We're saying the same thing in different ways.
I'm a little concerned about the noise level of an order edit - every change will have to be calculated/adjusted/committed immediately as I have no way of knowing when the edit is done. Still, I was going to have to create something to deal with my method of handling failed credit authorizations, so this will be consistent with those requirements.
Thanks, especially for the pointer on getting an initialized instance of the tax provider - I would never have discovered that.

-Nick