Why does the carrier id change when a new range rule is added?

[Beluga]

I just noticed the weird behavior described in the topic title when I was trying out weight rules.. The old rule entries are even left in the tables ps_range_weight and ps_delivery!

This is no problem for me, but I was just wondering, why does it do it in a messy way like this?

[Charles T.]

I'm having the very same problem.

I think it always worked like that. It has been thought as some kind of historization... but yes, this is another stupid thing in prestashop.

 

Everytime you change anything on a carrier's setting, it creates one or two new carriers in database, set the former one as deactivated and messes up every shipping module (expeditor, chronopost, TNT, ...) 

 

All those modules try to look for orders with the most recent carrier ID but fail because all orders had been placed on the older carrier ID's.

 

It's a pain everytime you try to get exports too. Let's say you want to count the number of orders sent by carrier. You would have to use tens of carrier IDs for a single actual carrier.

 

That's why there is a new field called id_reference that is set to the original id_carrier.

 

I have to hack every module to have all the shipping exports to work properly.

Edited October 18, 2013 by Charles T. (see edit history)

[Beluga]

Thanks for the insight, Charles. I was kind of baffled when I noticed that. Luckily, I won't be running into issues with what I plan to do: create carrier rules for a fixed price per every kilogram by inserting them into ps_range_weight and ps_delivery (1, 2, 3 .. 200 kg - who knows how high I'll end up ).

[Beluga]

Ok, I tried the thing I talked about in my last post and succeeded. This can be done in a straightforward way using phpmyadmin's import and selecting CSV. So you build two CSV files, one for ps_range_weight and another for ps_delivery. Build them in a spreadsheet. I have to say I made this a bit easier, because I only need one zone, so this might be more complex, if you need more zones.

 

For ps_range_weight, check the database for the last id_range_weight id number and input in your spreadsheet a number that is +1 the last id.

Then for the next row you can do =SUM(A2 + 1) and then fill that down to how much you want (in Libreoffice, click the cell and then shift click to the last cell you want filled and press CTRL-D).

For the id_carrier, check the db or backoffice for the current id (remember this is volatile so double check). Just fill it down in the spreadsheet.

For the delimiter1 and delimiter2 columns, be sure to select all the cells you will be filling and change the formatting to use USA decimal (dot) and 6 decimal places. Then you can do that =SUM trick however you want and fill 'em down.

 

For ps_delivery, it's more of the fill down routine.

Remember to have matching id_range_weight.

You can use NULL for id_range_price, if you want, but don't use " as text separator, because otherwise phpmyadmin will import it as text and not a NULL value. So for example in Libreoffice CSV saving dialog, remove the " text separator completely.

The tricky thing about ps_deliver is that you must use an increment of 2 when inputting the id_delivery! So if the database has the last id_deliver as 17, you must begin from 19 and +2 it in your =SUM.

 

If you mess it up the first time, you can try updating the Carrier in the backoffice, going to phpmyadmin to check the situation with the id_carrier and then running the SQL command (replace with your own values):

UPDATE ps_delivery
SET price=0.180000
WHERE id_carrier=6;

When saving the CSV files, remember to use UTF-8 (it's the default in phpmyadmin). Also select the correct delimiter in phpmyadmin CSV import (semicolon is the default). You also cannot have headers in the CSV import, so you have to delete the header rows (eg. id_range_weight;id_carrier;delimiter1;delimiter2) from the files.

Edited October 19, 2013 by Beluga (see edit history)