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

[DivaVocals]

Currently Super Orders doesn't support "true" internationalization for payment types. While we've not done a full analysis of what would be needed to implement this, I imagine that to do this would not only require some re-write/modification of the current Super Orders code, but also a good deal of the core Zen Cart code and possibly some of the payment modules code would have to modified as well to fully implement this..

However, (as the readme indicates) it's easy enough to enter new payment types or modify existing payment types in Super Orders from the Zen Cart admin.. However, in doing this you should note that your new payment types will simply be included in the payment types dropdown. They will not be automatically selected when language 2 is selected.

Additionally for credit card payments (Visa MC, AMEX, etc), Super Orders automatically enters a payment record for payments made with credit cards. It does this when the payment type code matches the credit card type code in the default Zen Cart credit card class file. So if you modify the existing payment types for any of the credit cards take care NOT to modify the payment type code. just modify the display name. You won't create errors if you modify the payment type code, it's just that the automatic payment entry simply won't work and you will have to manually enter a payment record for the order (like you must do for orders paid by checks, money order, etc).

Hallo!

INSERT INTO so_payment_types VALUES (NULL, 1, 'CA', 'Cash');
INSERT INTO so_payment_types VALUES (NULL, 1, 'CK', 'Check');
INSERT INTO so_payment_types VALUES (NULL, 1, 'MO', 'Money Order');
INSERT INTO so_payment_types VALUES (NULL, 1, 'ADJ', 'Adjustment');
INSERT INTO so_payment_types VALUES (NULL, 1, 'CC', 'Credit Card');
INSERT INTO so_payment_types VALUES (NULL, 1, 'MC', 'Master Card');
INSERT INTO so_payment_types VALUES (NULL, 1, 'VISA', 'Visa');
INSERT INTO so_payment_types VALUES (NULL, 1, 'AMEX', 'American Express');
INSERT INTO so_payment_types VALUES (NULL, 1, 'DISC', 'Discover');

This works great for an one-language site.

How could I update the database to get it working on an bilingual site?

I do not really care about the translation. I just need the drop down menu to show the same options if language 2 is selected in the admin area.

I tried

INSERT INTO so_payment_types VALUES (NULL, 2, 'CA', 'Cash');
INSERT INTO so_payment_types VALUES (NULL, 2, 'CK', 'Check');
INSERT INTO so_payment_types VALUES (NULL, 2, 'MO', 'Money Order');
INSERT INTO so_payment_types VALUES (NULL, 2, 'ADJ', 'Adjustment');
INSERT INTO so_payment_types VALUES (NULL, 2, 'CC', 'Credit Card');
INSERT INTO so_payment_types VALUES (NULL, 2, 'MC', 'Master Card');
INSERT INTO so_payment_types VALUES (NULL, 2, 'VISA', 'Visa');
INSERT INTO so_payment_types VALUES (NULL, 2, 'AMEX', 'American Express');
INSERT INTO so_payment_types VALUES (NULL, 2, 'DISC', 'Discover');

but this failed as duplicate entry in the database.

Will the operation of super orders be impaired if I enter new codes in the payment_type_code in order to cater for the translation?

Otherwise, how could I make it work when I choose my second admin language?

Kind regards,
orange_juice

[orange_juice]

Currently Super Orders doesn't support "true" internationalization for payment types. While we've not done a full analysis of what would be needed to implement this, I imagine that to do this would not only require some re-write/modification of the current Super Orders code, but also a good deal of the core Zen Cart code and possibly some of the payment modules code would have to modified as well to fully implement this..

However, (as the readme indicates) it's easy enough to enter new payment types or modify existing payment types in Super Orders from the Zen Cart admin.. However, in doing this you should note that your new payment types will simply be included in the payment types dropdown. They will not be automatically selected when language 2 is selected.

Additionally for credit card payments (Visa MC, AMEX, etc), Super Orders automatically enters a payment record for payments made with credit cards. It does this when the payment type code matches the credit card type code in the default Zen Cart credit card class file. So if you modify the existing payment types for any of the credit cards take care NOT to modify the payment type code. just modify the display name. You won't create errors if you modify the payment type code, it's just that the automatic payment entry simply won't work and you will have to manually enter a payment record for the order (like you must do for orders paid by checks, money order, etc).

