Gnidhal
6 Oct 2006, 16:40
fissiaux
6 Oct 2006, 18:47
Une fois que tu auras corrigé le define qui manque, enlève le long code que tu as posté et qui ne sert à rien.
CITATION(fissiaux @ 6 Oct 2006, 19:47) [snapback]198047[/snapback]
Une fois que tu auras corrigé le define qui manque, enlève le long code que tu as posté et qui ne sert à rien.
j'ai toujours la meme erreur qui s'affiche
effectivement il manquait le define dans le application_top du catalog mais j'ai toujours la meme erreur qui s'affiche au niveau du serveur...
merci de m'aider car j'ai vraiment besoin de cette contrib..
merci
Gnidhal
9 Oct 2006, 12:50
Si tu as corrigé et que tu as toujours l'erreur c'est que ta correction n'est pas bonne.
Reprends pas à pas le fichier d'install et vérifie que tu as tout fait.
zingueur
17 Oct 2006, 14:59
Bonjour,
J'ai installé ordecheck. Tout semble fonctionner. Y compris l'enregistrement des commandes sauf que après paiement, en cliquant sur le bouton retour à la boutique, j'ai ce message :
Fatal error: Cannot redeclare tep_db_connect() (previously declared in /home/wb46213/catalog/includes/functions/database.php:13) in /home/wb46213/catalog/includes/functions/database.php on line 13
Quelqu'un a eu ce problème.
Y-a-til un rapport avec une autre contrib Qtpro ?
Merci par avance de votre aide

....
apparemment mon erreur serait celle-ci:
http://www.oscommerce-fr.info/faq/qa_info.php?qID=168mais je ne vois pas quel fichier est en cause...
je cherche.

Touvé. Suis-je bête. Oubliez ce post.
Gnidhal
17 Oct 2006, 17:09
CITATION(zingueur @ 17 Oct 2006, 15:59) [snapback]199827[/snapback]
Touvé. Suis-je bête. Oubliez ce post.
Bin ce serait cool de dire quelle est ton erreur initiale et quelle est ta soluce... pour les zôtres
Norheco
27 Oct 2006, 16:24
Que de travail sur cette contribution, bravo tout le monde.
J'en suis à l'installation moi aussi de cette contribution. J'ai un petit soucis sur un point: dans la contrib, il est mentionné de admin /boxes/customers.php de changer cette ligne:
'<a href="' . tep_href_link(FILENAME_ORDERS, '', 'NONSSL') . '" class="menuBoxContentLink">' . BOX_CUSTOMERS_ORDERS . '</a><br>');
Au départ, je comprends qu'il s'agit plutôt de admin /includes/boxes/customers.php, une simple erreur que je mentionne ici et qui pourrait aider un néophite (ce que je suis pas mal d'ailleurs).
Mais, si je regarde les lignes auxquelles on semble faire référence, dans mon fichier, elles sont écrites comme ceci:
'<a href="' . tep_href_link(FILENAME_ORDERS, '', 'NONSSL') . '" class="menuBoxContentLink">' . BOX_CUSTOMERS_ORDERS . '</a>');
Je n'ai pas de <br> à la fin. Je ne sais trop quoi faire avec ce changement, quelqu'un pourrait m'aiguiller. Je sais que ce petit problême est très simple comparé à ceux dont vous faites mention dans ce post.
Merci, Normand...
thierry_montpellier
15 Nov 2006, 18:22
Bonjour a tous

Jolie post a lire mais tres intéressant

Et vous avez l'air d'avoir fais de jolie boulot.
Cette contribution est parfaite pour recupérer des commandes perdues ce qui est rarement mon cas (utilisation de PAYPAL et SP+) depis que j'ai bien configuré le tout.
Mon souhait c'est de pouvoir connaitre les commandes non arrivé a terme pour envoyer un email au client pour leur donner un lien vers un questionnaire rapide pour savoir pourquoi il n'ont pas acheté les articles contenus dans leur panier et donc améliorer grandement la boutique dans ce sens

