PhenixTweet

1 jour

a répondu au Message de yoyo64 - 1 jour

Mettez plutôt un
bottom: 5px;
car suivant les écrans la hauteur de l'image peut varier.

2 jours

a répondu au Message de yoyo64 - 2 jours

c'est bon avec ce css
.custom-flags.cf-positioned {
position: absolute;
top: 170px;
left: 50%;
transform: translateX(-50%);
z-index: 20;
}

2 jours

hello comment descendra en bas de la photo
car dans position ca change rien

2 jours

Pour ceux qui utilisent UPS, voici la mise à jour Regex à compter du 01/07/2026 pour les codes postaux dits RURAUX pour UPS en France, Espagne, Italie, Suisse, Portugal en fichier txt

UPS_Rural_Regex_01.07.2026.txt

4 jours

a répondu au Message de Eolia - 4 jours

Bien , j'attends avec intérêt cette version qui devrait répondre à mon besoin.

5 jours

a répondu au Message de eric - 5 jours

Je vais sortir un module de tracking (1700 transporteurs) avec api gratuite jusqu'à 50 n° de suivis par mois dans la prochaine version

5 jours

a répondu au Message de Eolia - 5 jours

Bah si vous voulez mais mon listing me suffit amplement. Faites comme vous le sentez si cela ne dérange pas les autres utilisateurs de phenix. Merci

5 jours

a répondu au Message de eric - 5 jours

Je parle de la somme affichée en haut du LISTING des commandes, mais celui-ci aussi se base sur total_paid_tax_incl. Je pourrais le modifier pour qu'il se base sur le total_paid_real :)

5 jours

a répondu au Message de Eolia - 5 jours

non , le calcul est faux , si vous remboursez un produit , le remboursement n'est pas pris en compte en BO , c'est d'ailleurs la raison pour laquelle j'utilise mon listing avec total_paid_real qui est vraiment la somme payée pour la commande y compris si vous remboursez des fdp ou autres ultérieurement. Différence de 13,76€ qui correspond à 2 remb de fdp de 8€ et 5.76€ sur les 2 copies d'écran suivantes.

5 jours

a répondu au Message de eric - 5 jours

Juste pour info, si vous filtrez les commandes du mois (ou n'importe quelle période en BO) la somme affichée en haut de la liste ne prend que les commandes valides :)

5 jours

a répondu au Message de Eolia - 5 jours

Effectivement , avec la contrainte valid =1 , le listing sort nickel . Merci

5 jours

a répondu au Message de eric - 5 jours

Le total_paid_real n'est jamais modifié. Il faut filtrer votre requête sur valid =1

5 jours

a répondu au Message de Eolia - 5 jours

oui , c'est une commande test qui a suivi tout le process -> attente paiement ( chèque ) paiement accepté -> livrée et test bouton rétractation avec tout le process de rétraction coté BO. Le dernier état avant annulation était remboursé et total_paid_real était au montant de la commande , c'est la raison pour laquelle j'ai passé le statut en annulé pour mettre ce champ à 0.00 ce qui n'a pas été le cas.

6 jours

a répondu au Message de eric - 6 jours

Ben ça dépend. La commande a été payée ou pas ?

6 jours

J'ai une requête qui utilise la table orders et le champ total_paid_real pour sommer les commandes de chaque mois avec le montant réel (commande annulée =0.00) ou remboursement surplus de fdp et/ou produit. J'ai testé ce week-end l'annulation de commande avec le bouton de rétractation ( commande avec un client test ). Avec l'état "remboursé" , le champ est toujours au montant de la commande test. J'ai donc changé le statut en commande "annulée" , c'est idem , le champ est le total de la commande alors qu'il devrait être nul comme toutes les autres commande annulées.

6 jours

a répondu au Message de eric - 6 jours

J'ai fait un module avec leur APi et leur okapi_key il y a un temps...

6 jours

Qui utilise/connait ce module ?

6 jours

a répondu au Message de Eolia - 6 jours

Maintenant je sais que, soit je mets à jour à la mano le statut pour déclencher le code de l'annulation commande ou j'installe un module pour suivre le statut mais j'ai au grand max 15 commandes/mois les mois les plus chargés donc un module pour ça...comment dire. Bref merci pour la réponse , je vais réfléchir à tout ça.

6 jours

a répondu au Message de eric - 6 jours

Le délai démarre quand la commande a le statut "livré".
Vous n'utilisez pas le module Colissimo pour les lettres suivies ?

Je ne peux pas me permettre d'inventer un calcul depuis la date d'expédition car ça va dépendre du lieu de livraison et que la commande soit réellement livrée (et non pas perdue ou non récupérée par le client)

6 jours

bonjour , le texte de rétractation en ligne indique "pour chaque commande livrée" , c'est l'état réel de la commande en BO ou c'est un calcul depuis l'état "expédiée" , je pose la question car je n'ai aucun retour automatique de l'état des commandes après l'état "expédiée", essentiellement des lettres suivies ( sticker qui dispose d'un n° de suivi et QR-code ) mais c'est à moi d'aller vérifier sur le site de La Poste que la lettre a été déposée dans la boite à lettre du client et de mettre l'état "livrée" à chaque commande.

