Right now, if an order reverts to the actual "Shopping cart" status, its shipping line items will be deleted so they can be recalculated when the customer returns to checkout. However, if the shipping checkout pane is on a checkout page other than the initial one, these shipping line items should also be deleted when the order is updated to statuses the represent pages before the shipping checkout pane.

Comments

esdrubal’s picture

esdrubal commented

I'm having a problem with this situation not happening. If I revert to the Shopping Cart status the shipping line is not deleted and the user cannot go anywere: clicking "Checkout" gives an error page. The only solution is a cart deletion by a site administrator.

rszrama’s picture

rszrama commented

Are you using 1.x or 2.x?

esdrubal’s picture

esdrubal commented

I'm using 1x.

esdrubal’s picture

esdrubal commented

I have solved the situation on going back to cart from checkout using Rules:

if Status=Cart and Unchanged Status <> Cart then delete Shipping Line Items

but if the user closes the browser or jumps to another page, then when going back to the cart (my Cart Block is quite trimmed: have only the View Cart and the total quantity, not the Checkout) he won't get anywhere.

I've tested it using the Checkout button on the Cart Block: I jump to the checkout with the address info previously used and get no problem in the shipment price (although I have only one flat rate shipment price).

I've tried this with Rules but don't have an event "When URL is /cart", and what I would like ("When Viewing Order") only works on the admin page.

rszrama’s picture

rszrama commented

Ok, for what it's worth, there's no real reason to continue using 1.x now that http://drupal.org/project/commerce_flat_rate is up.

esdrubal’s picture

esdrubal commented

Thanks for the info. I've moved to Shipping 2.x and it's Flat Rate but I'm still getting the same error: leaving checkout blocks that cart from being reused.

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

This is an important one. I was able to get an order-total based shipping rate (Free if over $100) by

1. Creating an order less than $100
2. Going through to the last checkout page with a shipping line item that pushed it over $100
3. Backing up with the back button. Now the "Free shipping" service is available because the order total is over $100.

My workaround is to change the rules component to call another (ruleset) component that deletes the shipping line item and *then* rates shipping.

rszrama’s picture

rszrama commented

Ahh, you should've been in my DrupalCamp Austin presentation. ; )

That problem is why I recently added the condition to the Shipping module to check for the currently selected shipping service. On http://www.realmilkcheese.com I had this problem, too, so I added the condition to let say make a shipping service available "if the order total > $99.99 AND the currently selected service IS NOT standard shipping". I did the inverse for standard shipping, so it shows up "if the order total < $100 OR the currently selected service IS standard shipping."

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

Ah, shucks. It wasn't recorded, I take it.

Actually, your rule is probably not fully accurate. You could have an amount over $100 and a current standard shipping and still deserve free shipping.

I think I'll demo this with deleting any shipping line item before rating, which is much more authoritative.

rszrama’s picture

rszrama commented

It's recorded. : )

In my case, there's no way for the total of an order to go up outside of adding products to the cart (or submitting the Cart form to change the quantity higher / lower) or selecting standard shipping. If a the cart contents were to be adjusted, then the status of the order would be reset and the shipping with it. Obviously you'd have to add additional conditions if there were other parameters in play that could raise an order total over the minimum limit for free shipping.

This is still an open report, though, so maybe we can just fix it here before enshrining a workaround in documentation. I still get a lot of people posting support requests about using taxes as discounts even though we've had selectable price component types for product pricing rules for a while now. ; )

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

IMO the shipping line item should be zeroed or else killed before rating begins.

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

I don't find a posted recording at http://2011.drupalcampaustin.org/sessions/practical-drupal-commerce, but I assume you mean it was recorded and will be posted later.

rszrama’s picture

rszrama commented

Right, it'll take 2 - 3 weeks they said. As for rate calculation, I'm not sure what you're saying. A base rate has to come from somewhere - whether it's from the flat rate that you've set or UPS or wherever. A shipping service always has some value, and the rate calculation rules are used to manipulate it as necessary for the site.

As I mentioned above, this is functionally equivalent to product pricing:

1) A product defines its base price -> becomes the unit price of a product line item -> which is passed through Rules for additional calculation.
2) A shipping service returns its base rate -> becomes the unit price of a shipping line item -> which is passed through Rules for additional calculation.

At the end of each process, the final unit price is what the user will end up paying.

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

I'm saying that before the *shipping service* is chosen/rated, the line item should be deleted. I'm not talking about calculation rules.

The alternative is a little more complex, but also valid, and that's having a method to determine order value - shipping. Might be useful. Order value - taxes would be useful too. As far as I can tell, there is not currently a way to access components of the order total (assuming components are kept there). That would be a fine thing as well, but lots of places to make mistakes.

rszrama’s picture

rszrama commented

Ahh, I see. Sorry for the misunderstanding. : )

googletorp’s picture

googletorp commented
Status: Active » Fixed

Think this issue is fixed now.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

marktheshark’s picture

marktheshark commented

Isn't this still present in Commerce Kickstart 2.5 with Shipping 2.0?