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

The invoice on super orders doesn't show the complete shipping method field as it does in the regular orders invoice. For instance, SO shows United States Postal Service: and the regular orders invoice shows United States Postal Service (Priority Mail):. Have I missed something during installation or is something I need to modify and if so, what file(s). Thanks.

Quote:

---

Originally Posted by BlindSide

The problem others have posted about occurred during system installation; your problem sounds like it's post-install, right?

Anyway, if you look at the so_payment_types table, you'll see there's a unique requirement on the payment_type_code field. If you are trying to insert a PayPal payment type, and already have one for another language, you need to make sure that you don't use the same value for the shorthand code.

---

It's a post-install problem, since I only started testing the mod after installing my test shop.
The language system gives three alternatives for three languages when adding a payment method, so I did the insertion only once. The code is the same in all languages. That's how it works for ZC.

Right, but payment methods are not a language-specific entity. The admin (currently) works off of a single language selection, and customers do not see these payment records. Hence, there was no need to add a language selection to the mix.

Should it be ideally? Sure. I'll make a note of it for a future release.

Quote:

---

Originally Posted by rollerdude

The invoice on super orders doesn't show the complete shipping method field as it does in the regular orders invoice. For instance, SO shows United States Postal Service: and the regular orders invoice shows United States Postal Service (Priority Mail):. Have I missed something during installation or is something I need to modify and if so, what file(s). Thanks.

---

No, the parenthesized section of shipping methods is being actively stripped out. It was a problem for the company I worked for when SO began, caused confusion on the part of customers. There's a number of posts about how to revert it. Do a quick search on the thread and you'll find it.

This quote comes from my offline conversation with Maurice. I thought others might find it enlightening.

Quote:

---

what are the "Order Completed' and "Order Cancelled' buttons supposed to do?

---

The "Order Completed" and "Order Cancelled" buttons were added to increased the finality of a finished order. The standard Zen Cart statuses are simply numbers; any value attached to them (beyond settings for downloads) are based entirely on the shopkeeper's office practices. In other words, there was no way to call an order "done" in the confines of the system; it depended entirely on everyone who managed orders to follow the same rules. If one person screwed it up (i.e. assigned the wrong status for a completed/cancelled order), the whole thing would flop. In addition, some of the SO reports could potentially report erroneous values if canceled orders were included in the tallies (read: your bookkeeper's worst nightmare).

Enter these special buttons. They still assign an order status, however they also set special flags in the order table. With those separate flags in place, the status can be anything, and the order still maintains some sense of closure.

Quote:

---

Originally Posted by BlindSide

Right, but payment methods are not a language-specific entity. The admin (currently) works off of a single language selection, and customers do not see these payment records. Hence, there was no need to add a language selection to the mix.

Should it be ideally? Sure. I'll make a note of it for a future release.

---

SO did ask me with boxes in three languages, what payment method I would like to add. There was nothing I could do except fill in the boxes.

[reviewing code]

By george she's right! Jeez, how long has it been since I touched this file? Run this SQL statement over your DB and the problem will be solved:

Code:

---

ALTER TABLE so_payment_types
  DROP INDEX type_code_2,
  DROP INDEX type_code,
  ADD UNIQUE idx_unq_payment_type ( language_id , payment_type_code );

---

Good catch, Heidi, and sorry it took me so long to get there. :bigups:

@everyone: This fix has already been incorporated into the installer for 2.1. Make the change if you need to, otherwise you can wait for 2.1.

Thanks BlindSide, I tried to patch the SQL by copying the code and got this:

1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
in:
[show index from ]
If you were entering information, press the BACK button in your browser and re-check the information you had entered to be sure you left no blank fields.

Server OS: Linux 2.6.9-67.0.7.ELsmp Database: MySQL 4.1.22-standard
PHP Version: 5.2.6 (Zend: 2.2.0)

I'm eagerly waiting for version 2.1!

The query does not appear to work with the "SQL Query Executor" tool in the Zen Cart admin. However this is definitely a valid query for the server information that the page displayed.

Do you have an alternative DB management tool, like phpMyAdmin? Your host almost certainly provides some interface to your databases via Cpanel or Plesk. I always recommend that you use those tools whenever possible, as the SQL tool in Zen Cart does have its moments.

Thanks Frank,

I'll try that later. It's way past midnight now.