UKJay

Update The above works fine for those who are not using the 'Larger Packages Percentage Increase' option in Admin / Configuration but I appreciate that many of you will want to use this so in checkout_shipping.php, instead of adding the line above, add: if (SHIPPING_BOX_WEIGHT >= $total_weight*SHIPPING_BOX_PADDING/100) { $total_package_weight = $total_weight+SHIPPING_BOX_WEIGHT; } else { $total_package_weight = $total_weight + ($total_weight*SHIPPING_BOX_PADDING/100); } Another small issue I noticed that when a load is split into 2 or more packages because of the weight, the modules were outputting the correct rates but were not declaring the correct weights - they were only showing the remainder weight after the other full packages were calculated. Hard to explain but what I mean is If you have set your largest package to 20kgs and your order is 30kgs, the correct shipping rate is shown but the text will delcare the weight of the package as 10kg (30kg - 20kg). This might not be an issue for many of you but if you want it fixed and have already coded the above changes then: In your installed modules from this contribution, find: global $order, $shipping_weight, $shipping_num_boxes; and replace it with: global $order, $shipping_weight, $shipping_num_boxes, $total_package_weight; Find: // Text shown on Checkout_shipping - Delivery Weight : 0.7 Kg's (Ships normally within 1 to 3 days) $shipping_method = MODULE_SHIPPING_RMSTANDARDPARCEL_TEXT_WAY . ' : ' . $shipping_weight . ' ' . and replace the $shipping_weight with $total_package_weight (note the MODULE-SHIPPING_ will change depending on the module you are amending) I'll see if I can trim this down any and add it as an updated contribution later when I get some time to play around with it a bit more.

Ok, written a solution for this. Its been tested in both my live server and my development server and works in both. In checkout_shipping.php find: $total_count = $cart->count_contents(); and immediately after it paste: $total_package_weight = $total_weight+SHIPPING_BOX_WEIGHT; In each of your shipping modules for this contribution (eg rmfirst.php), find: global $order, $total_weight; and change to: global $order, $total_weight, $total_package_weight; and then find: if ($total_weight > and replace with: if ($total_package_weight > The issue is that $total_weight is solely the weight of the goods themselves and does not include the tare weight of any packaging. $shipping_weight DOES contain both the total weight of the goods as well as the tare but is defined after the shipping modules are called. By creating a new variable $total_package_weight and defining its value at the same time as $total_weight is defined, it passes the correct total weight of the parcel and packaging to the comparator for the maximum weight allowed for each mail and courier service.

In shipping, the modules I have all the Royal Mail ones in this contribution as well as Citylink. No others as we only deal in the UK market. I have not modified any of the files (apart from reducing the overall limit by 0.1kg as that is my Tare Weight). I have no other shipping modules active or installed. In configuration / shipping, Tare Weight is set to '0.1' and increase for larger parcels set to '0' as it is not required. As an example of prices, my rmsecond text string is '0:0,.1:.92,.25:1.20,.5:1.52,.75:1.92,1:2.30' - as these are only the prices, they are not an issue and should not effect the weight comparison calculation. As I mentioned earlier, when I echo out the values of both $shipping_weight and $total_weight, $total_weight = the weight of the goods themselves (as the variable name suggests) and $shipping_weight is the weight of the goods PLUS the Tare weight (again, as the variable name suggests). I'm wondering if, because many of my items are weighed in exact kilograms, this has not been apparerent in many other installations. Its not a big issue for me to have hard coded the tare into the maximums in each module php file. I've not made any other changes and by echoing out the above values I know that if I can use $shipping_weight as my comparison variable for the maximum allowed weight, it will work. Cheers for the replies ;)

Thanks for the reply Tiger - I understand what you are saying but its down to the wrong variable being used to check for valid postal options in my opinion. I could alter the max weights but then I'd also need to alter the strings to allow for the postage to be increased everytime the weight increased by 1kg and this would make this particular method of postage uneconomical. I simply need to have it so that the shipping weight is used as the comparison variable and not the weight of the order solely. Cheers

Ok, a quick play shows that $total_weight is the weight of the order without the tare weight. $shipping_weight is with tare weight so somehow the check needs to compare $shipping_weight to the maximum allowed weights.

To clarify the problem when using a TARE weight: Like others here I have recently experienced a problem with certain shipping options being displayed as £0.00 when I have an entry in Tare Weight in my shipping options. An example - I had a cart with a 1kg item and have a standard Tare weight of 0.1(kg) set in my shipping options in the Configuration settings. When this item came through to shipping, it correctly identified the weight on the screen as 1.1kg and displayed the error for Second Class Mail as exceeding the 1kg limit however it still displayed this option with a £0.00 rate as opposed to not displaying it. The work around I currently have is to hack each shipping module php file and reduce the maximum weights by 0.1 however I cannot see why this is not picking up before this area. EG, in 'rmsecond.php' on approx line 24 I am changing if ($total_weight > 1.0) to if ($total_weight > 0.90) I notice that this uses $total_weight for this parameter yet later on the weight is declared as $shipping_weight so these are obviously equal (ie $shipping_weight would appear to include the Tare weight and $total_weight would not) I'm not proficient as following OOP so cannot spot any quick fix other than my hard coding the figures so can anyone help me please? Regards

Who cares? - I get paid correctly and no annoying emails. Thats all I wanted!

Ok, I had this until I changed the 'Set PayPal Acknowledged Order Status' and 'Set PayPal Completed Order Status' in the admin section (admin/modules/payment/paypal IPN) away from DEFAULT and gave them appropriate values from the drop down boxes (for me I chose PENDING and PREPARING [PAYPAL IPN]) respectively. Not sure if this is a concidence but since I changed them yesterday, all test payments and 2 live payments have gone through clean with no INVALID emails.

Update on this - about an hour after my test purchase an email returned to confirm the order so there appears to be a delay in Paypal confirming the order as valid!

Like a lot of others I am having issues with receiving the "PayPal IPN Invalid Process" email - the account is getting credited so I'm not too bothered by it. However, there are a couple of other issues I am having and I'd like some help if anyone can offer some: 1. When I use the sandbox account, EVERYTHING runs as it should but when I use the LIVE system and run a small transaction to test, the money is credited fine however the orders_purchased field is not updated for the purchased items. This field is updated when I run the test on sandbox. Any ideas? 2. The clients postal address is not being received by my paypal merchant account so that when I click on 'details' for the transaction, I can see the invoice ID but no postal address. This is not a HUGE problem however I would like to be able to print my postal stickers from Paypal. Thanks in advance!

Yeah, fair comment - just re read it and I see what you mean. Got to forgive me, its a hot day and my brain is a little over heated.

I got to disagree Jack with regards to file type - there may be little difference in URLs ending solely in .php but once you start passing variables via URLs then you will suffer in SEO terms. I ran an experiement with two very similar sites last year, both launched on the same date, with similar amount of data (approx 12,000 database driven pages), both SEO'd in exactly the same way with the exception that one site passed variables via the URL and the other had the URL's rewritten via .htaccess to more 'friendly' URL's ending in .htm. Result, the friendly URL site was fully indexed in Google within 6 weeks - thats all 12,000 pages included. The site with dynamic URLs has approximately 1000 indexed after the same period and even after a further 7 months is not fully indexed. I agree about the sub directories, although some of that can be countered by using the .htaccess files to rewrite and redirect traffic to apparently higher directories.

Better still would be http://www.xxxxxxxx.de/backwaren-teige-hefenteig/index.htm as google prefers .htm endings to dynamic endings like .php