Re: Super Orders 1.3.9 Tax Error On Invoice
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
Quote:
Originally Posted by
profitshock
I am experiencing the same issues as Centec2b.
Zen Cart version is 1.3.9e
PHP Version: 5.2.x
SO version: 2 - 139
Searching through the posts this issue was bought up with ZC 1.3.8 and due to the amount of activity probably got over looked.
Where 'None!' appears, based on what I see in the ZenCart invoice.php file I would expect to see the tax rate.
As far as I can work out the code affecting this is in super_invoice.php
Lines 239 - 245
Code:
if ($display_tax) {
echo zen_display_tax_value($order->products[$i]['tax']) . '%';
}
else {
echo ENTRY_NO_TAX;
}
echo '</td>' . "\n" ;
The corresponding code (as far as I can tell) in invoice.php is
Code:
echo ' <td class="dataTableContent" align="right" valign="top">' . zen_display_tax_value($order->products[$i]['tax']) . '%</td>' . "\n" .
The only thing I can think of is that the if($display_tax) in SO is not finding or reading the tax code but I wouldn't know where to fix it.
Given that the original invoice.php file uses other ZC functions to determine the tax rate etc I have to wonder why the 'if' statement exists at all. Is there a reason specific to SO ??
In my case the pricing of the tax calculation works fine so it is just a display issue in the product lines.
Super Orders 2.0 Rev49 RC1 being tested!!!
At long last I've got everyone's code compiled into our RC1 version..:clap: We're testing it now, and hopefully we'll be able to submit this soon.. Stay tuned!!!
Highlights include:
General updates
- Incorporate commenting updates from the default Zen Cart orders.php (most notably the hidden "admin only" comments functionality)
- Correct errors with downloads flags not setting correctly
Edit Orders
(http://www.zencartmod.com/index.php?...&products_id=3)
- Install package includes the modified files needed for those who use Edit Orders. (you must install Edit Orders BEFORE using these files)
- We've made a few improvement to the Edit Order files as follows:
- Incorporate commenting updates from the default Zen Cart orders.php (most notably the hidden "admin only" comments functionality)
- There is now one button to take you back to to the Super Orders order details page for the order you are adding products to and another new button to take you back to the Edit Order page for the order you are adding products to.. (Currently in Edit Orders the "Add Products" section only has a "Back" button that returns you to the order details page for the order you are adding products to..)
Reporting & Order Update Improvements
- Improved orders awaiting payment report
- PDF printing options included in batch printing
- Additional search options for Batch printing/update functions
Super Orders Payments Improvements
- For orders paid with PayPal the store owner is no longer required to manually enter a payment in Super Orders. Super Orders will now automatically enter a payment record and show these orders as paid without requiring the store owner to enter a manually enter a payment record.1
Split Orders Improvements
- Splitting an order now results in a “parent order” (original order number) and a child order (new order number). The resulting parent and child orders cannot be split.
- Super Orders now correctly re-calculates BOTH the parent and the child order when an order is split. (The original shipping charges stay with the parent order)
- If an order is paid in full, the split order function will distribute the payment correctly across both the parent and child orders so that you end up with two fully paid orders which true up to the amount of the original order amount.
- The original payment information is displayed on both the parent and child orders. This display shows the original grand total paid. ($ Parent + $ Child = Grand Total)
- For split orders paid via PayPal the “empty” PayPal payment notification data panel will no longer be displayed on child orders.
- The split order packing list button now appears ONLY when the order is either a parent order or the resulting child order -- otherwise it will NOT display.. (Currently it displays on EVERY order when the order includes multiple items)
- The split packing list details has been fixed to function as it was originally intended (but did not).
- The packing list for the parent order displays the FULL original order with the items that were moved to the child order flagged as "Product(s) will ship separately"
- The packing list for the child order displays the FULL original order with the items that remained on the parent order flagged as "Product(s) will ship separately"
About PayPal Payments:
1 There are a number of threads on the Super Orders support thread which discuss a number of methods for automating PayPal payments. Some of these methods include automating refunds as well. We chose not to implement any of these solutions or variations of them in order to maintain a level of consistency when it came to the module’s basic "out the box" functionality. This keeps the application functional across a wide variety of stores. While other payment methods (notably the Offline Credit Card Processing and Authorize.net modules) did not require the entry of a payment record, payments received through the PayPal payment module required shop owners to manually enter a payment record in Super Orders. (hence the reason for this change)
Furthermore, Super Orders does not include automated refunds processing for any other payment module (such as Authorize.net). Including automated refunds processing for ONLY the PayPal payment module while ignoring other payment modules would be building in a level of inconsistent functionality for a module that will be used by MANY different store owners each with different needs. Therefore the application's consistency was the guide in how this function was implemented.
That said, I fully recognize that there are shop owners who may want this specific functionality (automated refunds processing) for their particular store. There are lots of threads which cover how to add automated refunds for PayPal paid orders, and owners requiring this functionality should seek out those posts and see if they can adapt the suggested code for their needs. (I cannot offer any assistance in this regard)
