Uncaught InvalidArgumentException: "" cannot be interpreted as a number

[mathieus]

Bonjour la communauté,

Je viens chercher de l'aide suite à un problème que je ne parviens pas à résoudre.

PS 1.7.8.5
Multistore avec 4 boutiques actives - thème commun pour toutes les boutiques
PHP 7.4.30

Pour certaines boutiques seulement (2 sur 4) j'ai cette erreur lors de la création de certaines commandes (disons 1 sur 20 environ) :

[11-Jul-2022 15:06:07 Europe/Paris] PHP Fatal error:  Uncaught InvalidArgumentException: "" cannot be interpreted as a number in /datas/www/mywebsite.com/www/vendor/prestashop/decimal/src/Builder.php:49
Stack trace:
#0 /datas/www/mywebsite.com/www/vendor/prestashop/decimal/src/DecimalNumber.php(73): PrestaShop\Decimal\Builder::parseNumber()
#1 /datas/www/mywebsite.com/www/src/Core/Localization/Number/Formatter.php(147): PrestaShop\Decimal\DecimalNumber->__construct()
#2 /datas/www/mywebsite.com/www/src/Core/Localization/Number/Formatter.php(106): PrestaShop\PrestaShop\Core\Localization\Number\Formatter->prepareNumber()
#3 /datas/www/mywebsite.com/www/src/Core/Localization/Locale.php(154): PrestaShop\PrestaShop\Core\Localization\Number\Formatter->format()
#4 /datas/www/mywebsite.com/www/classes/PaymentModule.php(443): PrestaShop\PrestaShop\Core\Localization\Locale->formatPrice()
#5 /datas/www/mywebsite.com/www/modules/cmcicpaiement/controllers/front/validation.php(165): PaymentModuleCore->validateOrder()
#6  in /datas/www/mywebsite.com/www/src/Core/Localization/Number/Formatter.php on line 108

Le résultat est que 
- Le paiement est bien reçu en banque (même si l'interface retour de la banque affiche une erreur 500, voir access.log :

xxx.xxx.xx.xxx - - [02/Jun/2022:00:06:28 +0200] "POST /fr/module/cmcicpaiement/validation HTTP/1.1" 500 4849 "-" "Monetico HttpClient")

- La commande est bien crée mais assignée à la mauvaise boutique (systématiquement à la boutique par défaut du multistore, ID1, alors qu'elle a été passée sur la boutique ID7)
- En vérifiant la table ps_order_details, les entrées sont attribuées à la bonne boutique (ID7)
- La commande ne possède pas d'état

Dans /classes/PaymentModule.php j'ai passé le DEBUG_MODE à true et je constate bien que le traitement ne semble pas passer par l'ensemble des étapes de l'order validation, le dernier debug d'une commande en défaut est le suivant :     PaymentModule::validateOrder - Message is about to be added

J'ai vu plusieurs cas similaires mais sans solutions / analyses concluantes dans mon cas.

Si quelqu'un a une idée / suggestion je suis preneur car j'ai épuisé toutes mes pistes !

Merci par avance pour votre aide, bonne journée,
 

[Tom Girou]

Visiblement le module de paiement passe de mauvaises informations lors de l'appel à validateOrder() dans son fichier validation.php.

J'investiguerais dedans ce qui est passé en paramètres, comment c'est construit et voir si ça vous donne une piste.

[mathieus]

Bonjour Tom Girou, merci du retour !

J'ai loggé les informations qui sortent vers Monetico et son retour, tout est conforme. En fait mon problème semble être un problème de contexte de boutique au niveau du panier / de la commande, mais je n'arrive pas encore à l'isoler. Le crash au retour du paiement est lié au fait que PrestaShop n'arrive pas à déterminer les bons prix .. car il n'est plus dans le contexte de la boutique depuis laquelle a été passée la commande et ne trouve donc pas le produit / prix approprié. Si jamais quelqu'un a des pistes à ce niveau je suis preneur ! Merci pour l'aide !

[Tom Girou]

1 hour ago, mathieus said:

Bonjour Tom Girou, merci du retour !

J'ai loggé les informations qui sortent vers Monetico et son retour, tout est conforme. En fait mon problème semble être un problème de contexte de boutique au niveau du panier / de la commande, mais je n'arrive pas encore à l'isoler. Le crash au retour du paiement est lié au fait que PrestaShop n'arrive pas à déterminer les bons prix .. car il n'est plus dans le contexte de la boutique depuis laquelle a été passée la commande et ne trouve donc pas le produit / prix approprié. Si jamais quelqu'un a des pistes à ce niveau je suis preneur ! Merci pour l'aide !

J'ai eu exactement ce problème avec une incompatibilité entre deux de mes modules (Axepta de BNP Paribas) et un autre module qui gère les frais de transport par groupe client.

De la même façon que vous, lorsque la passerelle de paiement envoie la notification de résultat de paiement, il est hors contexte, il est donc impossible de récupérer le shop, le client ou le panier via le contexte.

Hors le module qui s'occupe de gérer les frais de port, avait des overrides sur des fonctions utilisées lors de la création de commande, et utilisaient le contexte uniquement. Donc, ça ne fonctionnait pas.

Ce que j'ai fait, c'est qu'avant de récupérer les infos du contexte, j'ai fait un check sur l'existence de paramètres : 
 

$cartIdShop = 0;
if ((int)Tools::getValue('id_cart') > 0) {
  $cart = new Cart((int)Tools::getValue('id_cart'));
  $cartCustomer = new Customer($cart->id_customer);
  $cartCustomerGroup = $cartCustomer->id_default_group;
  $cartIdShop = (int)$cart->id_shop;
}

Vu que ma passerelle de paiement passe en paramètres de requête l'ID Cart entre autres, je check son existence. Si le paramètre existe, alors je vais "recréer" mon objet à partir de son ID. Je recrée le Customer à partir du panier, ainsi que le group, le shop, etc...

Puis au moment d'utiliser les valeurs, j'utilise des ternaires : 

$cartCustomerGroup ?: $oContext->customer->id_default_group

Si ma variable est définie, je l'utilise, sinon, je fallback sur l'utilisation du contexte.

 

Peut-être que cela vous permettra de résoudre le problème ?