Halyra

La Version Beta HPOS est désormais disponible en version stable : Version 5.3.1

Bonjour,

Y a-t-il du nouveau sur ce sujet qui reste en suspens ?

Avez-vous testé la solution de ne pas avoir sur les base de données, de caches additionnels autres que ceux déjà inclus dans Woocommerce et WordPress ?

Bonjour,

Je suis preneur d’un transporteur supplémentaire qui apporterait de l’originalité dans les services et renforcerait la concurrence pour les e-marchands. Les transports longues et moyennes distances m’apparaissant bien couverts, mes recherches actuelles était plut?t du coté de prestataires spécialisés dans le dernier kilomètre (coursiers ou activité similaires). Viser 2024.

DPD comme candidat ? Je n’ai pas vu d’attentes particulières ; il est dans le Groupe LaPoste, déjà bien desservi sur CDI.

Je repèserai tout cela en début 2024. Les suggestions sont les bienvenues.

Bonjour,

Peu de chance de trouver un contr?le qui soit indépendant du cache, et qui soit aussi visible que l’absence du bouton label sur les pages WC ou CDI.

En revanche vous devriez tester un contournement, peut-être mieux géré par votre cache :

Dans le ficher /includes/CDI-Function.php (CDI 5.2.5) ligne 139 :

… remplacer add_post_meta( $idorder, ‘_cdi_meta_exist_uploads_’ . $type, true, true );

par update_post_meta( $idorder, ‘_cdi_meta_exist_uploads_’ . $type, true );

Bonjour,

Le point 1) est normal et n’apporte pas d’éléments d’analyse supplémentaires.

Les points 2) fichier txt présent, et 3) _cdi_meta_exist_uploads_label absent, sont très intriguants.

En effet, en supposant que la situation est bien relevée dès l’incident, et donc avant de régénérer une autre étiquette pour la commande qui alors remplacera les données précédentes, ces données sont contradictoires. Elles sont générées dans la même séquence courte (function cdi_uploads_put_contents) et ne peuvent qu’ être en cohérence. 

Je n’ai aucune piste, mais ?a ressemble comme si il y avait eu un problème sur la BdD (cache ou autre chose).

A suivre donc

Bonjour,

Non cas pas encore rencontré.

Lors d’un prochain incident, pourriez-vous faire les vérifications suivantes :

1) vérifier dans les logs (CDI + WP) s’il y a une erreur quelconque au moment de la supposée génération de l’étiquette ;

2) contr?ler dans le répertoire /wp-content/uploads/cdistore/ si vous avez un fichier de nom “CDI-label-<id-order>.txt” qui est alors l’étiquette stockée.

3) contr?ler si vous avez dans la table “???_postmeta” de la BDD wordpress, une entrée de nom “_cdi_meta_exist_uploads_label” pour l’ordre “<id-order>” avec la valeur “1” qui signifie qu’une étiquette a été stockée.

Il faut qu’on arrive à déterminer s’il s’agit d’une absence de la pièce jointe dans la réponse du transporteur ou d’un incident ou bug dans le process de stockage.

Dans la prochaine version de CDI (5.3.xxx), il aura des logs supplémentaires si cet incident se produit.

Bonjour,

Vous avez dans les versions de développement https://www.ads-software.com/plugins/collect-and-deliver-interface-for-woocommerce/advanced en bas de page, une version en bêta test (5.3.0.x-Beta, x évoluant progressivement avec les versions) .

Cette version devrait vous permettre de résoudre votre problème.Elle inclut un filtre supplémentaire “cdi_filterstring_shipping_altercartview” avec dans le fichier CDI /examples/CDI-filters-example.php un modèle sur ce filtre qui ressemble bien à votre cas.

Bonjour,

Surtout, ne choisissez pas des plugins de shipping au hasard.
Actuellement très mobilisé sur d’autres sujets urgents, bien loin de l’informatique, je ne peux pas être immédiatement disponible. Mais je vous promet des pistes de réalisation d’ici quelques temps.

Bonjour,

La fonction que vous chercher à produire est grosso-modo celle que pourrait? faire un plugin commercial de WC additionnant plusieurs tarifs élémentaires par produit ou catégorie de produits. Si vous adoptiez un tel plugin, il pourra fonctionner avec CDI.

