Paco112

Le non accès au FTP ou la bdd ne changera rien, on peut effectivement passer par un module pour faire les modif sur la facturation. De toute façon tel que la loi est écrite ce n'est pas a l’hébergeur de garantir l'Inaltérabilité mais bien au logiciel. Même si il y a un lien évident entre les 2 c'est bien le logiciel le responsable l'égal de cette Inaltérabilité.

Voilà leurs définitions : http://bofip.impots.gouv.fr/bofip/1298-PGP.html#1298-PGP_180._Le_droit_de_communicat_074 D’après mon interprétation prestashop est bien concerné.

Bonjour, Au 1er janvier 2018 la nouvelle loi finance 2016 entrera en vigueur. Cette loi impose à tous logiciels de compatibilité et de gestion de caisse d’être certifié par un organisme compétant ou individuellement par l’éditeur. Hors pour être certifié il faut que les données comptables respect les conditions suivantes : - Inaltérabilité - Sécurisation - Conservation - Archivage Problème Prestashop ne peux respecter dans l’état le premier critère d’inaltérabilité étant donné que les données sont directement modifiables dans la base de données et ne sont pas signées. Qu’elle est donc la position de prestashop sur cette nouvelle loi ? Les e-commerçants français qui utilisent pretsashop seront-ils tous dans l’illégalité au 1er janvier 2018 ? Texte de loi complet : http://bofip.impots.gouv.fr/bofip/106[spam-filter]PGP.html?identifiant=BOI-TVA-DECLA-30-10-30-20160803 Plus d’info : https://www.service-public.fr/professionnels-entreprises/actualites/A10279 https://linuxfr.org/news/projet-de-loi-de-finances-fr-2016-interdiction-des-logiciels-libres-de-comptabilite-et-de-caisse

Comme d'habitude aucune personne de prestashop pour parler de ce problème ? Je me demande vraiment à quoi sert la section rapport de bug de ce forum !

Bonjour, Voici quelques explications sur le stock réel : Tout d'abord il est inutile de chercher a synchroniser la table ps_stock_available avec ps_stock pour la simple et bonne raison que ps_stock_available est automatiquement recalculé à chaque commande et mise à jour d'un produit. Si le stock réel est incohérent avec le stock physique c'est très souvent du a des commandes qui réserve le stock alors qu'elles ne devraient pas. Vous trouverez ici plus d'informations sur un bug de réservation de stock : https://www.prestashop.com/forums/topic/592407-erreur-r%C3%A9sa-et-calcul-du-stock-r%C3%A9el/ La première chose à faire est donc de corriger ce bug ! Ensuite je vous encourage a vérifier l'intégralité de vos statuts, notamment la cohérence des options, exemple un statut ne devrait pas être considéré comme payé et non valide ! Si vous corrigé le bug cité plus haut, alors tous les statuts "considérer la commande comme valide" et "non expédié" vont réserver le stock. Une fois que vous passerez dans un statuts de type "expédié" le stock ne sera plus réservé mais sortira de votre stock physique. Une fois tous cela effectué, il faut resynchroniser l’ensemble de la table ps_stock_available pour cela il faut utiliser un script de ce type : $products = Db::getInstance()->executeS('SELECT id_product FROM `'._DB_PREFIX_.'product`'); foreach($products as $product) { if (StockAvailable::dependsOnStock((int)$product['id_product'])) { StockAvailable::synchronize((int)$product['id_product']); } }

Bonjour, Il s'agit d'une erreur que j'ai déjà signalé il y a plusieurs mois mais comme je vois qu'aucun changement n'a été effectué sur les dernières version de prestashop, y compris la version 1.7, je ré-expose ce qui me semble une ÉNORME erreur de stock lorsque la gestion de stock avancé est activée. Tout d'abord convenons ensemble d'une chose : Les statuts de type "En attente de paiement" dont l'option "Considérer la commande associée comme validée" n'est PAS coché NE DOIVENT PAS RÉSERVER LE STOCK. Sinon il serait assez facile de flinguer le stock d'une boutique en passant de multiples commandes en paiement par chèque/virement. Hors une requêtes SQL démontre que prestashop réserve le stock dans TOUS LES CAS sauf si la commande est dans un statuts expédié, annulé ou en erreur. La requête sql en question se trouve dans le fichier StockManager.php dans la fonction getProductRealQuantities. Cette requête à pour but de comptabiliser les quantités à réserver qui ne sont pas encore sortie du stock physique. $query->where('os.shipped != 1'); $query->where('o.valid = 1 OR (os.id_order_state != '.(int)Configuration::get('PS_OS_ERROR').' AND os.id_order_state != '.(int)Configuration::get('PS_OS_CANCELED').')'); Analysons cette clause WHERE : 1 - Le status de la commande ne doit pas être expédié => ok tout va bien car dans ce statut les quantités sont sorties du stock physique et non donc plus lieu d’être réservés ! 2 - La commande doit être valide OU ne pas être dans un statuts annulé ou en erreur. Le problème se situe dans le OR de "o.valid = 1 OR" En effet si ma commande est en statuts "En attente de paiement par chèque" configuré pour ne pas considérer la commande comme valide et bien la quantité de chaque produit sera tout de même comptabilisé comme réservé car la seconde partie de la clause WHERE renverra TRUE ! Il faut donc remplacé le OR par AND pour corriger ce problème : "o.valid = 1 AND" Je comprends tout à fait cette requête d'un point de vue développeur 1 commande non annulé == réservation de stock. Mais d'un point de vue commerçant c'est totalement illogique. Je ne connais pas un seul commerçant qui réserve un stock pour un client dont il n'a aucune assurance qu'il va régler la commande ! De plus comme je l'ai dit plus haut cela veut dire qu'un robot peut très bien réservé l'intégralité du stock d'une boutique sans jamais payer. Ce problème existe sur toutes les versions de la 1.5 à la 1.7 ! Ma question est donc : Est ce que comportement est volontaire ? Si oui trouvez moi un commerçant qui trouve ce comportement logique alors qu'il est possible de créer des status de type "Acompte" lorsque l'on veut réellement réserver le stock.

