and exactly HOW would one add a coupon to the order in an order editing module without manually entering it????
If you are going to suggest a feature.. it would help if you could explain how it should work.. IJS..:smile:
Printable View
Hoping someone can help me out here. It has everything to do with this module and a little with another I am working on. Basically I am trying to generate a sales report that is accurate in it pulls the sales data from the orders_total table. Currently the sales report plug in pulls from the orders table and then recalculates the price on every order. This is causing me huge inaccuracies. So I have redone this report to pull from the table I need. It is accurate to the penny every time it is run. However, the inaccuracy comes when an order is edited. I am thinking this is because it updates the orders table and not the orders_total table. Is there an easy way to get the edit order module to update the orders_total table as well? Specifically I am looking to update the fields that appear starting with subtotal and go down to total. ie sub-total, shipping, sales tax, discounts, and total. Can anyone please help me out with this?
Thank you in advance!
I would agree! As you can see in my question I tried to be very specific in what I wanted. Hopefully someone can help me out! :)
Sometimes I think maybe I am too specific because I don't always get the help I need. Other times people bend over backwards to help out. The times they don't it seems I have asked for a too specific of a need.
I have figured out my question after a few hours of studying this. I was given bad information by a programer that charges. Imagine that!
Can you elaborate on what exactly is inaccurate (with Edit Orders)? Do you have any 3rd party order total modules installed? Was the order created at a time when ot_subtotal or ot_total were disabled (and then later edited)? Was the order previously edited by a version Edit Orders 4.0 (or older)?
Edit Orders 4.1 (and newer), does update both... It actually REQUIRES the order total modules ot_subtotal and ot_total to be installed and enabled (at this time) as it utilizes the values of these two modules. Further it loads and processes any enabled order total modules against the order (when editing) to ensure they are updated (and doing the math automatically).
Edit Orders 4.0 and earlier did their own calculations (and direct mysql calls to access the tables). They did not load or utilize the order total modules (although they did write to the database table). Using these older versions may require the store owner to do their own calculations and math... And then enter the correct information in the various fields.
My best guess too...
Would the cost (money and risk) really be worth the benefit? Especially considering how easy it is to navigate coupons already using the built in Zen Cart coupon admin page?
Store owners can use "admin" --> "gift certificate / coupons" --> "coupon admin" to look through the available coupons for their store. This existing tool lets them page through coupons very quickly to find the coupon they want to apply to an order. This tool also shows all the settings on each coupon and what the coupon does when applied to an order.
If the customer did not enter the coupon (or provide the coupon information if they called in) why would a store owner erode margin further (by spending the time to see if a valid coupon exists and then applying a discount coupon to the order)? Why even bother with a coupon if this case? Just lower the cost of the products if you plan to give every customer the discount... Or use the "group discount" modules... Or shell out the $$ for some of the order total discount modules written for Zen Cart...
<rant>
A dropdown with coupons could be problematic, especially on mature stores with a large number of coupons and gift certificates / vouchers (both are stored in the same database table). Would you really want potentially hundreds of items in a dropdown?
Next I'll hear "just filter them to ones which are applicable to the order"... So now you want to add additional processing time for each and every coupon? Not to mention issuing a considerable number of SQL queries? All needing to be performed EACH AND EVERY time the order is loaded (or edited) in Edit Orders?
Okay, and now that we have filtered the coupons... How do you know which coupon does what? Sure you have the coupon name in the dropdown, but it is only a name (and is not required to be unique). Coupons in Zen Cart can be applied in many different ways and contain many different settings...
So even with this "dropdown", in order to know what a coupon does (without applying it to the entire order and starting over back at the first paragraph), a store owner would need to go to the Zen Cart coupon admin page to see what the coupon does. So in this case, no time has been saved (quite the opposite actually)...
Add on top of this all the coding required to support such functionality (everything above, AJAX code for selection, PHP handlers for fallback when JavaScript fails or is disabled, etc). And now what happens if ot_coupon is changed in a future version (in order to filter the coupons we needed to directly use a method from this order total module)?
Who is going to PAY for the cost required to implement and maintain a coupon dropdown? Especially given the limited
</rant>
The only application I could envision something like this occurring is if say a discount is offered on a specific day for example, and the system went down for a period of time, but orders were still being manually processed to be updated later. Regardless, would think that such a coupon could be incorporated into a sale type situation instead or some other method, and that the quantity of such orders hopefully would be limited to a small number. And in that case would agree that the cost would seem high in comparison to the manual entries needed to catch up. (I use the term manual loosely though as there could be ways to populate en mass.)