La contribution me convenait je pense au début mais plus maintenant car le controle a l'air de se faire pour les paiements extérieurs à la boutique. Pouvez vous m'en dire plus ???
d'avance merci
Thierry
Celluloid
15 Nov 2006, 18:36
Bon, je vais discrètement reposter ici avant que mon sujet externe tombe dans les oubliette (les up, c'est mââl

) :
CITATION
OrderCheck et Order Editor sont-elles compatibles ?
Dans quel ordre vaut-il mieux installer l'une et l'autre pour minimiser les arrachages de cheveux ?
Yann06
15 Nov 2006, 18:49
Je ne veux pas f... le b... , mais n'est-t-il pas plus simple (sur des boutiques de moyenne envergure), d'utiliser la contrib recover card sales + order editor ??
C'est celle qui me permet lors d'une bourde du check-out avec spplus de retrouver le panier de l'acheteur et si le paiement à bien été effectué, de créer la commande fantôme.
Ok, on fait ça "a la main", mais au moins on passe par tous les points de verif.......
Gnidhal
15 Nov 2006, 19:25
CITATION(thierry_montpellier @ 15 Nov 2006, 18:22) [snapback]205825[/snapback]
La contribution me convenait je pense au début mais plus maintenant car le controle a l'air de se faire pour les paiements extérieurs à la boutique.
en effet, dans ce cas replies-toi d'une version : la 2.0 est parfaite pour ton usage.
CITATION(Celluloid @ 15 Nov 2006, 18:36) [snapback]205831[/snapback]
OrderCheck et Order Editor sont-elles compatibles ?
Dans quel ordre vaut-il mieux installer l'une et l'autre pour minimiser les arrachages de cheveux ?
Heuuu bin heuuu...
Alors, je ne tutoies pas personnellement Order Editor mais de ce que j'ai vu elle touche aux tables "orders_" ce que ne fait pas OrderCheck. Donc pas d'incompatibilité de principe mais faut voir ce que fait Order Editor... dans le principe OrderCheck pré-enregistre les commandes dans d'autres tables. Si les commandes arrivent au bout de leur chemin normal, elles sont enregistrées dans les tables orders_... après OrderCheck peut comparer les tables et si il y a une différence (absence de commande dans les tables orders_ alors qu'elle l'est dans orders_check_) allumer un voyant rouge.
Après si la commande est modifiée par Orders Editor, la comparaison sera donc fausse (voyant rouge).
CITATION(Yann06 @ 15 Nov 2006, 18:49) [snapback]205833[/snapback]
Je ne veux pas f... le b... , mais n'est-t-il pas plus simple (sur des boutiques de moyenne envergure), d'utiliser la contrib recover card sales + order editor ??
C'est un peu le problème de tout Open Source et de ses addons. Chacun développe son bidule dans son coin en fonction de ses besoins. Il existe donc souvent plusieurs contributions répondant à un problème récurant car chacun y est allé de sa petite analyse et a vu le problème par sa lorgnette.
JE ne connais pas recover cart... sûrement un truc utile. Faut voir...
Yann06
16 Nov 2006, 11:54
Pour info, recover card sales permet d'avoir un listing des paniers clients (+email+tel+nom+prix etc..)Donc la commande perdue puisqu'elle est sensé etre encore dans le panier.
Elle permet aussi d'envoyer un email à tous les clients qui n'ont pas finalisé leur panier (ou à un seul)
Et bien sur, de vider les paniers...
Voilou pour l'info Gnidhal....je répètes que c'est pour une boutique de petite envergure et que OrderCheck me semble plus "pro" dans son utilisation.(et bravo pour le boulot sur celle-ci)
C'etait juste pour donner un palliatif, une autre vision (ma petite lorgnette !!!

)
marsupouse
17 Nov 2006, 12:16
Bonjour à tous et merci pour cette contibution, bien pratique ma foie avec ATOS...
Alors j'ai juste un petit problème que j'ai isolé mais en fait je ne comprends pas comment à la base s'est sensé marcher (jsuis sur MS2 et jai laderniere version de ordercheck).
Alors voila en fait j'ai toujours un id_orders en décalage de 1 entre la table orders et holding_orders, et donc forcement le voyant reste au rouge ds l'admin même lorsque la commande est bien validée...
Apres quelques recherches, je ne vois pas comment cela pourrait etre possible autrement, vu qu'avant de rentrer les infos ds les tables on verifie l'id le + grand et on incrémente...
Bien sur je dois louper qqchose

Une ptite piste ?
MErci a tous et bone continuation
Gnidhal
17 Nov 2006, 12:55
peut-être un bug que je n'ai pas fixé correctement avec l'id commande.
En fait on prend le dernier ID (tables normales et tables de secours pour éviter les doublons), on incrémente et on enregistre dans les tables de secours. Dans le cas où la commande se termine normalement, l'incrément est normalement fait sur la dernière commande dans la table orders, pas sur la dernière dans la table orders_check.
Si l'incrément se fait là aussi sur le plus haut des deux tables, tu viens de trouver le bug