Il est possible que vous obteniez un crash en allant sur la page admin de listing des produits. Ce problème est dû à un mauvais id de la catégorie Accueil. Pour corriger ce bug il suffit de placer ce script à la racine du dossier adminXXXXX et de l’exécuter : <?php if (!defined('_PS_ADMIN_DIR_')) { define('_PS_ADMIN_DIR_', getcwd()); } include(_PS_ADMIN_DIR_.'/../config/config.inc.php'); include(_PS_ADMIN_DIR_.'/functions.php'); $id_old_category = (int)Db::getInstance()->getValue('SELECT id_category FROM '._DB_PREFIX_.'category WHERE is_root_category = 1'); if ($id_old_category && $id_old_category != 2) { echo "Correction id_category root ".$id_old_category." to 2 ... "; Db::getInstance()->execute('UPDATE '._DB_PREFIX_.'category SET id_category = 2 WHERE id_category = '.$id_old_category); Db::getInstance()->execute('UPDATE '._DB_PREFIX_.'category_shop SET id_category = 2 WHERE id_category = '.$id_old_category); Db::getInstance()->execute('UPDATE '._DB_PREFIX_.'category_lang SET id_category = 2 WHERE id_category = '.$id_old_category); Db::getInstance()->execute('UPDATE '._DB_PREFIX_.'category_group SET id_category = 2 WHERE id_category = '.$id_old_category); echo "OK"; } else { echo "id_category root is already OK !"; } Ce script va corriger l'id de la catégorie Accueil pour qu'il soit égal à 2 comme le désire prestashop si cela est nécessaire. Vérifiez également que la table ps_category_group soit correct car il est possible que l'id de la catégorie parent qui doit égal à 1 ne soit pas correct. Voilà après cela votre prestashop devrait fonctionner correctement sur un Galera Cluster.

Bonjour, Si comme moi vous utilisez un Galera Cluster MySQL ou MariaDB vous avez certainement remarqué que l'installation de prestashop planté lamentablement. La raison est simple un Galera Cluster ne peut pas avoir un auto_increment et offset de 1. Voici donc la méthode que j'utilise pour résoudre ce problème et avoir une installation propre : 1 - Supprimer le check auto_increment et offset : Dans le fichier install/models/database.php commentez les lignes 75 à 77 de la fonction testDatabaseSettings comme ci-dessous : /*if (!Db::checkAutoIncrement($server, $login, $password)) { $errors[] = $this->language->l('The values of auto_increment increment and offset must be set to 1'); }*/ 2 - Supprimer l'installation des produits demo : Dans le fichier install/models/install.php ajouter "return true;" au début de la fonction installFixtures ( ligne 750 ) comme ci-dessous : public function installFixtures($entity = null, array $data = array()) { return true; $fixtures_path = _PS_INSTALL_FIXTURES_PATH_.'fashion/'; 3 - Désactiver l’installation de certains modules qui ne passe pas : Toujours dans le fichier install/models/install.php commentez les modules suivant dans la fonction getModulesList (ligne 593 ) : blockcategories, blockstore, blocksupplier, dashgoals, themeconfigurator public function getModulesList() { $modules = array(); if (false) { foreach (scandir(_PS_MODULE_DIR_) as $module) { if ($module[0] != '.' && is_dir(_PS_MODULE_DIR_.$module) && file_exists(_PS_MODULE_DIR_.$module.'/'.$module.'.php')) { $modules[] = $module; } } } else { $modules = array( 'socialsharing', 'blockbanner', 'bankwire', 'blockbestsellers', 'blockcart', 'blocksocial', //'blockcategories', 'blockcurrencies', 'blockfacebook', 'blocklanguages', 'blocklayered', 'blockcms', 'blockcmsinfo', 'blockcontact', 'blockcontactinfos', 'blockmanufacturer', 'blockmyaccount', 'blockmyaccountfooter', 'blocknewproducts', 'blocknewsletter', 'blockpaymentlogo', 'blocksearch', 'blockspecials', //'blockstore', //'blocksupplier', 'blocktags', 'blocktopmenu', 'blockuserinfo', 'blockviewed', 'cheque', 'dashactivity', 'dashtrends', //'dashgoals', 'dashproducts', 'graphnvd3', 'gridhtml', 'homeslider', 'homefeatured', 'productpaymentlogos', 'pagesnotfound', 'sekeywords', 'statsbestcategories', 'statsbestcustomers', 'statsbestproducts', 'statsbestsuppliers', 'statsbestvouchers', 'statscarrier', 'statscatalog', 'statscheckup', 'statsdata', 'statsequipment', 'statsforecast', 'statslive', 'statsnewsletter', 'statsorigin', 'statspersonalinfos', 'statsproduct', 'statsregistrations', 'statssales', 'statssearch', 'statsstock', 'statsvisits', //'themeconfigurator', ); } return $modules; } Voilà l'installation devrait maintenant ce faire sans erreur. Si d'autre modules plante il suffit de les commenter. Une fois l'installation terminé vous pourrez installer les modules précédemment désactivé sans aucun problème via l'admin de prestashop en cliquant simplement sur le bouton installer de chaque module. Par expérience je confirme que prestashop fonctionne parfaitement par la suite sur un Galera Cluster, il serait donc peut être bon que l'équipe de dev se penche sur ce problème d'installation pour éviter ce genre de modifications.

