Module execution order

[Mike521w]

I'm working on a module that I want to modify the sales tax basket charge. I want Miva's state-based sales tax to continue working, and ideally my module will overwrite that entry when needed. I'm not very experienced with miva modules but I can manage to tinker my way through creating them when needed. In this case though, the module works fine if I add the charge as something other than tax - but when I make it type tax, it *seems* not to do anything. I think what's really happening is it's working fine, but then state-based tax overwrites it.

Is there any way to control the order so my module will only run after state-based runs?

[Bruce - PhosphorMedia]

If you haven't. I believe you'll have to create your module as a "Tax" module. Being that it would be installed AFTER Miva's Sales Tax module, the functions in that module will run second. Relying on a System module's System_Action wouldn't work because that runs BEFORE actual actions (i.e., triggered by CTAX) are run. (At least, that's what I've always assumed.)

[Kent Multer]

A store can only run one tax module at a time. I did once write a "pass-thru" tax module that could call another tax module in a nested fashion, but that was kind of an extreme case. A more standard solution in this case would be to write a log module to be triggered by the CTAX action. Log modules are called after the store processes the action, so the tax charge will be in the basket at that time. And "log" modules aren't restricted to just writing log files; they can do all kinds of other jobs.

I'll also mention that I have a utility module that can be used for jobs like this, performing custom processing before or after a system action. If you get tired of tinkering and want a quick solution, you can drop me a line about that.

[Bruce - PhosphorMedia]

That would be for a pure tax module, put couldn't you add the tax module functions to say a module that registers as a utility module? What about using an 'extension' to the tax module?

[Kent Multer]

Well, hmmm, I suppose it's possible that some of those ideas might work. But the Store Settings admin page still has just that one dropdown menu to select a tax module, so I think the only-one-module restriction still applies to the CTAX action. All the modules in that menu are registered as tax modules, but the store only calls one of them. Extensions are just for component modules, not for other types; extensions don't get triggered by Action codes like CTAX. But come to think of it, now that Store Morph has mvt:do, it's possible to do all kinds of tricky things with template code on a checkout page, by making use of code within the store. I'm not sure if that would work in this case; and even if it would, there are side effects to consider that make the complete solution more complex. It's not a great practice to have that kind of critical code sitting around on a page template, where one slip of a mouse could produce a serious problem.

HTH --

[Mike521w]

Thanks Kent and Bruce - actually I have the module set up in two ways. First is how I described it above, with the idea that it will run side by side with the store's state-based tax module (but as mentioned, that's not working how I wanted).

The second way is as the store's actual tax module, replacing the state-based tax module. This actually works fine, but the only thing I don't like about it is it automatically removed state-based tax from the store when I installed it, and I see no way to re-install state-based if I wanted. Maybe I'm missing something obvious there..? For example if I look at the state-based module under the modules screen, it shows that it's assigned to 0 stores.

I don't expect to switch back to it, but still, I don't like the idea of removing a built-in module with no clear way to replace it..

[Mike521w]

nevermind, I found it! It's under store settings > settings > sales tax calculation. Haven't looked there in years so completely forgot about it

[alphabet]

I wrote a small PRE_ACTION store morph code that rewrites the s01_StateTaxStates table with correct rooftop state rate values based on zip+4 tables.

I discovered that each Action, SHIP PSHP CTAX , triggered the PRE_ACTION so unfortunately for now it makes three table writes but it works. I tried, but could not discover how to rewrite on just the third iteration.

My first thought was to use a POST_ACTION but I used PRE_ACTION because I couldn't get the store morph to pass the globals to OPAY when I executed the code as a POST_ACTION.

But I can use a POST_ACTION to rewrite s01_BasketCharges table if logged in customer is tax exempt. I have a custom customer boolean field that indicates tax exempt on OSEL page.

So it seems that a Store Morph PreAction will execute in a different order than a System_Action.

[Mike521w]

I didn't even know POST_ACTION and PRE_ACTION existed - pretty cool.

I actually finished the module I was talking about above as a Tax module to be used as a replacement for the state-based tax module. So instead of overwriting the state-based tax charge, it's completely responsible for it.

[RayYates]

For posterity if you need to modify the way an existing tax module works, you can do it with a log module. That runs last, after the store actions but before the page loads. That's what the POSTACTION process is doing.