Thank you for your prompt reply.

Actually, what happens is the following:

When I am trying to add a new payment in an order, if the English language is preselected, everything works great.

If I select my language the drop down menu for the payment method -in the popup window- will show nothing. No selections at all.

If I go to admin -> Localization -> payment types, I see the same payment types which are also shown in the relevant drop down menu.

If I try to 'edit' them, although the same payment name and payment code appear to both language entries and this is great news ... hitting the 'update' button without changing anything at all, just hitting the 'update' button the following error appears:

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 'where payment_type_id = '1'' at line 1
in:
[update so_payment_types se where payment_type_id = '1']
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.

I do not need the translation. I need it to work in my language because the mail sent to the client depends on the language it is set to the admin area.

Native clients should receive emails in their language ... and therefore I should make it work in both languages.

I would appreciate your help if this is an issue related to super orders and easy to fix, or I would just like to report it as a bug.

Kind regards,
orange_juice

[DivaVocals]

Again, my answer is the same with regards to the internationalization of Super Orders.. While we haven't done any in depth analysis on what it would take to include this support, it appears that it would require a fairly substantial code change to Super Orders and POSSIBLY some core Zen Cart files to implement this. Especially to make sure that the auto payments functionality for credit payments continues to work as it does now.. We've not done any work in that respect and the upcoming release (currently in testing) does not address this.

As for the SQL error you are reporting.. It's been corrected in the upcoming release and is included in the RC2 code we are testing. It's a harmless/nuisance error since it only occurs if you update a payment code when you haven't made any actual changes.

Thank you for your prompt reply.

Actually, what happens is the following:

When I am trying to add a new payment in an order, if the English language is preselected, everything works great.

If I select my language the drop down menu for the payment method -in the popup window- will show nothing. No selections at all.

If I go to admin -> Localization -> payment types, I see the same payment types which are also shown in the relevant drop down menu.

If I try to 'edit' them, although the same payment name and payment code appear to both language entries and this is great news ... hitting the 'update' button without changing anything at all, just hitting the 'update' button the following error appears:

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 'where payment_type_id = '1'' at line 1
in:
[update so_payment_types se where payment_type_id = '1']
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.

I do not need the translation. I need it to work in my language because the mail sent to the client depends on the language it is set to the admin area.

Native clients should receive emails in their language ... and therefore I should make it work in both languages.

I would appreciate your help if this is an issue related to super orders and easy to fix, or I would just like to report it as a bug.

Kind regards,
orange_juice

[DivaVocals]

I do not need the translation. I need it to work in my language because the mail sent to the client depends on the language it is set to the admin area.

Native clients should receive emails in their language ... and therefore I should make it work in both languages.

Have you tried copying over the Super Order language files to the language folders for the desired language?? If you don't need the translations in theory this should work..

I would appreciate your help if this is an issue related to super orders and easy to fix, or I would just like to report it as a bug.

This is not a bug, it is a feature/functionality that currently does not exist.. (BIG difference as a bug technically implies a function that prevents the module from working at all.. Super Orders works, it just does not fully support internationalization features)

[orange_juice]

Thank you for your answers, you are great!

Have you tried copying over the Super Order language files to the language folders for the desired language?? If you don't need the translations in theory this should work..

I have done this, it works mostly, only the issue with the types of payment is currently misbehaving.

This is not a bug, it is a feature/functionality that currently does not exist.. (BIG difference as a bug technically implies a function that prevents the module from working at all.. Super Orders works, it just does not fully support internationalization features)

OK, I understood about the multilingual support.
I was mostly referring to the mysql message which is already solved in the next release of super orders.

Thank you again, you have been very helpful and kind.

Kind regards,
orange_juice

[DivaVocals]

It will show the payment types twice. Since SO doesn't quite support internationalization this is the result.. It's not elegant, but doable though..

Thank you for your answers, you are great!