je ne suis pas sur ce code en ce moment, alors si tu trouves la soluce, nous sommes preneurs
marsupouse
17 Nov 2006, 13:59
A prioris c'est ca

jpensais plus a une defaillance de mon coté avt de remettre en compte ca

donc ds l'install la modif a faire sur checkout_process est la même sur checkout_confirmation
a savoir
CODE
// test last orders_id
$_oders_max_query = tep_db_query("select max(orders_id) as max_id from " . TABLE_ORDERS . "");
$_oders_max = tep_db_fetch_array($_oders_max_query);
$_orders_id = $_oders_max["max_id"];
// test last holding_orders_id
$holding_oders_max_query = tep_db_query("select max(orders_id) as max_id from " . TABLE_HOLDING_ORDERS . "");
$holding_oders_max = tep_db_fetch_array($holding_oders_max_query);
$holding_insert_id = $holding_oders_max["max_id"];
// assign last orders_in to prevent duplicate entry
$insert_id = ($_orders_id >= $holding_insert_id )? $_orders_id+1 : $holding_insert_id+1;
que l'on peut donc peut etre remplacer pour checkout_process par (on supprime le test tt betement) :
CODE
// test last holding_orders_id //le dernier id validé et testé est ds cette table, vu qu'on passe tjrs par elle avant
$holding_oders_max_query = tep_db_query("select max(orders_id) as max_id from " . TABLE_HOLDING_ORDERS . "");
$holding_oders_max = tep_db_fetch_array($holding_oders_max_query);
$holding_insert_id = $holding_oders_max["max_id"];
// assign last orders_in to prevent duplicate entry //on prends le mm on incrémente pas et basta
$insert_id = $holding_insert_id;
Y'a bon

