Les commandes ne contiennent pas tout le panier après paiement par CB

[L E O]

Mon message initial n'a plus lieu d'être puisque j'ai trouvé l'origine du problème expliquée dans le message suivant qui reste actuellement sans réponse de la part de Prestashop.

 

En parcourant les forums on s'aperçoit que l'incident existe depuis plusieurs années mais je n'ai pas trouvé de solution concrète.

 

Apparemment le processus de conversion du panier en commande ne va pas à son terme après le paiement par Carte.

 

Merci pour vos pistes d'investigation ou solution !

 

--------------------------------------------------------------------------------------------------------------------------------------------

 

Je suis sidéré par ce que je viens de découvrir : Prestashop ne sait pas faire une simple addition !

Je modère mes propos aux vues des résultats présentés dans le post suivant, en espérant que cela puisse faire avancer la résolution.

 

J'ai constaté cela avec effarement sur le site d'un client qui me demandait, à juste titre, pourquoi les montants des factures sont toujours surévalués de quelques centimes ou euros. (PS 1.6.1.1 avec default-bootstrap)

 

Le total des montants est systématiquement faux comme le montre les deux copies ci-jointes (je peux en fournir des centaines d'autres).

Ex 1: 108,44 + 68,80 + 0,95 = 178,19 et Prestashop trouve 182,32

Ex 2: 226,74 + 68,34 + 9,86 = 304,94 et Prestashop trouve 305,19

 

Pour quelle raison le calcul est-il faux, cela semble incompréhensible ?

 

Cette situation est extrèmement grave puisque tout le calcul qui suit (TVA etc) sur la facture est donc faux aussi.

Je rappelle qu'une facture fausse en comptabilité est soumise à une amende.

 

Qui va payer pour l'ensemble des fausses factures crées par Prestashop ?

 

Je pense qu'il y a urgence à régler ce problème.

Edited September 10, 2015 by L E O (see edit history)

[L E O]

Bon, après quelques heures de recherche voici une première piste à explorer.

Il se trouve que de nombreuses commandes ne contiennent pas la totalité des produits commandés par les clients.

Elles sont soit vides soit incomplètes.

En interrogeant quelques clients concernés, tous ont obtenus une page blanche (erreur 500) après avoir effectué leur paiement.

 

Le processus qui transforme le panier en commande n'arrive donc pas à son terme ce qui génère:

• des commandes vides ou incomplètes
• un différence entre le total des montants des articles et celui réellement facturé

En contrôlant, le contenu des paniers et celui des commandes correspondantes je retrouve bien la différence.

 

Comment résoudre en URGENCE ce problème SVP ?

 

La configuration est la suivante : PS 1.6.1.1

Hébergement sur serveur dédié OVH : PHP 5.3.3, MySQL 5.1

Détail du php info

Directive    Local Value    Master Value
allow_call_time_pass_reference    Off    Off
allow_url_fopen    On    On
allow_url_include    Off    Off
always_populate_raw_post_data    Off    Off
arg_separator.input    &    &
arg_separator.output    &    &
asp_tags    Off    Off
auto_append_file    no value    no value
auto_globals_jit    On    On
auto_prepend_file    no value    no value
browscap    no value    no value
default_charset    no value    no value
default_mimetype    text/html    text/html
define_syslog_variables    Off    Off
disable_classes    no value    no value
disable_functions    no value    no value
display_errors    Off    Off
display_startup_errors    Off    Off
doc_root    no value    no value
docref_ext    no value    no value
docref_root    no value    no value
enable_dl    Off    Off
error_append_string    no value    no value
error_log    no value    no value
error_prepend_string    no value    no value
error_reporting    22527    22527
exit_on_timeout    Off    Off
expose_php    On    On
extension_dir    /usr/lib64/php/modules    /usr/lib64/php/modules
file_uploads    On    On
highlight.bg    #FFFFFF    #FFFFFF
highlight.comment    #FF8000    #FF8000
highlight.default    #0000BB    #0000BB
highlight.html    #000000    #000000
highlight.keyword    #007700    #007700
highlight.string    #DD0000    #DD0000
html_errors    Off    Off
ignore_repeated_errors    Off    Off
ignore_repeated_source    Off    Off
ignore_user_abort    Off    Off
implicit_flush    Off    Off
include_path    .:/usr/share/pear:/usr/share/php    .:/usr/share/pear:/usr/share/php
log_errors    On    On
log_errors_max_len    1024    1024
magic_quotes_gpc    Off    Off
magic_quotes_runtime    Off    Off
magic_quotes_sybase    Off    Off
mail.add_x_header    On    On
mail.force_extra_parameters    no value    no value
mail.log    no value    no value
max_execution_time    3600    3600
max_file_uploads    20    20
max_input_nesting_level    64    64
max_input_time    -1    -1
max_input_vars    6000    6000
memory_limit    512M    512M
open_basedir    no value    no value
output_buffering    4096    4096
output_handler    no value    no value
post_max_size    8M    8M
precision    14    14
realpath_cache_size    16K    16K
realpath_cache_ttl    120    120
register_argc_argv    Off    Off
register_globals    Off    Off
register_long_arrays    Off    Off
report_memleaks    On    On
report_zend_debug    On    On
request_order    GP    GP
safe_mode    Off    Off
safe_mode_exec_dir    no value    no value
safe_mode_gid    Off    Off
safe_mode_include_dir    no value    no value
sendmail_from    no value    no value
sendmail_path    /usr/sbin/sendmail -t -i    /usr/sbin/sendmail -t -i
serialize_precision    100    100
short_open_tag    On    On
SMTP    localhost    localhost
smtp_port    25    25
sql.safe_mode    Off    Off
track_errors    Off    Off
unserialize_callback_func    no value    no value
upload_max_filesize    20M    20M
upload_tmp_dir    no value    no value
user_dir    no value    no value
user_ini.cache_ttl    300    300
user_ini.filename    .user.ini    .user.ini
variables_order    GPCS    GPCS
xmlrpc_error_number    0    0
xmlrpc_errors    Off    Off
y2k_compliance    On    On
zend.enable_gc    On    On

Edited September 9, 2015 by L E O (see edit history)

[imaction_mo]

HELP je subis la même chose amis je ne trouve pas la réponse. C'est très urgent bien sûr...

[imaction_mo]

up!

Je confirme que le processus qui transforme le panier en commande peut arriver à son terme "altéré", ce qui a généré en 3 jours (malheureux concours de circonstances? ):

• une commande payée par le client mais vide en BO. J'ai du aller rechercher le panier de la cliente...
• une commande incomplète. Entre le moment du panier, du paiement et de la finalisation de commande un produit s'est trouvé en rupture mais la cliente l'a payé et elle ne le retrouve pas dans sa commande alors qu'il était dans son panier
• une différence entre le total des montants des articles dans le panier et celui réellement facturé (je pense que le client avait préparé plusieurs jours à l'avance son panier et le cache a fait le reste...)...

J'aimerais bien comprendre le cheminement prestashop....

[Eolia]

Pas simple à debuguer, les raisons peuvent être multiples.

 

• Lors de l'ajout au panier Prestashop récupère le contexte issu du cookie (1ère source d'erreur potentielle si vous jouez entre le back office et le front)
• Avec ce contexte il ajuste les données suivant l'id_customer, les règles paniers, de groupe, de pays etc...
• Si vous avez des modules hookés sur l'ajout au panier, ceux-ci entrent en jeu (et si l'un d'entre eux plante lamentablement, echec du retour)
• Toutes ces actions se font en échange avec le serveur par rechargement de la page ou en ajax (javascript qui appelle une url du serveur et serveur qui renvoie les infos). Si votre serveur rame un peu et met du temps à répondre c'est une nouvelle cause d'échec.

Pour controler les éventuelles erreurs serveur commencez par activer l'affichage des erreurs et ouvrez également la console du navigateur pour analyser les retours xhr. Vérifiez les modules accrochés sur ce hook et regardez les logs d'erreurs de presta.

[imaction_mo]

Bonjour

merci pour ce message intéressant.

Nous avons dupliqué le site sur un autre domaine sur le meme serveur

Nous allons faire les tests

 

Merci beaucoup pour ces infos

[L E O]

Imaction_mo est-ce que vous avez du nouveau sur ce problème qui persiste chez mon client.

Merci pour votre retour d'expérience.

[Eolia]

Pour info, depuis 2 jours que le forum rame, de nombreuses commandes sont payées mais retour paiement échoué... coincidence ? Vérifiez quels modules sont greffés sur le hook validateOrder

[imaction_mo]

Bonjour

Merci pour  tous ces échanges

 

Une question : Eolia que voulez-vous dire par "Vérifiez quels modules sont greffés sur le hook validateOrder"?

 

En ce qui concerne les erreurs 500, nous avons fait intervenir le développeur du module CIC Paiement, nous sommes en attente de sa réponse

 

Depuis ces commandes "malheureuses", nous avons fait installer "speedlite" sur notre serveur. La différence de temps de réponse semble assez importante.

Nous avons réduit le délai cookies front office.

 

Nous avons eu plusieurs commandes sans soucis pour l'instant...

 

Nous attendons encore quelques jours puis nous passerons en 1.6.13

 

Cordialement

[Eolia]

Allez dans Modules -> Position,  Afficher les points d'accroche invisibles et regardez quels modules sont accrochés sur le hook validateorder, si l'un d'eux plante, le temps de réponse devient trop long et la banque a déjà refermé sa connexion, donc Prestashop n'ayant pas le retour (OK ou KO) n'arrive pas à finaliser la commande. (Panier vide et ou pas de statut)

Edited January 14, 2016 by Eolia (see edit history)