I have done this, it works mostly, only the issue with the types of payment is currently misbehaving.



OK, I understood about the multilingual support.
I was mostly referring to the mysql message which is already solved in the next release of super orders.

Thank you again, you have been very helpful and kind.

Kind regards,
orange_juice

[orange_juice]

It will show the payment types twice. Since SO doesn't quite support internationalization this is the result.. It's not elegant, but doable though..

It is fairly all right!

Kind regards,
orange_juice

[stevelucky]

I anybody else having problems deleting orders? Recently, whenever I try to delete an order, I get the button that allows me to confirm the deletion, and when I click that, I get taken to a blank page. When I go back into the admin, the order's still there. Has anyone else had this?

[DivaVocals]

I've found out more and None! is displayed in the invoice by some clever logic that is only useful if your are based in the US.
See http://www.zen-cart.com/forum/showpo...&postcount=150 which is where BlindSide explains it more.

By removing the 00-0000000 number from
Configuration > Super Orders > Federal Tax Exempt Number in admin,
the Invoice now displays 0.00% in the Tax Column in stead of None!.
While it's an improvement it's still incorrect and not relevant to the European marketplace in it's current format.

I can't for the life of me see how it can be configured to use VAT so to all intents and purposes it can be 'hidden' for the time being or partially disabled and used for display only of an EU VAT number.

The other option is to call and display the correct rate from the original order (if it is stored). I say from the order rather than the current rate because the current rate may change. While that's fine if you are posting your invoice today it would be wrong if you tried to reprint for example an old invoice and the tax rate had changed from 15 - 17.5% or 17.5 - 20%.

hths

Kevin

Finally had some time to really look into this.. Believe it or not this is not fully a Super Orders issue, but rather a function of how you configure taxes in Zen Cart.

First: The Configuration > Super Orders > Federal Tax Exempt Number in admin doesn't do any validation of the number entered here. The Super Orders logic simply removes the tax display on invoices and orders when there is ANY value set here. So (except for the language used) this feature is not USA specific per-say. So it should work for ANY country/state which supports tax exemption.

All that said, this configuration setting should have a default value of NULL when Super Orders is installed. In the next Super Orders release I will make sure that NULL is the default setting. I will also update the language definitions for this configuration setting so that it is less "USA-Centric". (ie: change "Federal Tax Exempt Number" to "Tax Exempt Number") This should eliminate a lot of the confusion for all shopowners..

Second: Your taxes are displaying 0% because you do not have your Zen Cart tax setup configured correctly. Super Orders invoice/order display and the Zen Cart default invoice/order display will display EXACTLY the same information if you have removed the Configuration > Super Orders > Federal Tax Exempt Number and correctly setup Zen Cart for calculating taxes for your country/state/zone. See if these FAQ articles help:

• My taxes aren't calculating properly. What should I check?: https://www.zen-cart.com/tutorials/i...hp?article=155
• How do I configure the taxes? (US state sales tax - single rate): https://www.zen-cart.com/tutorials/index.php?article=76
• How do I set up VAT?: https://www.zen-cart.com/tutorials/index.php?article=77
• How do I set a default Tax Class for new-products?: https://www.zen-cart.com/tutorials/index.php?article=78

I followed the instructions for setting up USA taxes, removed the Federal Tax Exempt Number from the Configuration > Super Orders > Federal Tax Exempt Number in admin and the problem you describe above disappears. See if removing Federal Tax Exempt Number, and following the instructions for configuring VAT does the same for you..

[RayGabriel]

Hi!

I installed and uninstalled the current release of Super Orders 2. with ZenCart 1.3.9f.

I ran the two uninstall SQLs, and I even erased and restored my Zencart directory with pre-Super Orders installation.

So it should all be gone - right? However, when I use admin to view orders.php, I get the below message. I can't find where the statement is that calls the wrong ORDERS statement

404 Not Found
The requested URL /MYSHOP/ADMIN/super_orders.php?origin=index&page=1&oID=1113&action=edit does not exist.

How do I get rid of Super Orders 2.0 totally and go back to stock Zencart installation?? Thanks so much.

Ray