Title: Manufourc's Replies | WordPress.org

---

# Manufourc

  [  ](https://wordpress.org/support/users/efourcade/)

 *   [Profile](https://wordpress.org/support/users/efourcade/)
 *   [Topics Started](https://wordpress.org/support/users/efourcade/topics/)
 *   [Replies Created](https://wordpress.org/support/users/efourcade/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/efourcade/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/efourcade/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/efourcade/engagements/)
 *   [Favorites](https://wordpress.org/support/users/efourcade/favorites/)

 Search replies:

## Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[CDI - Collect and Deliver Interface for Woocommerce] Erreur fatale “Class cdi_c_Carrier_colissimo not found” — CDI 5.5.12](https://wordpress.org/support/topic/erreur-fatale-class-cdi_c_carrier_colissimo-not-found-cdi-5-5-12/)
 *  Thread Starter [Manufourc](https://wordpress.org/support/users/efourcade/)
 * (@efourcade)
 * [7 months, 1 week ago](https://wordpress.org/support/topic/erreur-fatale-class-cdi_c_carrier_colissimo-not-found-cdi-5-5-12/#post-18815309)
 * Bonjour,
 * log bien envoyé par mail privé CDI.
 * merci
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[CDI - Collect and Deliver Interface for Woocommerce] Colissimo : erreurs SOAP/WSDL intermittentes (SoapFault Parsing WSDL) en admin](https://wordpress.org/support/topic/colissimo-erreurs-soap-wsdl-intermittentes-soapfault-parsing-wsdl-en-admin/)
 *  Thread Starter [Manufourc](https://wordpress.org/support/users/efourcade/)
 * (@efourcade)
 * [8 months, 4 weeks ago](https://wordpress.org/support/topic/colissimo-erreurs-soap-wsdl-intermittentes-soapfault-parsing-wsdl-en-admin/#post-18766422)
 * Bonjour,
 * Je reviens avec un complément d’analyse sur les erreurs Colissimo (SOAP/WSDL).
   J’ai pu isoler une cause “métier” dans la requête SOAP envoyée à l’API Colissimo,
   et je partage aussi un **workaround temporaire** (patch local) au cas où d’autres
   personnes seraient bloquées en production, en attendant une correction officielle.
 * **1) Symptôme côté Colissimo**
 * Lors d’un KO, l’endpoint SOAP répond :
    - **HTTP 500**
    - `Content-Type: multipart/related; type="application/xop+xml"` (MTOM/XOP)
 * En extrayant la SOAP Fault contenue dans la réponse multipart, on obtient notamment:
    - `faultcode = soap:Client`
    - `faultstring = Unmarshalling Error: Not a number: 633.3333`
 * **2) Cause identifiée : champ `totalAmount` non conforme**
 * Le champ `<totalAmount>` est parfois envoyé avec une valeur décimale à plus de
   2 décimales (ex. `633.3333`), ce qui provoque la fault “Not a number”. Il semble
   que l’API Colissimo attend un format strict (probablement un entier en centimes),
   et rejette une valeur décimale.
 * **3) Fichier et ligne de code concernée**
 * Le champ `totalAmount` est construit dans le fichier :
 * `/wp-content/plugins/collect-and-deliver-interface-for-woocommerce/includes/CDI-
   Carrier-colissimo/Colissimo-Affranchissement.php`
 * Ligne de code concernée (construction de `totalAmount`) :
 * `$service['totalAmount'] = (float)(str_replace (',', '.', $num)) * 100 ;`
 * Dans mon cas, ce calcul peut produire une valeur avec plusieurs décimales une
   fois multipliée par 100 (ex. `633.3333`), alors que l’API semble attendre un 
   entier.
 * **4) Exemple de requête SOAP (sanitisée) qui déclenche l’erreur**
 * Voici un exemple minimal avec données anonymisées. Le point important est la 
   valeur de `totalAmount` :
 * `<?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.
   org/soap/envelope/" xmlns:ns1="http://sls.ws.coliposte.fr" xmlns:xsi="http://
   www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Body> <ns1:generateLabel> <generateLabelRequest
   > <contractNumber>833620</contractNumber> <password>xxxxxx</password> <outputFormat
   > <outputPrintingType>PDF_A4_300dpi</outputPrintingType> </outputFormat> <letter
   > <service> <productCode>DOM</productCode> <depositDate>2025-12-26</depositDate
   > <totalAmount>633.3333</totalAmount> <orderNumber>31426</orderNumber> <commercialName
   >XXX YYY</commercialName> <returnTypeChoice>2</returnTypeChoice> </service> <
   parcel> <weight>0.1</weight> </parcel> <customsDeclarations> <includeCustomsDeclarations
   >1</includeCustomsDeclarations> <contents> <category> <value>3</value> </category
   > </contents> </customsDeclarations> <sender> <senderParcelRef>31426</senderParcelRef
   > <address> <companyName>XXX YYY</companyName> <line2>6 rue XXX YYY</line2> <
   countryCode>FR</countryCode> <city>XXX</city> <zipCode>13000</zipCode> <email
   >email@xxx-yyy.tld</email> </address> </sender> <addressee> <address> <companyName
   >TEST -31426-</companyName> <lastName>xxx</lastName> <firstName>yyy</firstName
   > <line2>66 Rue xxx</line2> <countryCode>FR</countryCode> <city>XXX</city> <zipCode
   >17000</zipCode> <phoneNumber>+336xxxxxxxx</phoneNumber> <mobileNumber>xxxxxxxxxx
   </mobileNumber> <email>xxx.yyy@gmail.com</email> </address> </addressee> </letter
   > </generateLabelRequest> </ns1:generateLabel> </SOAP-ENV:Body> </SOAP-ENV:Envelope
   >`
 * **5) Remarque sur le comportement `SoapClient`**
 * Dans ce cas précis (HTTP 500 + multipart), `SoapClient->__doRequest()` peut retourner`
   NULL` côté PHP, alors que la réponse contient bien la SOAP Fault. Une requête
   équivalente en `curl` récupère bien un body (multipart) contenant l’enveloppe`
   <soap:Fault>…</soap:Fault>`.
 * **6) Workaround temporaire (patch local appliqué)**
 * En attendant une correction officielle, j’ai appliqué un patch local qui force`
   totalAmount` à être un entier en centimes (arrondi), afin d’éviter l’envoi d’une
   valeur décimale non acceptée par Colissimo.
 * **Avant (ligne 183):**
 * `$service['totalAmount'] = (float)(str_replace (',', '.', $num)) * 100 ;`
 * **Après (workaround) :**
 * `$amount = (float) str_replace(',', '.', (string) $num);`
 * `$service['totalAmount'] = (string) (int) round($amount * 100, 0, PHP_ROUND_HALF_UP);`
 * Depuis ce changement, l’erreur `Unmarshalling Error: Not a number` ne se reproduit
   plus de mon côté.
 * Merci d’avance,
   Et joyeuses fêtes !
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[CDI - Collect and Deliver Interface for Woocommerce] Colissimo : erreurs SOAP/WSDL intermittentes (SoapFault Parsing WSDL) en admin](https://wordpress.org/support/topic/colissimo-erreurs-soap-wsdl-intermittentes-soapfault-parsing-wsdl-en-admin/)
 *  Thread Starter [Manufourc](https://wordpress.org/support/users/efourcade/)
 * (@efourcade)
 * [8 months, 4 weeks ago](https://wordpress.org/support/topic/colissimo-erreurs-soap-wsdl-intermittentes-soapfault-parsing-wsdl-en-admin/#post-18766111)
 * Re,
 * Je reviens avec quelques éléments factuels supplémentaires qui peuvent aider 
   à isoler la cause.
 * 1) Le fatal est bien déclenché sur la ligne 308
   Les logs PHP pointent systématiquement:/
   includes/CDI-Carrier-colissimo/Colissimo-Affranchissement.php:308au moment du
   new SoapClient(…?wsdl)
 * Messages rencontrés (selon les occurrences) :
    - “Premature end of data … line 195”
    - “failed to load external entity …”
      (toujours sur “SOAP-ERROR: Parsing WSDL:
      Couldn’t load …?wsdl”)
 * 2) Côté log CDI : j’ai également des occurrences où l’endpoint renvoie du HTML
   503 (nginx)
   Dans le log interne CDI, je constate parfois un contenu de type page
   d’erreur :“503 Service Temporarily Unavailable”avec mention “nginx”.Donc, ponctuellement,
   l’URL WSDL ne renvoie pas un WSDL valide mais une page HTML 503 (ce qui colle
   bien avec les erreurs de parsing WSDL ci-dessus).
 * 3) Vérification “infra” : tests depuis le serveur OK la plupart du temps (curl
   + SoapClient)
   Pour écarter un problème réseau permanent côté serveur, j’ai testé
   directement depuis la machine (Plesk PHP 8.1 CLI, extension soap active) :
    - Résolveur DNS : ~10–15ms
    - HTTPS WSDL : HTTP 200 stable (sur une série de 30 tests), taille constante(
      ~57KB)
    - Et surtout, un probe PHP SoapClient sur la même URL WSDL passe bien :
    - 1er appel ~0.3s (chargement initial)
    - appels suivants ~0.001s (ce qui correspond au WSDL en cache)
    - soap.wsdl_cache_enabled=1 / soap.wsdl_cache_ttl=86400 / default_socket_timeout
      =60
 * Ça ne supprime pas la possibilité d’indisponibilités ponctuelles côté endpoint,
   mais ça semble exclure un souci “réseau/timeout permanent” côté serveur.
 * Merci

Viewing 3 replies - 1 through 3 (of 3 total)