7 jours

a répondu au Message de yoyo64 - 7 jours

Localisation => Traductions => Traductions des messages d'erreur

7 jours

merci je peux le traduire ou par contre There is a problem with your last order.

7 jours

A ajouter à vos CGV (pour les boutiques européennes)

RETRACTATION EN LIGNE
Conformément à l’ordonnance du 5 janvier 2026, transposant la directive européenne 2023/2673 du 22 novembre 2023 qui modifie l’article L221-21 du Code de la consommation chaque client peut exercer son droit de rétractation en ligne.
Depuis l'Espace Client "Votre compte" => "Historique des commandes", un bouton "Je veux annuler ma commande" permet d'effectuer la demande de rétractation pour chaque commande livrée.
Ce bouton est visible et disponible pendant la durée légale du délai de rétractation (14 jours). Celui-ci démarre à la livraison complète du bien.
Après le clic sur ce bouton, le client devra confirmer ses informations (identité, référence du contrat, e-mail et produits concernés) ;
Une fois les informations validées, le client confirmera sa demande en cliquant sur "Je confirme mon annulation de commande" et un accusé de réception sera envoyé immédiatement par email au client et au site. La commande concernée passera alors à l'état "Demande d'annulation de commande".
Le Service Client prendra alors contact avec le client dans les plus brefs délais pour valider la rétractation si celle-ci entre dans le cadre prévu par la loi

7 jours

a répondu au Message de BigM - 7 jours

Vous avez bien le order_conf.html d'origine dans les mails (core/votre thème) avec la variable {payment} dedans ?
Car cette variable est déterminée dans OrderHistory par

CODE
        $methods = [];
        if($payments = OrderPayment::getByOrderReference($order->reference)) {
            foreach($payments as $payment) {
                $methods[] = trim(Tools::substr($payment->payment_method, 0, 32)).' ('.Tools::displayPrice($payment->amount).')';
            }
        }
        if(empty($methods)) {
            $payment_methods = $order->payment;
        }
        else {
            $payment_methods = implode(' / ', $methods);
        }

et la fonction getByOrderReference() ne ramène que les moyens de paiement enregistrés dans la table order_payment. A aucun moment le statut n'est utilisé.

7 jours

a répondu au Message de Eolia - 7 jours

Je ne sais pas pourquoi ce problème se produit ni s’il est systématique ou seulement occasionnel, mais j’ai mis le statut sur « hide from customers » afin que « waiting for stripe capture » n’apparaisse plus dans l’historique des commandes.

Concernant les e-mails, je n’arrive pas à reproduire le problème, mais je l’ai constaté dans l’e-mail d’un client (voir pièce jointe).

7 jours

a répondu au Message de yoyo64 - 7 jours

Si vous êtes en OPC il faut ajouter ces lignes dans /controllers/OrderOpcController.php, avant la ligne 729:

CODE
        if($this->context->customer->id_risk >= 3) {
            if($this->context->customer->id_risk == 3) {
                return ''.Tools::displayError('There is a problem with your email. Please contact us if you wish to finalize your order.', false).'';
            }
            else {
                return ''.Tools::displayError('There is a problem with your last order and your account is suspended. Please contact us if you wish to finalize your order.', false).'';
            }
        }

Concernant store commander, vu qu'il utilise le cookie, évitez ce genre test inutile.

8 jours

hello Comment fonctionne le mode "client à risque" ?J'ai rencontré un comportement étrange.Sur mon PC bureau, je me connecte avec mon compte admin. Je passe ce compte en "client à risque" et j'arrive toujours à passer commande normalement, sans aucun message d'alerte dans l'admiPar contre, dès que j'ouvre Store Commander, impossible de dérouler les catégories.je remets le compte en client normal, Store Commander refonctionne J'ai refait le test depuis mon PC à la maison avec le même compte et j'obtiens exactement le même résultat : Store Commander ne fonctionne plus et si je me connecte avec

8 jours

a répondu au Message de BigM - 8 jours

Dans ce mail, seul le module de paiement est écrit, en aucun cas le statut de la commande.

9 jours

a répondu au Message de Eolia - 9 jours

Mais l’e-mail est envoyé depuis le statut « Registered order ».

Pour être honnête, je ne suis pas vraiment sûr pour le moment dans quelle mesure c’est un problème. Je reçois rarement des e-mails de clients qui répondent directement à la confirmation de commande au lieu d’utiliser le formulaire de contact. C’est simplement arrivé deux fois récemment, et dans les deux cas ils avaient payé via Stripe, et c’est là que je l’ai remarqué.

9 jours

a répondu au Message de BigM - 9 jours

L'email n'envoie pas le statut mais uniquement le moyen de paiement (Stripe)