OLD Super Orders 2.0 (See v3.0 thread instead)

Quote:

---

Originally Posted by MikeyG

I have at last gone live with my upgrade so on version 1.3.7 Yippeeee!

However couple of small niggles.

First one I have posted above regarding the error when using the batch update status.

---

First off, congrats! The first one is always the hardest.

Yeah I looked at that one. I think it has something to do with the structure of the table. Try this: open admin/includes/functions/extra_functions/super_orders_functions.php and scroll down to the function update_status(). After the call to global $db (first line inside the function), add the following code:

Code:

---

  if ($notified == '') {
    $notified = 0;
  }

---

Upload and see what you get.

Quote:

---

The second question is regarding the payment gateway and how do I get orders placed using a credit card over the web through the protx gateway to come up in Super orders with the payment details and status as paid.

If I have missed the instructions some where I apologies. I am hoping that I do not have to enter the payment details for every order that goes through the web sight and protx okay.

---

Someone PM'd me with the same question, just for a different gateway. The answer is the same: you need to get your payment gateway to input the payment data to the Super Orders tables. If the gateway uses the cc_ fields in the `orders` table, this should happen automatically if you properly modified the catalog-side order class as described in the readme.

If it does not use those fields, then you need to do a little coding (emphasis on the "little"). Open includes/classes/super_order.php and take a look at the function cc_line_item(). There you'll find the logic to add lines to the SO payment tables.

Make a copy of this function, rename it, and simply modify it to look at the payment information created by your payment gateway, instead of the stuff in `orders`. Finally, replace cc_line_item() with this function in the catalog-side order class. I hope that doesn't sound more complicated than it is; all you need is some PHP knowledge.

Quote:

---

Originally Posted by aeolidia

I installed super orders on a 1.3.7 site and everything is working fine in the admin, but when you click to confirm your order (last stage of checkout), you get this error:

Fatal error: Call to a member function on a non-object in /home/blablabla/includes/classes/order.php on line 891

When I remove the chunk of code needed for super orders from order.php, the order goes through just fine.

Here is the code that seems to be causing me trouble:

Code:

---

// BEGIN Super Orders edit
// add CC data as a line item to SO payment system
if (zen_not_null($this->info['cc_type']) || zen_not_null($this->info['cc_owner']) || zen_not_null($this->info['cc_number'])) {
  require(DIR_WS_CLASSES . 'super_order.php');
  $so = new super_order($insert_id);
  $so->cc_line_item();
}
// END Super Orders edit

---

I'm stuck! Thanks.

---

Sounds like you didn't upload the super_order.php class to the catalog. The class needs to go in admin/includes/classes/super_order.php and includes/classes/super_order.php. The module download has the file in both places, you just need to upload the whole thing (i.e. not just the "admin" folder).

Quote:

---

Originally Posted by BlindSide

Sounds like you didn't upload the super_order.php class to the catalog. The class needs to go in admin/includes/classes/super_order.php and includes/classes/super_order.php. The module download has the file in both places, you just need to upload the whole thing (i.e. not just the "admin" folder).

---

Mysterious! I uploaded all the files when I installed and I just now double checked my /admin/includes/classes and /includes/classes folders and both have their own super_order.php file. Is there anything else I should be looking at?

What does the code chunk that goes on order.php do, exactly? If I can't solve it, is it safe to leave it out?

Apologies if this has been asked (though I did a quick search)...
With the 'purchase order' option is there a way to modify it so that a 'purchase o/n' (text) field appears below the relevant payment option. Thus would allow the customer to enter a purchase order at time of order instead of requiring them to send a fax (or similar) and admin add the p/o number manually.

Quote:

---

Originally Posted by aeolidia

Mysterious! I uploaded all the files when I installed and I just now double checked my /admin/includes/classes and /includes/classes folders and both have their own super_order.php file. Is there anything else I should be looking at?

What does the code chunk that goes on order.php do, exactly? If I can't solve it, is it safe to leave it out?

---

The block of code needs to appear after the following line...

Code:

---

  $insert_id = $db->Insert_ID();

---

If the $insert_id (i.e. the new order number) is not set when this code is called, that will result in the error you are seeing. If the code is in the right place, and the class is in the right folder, it will work. Double-check your entire setup.

Quote:

---

Originally Posted by Broll

Apologies if this has been asked (though I did a quick search)...
With the 'purchase order' option is there a way to modify it so that a 'purchase o/n' (text) field appears below the relevant payment option. Thus would allow the customer to enter a purchase order at time of order instead of requiring them to send a fax (or similar) and admin add the p/o number manually.

---

You could probably modify the code to collect it, but at this point it's not built in. I added the PO feature for my company, and left it out on purpose. And though it's beyond the scope of your question, I thought you might want to know why...

• Collecting the PO at checkout means that the customer must have the PO in advance. Some businesses don't release a PO until they have an invoice, which they get after going through checkout.
• Some companies are just abhorrently slow at processing PO's, and the individual could miss out on a product you have in short supply.
• The customer could enter the wrong number, either by mistake of the billing office or the customer. No offense to the customer, but I know my employees will enter the right number more consistently.
• Finally, I'm always looking for ways to eliminate hurdles between my customers and the products they want. Requiring a PO number for PO orders won't deter most users, but why settle for "most" instead of "all?" I don't want to lose that "other" group that does go somewhere else because they don't have a PO number, and/or don't know how to immediately get one.

Dealing with schools and school districts, I've learned that everyone who uses a PO billing system does things a little bit differently from everyone else, and the best solution is to code for the most common denominator.

Blindside,

Thanks for the code on the update status. Seems to have done the trick.

I have been through the class files in the read me and all the code is in place as described, but it is not updating the info as described so I need to look a the payment gateway bit - however not too sure where to start. I am using the protx form mod by conor.

I can understand some of the logic but I am not programmer so losts as to how to amend. Sorry! I hope you can point me in the right direction.

Many thanks for all your invaluable support / help.

MG

i'm trying to install the
-- Super Orders configs (Admin > Configuration > Super Orders)
-- Automatic Status Updating

but i keep getting this error #1146 - Table 'XXX_XXX.configuration' doesn't exist

i'm half way in inserting these configuration codes manually but i'm noticing these errors poping up in the admin/configuration/super orders area. do i have to worry about these as i'm still not finished upgrading the configuration sql file

the warming is

Warning: call_user_func(zen_get_order_status_name ): First argument is expected to be a valid callback in /home/www/gorillagear.ca/store/admin/includes/functions/general.php on line 1528

Warning: call_user_func(zen_get_order_status_name ): First argument is expected to be a valid callback in /home/www/gorillagear.ca/store/admin/includes/functions/general.php on line 1528

ok i have 3 of the warnings stated above in the admin area as stated above and my i still get a NONE! in the tax columns on the invoice but my federal tax id comes up allright.

Blindside,

I have spotted another issue which has been posted a few pages back in post 488 I think, which was that when notifying the customer using batch update, the update occurs but no emails are sent and the notify customer field in each of the orders has a red cross despite the notify customer field being ticked.

Has this been fixed?

Regards

MG

Quote:

---

Originally Posted by BlindSide

Yeah I looked at that one. I think it has something to do with the structure of the table. Try this: open admin/includes/functions/extra_functions/super_orders_functions.php and scroll down to the function update_status(). After the call to global $db (first line inside the function), add the following code:

Code:

---

  if ($notified == '') {
    $notified = 0;
  }

---

Upload and see what you get.

---

Unfortunately I've tried this still with no luck!!

Thanks for trying.

Craig