Suppression de transporteurs et nettoyage des tables

[Odjavel]

Bonjour,

J’ai une petite question à poser aux spécialistes.

Lorsque je supprime un transporteur, PS fait une suppression logique (deleted=1). Normal, cela permet de conserver les noms des transporteurs utilisés dans le passé afin que les anciennes commandes restent renseignées.

Par contre, je ne comprends pas pourquoi certaines tables ne sont pas nettoyées à la suppression des transporteurs.

La table ps_delivery, par exemple. Quel intérêt de conserver les tarifs sur tranches de prix/poids pour un transporteur supprimé ? Ces tranches ne resserviront plus jamais, non ?
Idem pour ps_range_weight et ps_range_price. Chez moi, le transporteur supprimé reste référencé dans ces tables. Pourquoi ? Ces tranches ne serviront plus.
Idem pour ps_carrier_group (on se fiche désormais de savoir à quel groupe de clients étaient affecté ce transporteur), ps_carrier_lang (plus besoin d’annoncer les délais de livraison à l’avenir), ou même ps_carrier_zones.

Pensez-vous que je peux supprimer de ces tables (surtout ps_delivery et ps_range_weight/price) toutes les lignes correspondant aux transporteurs supprimés ?

Merci d’avance pour votre éclairage.

[Odjavel]

Re,

 

Je me permets de remonter ce sujet, car je tache actuellement d'optimiser mon site et cette question reste toujours en suspend.

Un spécialiste pour me donner un avis là-dessus ?

Dans la liste des tables à nettoyer, j'ajouterais même: ps_carrier_shop et  ps_carrier_tax_rules_group_shop, dont les données ne serviront plus.

Merci !

[Janett]

Possible qu’elles soient conservées car elles peuvent encore être utilisées.

Je n’ai pas testé mais je suppose que sur les anciennes commandes, il y a des cas où cela pourrait servir de nouveau.

Par example, si on a besoin de recalculer les totaux etc...

Je prend l’exemple d’une erreur comptable à corriger sur une facture, il est interdit par la loi de modifier une facture après qu’elle ait été éditée. D’ailleurs certains logiciels l’enregistrent dans une blockchain pour garantir son intégrité.

Du coup, si le client veut changer son adresse postale ou s’il y a une erreur sur la facture : il faut annuler cette facture, créer un avoir, refaire une facture utilisant l’avoir.

Concrètement dans Prestashop, il faudrait annuler la commande, générer un avoir, créer une nouvelle commande utilisant l’avoir et une nouvelle facture sera générée.

Du coup dans ce genre de cas, peut être que ces données dont tu parles seraient utiliser. Faudrait tester.

Plus d’infos sur le travail en cours sur les sujets légaux et la facturation dans Prestashop : https://github.com/PrestaShop/PrestaShop/issues/13822

[Odjavel]

Merci de ton intérêt, Janett.

Je comprends, mais j'en doute.

La table ps_orders et les ps_order_xxxxx contiennent toutes les données de chaque commande en brut, afin que rien ne soit recalculé, ce qui est plutôt bien.

Il n'y a donc jamais re-calcul des frais de port pour une commande validée, même si tu re-crées une facture. Et si tu crées une nouvelle commande, tu n'auras de toutes façons plus accès au transporteur ayant été utilisé la première fois si tu l'as supprimé entre-temps.

Non, vraiment, je n'arrive pas comprendre pourquoi PS ne nettoie pas ces tables lors de la suppression d'un transporteur. Négligence ou but bien précis ?

[Janett]

Faudrait creuser effectivement, comme beaucoup de comportements de Prestashop d’ailleurs, y a beaucoup de cas où on ne sait pas trop ce qu’ils avaient en tête à l’époque.

C’est assez amusant à suivre sur Github car ils sont en train de migrer sur Symfony et régulièrement ils se posent ce genre de question en tombant sur des comportements à priori incohérents.

J’aurai tendance à dire, laissons cela comme ça pour le moment et attendons qu’ils s’attaquent à cette partie lors de la migration. Ils vont forcément devoir chercher à comprendre aussi.

Ce sera l’occasion d’en savoir plus et de savoir si on peut oui ou non supprimez ces données à priori inutiles.

Mais dans le doute, je préfère les conserver faute d’explication sur leur présence dans la base de données.