Bonjour, A vue d’œil le problème provient de : 'lang' => true qui devrait être a false. En effet un prix de peut pas être multi langue. De plus il me semble (je n'ai pas fait cette manip depuis un moment) que tu dois aussi créer le champ dans la table ps_product_shop en plus de ps_product.

Mon private cloud n'heberge pas qu'un site biensur. La gestion au quotidiens c'est juste du controlle sur des interfaces graphiques. Le gros du boulo c'est de monter l'archi des serveurs virtualisés, une fois que tous est en place et si c'est bien fait il est tres rare d'avoir besoin de remettre les mains sous le capot.

Je suis bien d'accord avec ton analyse zoomzoom, prestashop est tres mal optimisé que ce soit en php ou en mysql donc sur des serveurs mutu on peut juste avoir au mieux du 1 à 2s de temps de réponse (pour la 1ere requete). Pour avoir un presta tres rapide et fiable il y a pas 36 solutions efficace : bcp de cache, une bonne puissance de calcul mysql et une big puissance de calcul php et bien sur une architecture full redondée pour assurer un taux de dispo supérieur à 99%. Voici un pingdom test d'un de mes sites e-com : http://tools.pingdom.com/fpt/#!/ci0Hro/http://www.picksea.com/fr/

Pour ma part après plusieurs jours de travail sur la migration de la version 1.5.2 à 1.5.3.1, cette dernière version NE SERA PAS mis en production. La raison est simple le panier n'est toujours pas fiable ( voir ce sujet : http://www.prestashop.com/forums/index.php?/topic/199687-15x-panier-vide/ ). Si vous êtes en version 1.4 restez y, au vus des 4 versions majeur de la 1.5 que j'ai testé il va falloir attendre encore au moins 6 mois avant d'avoir une version 1.5 stable.

Après avoir essayé toutes les solutions trouvées sur le forum, le bug persiste toujours. Étant actuellement en version 1.5.2 je décide donc de tester la version 1.5.3.1. Et là c'est le drame, encore une énième version ALPHA. Néanmoins le bug à légèrement changer de forme maintenant c'est beaucoup plus rigolo, le panier apparait 1 fois sur 3 très exactement ( F5 refresh sur le panier ). Bref à quand un panier STABLE POUR TOUS !!!!! ( c'est pas comme si c'était la base ... )

Si le champs ajouté est de type " lang = true " alors le tpl doit etre construit de manière à avoir 1 champs par langue : <tr> <td class="col-left"> {include file="controllers/products/multishop/checkbox.tpl" field="pointsforts" type="tinymce" multilang="true"} <label>{l s='Points forts :'}<br /></label> <p class="product_description">({l s='Points forts du produit'})</p> </td> <td style="padding-bottom:5px;" class="translatable"> {foreach from=$languages item=language} <div class="lang_{$language.id_lang}" style="{if !$language.is_default}display: none;{/if} float: left;"> <input size="100" type="text" id="pointsforts_{$language.id_lang}" name="pointsforts_{$language.id_lang}" value="{$product->pointsforts[$language.id_lang]|htmlentitiesUTF8}" style="width: 538px;" /> </div> {/foreach} <p class="clear"></p> </td> </tr> De plus il n'y a aucune modification à apporter au fichier : AdminProductsController.php

Chez moi le fix shop.php semble fonctionner néanmoins il semble créer un autre bug encore plus grave : Certaines commandes reste en mode panier ( même après un paiement atos ou autres ). J'ai donc eu plusieurs commandes dont le paiement était effectué mais aucune commande dans la base de donnée seulement des paniers ( que j'ai donc du valider manuellement ) Depuis la désactivation de ce fix j'ai retrouvé le pb de panier vide mais je n'ai plus ce problème de commande.