?
EDIT: y a qd même un truc qui me chagrine la jpense que j'oublie un parametre :s. attends jvais y arriver
Gnidhal
17 Nov 2006, 14:29
sur la bonne piste (désolé pas les moyens de tester) mais je pense plutôt que c'est
CODE
$insert_id = $_orders_id+1;
(j'ai du faire un copier/coller malheureux lors de la réalisation du pack)
[edit] Bah non plus, à la réflexion. c'est peut-être toi qui a raison... encore que... si la précédente commande n'est pas passée (donc dans holding uniquement)... heuuuu gratt-gratt
marsupouse
17 Nov 2006, 16:09
j'ai pensé a la même chose que toi au début...il me semblait plus logique d'etre sur l'id order et puis en fait non ca ne marcherait pas non plus...
d'ou l'autre solution mais je sens qu'il y a une couille...
mais en mm temps on verifie la 1ere fois l'id le + haut des 2 tables, et on l'attribue a la table holding...
donc ensuite si on recupere le dernier holding forcement il est pas en double ds la table order
mais comme tu dis...grat...grat
Gnidhal
17 Nov 2006, 20:21
oui la soluce serait dans checkout_process uniquement : (cheminement normal d'une commnade)
CODE
$insert_id = ($_orders_id >= $holding_insert_id )? $_orders_id+1 : $holding_insert_id;
car les holdings_orders ne sont pas utilisées quand la commande est payée par chèque par exemple.
d'où le cas du test !
en ce qui concerne checkout_confirmation, le code est inutile je crois car reporté dans le functions/orderscheck_functions...
marsupouse
20 Nov 2006, 13:56
Ok nickel

c'est vrai que j'avais zappé pour les commandes autres que par CB vu que je ne fais que ca ds les boutiques OScommerces
en tout cas ca a l'air de bien rouler
brousaille
22 Nov 2006, 06:44
J'ai remarqué un bug avec cette contrib quand elle tourne avec QTPro. En cas d'échec d'une commande, on à la posibilité de faire un move de la commande fantome et de la rendre active. Seulement la mise a jour des stocks ne prend pas en compte les attributs définis avec QTPro.
Quelqu'un s'est t'il penché sur ce problème ?
Merci par avance
B.
Gnidhal
22 Nov 2006, 08:50
CITATION(brousaille @ 22 Nov 2006, 06:44) [snapback]206998[/snapback]
J'ai remarqué un bug avec cette contrib quand elle tourne avec QTPro.
Non, ce n'est pas un bug

c'est à toi d'adapter la contrib pour qu'elle fonctionne avec QTPro
Bonjour,
je me permet de venir ici, car je viens d'installer cette contrib (2.5.1) (qui se revele indispensable, je ne comprend pas comment on pouvais avoir une trace de commande si le client ne reviens pas à la boutique.....)
J'ai testé plusieurs fois mais elle ne fonctionne pas, je n'ai aucune commandes dans "controles de commandes", j'ai reverifier la procédure d'installation une 2eme fois, tres doucement....
Pourtant, aucun message d'erreur nul part....
Et à la validation de commande non plus (checkout_success), rien dans "controles des commandes" (sauf dans la page "commandes" bien sur)
Merci pour votre aide.
Gnidhal
22 Nov 2006, 15:27
la 2.5.1 n'enregistre les commandes que dans le cas d'un mode de paiement externe (paypal ou serveur de banque)
les règlements par chèque ou autre ne sont pas préenregistrés.
Pour pré enregistrer toutes les commandes, il faut prendre la version précédente, la 2.0 (qui fonctionne parfaitement d'ailleurs)
Je ferais un update de cette contrib' dans les prochaines semaines avec les derniers fix
brousaille
23 Nov 2006, 04:40
CITATION(Gnidhal @ 22 Nov 2006, 03:50) [snapback]207002[/snapback]
Non, ce n'est pas un bug

c'est à toi d'adapter la contrib pour qu'elle fonctionne avec QTPro

Oui c'est vrai !!!

Et est ce que qqun c penché dessus ? Sinon je le ferrai
demoalt
23 Nov 2006, 16:19
Je viens d'installer la contrib 2.5.1
Pour info j'ai le même bug.... donc je vais voir pour les modifs à faire.
par contre, mettre une option pour la prochaine version d'enregistrer toutes les commandes (meme paiement par chèque) est une très bonne idée!
A+
CITATION(marsupouse @ 17 Nov 2006, 06:16) [snapback]206192[/snapback]
Bonjour à tous et merci pour cette contibution, bien pratique ma foie avec ATOS...
Alors j'ai juste un petit problème que j'ai isolé mais en fait je ne comprends pas comment à la base s'est sensé marcher (jsuis sur MS2 et jai laderniere version de ordercheck).
Alors voila en fait j'ai toujours un id_orders en décalage de 1 entre la table orders et holding_orders, et donc forcement le voyant reste au rouge ds l'admin même lorsque la commande est bien validée...
Apres quelques recherches, je ne vois pas comment cela pourrait etre possible autrement, vu qu'avant de rentrer les infos ds les tables on verifie l'id le + grand et on incrémente...
Bien sur je dois louper qqchose

Une ptite piste ?
MErci a tous et bone continuation
Ghibli
24 Nov 2006, 11:44
Bonjour,
Juste pour information, en testant avec cette contribution 2.5.1, j'ai remarqué que la redirection de checkout_payment_ext.php ne fonctionnait pas sous Firefox. Il semble que ce soit un bug avec SetTimeout().
J'ai mis dans le <head> :
CODE
<script language="javascript">
function adresse() {
window.document.forms["checkout_confirmation"].submit();
}
setInterval("adresse()", parseInt('10000'));
</script>
Et là ca fonctionne.
Je ne sais pas si cela vous est arrivé mais ça fonctionne ainsi.
Concernant le voyant rouge, il est toujours rouge chez moi dans le contrôle des commandes même après une validation de paiement... Je ne sais pas si il reste toujours un bug.
Ceci dit, merci énormément pour cette contribution et votre temps passé dessus car vous ne pouvez pas savoir comment celà à arrangé les choses entre moi et ma cliente, et in fine pour les clients de la boutique...
Merci
Gnidhal
24 Nov 2006, 14:45
Bonjour,
lis bien les messages précédents dans ce post et notamment celui-ci. :
http://www.oscommerce-fr.info/forum/index....st&p=206294Le petit fix a été proposé pour le problème que tu cites. ça devrait résoudre le coup du voyant rouge.
Sinon la 2.0 fonctionne à merveille mais enregistre toutes les commandes en double, quel que soit le mode de paiement.
Quand ou problème lié à la tempo javascript, j'avoue ne pas l'avoir rencontré. Merci toutefois pour ce petit fix.
Le problème dépend peut-être de la config de l'hébergement ou du niveau de sécurité du navigateur.
Ghibli
24 Nov 2006, 15:09
Bonjour Gnidhal,
Merci pour ta réponse, ça fait plaisir.
J'ai donc fait ainsi :
CODE
// assign last orders_in to prevent duplicate entry
//$insert_id = ($_orders_id >= $holding_insert_id )? $_orders_id+1 : $holding_insert_id+1;
$insert_id = ($_orders_id >= $holding_insert_id )? $_orders_id+1 : $holding_insert_id;
// ------------------------------------------------------------------------------------------
$sql_data_array = array(
'orders_id' => $insert_id,
'customers_id' => $customer_id,
'customers_name' => $order->customer['firstname'] . ' ' . $order->customer['lastname'],
On verra bien avec les nouvelles commandes

Pour firefox le niveau était normal, fonctionnant avec d'autres sites, quant à l'hébergement je ne sais pas.. J'avais vu trainer justement la fonction setTimeout sur bugzilla, va savoir...
Merci en tout cas...
demoalt
24 Nov 2006, 17:49
pour moi ca passe. par contre les vérifs de duplicate ne sont pas exactes, j'ai changé le code suivant dans check_orders_check.php (admin/includes/functions) pour ne pas prendre en compte la différence de 'status'.
CODE
function check_duplicate_orders_flag($orders_check_id, $languages_id) {
// $orders_query_duplicate_orders = "select o.orders_id, o.customers_id, o.customers_name, o.payment_method, s.orders_status_name, ot.text as order_total from " . TABLE_ORDERS . " o left join " . TABLE_ORDERS_TOTAL . " ot on (o.orders_id = ot.orders_id), " . TABLE_ORDERS_STATUS . " s where o.orders_id = '" . $orders_check_id . "' and o.orders_status = s.orders_status_id and s.language_id = '" . $languages_id . "' and ot.class = 'ot_total' order by o.orders_id DESC";
$orders_query_duplicate_orders = "select o.orders_id, o.customers_id, o.customers_name, o.payment_method, ot.text as order_total from " . TABLE_ORDERS . " o left join " . TABLE_ORDERS_TOTAL . " ot on (o.orders_id = ot.orders_id), " . TABLE_ORDERS_STATUS . " s where o.orders_id = '" . $orders_check_id . "' and o.orders_status = s.orders_status_id and s.language_id = '" . $languages_id . "' and ot.class = 'ot_total' order by o.orders_id DESC";
$check_duplicate_orders = tep_db_query($orders_query_duplicate_orders);
$check_duplicate_orders = tep_db_fetch_array($check_duplicate_orders);
// $orders_query_duplicate_holding = "select oc.orders_id, oc.customers_id, oc.customers_name, oc.payment_method, s.orders_status_name, ot.text as order_total from " . TABLE_HOLDING_ORDERS . " oc left join " . TABLE_HOLDING_ORDERS_TOTAL . " ot on (oc.orders_id = ot.orders_id), " . TABLE_ORDERS_STATUS . " s where oc.orders_id = '" . $orders_check_id . "' and oc.orders_status = s.orders_status_id and s.language_id = '" . $languages_id . "' and ot.class = 'ot_total' order by oc.orders_id DESC";
$orders_query_duplicate_holding = "select oc.orders_id, oc.customers_id, oc.customers_name, oc.payment_method, ot.text as order_total from " . TABLE_HOLDING_ORDERS . " oc left join " . TABLE_HOLDING_ORDERS_TOTAL . " ot on (oc.orders_id = ot.orders_id), " . TABLE_ORDERS_STATUS . " s where oc.orders_id = '" . $orders_check_id . "' and oc.orders_status = s.orders_status_id and s.language_id = '" . $languages_id . "' and ot.class = 'ot_total' order by oc.orders_id DESC";
$check_duplicate_holding = tep_db_query($orders_query_duplicate_holding);
$check_duplicate_holding = tep_db_fetch_array($check_duplicate_holding);
/* print_r($check_duplicate_holding);
print_r($check_duplicate_orders);
*/
$flag = ($check_duplicate_holding == $check_duplicate_orders) ? true : false;
return $flag;
}
schumi31
27 Dec 2006, 11:13
j'ai installé cette contribu mais j'ai un pb lors du choix du mode de paiement CB via Cic Cybermut...
lorsque on selectionne ce mode de paiement, on a bien la page intermédiaire de la contribu puis au bout de 10sec j'arrive sur la page du panier vide....
la redirection vers le serveurc CIC est zappé...
Gnidhal
27 Dec 2006, 11:19
Je ne suis pas sûr que cette contrib soit compatible avec cybermut...
mais revois l'install au cas où
reflet
18 Jan 2007, 17:03
Bonjour,
J'ai installé order check_2.5.1b et tout va bien dans l'admin mais quand
j'essaie à passer une commande j'arrive à check out confirmation et
je trouve cet message :
1054 - Champ 'comments' inconnu dans field list
insert into holding_orders (customers_id, customers_name, customers_street_address, customers_suburb, customers_city, customers_postcode, customers_state, customers_country, customers_telephone, customers_email_address, customers_address_format_id, delivery_name, delivery_street_address, delivery_suburb, delivery_city, delivery_postcode, delivery_state, delivery_country, delivery_address_format_id, payment_method, cc_type, cc_owner, cc_number, cc_expires, date_purchased, orders_status, comments, currency, currency_value) values ('2', 'mark xxxxx', '', '', 'xxxxx', 'xxxxx', 'cantal', 'France', 'xxxxxxxxxx', 'xxxxxxxxxx@free.fr', '1', 'xxxxx xxxxx', ', '', 'xxxxx', 'xxxxx', 'xxxxx', 'France', '1', 'Paiement Sécurisé sur le site Caisse d\'Epargne', '', 'mark xxxxxxx', '', '', now(), '1', '', 'EUR', '1.00000000')
[TEP STOP]
Merci
Reflet
Gnidhal
18 Jan 2007, 17:38
Salut,
D'abord, quand tu publies une requête par copier/coller, efface toutes les donnés personnelles comme une adresse mail ou un téléphone ou un nom.
Ici on est sur le web, donc c'est lisible du monde entier

En ce qui concerne ton problème, je ne sais pas ce que tu as bricolé, mais la table "orders" et à fortiori "holding_orders" ne comporte pas de champs "comments".
Donc reprends l'install et tes modifications...
reflet
18 Jan 2007, 20:22
Merci Gnidhal ce vrai
Donc deuxieme question est-ce-que check orders est compatible avec header tags ?
que pense tu
mon probleme commence après que j'ai installé header tags.
merci
Reflet
Gnidhal
18 Jan 2007, 21:00
A ma connaissance Headers_tags ne touche pas aux tables "orders" donc je ne vois pas le rapport.
reflet
19 Jan 2007, 11:44
j'ai trouver

j'ai installé check orders correctement, par contre j'ai installé le fichier SQL de la contribution
order logging donc ça ne fonctionnait pas.
merci pour votre aide.
Reflet
rtony30
20 Jan 2007, 22:22
bonjour
suite a l instalation de la contribution check order j ai u n probleme avec le paiment par cheque
dans l admin je voit pas les commande des client qui on effectué un paiment par cheque
par contre je recoit un email de leur commande
d ou ca peut venir svp?
cloubech
20 Jan 2007, 22:32
est-ce que le message de Gnidhal du 22 novembre dans cette page répond à ta question ?
rtony30
20 Jan 2007, 22:58
si j ai bien compris la commande par cheque ne peut pas etre dans controle commande
mais avant je voyais les commande cheque dans commande
donc on est oblige d enlever le paiment par cheque?
@+
Gnidhal
20 Jan 2007, 23:01
CITATION(rtony30 @ 20 Jan 2007, 22:58) [snapback]217153[/snapback]
donc on est oblige d enlever le paiment par cheque?
Non, aucun rapport avec la contribution, je ne vois pas quel est ton problème.
Dans le paiement par chèque cette contribution n'est pas exploitée. Si tu perds des commandes, vérifie ton installation
jerome le grand
20 Jan 2007, 23:40
les gas il faut lire le fichier d'install complet surtout que c'etais ecrit au debut du fichier
apres ont se demande pourquoi vous avez des problemes d'install.

CITATION
Quoi de neuf dans cette version 2.5.1 parv rapport à la version 2.5 ?
Cette nouvelle version n'enregistre les commandes dans les tables de sauvegarde uniquement si la méthode de paiement utilise un serveur externe comme un serveur de banque ou Paypal.
Toutes les commandes utilisant une méthode de paiement locale (par chèque, à la livraison...) ne risquant pas de se perder, ne sont pas dupliquées dans les tables "holding_orders".
NB : Si vous souhaitez sauvegarder en double toutes les commandes utilisez la version 2.5 de Order Check (version précédente)
rtony30
21 Jan 2007, 09:38
salut
je parle pas d avoir les commande par chèque dans les table de sauvegarde
je dit que les commandes passe par cheque, on les voit pas dans commande(comme ca fonctionner avant d installer)
par contre je voit la commande dans l email que je recoit
Gnidhal
21 Jan 2007, 10:19
Repars de ta sauvegarde avant install et refais l'installation pas à pas.
Je ne vois pas pourquoi chez toi ça marcherait différemment d'ailleurs.
rtony30
21 Jan 2007, 12:07
salut
le probleme c est que j ai eu un souci avec ma sauvegarde hier
j ai galeré pour l installer j ai recommencer 4fois
donc j ai plus les fichier avant l install de check order
peut tu me dire au moin sur quel fichier ca peut venir
merci@+
vu que je recoit la commande par email ca veut dire quelle est pris en compte
ca viendrais pas d un fichier dans l admin ?
car le client ne voit pas ca commande et moi dans l admin non plus
j ai charger un fichier checkout_process.php propre
on voit la commande par cheque
donc je vais rajouter le code de la contrib pour voir
cest OK tout semble fonctionné merci
je crie pas eureka car hier j ai crié trop top
merci
Apres avoir relu tout le sujet, et relu toute l'installation (versioin 2.5.1), je ne comprend pas trop le principe qui me pose probleme :
Quand un client revien bien à la boutique apres paiement, l'order_id saute toujours un numéro, donc la commande du controles de commande reste ROUGE, puisqu'il a un ID different.
Je comprend l'interet d'assigner un numéro ID avec ceci dans le checkout_process :
CODE
// assign last orders_in to prevent duplicate entry
$insert_id = ($_orders_id >= $holding_insert_id )? $_orders_id+1 : $holding_insert_id+1;
Mais j'ai du louper quelque chose, car ou est la fonction(dans la partie boutique) qui compare la commande pour pouvoir lui assigner orders_id+1(quand un client retourne a la boutique) et non holding_orders_id+1 ??
Si je comprend bien cette ligne, dans la table orders le dernier ID est par ex.: 10, lors du passage sur checkout_payment_ext, il créé la commande avec l'ID 11 dans la table holding, au retour du client sur checkout_process, il compare, et comme 10 n'est pas >= a 11, il me fait une commande validé avec un ID de 12
J'ai loupé quelque chose ?
Gnidhal
21 Jan 2007, 21:47
la 2.5.1b fixe ce problème.
Merci Gnidhal pour ta réponse, j'ai donc pris la 2.5.1b, passé au peigne fin pour la mise à jour.
Ce qui a changé dans checkout_process :
CODE
// assign last orders_in to prevent duplicate entry
$insert_id = ($_orders_id >= $holding_insert_id )? $_orders_id+1 : $holding_insert_id;
Alors oui, maintenant ca marche, quand un client retourne bien sur la boutique, il prend le dernier ID de la table holding, et la commandes passe en vert dans controles commandes.
Par contre, et dsl si j'ai loupé un truc quelque part, maintenant, a chaque commande, si jamais $_orders_id n'est PAS superieur ou égale a $_holding_insert_id, il va lui attribuer le dernier ID du $_holding_order.
Moi pas comprendre......
Si j'ai donc des commandes sans retour marchand, mais bien payé, et qu'un autre client pendant ce temps fait une commande (cheque ou paypal) et bien le checkout_process va lui donner le dernier ID de la table holding au lieu du $_orders_id+1
Je me retrouve avec une commande dans la tables ORDERS qui a le meme ID que dans holding_orders alors que c'est 2 commandes totalement differentes......
Ne faudrait il pas ajouter une verification sur checkout_process, pour savoir si la commande (en session?!) qui revient d'un paiement externe (donc "retour chez le marchand" cliqué) lui attribue l'order_id de la table holding lui correspondant mais si cette verification rertourne fausse, faire une attribution avec
CODE
// assign last orders_in to prevent duplicate entry
$insert_id = ($_orders_id >= $holding_insert_id )? $_orders_id+1 : $holding_insert_id+1;
Gnidhal
22 Jan 2007, 08:48
Judicieuse remarque !
le fait est que cette numérotation était bien gérée avec la 2.5 car toutes les commandes passaient par holding_orders.
Et il est vrai que puisqu'on a 2 canaux d'enregistrement de commande, il faut aussi synchroniser le canal normal sur le numéro le plus haut !
ton patch me semble bienvenu donc mais il ne faut pas oublier de modifier le checkout_process aussi dans la récupération de l'id et placer ton patch en haut juste avant :
CODE
$sql_data_array = array('customers_id' => $customer_id,
qui devrait devenir
CODE
$sql_data_array = array('orders_id' => $insert_id,
'customers_id' => $customer_id,
à vérifier je fais ça en vitesse
Ok, c'est bon.
Et c'est toujours le plus simple qui fonctionne.
Dans checkout_process.php remplacer ceci :
CODE
// OrderCheck
// test last orders_id
$_oders_max_query = tep_db_query("select max(orders_id) as max_id from " . TABLE_ORDERS . "");
$_oders_max = tep_db_fetch_array($_oders_max_query);
$_orders_id = $_oders_max["max_id"];
// test last holding_orders_id
$holding_oders_max_query = tep_db_query("select max(orders_id) as max_id from " . TABLE_HOLDING_ORDERS . "");
$holding_oders_max = tep_db_fetch_array($holding_oders_max_query);
$holding_insert_id = $holding_oders_max["max_id"];
// assign last orders_in to prevent duplicate entry
$insert_id = ($_orders_id >= $holding_insert_id )? $_orders_id+1 : $holding_insert_id+1;
par ceci :
CODE
// Si retour de paypal, assigne le dernier order_id de la table holding au client
if ($paypal->code == 'paypal') {
$holding_oders_max_query_paypal = tep_db_query("select max(orders_id) as max_id from " . TABLE_HOLDING_ORDERS . " where customers_id = '" . $customer_id . "'");
$holding_oders_max_paypal = tep_db_fetch_array($holding_oders_max_query_paypal);
$insert_id = $holding_oders_max_paypal["max_id"];
} else {
// OrderCheck
// test last orders_id
$_oders_max_query = tep_db_query("select max(orders_id) as max_id from " . TABLE_ORDERS . "");
$_oders_max = tep_db_fetch_array($_oders_max_query);
$_orders_id = $_oders_max["max_id"];
// test last holding_orders_id
$holding_oders_max_query = tep_db_query("select max(orders_id) as max_id from " . TABLE_HOLDING_ORDERS . "");
$holding_oders_max = tep_db_fetch_array($holding_oders_max_query);
$holding_insert_id = $holding_oders_max["max_id"];
// assign last orders_in to prevent duplicate entry
$insert_id = ($_orders_id >= $holding_insert_id )? $_orders_id+1 : $holding_insert_id+1;
}
Et c'est tout bon, le client qui retourne bien, obtient le dernier ID de la table holding (SA commande) et pour tout autre moyen de paiement, on assigne l'ID à "l'ancienne" version 2.5.1
Pour d'autre moyen de carte que paypal il suffit de remplacer la ligne :
CODE
$paypal->code == 'paypal'
Par la classe et code correspondant.
mediagraphie
11 Jul 2007, 09:39
Bonjour, je viens d'installer order check 2.5.1c sur ma boutique et je me retrouve confronté à un problème. lorsque j'arrive sur la page
http://xxx.fr/checkout_payment_ext.php, je suis redirigé vers
http://xxx.fr/logoff.php sans avoir accès au paiement ATOS de ma banque.
en cherchant dans checkout_payment_ext.php, j'ai trouvé les lignes :
CODE
<td class="main"><?php echo TEXT_MAIN ."<b>". $order->info['payment_method'] ."</b>";
$link_out = (isset($_POST['module_link']) && !empty($_POST['module_link'])) ? $_POST['module_link']: tep_href_link(FILENAME_LOGOFF);
unset($_POST['module_link']);
echo tep_draw_form('checkout_confirmation', $link_out, 'post');
foreach ($_POST as $key=>$value) {
echo tep_draw_hidden_field ($key, $value);
}
?></td>
Donc ca me renvoie bien vers logoff.php.
Est-ce que quelqu'un a déjà eu ce problème ? et sourtout comment le régler ?
Merci d'avance
Mathieu
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'informations, la mise en page et les images, veuillez
cliquer ici.