8 replies [Last post]
suydam's picture
Offline
Joined: 06/16/2008
Juice: 24
Was this information Helpful?

My goal: Add some fields to the form uc_cart_checkout_form so that later, when reviewing and processing orders, I have more information than the existing form provides.

I'd like to do this without hacking the core modules because that would break my upgrade path.

I can use hook_form_alter() to add the form fields pretty easily.
I can roll my own submit function into the chain so that I can grab those fields out of the form and store them.

The problem is, I need the order_id.

Now, in hook_order() I can easily get that order information out of the order object. No problem there.
That gives me access to the order_id.

The issue is, I don't know to blend the two.

When I have the order_id, I don't have the form values.
When I have the form_values I don't have the order_id.

Help? Smiling

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: hook_form_alter() vs. hook_order()

Well, in trying to preserve flexibility/extensibility with the checkout and order systems separately, I overlooked making it easy for developers to connect information between the two. Sad

What it takes is:

  1. A checkout pane defined by hook_checkout_pane() to handle adding and processing the fields through the checkout form. This is also where the fields can be added to the order object. For small bits of data that you won't ever need to search/list separate from the order view page, I recommend adding the data to $order->data. Otherwise you'll need to implement hook_order() to actually save the data with the order once the checkout pane adds the data to the order object.
  2. An order pane defined by hook_order_pane() that governs the display of the information on the order view pages (and form fields to edit the data on the order edit pages).

The Lead Tracker contribution is the closest thing we've put out to an official example of how to do this.

suydam's picture
Offline
Joined: 06/16/2008
Juice: 24
Re: Re: hook_form_alter() vs. hook_order()

So there is no way, from within hook_form_alter() on a form that knows about the order, to actually fetch the order ID?

Any plans for that in the future? It should would make things easier!

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: Re: Re: hook_form_alter() vs. hook_order()

I guess it just depends where you are... in some cases, the order ID is in the URL. In other cases it's stored as a hidden value. Sometimes, it's in the session. It should certainly be standardized, and I'd hope to do it during the Drupal 6 cycle.

goatvirus's picture
Offline
Joined: 12/03/2009
Juice: 52
hey Ryan well, this is

hey Ryan

well, this is slightly off topic but i believe the cause of my grief here is very similar to what prompted @suydam to start this thread (please correct me if i'm wrong!)

we are trying to calculate a state sales tax (for South Carolina) that actually changes according to which County you are in.

there is a similar issue with Florida (see http://drupal.org/project/uc_taxes_floridasurtax) but with Florida, the ZIP code will definitively tell which County the address is in. therefore, no extra address fields are needed, the ZIP code is enough.

with South Carolina on the other hand, some ZIP codes are spread over two or even three different Counties, so the ZIP alone is not enough. therefore we decided to just add a field for County, and only make that field appear (and be required) if state is South Carolina. that;s just basic DHMTL and some code in the form_alter hook, not a problem.

the problem comes with: how do you then take these form values and get them into the order? when the $form and $form_state arrays from standard Drupal form hooks DON'T contain the order ID or the order object? at least not for the uc_cart_checkout form, which is where we need to do this?

well, after a bit of digging through the code, i DID manage to find a way to get the County value saved to the serialized "data" field in uc_orders: by adding a 2nd form validation call to uc_cart_checkout (since the first validation call actually creates the order in the database), this code is getting the order id from $_SESSION['cart_order'] and then reading the order from the table, adding my county stuff to the "data" array, and saving it back to the table.

the problem: this doesn't happen soon enough, the $order value passed in to the _calculate_tax hook is not containing the data that i saved!

also, i am guessing that there is some AJAX involved in the page (ie: /cart/checkout) that contains the uc_cart_checkout form, because even if the form hasn't been submitted yet, the AJAX for shipping rates is also calculating the tax and showing both in the "Order total preview", based on country and state, etc. am i right?

so does that mean that the only way we can reliably calculate a tax based on a new user-defined address field (ie: County) is to go into the ubercart core modules code for uc_cart and uc_order (and who knows where else), and modify them to pass county around as another predefined address field, just like delivery_zone, delivery_country, etc. ?

or is there another way? if there is, i'm all ears!

cheers
Peter Fisera
http://goatvirus.com
http://earthangelconsulting.com

adTumbler's picture
Offline
Joined: 08/22/2010
Juice: 23
Calculating Tax

Peter

I am doing some work with a company who specialize in calculating sales tax

I am in California, who may only be second to new York in the complexity of doing this.

The idea is to create a module that will; call their soap API with a to and from address - and have them send the correct tax rates back.

There will be three versions (we hope)

1) A no cost version for up to some number of transactions - for start up businesses who need help to get going

2) A more complete implementation with line item tax rates, them saving tax data for the many tax districts - needs integration order status

3) An accountants dream, where they get the lines, do the tax calculation, store the data, and carry the liability for the tax errors

It seems that implementing the logic for taxation across 50 states is possible, but I am not sure that keeping the rules maintained is a productive use of development resource. I see it like having a module that works with paypal - saves me handling all the payment issues - but I pay per transaction.

let me know if this sounds useful

Alex

Lance Brown's picture
Offline
Joined: 02/10/2010
Juice: 13
Needed for North Carolina as well

Greetings,

I'm facing the same problem in North Carolina. We, too, have several counties that add on additional tax and zipcodes that don't align with county borders.

How is your work coming along? I have a client that recently opened their storefront and are eager to get their online store going, but I'm struggling with handling the state/county tax issue.

--[Lance]

Lance Brown's picture
Offline
Joined: 02/10/2010
Juice: 13
SUCCESS, after a fashion

Gads, this is krufty, but it worked.

I added a 'county' field using the Ubercart Extra Fields Pane module, edited the 'serializeOrder' function in payment/uc_payment/uc_payment.js to include the ucxf-county variable in the json it submits, and added a JS call to set a '.change(getTax)' trigger on the ucxf-county input select html tag.

I was then able to refer to $order->uxcf_county in the Tax rules using an 'Execute custom PHP code' condition to select the correct state/county tax rate.

This is extra nasty, and I hope to modularize it soon, or something, as it is quite unmaintainable, but it works.

--[Lance]

bettisfr's picture
Offline
Joined: 12/21/2011
Juice: 25
I need your code!

Hi Lance, I have the same problem (is a bit different but it is semantically the same)... can you paste your code here?
I need to see the serializeOrder() and the .change(...) functions.

Moreover, if you want to upgrade ubercart modules, the process will replace all edits?