jsalis

I have older versions of this contribution working on two different carts, but I am trying to get 1.5 working now on a third cart. Everything appears to work OK except adding addresses to the address book, and editing addresses in the address book. These two functions work, but they don't work OK. The edits take place on the server side (and the new addresses are inserted), however; despite the a 200 OK with a response of { "success": "true", } The following code block in the checkout.php file (around line 601) onePage.queueAjaxRequest({ url: onePage.pageLinks.checkout, beforeSendMsg: 'Updating Address', dataType: 'json', data: $(":input", this).serialize(), type: 'post', success: function (data){ onePage.loadAddressBook($this, addressType); }, errorMsg: 'There was an error saving your address, please inform <?php echo STORE_NAME; ?> about this error.' }); Is returning the errorMsg rather than completing the success function. I have gone through all the applicable code and cannot find any reason why this would happen. If I close the alert and close the dialog then click change address I can see that the changes were in fact saved despite the error message to the contrary. Furthermore once the new address has been added or edit made I can simply click the radio button of the address I want to change to and then click confirm and it changes it without any error message. Any help would be greatly appreciated.

I had time to look into the form field validation issues I was having and discovered the following: 1.) There apparently are validation scripts that do at least the minimum checks (ie. min. length) 2.) These functions are not being called and form data is going straight to the AJAX function. I put an alert in each of the three validation scripts I found (getFieldErrorCheck(), checkFieldForErrors(), fieldErrorCheck()) and none of the alerts came up. 3.) Apparently you should be able to force validation on a field by adding the class name "required" to an input, though I tried this and it did nothing. I imagine there would also have to be an entry in the getFieldErrorCheck() function which in my case there is. 4.)fieldErrorCheck() appears to be called on the various fields from the attachAddressFields() function, but in my case this call is not being made. Does anybody have any pointers here?

Duh! It might help some of you if I actually provide the link I spoke of. Here is the link to the fix for discount_coupons.php

I think I follow what you are saying, but that is not exactly what I am doing. Possibly we have different taxation requirements, I am in California, here we are not taxing shipping, the shipper taxes us we pass the entire cost of shipping along. The shipping company pays the tax to the state. Anyway I have a product store and a sandbox setup with completely different checkout systems right now. The production store has the default multi-page checkckout and the order total information on a test order I just created looks like this: That is a ten percent discount. The Priority processing is not taxable and specifically excluded from the discount. Note that the batteries are taxable and the tax rate is displayed, but not included in the line item total. The discount is displayed above the subtotal in this case, so I display the subtotal with the discount applied. Then shipping (calculated on the prediscount subtotal) and tax (calculated on the post discount subtotal of taxable items only) is added and a total provided. This meets local requirements. And unless my calculator has issues it is calculated correctly every time. Though I don't think this is exactly the arrangement you are speaking of. Next is a shipping discount. This is not as pretty, but definitely accurate. The order total module and discount module do not work together well enough to change the sort order of the discount line only when a shipping discount is applied. Since it is rare that we offer shipping discounts I went with above the subtotal. Technically in this case the discount is not applied to the subtotal, but applied between shipping and tax despite where it is displayed. the calculation appears to be off by a penny, because of the way the the line items and discount are rounded to the second decimal place. This seems to happen about 25% of the time. In the production environment I also moved the discount code entry from the checkout_payment.php page to the shopping_cart.php page and wrote an AJAX script to validate the code, tell the customer what the discount will be, and save the code in a session variable to be applied on the checkout_confirmation.php page. My cart is highly custom at this point and the code is not easy to integrate into another cart, but I will happily send you the code I used to integrate all or part of the solutions above if you think they will meet your local requirements. My sandbox is using the one page checkout and always displays the subtotal without the discount and displays/applies the discount right after the subtotal line. Otherwise all taxation is setup the same way in the sandbox version which should go to production later this week.

While doing further testing I have found the following Using KGT with One Page Checkout if the coupon is processed prior to selecting a different table rate shipping method the discount will also apply to the shipping as well as the subtotal. For a fix checkout this post I wrote regarding the includes/classes/discount_coupons.php and how I fixed the issue two post later. I also discovered that the Low Order Fee module apparently does not work in One Page Checkout. Does anybody have Low Order Fee working in One Page Checkout and if so how did you do it?.?.? Lastly I still haven't gotten back to the validation of the New Address and Edit Address functions yet. I hope to do that this afternoon.