Vous ne pourrez pas faire cela “de base” avec la méthode incluse dans CDI car elle effectue un calcul de tarif global sur le panier. Toutefois, vous pouvez obtenir le même résultat en utilisant le filtre CDI “$rate = apply_filters( ‘cdi_filterarray_shipping_rate’, $rate, $rates, $classlist );”. En faisant quelques lignes de code pour calculer , dans l’environnement checkout de WC, et en analysant les différents produits du panier, le tarif que vous souhaitez appliquer au client.

Certains ont fait des choses assez similaires, et pourraient guider.

Bonjour,

Je vais vérifier de mon coté, mais de mémoire la Norvège ne fait pas partie de l’UE, mais de l’AELE (Islande, Liechtenstein, Norvège, Suisse). Son traitement devrait donc être identique à ce qui est fait pour les expéditions vers la Suisse (pas de TVA et CN23 nécessaire). Le lieu du destinataire de la facturation lui n’entre pas dans les paramètres.

A suivre donc.

Bonjour,

Rien n’a été modifié sur CDI sur ces fonctions. Y a-t-il une erreur générée dans les logs ?

Une possibilité que vous devriez regarder. La Poste avait limité le nombre de colis à 250 par requête bordereau  (chiffre non documenté dans leurs spécifications). C’est pourquoi CDI découpe les très grosses demandes en plusieurs requêtes de 200 colis. Pouvez-vous vérifier que le max de 250 n’a pas été abaissé à 120 à La Poste ?

Bonjour,

Il faudrait demander à votre hébergeur d’installer l’extension PHP Soap sur votre configuration.

Bonne continuation.

Bonjour,

La récente nouvelle version installée 5.2.5 devrait solutionner votre problème : 1) une gestion bien plus serrée de l’exclusivité d’accès au process de synchronisation CDI, en cas d’admins concurrents sur Woocommerce et 2) en alternative, un nouveau filtre ‘cdi_filterstring_retourcolis_eligible_force’ dans le module CDI-Retour-Colis.php pour vous permettre un contr?le complet (voir l’exemple sur fichier /examples).

Merci de faire partager au forum vos conclusions sur ce sujet.

Bonjour,

Je ne vois finalement que le cas d’un conflit d’accès concurrents à la liste des commandes WC (wp-admin/edit.php?post_type=shop_order), là où se réalise la synchronisation Passerelle->WC, si plusieurs administrateurs opèrent sur cette même liste de commandes et entrent simultanément dans la séquence de synchronisation. Mes tests n’ont pas pu le prouver, mais le code semble bien orienter vers cette voie. La séquence de synchronisation, assez courte, est la fonction  “cdi_synchro_metabox_gateway” du module CDI-Orderlist.php.

S’il se confirmait que c’est un pb lié à plusieurs admin en concurrence, et donc un phénomène aléatoire, c’est statistiquement les 4000 commandes impactées qui impressionnent, mais à mettre en rapport avec le volume de commandes totales gérées. Merci s’il y a des éléments complémentaires à prendre en compte sur ce pb.

Pour pallier au problème d’exploitation qui se pose actuellement, le filtre ‘cdi_filterstring_retourcolis_eligible’ dans le module CDI-Retour-Colis.php est trop restreint et donc peu inutilisable dans ce cas. Si ce diagnostique est confirmé, un deuxième filtre sera inclus dans une prochaine version de CDI.

Bonjour,

Je n’arrive pas à déterminer où se passe votre difficulté. Toutefois 2 points de vérification utiles :

• Si votre problème est lors de la définition des méthodes de livraison CDI, vérifiez que vos shipping-zone de WC sont dans le bon ordre, et que le pays France ne se trouve pas dans 2 shipping-zones, WC ne traitant alors que la première trouvée.
• Sil s’agit d’une difficulté en back-office pour la génération des étiquettes d’affranchissement Colissimo, faites un click sur le bouton rouge “Réinstaller les paramètres officiels de CDI”, un des paramètre ayant peut-être été modifié par inadvertance.