Jump to content


  • Posts

  • Joined

  • Last visited

seezee's Achievements


Newbie (1/14)



  1. in case anyone is still having trouble with this, see http://www.prestashop.com/forums/viewthread/41286/ --cz
  2. nope. i tried changing this: to this: and also to this: neither change has any discernable effect. any PHP gurus out there know of another change that might reorder the carriers to display the highest ID first, and the lowest IDs last? --cz
  3. that makes sense, since UPS Saturday Delivery is the last carrier on the list, which is because it has the highest ID -- highest ID = last item edited. unfortunately, editing the carrier I want as default would also have the unwanted effect of moving it to the bottom of the list of available carriers -- not a desirable outcome. has this been reported as a bug so the developers can start on a fix? thanks, --cz
  4. more testing reveals this: changing the default carrier _does_ change the shipping amount shown in the cart preview. it just doesn't change the default selection on the 'choose carrier' page. --cz
  5. small correction -- the cart is actually defaulting to UPS Saturday Delivery instead of the default option set in the back office. --cz
  6. [sOLVED]i located the bug report on this one -- the solution is to download & install the SVN version of order.php. instructions for obtaining the SVN version are at the bottom of the main download page (below the language packs), here: http://www.prestashop.com/en/downloads/ REMEMBER to backup your old order.php, especially if you've manually modified it in the past. Thanks to all who posted possible solutions -- knowing it was a bug helped me to solve this. i've configured the following carriers: United States Post Office United States Post Office AK/HI UPS 2nd Day Air UPS 2nd Day Air AK/HI UPS Next Day UPS Next Day AK/HI UPS Saturday Delivery UPS Saturday Delivery AK/HI in backoffice >> shipping >> carrier, under carrier option, i've set United States Post Office as the default carrier. this method is available to buyers in the continental u.s.; buyers in AK or HI do not have this option (they have United States Post Office AK/HI, which has the same rates, but longer delivery time). when i login with either my california or oklahoma test account, both of which have the default method available (continental u.s., remember?), and i reach the 'choose shipping method' page, the radio button for UPS 2nd day air is selected. i have tried setting other carriers as default, as well, but none seem to override this behaviour. additional info: the backoffice doesn't overwrite carrier entries in the sql database when you update or delete them -- instead, it makes a new entry, incrementing up the index by 1, and marks the old entry as 'deleted' (1 instead of 0). i manually deleted some of the redundant entries; could that be affecting it? also possibly pertinent: i have modified my classes/cart.php to apply free shipping for orders over a certain amount for 2 specific carriers only (United States Post Office [id=20] and United States Post Office AK/HI [id=21]) // Added Default carrier only Free Shipping --cjz if (isset($configuration['PS_SHIPPING_FREE_PRICE']) AND (($id_carrier==20) || ($id_carrier==21)) AND $orderTotal >= floatval($configuration['PS_SHIPPING_FREE_PRICE']) AND floatval($configuration['PS_SHIPPING_FREE_PRICE']) > 0) return $shipping_cost; if (isset($configuration['PS_SHIPPING_FREE_WEIGHT']) AND (($id_carrier==20) || ($id_carrier==21)) AND $this->getTotalWeight() >= floatval($configuration['PS_SHIPPING_FREE_WEIGHT']) AND floatval($configuration['PS_SHIPPING_FREE_WEIGHT']) > 0) return $shipping_cost; and i've modified classes/product.php as follows: // Moved to end of price calculation so tax gets applied to discounted price -- see below! -- cjz // Exclude tax // $tax = floatval(Tax::getApplicableTax(intval($result['id_tax']), floatval($result['rate']))); // if ($forceAssociatedTax) // $tax = floatval($result['rate']); // if (Tax::excludeTaxeOption() OR !$tax) // $usetax = false; // if ($usetax) // $price *= (1 + ($tax / 100)); // End moved block // Attribute price $attribute_price = $usetax ? $result['attribute_price'] : ($result['attribute_price'] / (1 + (($tax ? $tax : $result['rate']) / 100))); if (isset($result['attribute_price'])) $price += $attribute_price; $reduc = self::getReductionValue($result['reduction_price'], $result['reduction_percent'], $result['reduction_from'], $result['reduction_to'], $price, $usetax, floatval($result['rate'])); // Only reduction if ($only_reduc) return $reduc; // Reduction if ($usereduc) $price -= $reduc; // Quantity discount if ($quantity > 1 AND ($qtyD = QuantityDiscount::getDiscountFromQuantity($id_product, $quantity))) $price -= QuantityDiscount::getValue($price, $qtyD->id_discount_type, $qtyD->value); // Group reduction if ($id_customer) $price *= ((100 - Group::getReduction($id_customer))/100); // Exclude tax $tax = floatval(Tax::getApplicableTax(intval($result['id_tax']), floatval($result['rate']))); if ($forceAssociatedTax) $tax = floatval($result['rate']); if (Tax::excludeTaxeOption() OR !$tax) $usetax = false; if ($usetax) $price *= (1 + ($tax / 100)); thanks, --cz
  7. In case you skipped the 1st post to this thread, I've edited it to include the correct solution to this problem. Please read the 1st paragraph of the 1st post. --cz
  8. I'm not feeling any love here ... I know others have had this problem with no useful solutions offered. I did some more digging into the source code & found out that you can save source code from Google Chrome to see the generated javascript; lo & behold, the wrong (higher) prices appear in the generated code instead of the correct ones. Still no closer to solving this, though. HELP! thanks, --cz
  9. I'd be interested to know if you did anything specific to fix this, as I'm having similar problems -- only the price showing up is almost DOUBLE the correct price, both before & after discount. cheers, --cz
  10. More information on the problem: i found out i had my taxes set up incorrectly for my situation; the instructions here are correct (but the problem persists; see more after the quote): So taxes are behaving correctly, more or less. the prices are still wrong on the product pages, only they've increased. Here's where it gets interesting. on another thread i saw someone mention that when you load the page, you may briefly see the correct price, which is quickly replaced by the wrong one. I checked the source code, and IT ONLY SHOWS THE CORRECT PRICE, at least for the discounted price. the line that shows the original, pre-discount price reads: $1,062.08 tax excl. which is close, but no cigar. it's actually the old price WITH TAX INCLUDED, not TAX EXCL. it should actually read: $980.00 tax excl. as it is supposed to be tax excluded. the 2 incorrect prices that my browser displays are nowhere in the source code. thanks, --cz
  11. okay, further investigation revealed that i had several tax items besides the one i wanted as default. i deleted the unnecessary ones and applied the correct one. then applied it to the individual products. now the price still shows up incorrectly, regardless of whether a 'combination' is on offer, so we can eliminate that as the culprit. to answer the question of mass combination deletion, just use the combination generator again, with only one option -- it'll wipe all the others out; then you can manually delete the one. still need to know why the pre-sale and after discount price is showing up wrong on the product page (it shows the correct price in the shopping cart) here's how i have it set up: 8.375% tax applies to purchases for Oklahoma purchasers only; all other allowed buyers pay no tax. 'apply tax' checked on individual products; tax enabled under tax options. all items so far are on sale, so 'reduction amount' is applied. so, for the example in the first post, retail before tax = $980, tax applied to pre-discounted price makes it $1062.08, discount of $245 makes final price w/ tax $817.08. but the product page shows pre-discounted, pre-tax price of $1440.60, not $980, and the after-discount, pre-tax price as $1108.28 -- where do these numbers come from?
  12. [sOLVED] [After looking at the bug tracker, I found the solution: my only currency is $USD, but I had left the conversion rate at the default of 1.45 (prestashop defaults to the euro). Changed it to 1 and it solved the issue. There's still a problem with the price displayed for taxable buyers, but that's another thread. --cz] I added a combination to a product on my test site, left the impact on price options to none, and the price changed (increased) by a mysterious amount. since i had used the combination generator i had to manually deleted 150+ combinations to test whether the combi was the culprit. it was. i deleted all instances and recreated the combi & it happened again (didn't use the generator yet since i'm testing the error). 3 questions: what's causing this, how can i fix it, and is there an easy way to mass delete combinatins?
  13. ok, in my case it was because i had some javascript embedded in my html (hivelogic's e-mail enkoder), which, apparently, the cms doesn't like. i took it out & it worked.
  14. I, too, have this error. I see no one has answered this question yet, even though it's 4 months old. Could it be a permissions problem? That seems to bolix a lot of my functionality.
  15. It looks like someone modified the demo while I was logged in & broke it; once it reset the language picker became available again. Still, it would be good to know what's causing this -- several other people have posted about this, and none have ever been answered. --cz
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More