Thanks for the information I am using the 3.32 and used the auto installer, but have modified the contribution twice; once to accommodate a custom auto discount module I built to automatically generate and send coupons that can be used by this module when a customer makes a qualifying order and again to accommodate the One Page Checkout contribution. Could be why I saw no effect, but after looking at the code in question and how the function is called and used in the catalog/includes/classes/order.php order class cart() function I just don't see how it could possibly work. Apparently I would need to see how ver.3.34 is coded. Oh well it is working now and an alternative is posted. Seems like I had similar issues getting taxes working when I first implemented this contribution. My settings are: Enable discount coupon? true Sort Order 2 Display discount with minus (-) sign? true Display subtotal with applied discount? false Display tax in discount line? None Exclude product specials? true Random Code Length 6 Display discount total lines for each tax group? false Allow negative order total? false Use the language file to format display string? false Display Format for Order Total Line Discount Coupon applied Debug Mode false It works fine now, but I can't recall what the tax issue was exactly or how I fixed it.

Ok I figured this one out. Instead of this: if( MODULE_ORDER_TOTAL_DISCOUNT_COUPON_DISPLAY_SUBTOTAL == 'false' ) { //we don't want to display the subtotal with the discount applied, so apply the discount then set the applied_discount variable to zero so that it's not added into the order subtotal, but is still used to correctly calculate tax $actual_shown_price = ( $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty'] ) - ( $discount['applied_discount'] + $discount['discount_tax'] ); $applied_discount = 0; $shown_price = $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty']; } else { $shown_price = ( $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty'] ) - ( $discount['applied_discount'] + $discount['discount_tax'] ); } It should be this: if( MODULE_ORDER_TOTAL_DISCOUNT_COUPON_DISPLAY_SUBTOTAL == 'false' ) { //we don't want to display the subtotal with the discount applied, so apply the discount then set the applied_discount variable to zero so that it's not added into the order subtotal, but is still used to correctly calculate tax $actual_shown_price = ( $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty'] ); // - ( $discount['applied_discount'] + $discount['discount_tax'] ); Comment out this part $applied_discount = 0; $shown_price = $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty']; } else { $shown_price = ( $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty'] ) - ( $discount['applied_discount'] + $discount['discount_tax'] ); } The $actual_shown_price was in fact being used, but it was performing essentially the same calculation as $shown_price. After commenting the part of that calculation that subtracted the discount and added the tax not only do I see the subtotal without the discount applied it is also used for my table rate shipping, which was the entire reason I needed the subtotal to reflect the pre-discounted price. My table rates are based on price and the subtotal was being reduced by the discount prior to the shipping calculation being made which is a percentage of that subtotal. Of course none of this was an issue until I implemented one page checkout. The standard checkout forced shipping selection prior to discount validation. With one page checkout this can occur in any order. Something to be aware of if you are considering the One Page Checkout contribution with this discount coupon contribution.

Can anybody confirm this actually works. I have made this change to version 3.2, but still have the exact same result. I still have the discount displayed in the subtotal. Since I don't see any more comment on this I assume it works in at least one version of the contrib.

Anybody else notice that the add/edit address features of this contribution has inadequate validation to prevent people form entering screwy information in the address fields? For example I am able to add a completely blank address then use that for my shipping address. The end result to this little game is that the customer gets to checkout without paying for shipping, because there is no geo_zone and the shipping modules are assigned to the geo_zones. Validate, validate, validate. I am just about to head out for Christmas vacation, when I get back I will fix this and post a patch to the forum if nobody beats me to it. I don't have time at the moment to see where else the validation is lacking, but in this case it is not the end of the world simply charge the customer for shipping when you call to ask where they want the order shipped to. This is very basic level of validation however, which makes me wonder if this validated at all or if the user input is even escaped.

I figured out a much simpler, and more direct approach. I created a function in the includes/classes/shipping.php class as follows: function first() { if (is_array($this->modules)) { $rates = array(); reset($this->modules); while (list(, $value) = each($this->modules)) { $class = substr($value, 0, strrpos($value, '.')); if ($GLOBALS[$class]->enabled) { $quotes = $GLOBALS[$class]->quotes; for ($i=0, $n=sizeof($quotes['methods']); $i<$n; $i++) { if (isset($quotes['methods'][$i]['cost']) && tep_not_null($quotes['methods'][$i]['cost'])) { $rates[] = array('id' => $quotes['id'] . '_' . $quotes['methods'][$i]['id'], 'title' => $quotes['module'] . ' (' . $quotes['methods'][$i]['title'] . ')', 'cost' => $quotes['methods'][$i]['cost']); } } } } $first = $rates[0]; return $first; } } Then made this simple change to the includes/checkout/shipping_method.php file around line 42. // $shipping = $shipping_modules->cheapest(); $shipping = $shipping_modules->first(); Now all I have to do is start my sort orders in the admin panel at 1 and whatever I give sort order 1 is now the default regardless of how much the shipping method cost. This solves the international problem by simply defaulting to the module with the lowest sort order. If my Canadian or Alaska/Hawaii options come after my lower 48 options it doesn't matter because they don't quotes for those orders anyway. Just to keep it from looking confusing in the admin panel I made my lower 48 options sort 1-5 my Alaska/Hawaii options sort 1-2 and my Canadian option is sort one, so as we begin shipping to more and more geo_zones I will simply have similar sort groups for each new geo_zone. Hope this helps some of you.

I need to be able to set the default shipping method. This will not be the lowest, nor the highest priced shipping method, so changing the cheapest() function to look for the most expensive is not an option. I played with the idea of using the sort order by making the following edit in the includes/checkout/shipping_method.php file around line 41. if($free_shipping == false){ $ds_sql="SELECT configuration_key FROM configuration WHERE configuration_title = 'Sort Order' AND configuration_key LIKE '%MODULE_SHIPPING_%' AND configuration_value = 0"; $ds_query=tep_db_query($ds_sql); $ds=tep_db_fetch_array($ds_query); $ds_method = substr($ds['configuration_key'], 16, -11).'_'.substr($ds['configuration_key'], 16, -11); $shipping = array( 'id' => $ds_method, 'title' => 'Default Method', 'cost' => 'Default Cost' ); // $shipping = $shipping_modules->cheapest(); This does in fact work in that it sets the default shipping method to whatever shipping method is current in the sort order 0 (zero) position. The only problem is that we ship to US and Canada. Canadian shipments do not have this option available. So if a Canadian shipping address is provided there will be no default shipping address. I guess this is not a terrible thing as we do not ship to Canada all that often, but I was wondering if anyone had some ideas how I could set the default for multiple geo_zones. I thought of having the sort over start over at zero again for Canadian options, and starting the Alaska/Hawaii options at zero, so there would be three zeros, but I haven't quite figured out how to change the query to make sure I get the default for the correct geo_zone_name. I cannot find a db only solution and may have to use the $shipping_modules object in conjunction with the configuration table in the db. Any ideas?

I noticed the same thing, but for unrelated reasons I decided to show the shipping address by default and require login. No issue now, of course this requires customers to use the original create account script to create an account prior to using one page checkout. This is preferred for now in my case because we collect quite a bit of custom data from our customers during the account creation process. I also used similar if() statements to check the vertical or horizontal layout for the shipping/billing addresses to provide the same option for making the shipping options line up horizontally with the payment options, so selecting horizontal in the admin panel makes both the addresses and Payment and shipping options horizontal and minimizes the amount of scrolling to checkout. A nice trade off. You can see it here lwtest.49ercommunications.com I am wondering if you have Auto-show billing/shipping modules is set to false?.?.?

Steve, Thanks for the tip I am finished testing and at least in test mode everything appears to work as designed. I did remember however, why I wasn't using this particular Authorize.net payment module; this module has no way to turn off customer notifications from Authorize.net (we send HTML equivalents from osC directly) and this module stores the entire credit card number in the osC db. To make this arrangement PCI compliant I would have to change my server environment. Does anybody know if the Authorize.net notifications can be turned off from the merchant control panel at the Authorize.net website or a simple way to make this module request that no e-mail notification be sent to the customer directly from Authorize.net for each transaction the way that the authorizenet_aim.php module does? I am sure I can modify this module to x out the middle digits of the cc number, but I sure wish the other Authorize.net modules worked with OPC. The authoriznet.php module even has the ability to select which credit card types you want to accept and does echeck.net. Though I understand that particular module has some licensing issue that restricts how it can be distributed. Thanks, Jason

I found the payment module specified here http://addons.oscommerce.com/info/5662 and installed substituting the file as you suggested and the payment method now sets correctly. I will test with some transactions, if all is well I will not need to post again, so I would like to thank you now. Merry Christmas Steve and Thanks a mint, this was much quicker than figuring out why the other Authorize.net module didn't work. -Jason

Hmmm, I don't have that one. I will have to see if I can scrounge up a English language file to go with it.