[Skip to main content](#vessel-content) # Profile for antidotcom ## [![antidotcom's Avatar](https://www.hikashop.com/media/kunena/core/svg/person.svg)](/forum/user/32815-antidotcom "View antidotcom's Profile") **[ Offline](/forum/user/32815-antidotcom)** - **User Type:** User - **Register Date:** 28 May 2014 - **Last login:** 2 weeks 19 hours ago - **Time Zone:** UTC +1:00 - **Local Time:** 09:04 - **Posts:** 98 - **Profile views:** 266 - **Thank you received:** 6 - **Gender:** Unknown - **Birthdate:** Unknown - **Medals:** Hikamarket Multivendor Hikaserial Standard Hikashop Business - Posts # antidotcom's recent posts (98 messages ) All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year | [ ](#forumbottom) | Subject | Replies / Views | Last Post | [ ](#forumtop) | |---|---|---|---|---| | [](/forum/5-support-en-francais-french-support-/910211-probleme-s-avec-les-dons-personnalises#370993) | [Problème(s) avec les dons personnalisés](/forum/5-support-en-francais-french-support-/910211-probleme-s-avec-les-dons-personnalises#370993 "-- HikaShop version -- : 6.4.0 -- Joomla version -- : 5.4.3 -- PHP version -- : 8.3.30 -- Browser(s) name and version -- : Chrome Bonjour, Le système de don personnalisé ne fonctionne plus... En effet, lorsque l'on indique un montant, celui ci n'est pas repris dans la page de ommande finale. il est indiqué 0.00... Le souci est que je ne sais pas depuis quelle mise à jour. d'hikashop ça c'est mis à dysfonctionner ... Il semble aussi que le système de paiement associer à systempay débloque aussi. Je n'ai touché à aucun paramétrage depuis l'installation en 2024. Le plugin donation est bien publié. La seule manipulation ayant été de désactiver et réactiver le plugin systempay lors de chaque mise à jour. J'ai cherché un bon moment tout seul comment réglé ces soucis, mais malheureusement, je ne m'en sors pas. Merci d'avance pour votre aide.") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 7 months 1 week ago, by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") [Last Post](/forum/5-support-en-francais-french-support-/910211-probleme-s-avec-les-dons-personnalises#370993 "Bingo ! C'était ça :) J'aurais du commencer mes vérifis par là... Merci pour le retour rapide. Tout est rentré dans l'ordre Bonne journée") 7 months 1 week ago by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") | Replies:2 Views:421 | [Last Post](/forum/5-support-en-francais-french-support-/910211-probleme-s-avec-les-dons-personnalises#370993 "Bingo ! C'était ça :) J'aurais du commencer mes vérifis par là... Merci pour le retour rapide. Tout est rentré dans l'ordre Bonne journée") by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") 7 months 1 week ago | | [](/forum/5-support-en-francais-french-support-/910211-probleme-s-avec-les-dons-personnalises#370967) | [Problème(s) avec les dons personnalisés](/forum/5-support-en-francais-french-support-/910211-probleme-s-avec-les-dons-personnalises#370967 "-- HikaShop version -- : 6.4.0 -- Joomla version -- : 5.4.3 -- PHP version -- : 8.3.30 -- Browser(s) name and version -- : Chrome Bonjour, Le système de don personnalisé ne fonctionne plus... En effet, lorsque l'on indique un montant, celui ci n'est pas repris dans la page de ommande finale. il est indiqué 0.00... Le souci est que je ne sais pas depuis quelle mise à jour. d'hikashop ça c'est mis à dysfonctionner ... Il semble aussi que le système de paiement associer à systempay débloque aussi. Je n'ai touché à aucun paramétrage depuis l'installation en 2024. Le plugin donation est bien publié. La seule manipulation ayant été de désactiver et réactiver le plugin systempay lors de chaque mise à jour. J'ai cherché un bon moment tout seul comment réglé ces soucis, mais malheureusement, je ne m'en sors pas. Merci d'avance pour votre aide.") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 7 months 1 week ago, by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") [Last Post](/forum/5-support-en-francais-french-support-/910211-probleme-s-avec-les-dons-personnalises#370993 "Bingo ! C'était ça :) J'aurais du commencer mes vérifis par là... Merci pour le retour rapide. Tout est rentré dans l'ordre Bonne journée") 7 months 1 week ago by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") | Replies:2 Views:421 | [Last Post](/forum/5-support-en-francais-french-support-/910211-probleme-s-avec-les-dons-personnalises#370993 "Bingo ! C'était ça :) J'aurais du commencer mes vérifis par là... Merci pour le retour rapide. Tout est rentré dans l'ordre Bonne journée") by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") 7 months 1 week ago | | [](/forum/14-hikaserial/909015-export-donnees-serials#365214) | [Export données serials](/forum/14-hikaserial/909015-export-donnees-serials#365214 "-- HikaShop version -- : 5.1.2 -- HikaSerial version -- : 5.0.0 -- Joomla version -- : 5.2.2 -- PHP version -- : 8.3 Bonjour, Ma demande concerne un shop vendant des bons cadeaux de type activité/loisir avec une date d'expiration (de 2 ans) utilisant les plugin Time limited et Attach serail. Actuellement, je peux exporter : Dans Hikashop : Les commandes (date, montant, etc...) et les serials associés. Dans hikaserial : Les serials, leur date d'association et leur statuts (non utilisé ou utilisé). En faisant un tableau croisé dynamique, je peux donc savoir quels sont les serials utilisés ou non. Seulement voilà, Afin de pouvoir fournir à mon comptable des données complètes sur 1 année comptable, j'aurais besoin de pouvoir exporter la date de modification de statut (date où le QR est scanné). Ceci afin de pouvoir avoir des données exactes, par an, de Serials achétés, utlisés, non utilisés ou périmés, A ma connaissance, ce n'est actuellement pas possible via le système d'export dans Hikaserial, alors que cette donnée est bien présente dans chaque fiche de chaque serial. Avez vous une solution à me proposer, afin de récupérer cette donnée hyper importante. Et, si jamais, le top du top serait de pouvoir tout exporter (données Hikashop et Hikaserail) dans un même fichier :) J'espère avoir été assez clair dans ma demande... Merci pour votre aide précieuse.") Category: [HikaSerial](/forum/14-hikaserial "A Joomla! component for HikaShop which add new features around serials/licences and unique content assignation.") Topic started 1 year 9 months ago, by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") [Last Post](/forum/14-hikaserial/909015-export-donnees-serials#365214 "Bonjour Jérome, Bon, je suis quand même tombé sur un os, car, les serials dont le statut est modifié manuellement, c.a.d sans scanner le QR n'ont pas de date de consommation ("serial_assign_date" )... or mon client doit parfois le faire (ex : pas de réseau lors de l'activité). Du coup, j'ai du exporter, et la table xxx_hikaserial_serial et la table serial history (contenant l'ID de l'utilisateur ayant changé le statut, le statut et la date de changement de statut). Je me retrouve donc avec 3 csv à coupler :/ Je vais tester l'intégration des colonnes dans la vue semaine pro. Je te tiens au courant. Merci") 1 year 9 months ago by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") | Replies:4 Views:991 | [Last Post](/forum/14-hikaserial/909015-export-donnees-serials#365214 "Bonjour Jérome, Bon, je suis quand même tombé sur un os, car, les serials dont le statut est modifié manuellement, c.a.d sans scanner le QR n'ont pas de date de consommation ("serial_assign_date" )... or mon client doit parfois le faire (ex : pas de réseau lors de l'activité). Du coup, j'ai du exporter, et la table xxx_hikaserial_serial et la table serial history (contenant l'ID de l'utilisateur ayant changé le statut, le statut et la date de changement de statut). Je me retrouve donc avec 3 csv à coupler :/ Je vais tester l'intégration des colonnes dans la vue semaine pro. Je te tiens au courant. Merci") by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") 1 year 9 months ago | | [](/forum/14-hikaserial/909015-export-donnees-serials#365177) | [Export données serials](/forum/14-hikaserial/909015-export-donnees-serials#365177 "-- HikaShop version -- : 5.1.2 -- HikaSerial version -- : 5.0.0 -- Joomla version -- : 5.2.2 -- PHP version -- : 8.3 Bonjour, Ma demande concerne un shop vendant des bons cadeaux de type activité/loisir avec une date d'expiration (de 2 ans) utilisant les plugin Time limited et Attach serail. Actuellement, je peux exporter : Dans Hikashop : Les commandes (date, montant, etc...) et les serials associés. Dans hikaserial : Les serials, leur date d'association et leur statuts (non utilisé ou utilisé). En faisant un tableau croisé dynamique, je peux donc savoir quels sont les serials utilisés ou non. Seulement voilà, Afin de pouvoir fournir à mon comptable des données complètes sur 1 année comptable, j'aurais besoin de pouvoir exporter la date de modification de statut (date où le QR est scanné). Ceci afin de pouvoir avoir des données exactes, par an, de Serials achétés, utlisés, non utilisés ou périmés, A ma connaissance, ce n'est actuellement pas possible via le système d'export dans Hikaserial, alors que cette donnée est bien présente dans chaque fiche de chaque serial. Avez vous une solution à me proposer, afin de récupérer cette donnée hyper importante. Et, si jamais, le top du top serait de pouvoir tout exporter (données Hikashop et Hikaserail) dans un même fichier :) J'espère avoir été assez clair dans ma demande... Merci pour votre aide précieuse.") Category: [HikaSerial](/forum/14-hikaserial "A Joomla! component for HikaShop which add new features around serials/licences and unique content assignation.") Topic started 1 year 9 months ago, by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") [Last Post](/forum/14-hikaserial/909015-export-donnees-serials#365214 "Bonjour Jérome, Bon, je suis quand même tombé sur un os, car, les serials dont le statut est modifié manuellement, c.a.d sans scanner le QR n'ont pas de date de consommation ("serial_assign_date" )... or mon client doit parfois le faire (ex : pas de réseau lors de l'activité). Du coup, j'ai du exporter, et la table xxx_hikaserial_serial et la table serial history (contenant l'ID de l'utilisateur ayant changé le statut, le statut et la date de changement de statut). Je me retrouve donc avec 3 csv à coupler :/ Je vais tester l'intégration des colonnes dans la vue semaine pro. Je te tiens au courant. Merci") 1 year 9 months ago by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") | Replies:4 Views:991 | [Last Post](/forum/14-hikaserial/909015-export-donnees-serials#365214 "Bonjour Jérome, Bon, je suis quand même tombé sur un os, car, les serials dont le statut est modifié manuellement, c.a.d sans scanner le QR n'ont pas de date de consommation ("serial_assign_date" )... or mon client doit parfois le faire (ex : pas de réseau lors de l'activité). Du coup, j'ai du exporter, et la table xxx_hikaserial_serial et la table serial history (contenant l'ID de l'utilisateur ayant changé le statut, le statut et la date de changement de statut). Je me retrouve donc avec 3 csv à coupler :/ Je vais tester l'intégration des colonnes dans la vue semaine pro. Je te tiens au courant. Merci") by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") 1 year 9 months ago | | [](/forum/14-hikaserial/909015-export-donnees-serials#365167) | [Export données serials](/forum/14-hikaserial/909015-export-donnees-serials#365167 "-- HikaShop version -- : 5.1.2 -- HikaSerial version -- : 5.0.0 -- Joomla version -- : 5.2.2 -- PHP version -- : 8.3 Bonjour, Ma demande concerne un shop vendant des bons cadeaux de type activité/loisir avec une date d'expiration (de 2 ans) utilisant les plugin Time limited et Attach serail. Actuellement, je peux exporter : Dans Hikashop : Les commandes (date, montant, etc...) et les serials associés. Dans hikaserial : Les serials, leur date d'association et leur statuts (non utilisé ou utilisé). En faisant un tableau croisé dynamique, je peux donc savoir quels sont les serials utilisés ou non. Seulement voilà, Afin de pouvoir fournir à mon comptable des données complètes sur 1 année comptable, j'aurais besoin de pouvoir exporter la date de modification de statut (date où le QR est scanné). Ceci afin de pouvoir avoir des données exactes, par an, de Serials achétés, utlisés, non utilisés ou périmés, A ma connaissance, ce n'est actuellement pas possible via le système d'export dans Hikaserial, alors que cette donnée est bien présente dans chaque fiche de chaque serial. Avez vous une solution à me proposer, afin de récupérer cette donnée hyper importante. Et, si jamais, le top du top serait de pouvoir tout exporter (données Hikashop et Hikaserail) dans un même fichier :) J'espère avoir été assez clair dans ma demande... Merci pour votre aide précieuse.") Category: [HikaSerial](/forum/14-hikaserial "A Joomla! component for HikaShop which add new features around serials/licences and unique content assignation.") Topic started 1 year 9 months ago, by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") [Last Post](/forum/14-hikaserial/909015-export-donnees-serials#365214 "Bonjour Jérome, Bon, je suis quand même tombé sur un os, car, les serials dont le statut est modifié manuellement, c.a.d sans scanner le QR n'ont pas de date de consommation ("serial_assign_date" )... or mon client doit parfois le faire (ex : pas de réseau lors de l'activité). Du coup, j'ai du exporter, et la table xxx_hikaserial_serial et la table serial history (contenant l'ID de l'utilisateur ayant changé le statut, le statut et la date de changement de statut). Je me retrouve donc avec 3 csv à coupler :/ Je vais tester l'intégration des colonnes dans la vue semaine pro. Je te tiens au courant. Merci") 1 year 9 months ago by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") | Replies:4 Views:991 | [Last Post](/forum/14-hikaserial/909015-export-donnees-serials#365214 "Bonjour Jérome, Bon, je suis quand même tombé sur un os, car, les serials dont le statut est modifié manuellement, c.a.d sans scanner le QR n'ont pas de date de consommation ("serial_assign_date" )... or mon client doit parfois le faire (ex : pas de réseau lors de l'activité). Du coup, j'ai du exporter, et la table xxx_hikaserial_serial et la table serial history (contenant l'ID de l'utilisateur ayant changé le statut, le statut et la date de changement de statut). Je me retrouve donc avec 3 csv à coupler :/ Je vais tester l'intégration des colonnes dans la vue semaine pro. Je te tiens au courant. Merci") by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") 1 year 9 months ago | | [](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565) | [Statut commande reste inchangé après paiement CB](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "-- HikaShop version -- : 5.1.1 -- Joomla version -- : 5.2.1 -- PHP version -- : 8.3.13 Bonsoir, J'ai un GROS souci... et c'est plutôt urgent... Suite à la migration de Joomla 4 vers Joomla 5 (avec changement de serveur), les statuts de commandes restent en "créés" et ne changent pas en "Confirmés" après que le paiement par carte bancaire ai été effectué par le client et validé par la banque. Le souci est que les clients ne reçoivent pas leurs bons cadeaux... Tout fonctionnait bien sous J4... Je ne sais pas par où commencer... Info complémentaires : Hikamarket 5.0.0 (mis à jour après migration vers J5) Hikaserial 5.0.0 Plugin de paiement bancaire : HikaShop Atos SIPS V2 payment Version BDD 8.0.36 (Tables checkées - Tout semble OK) Merci d'avance pour votre aide") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 1 year 11 months ago, by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") [Last Post](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "Bonsoir Nicolas, J'ai finalement résolu le problème grâce à vous et à mon hébergeur :) Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403. La Solution : Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java". Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java" Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess. Voilà, Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :) Encore merci pour votre aide Bonne soirée") 1 year 11 months ago by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") | Replies:6 Views:622 | [Last Post](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "Bonsoir Nicolas, J'ai finalement résolu le problème grâce à vous et à mon hébergeur :) Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403. La Solution : Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java". Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java" Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess. Voilà, Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :) Encore merci pour votre aide Bonne soirée") by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") 1 year 11 months ago | | [](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364563) | [Statut commande reste inchangé après paiement CB](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364563 "-- HikaShop version -- : 5.1.1 -- Joomla version -- : 5.2.1 -- PHP version -- : 8.3.13 Bonsoir, J'ai un GROS souci... et c'est plutôt urgent... Suite à la migration de Joomla 4 vers Joomla 5 (avec changement de serveur), les statuts de commandes restent en "créés" et ne changent pas en "Confirmés" après que le paiement par carte bancaire ai été effectué par le client et validé par la banque. Le souci est que les clients ne reçoivent pas leurs bons cadeaux... Tout fonctionnait bien sous J4... Je ne sais pas par où commencer... Info complémentaires : Hikamarket 5.0.0 (mis à jour après migration vers J5) Hikaserial 5.0.0 Plugin de paiement bancaire : HikaShop Atos SIPS V2 payment Version BDD 8.0.36 (Tables checkées - Tout semble OK) Merci d'avance pour votre aide") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 1 year 11 months ago, by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") [Last Post](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "Bonsoir Nicolas, J'ai finalement résolu le problème grâce à vous et à mon hébergeur :) Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403. La Solution : Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java". Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java" Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess. Voilà, Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :) Encore merci pour votre aide Bonne soirée") 1 year 11 months ago by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") | Replies:6 Views:622 | [Last Post](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "Bonsoir Nicolas, J'ai finalement résolu le problème grâce à vous et à mon hébergeur :) Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403. La Solution : Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java". Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java" Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess. Voilà, Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :) Encore merci pour votre aide Bonne soirée") by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") 1 year 11 months ago | | [](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364555) | [Statut commande reste inchangé après paiement CB](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364555 "-- HikaShop version -- : 5.1.1 -- Joomla version -- : 5.2.1 -- PHP version -- : 8.3.13 Bonsoir, J'ai un GROS souci... et c'est plutôt urgent... Suite à la migration de Joomla 4 vers Joomla 5 (avec changement de serveur), les statuts de commandes restent en "créés" et ne changent pas en "Confirmés" après que le paiement par carte bancaire ai été effectué par le client et validé par la banque. Le souci est que les clients ne reçoivent pas leurs bons cadeaux... Tout fonctionnait bien sous J4... Je ne sais pas par où commencer... Info complémentaires : Hikamarket 5.0.0 (mis à jour après migration vers J5) Hikaserial 5.0.0 Plugin de paiement bancaire : HikaShop Atos SIPS V2 payment Version BDD 8.0.36 (Tables checkées - Tout semble OK) Merci d'avance pour votre aide") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 1 year 11 months ago, by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") [Last Post](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "Bonsoir Nicolas, J'ai finalement résolu le problème grâce à vous et à mon hébergeur :) Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403. La Solution : Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java". Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java" Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess. Voilà, Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :) Encore merci pour votre aide Bonne soirée") 1 year 11 months ago by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") | Replies:6 Views:622 | [Last Post](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "Bonsoir Nicolas, J'ai finalement résolu le problème grâce à vous et à mon hébergeur :) Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403. La Solution : Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java". Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java" Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess. Voilà, Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :) Encore merci pour votre aide Bonne soirée") by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") 1 year 11 months ago | | [](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364554) | [Statut commande reste inchangé après paiement CB](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364554 "-- HikaShop version -- : 5.1.1 -- Joomla version -- : 5.2.1 -- PHP version -- : 8.3.13 Bonsoir, J'ai un GROS souci... et c'est plutôt urgent... Suite à la migration de Joomla 4 vers Joomla 5 (avec changement de serveur), les statuts de commandes restent en "créés" et ne changent pas en "Confirmés" après que le paiement par carte bancaire ai été effectué par le client et validé par la banque. Le souci est que les clients ne reçoivent pas leurs bons cadeaux... Tout fonctionnait bien sous J4... Je ne sais pas par où commencer... Info complémentaires : Hikamarket 5.0.0 (mis à jour après migration vers J5) Hikaserial 5.0.0 Plugin de paiement bancaire : HikaShop Atos SIPS V2 payment Version BDD 8.0.36 (Tables checkées - Tout semble OK) Merci d'avance pour votre aide") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 1 year 11 months ago, by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") [Last Post](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "Bonsoir Nicolas, J'ai finalement résolu le problème grâce à vous et à mon hébergeur :) Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403. La Solution : Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java". Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java" Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess. Voilà, Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :) Encore merci pour votre aide Bonne soirée") 1 year 11 months ago by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") | Replies:6 Views:622 | [Last Post](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "Bonsoir Nicolas, J'ai finalement résolu le problème grâce à vous et à mon hébergeur :) Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403. La Solution : Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java". Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java" Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess. Voilà, Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :) Encore merci pour votre aide Bonne soirée") by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") 1 year 11 months ago | | [](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364543) | [Statut commande reste inchangé après paiement CB](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364543 "-- HikaShop version -- : 5.1.1 -- Joomla version -- : 5.2.1 -- PHP version -- : 8.3.13 Bonsoir, J'ai un GROS souci... et c'est plutôt urgent... Suite à la migration de Joomla 4 vers Joomla 5 (avec changement de serveur), les statuts de commandes restent en "créés" et ne changent pas en "Confirmés" après que le paiement par carte bancaire ai été effectué par le client et validé par la banque. Le souci est que les clients ne reçoivent pas leurs bons cadeaux... Tout fonctionnait bien sous J4... Je ne sais pas par où commencer... Info complémentaires : Hikamarket 5.0.0 (mis à jour après migration vers J5) Hikaserial 5.0.0 Plugin de paiement bancaire : HikaShop Atos SIPS V2 payment Version BDD 8.0.36 (Tables checkées - Tout semble OK) Merci d'avance pour votre aide") Category: [Support en Français (French Support)](/forum/5-support-en-francais-french-support- "Cette section de notre forum est dédiée au support de HikaShop en Français. Si vous avez des notions en anglais, préférez utiliser les sections anglaises qui contiendront plus d'informations.") Topic started 1 year 11 months ago, by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") [Last Post](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "Bonsoir Nicolas, J'ai finalement résolu le problème grâce à vous et à mon hébergeur :) Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403. La Solution : Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java". Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java" Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess. Voilà, Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :) Encore merci pour votre aide Bonne soirée") 1 year 11 months ago by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") | Replies:6 Views:622 | [Last Post](/forum/5-support-en-francais-french-support-/908892-statut-commande-reste-inchange-apres-paiement-cb#364565 "Bonsoir Nicolas, J'ai finalement résolu le problème grâce à vous et à mon hébergeur :) Toutes les infos couplées m'ont permis d'arriver au fait que le souci venait bien du nouvel .htaccess que j'avais généré par Admin Tools après migration. Un souci avec le user agent Java générant une 403. La Solution : Dans le .hatccess Maker, en activant l'option "Block access from specific user agents", nous retrouvons dans la liste des user agents bloqués "Java". Or la requête réalisée par le module de paiement Atos Sips utilise le user-agent "Java" Il suffit donc de supprimer "Java" ce cette liste et de regénérer un nouvel .htaccess. Voilà, Tout est rentré dans l'ordre, sauf pour les clients ayant passés commande entre-temps et qu'il va falloir contacter, mais ça c'est une autre histoire :) Encore merci pour votre aide Bonne soirée") by [antidotcom](/forum/user/32815-antidotcom "View antidotcom's Profile") 1 year 11 months ago | [](/forum/topics/feed/mode-topics?format=feed&type=rss) Time to create page: 0.093 seconds [Powered by](/forum/credits) [Kunena Forum](https://www.kunena.org)