Le bouton “Facture” Apparait, la facture peut être créée.

Génération d’une facture sous magento

Sur d’anciennes versions de Magento, lorsqu’une commande s’est mal déroulée, il est parfois impossible de créer une facture pour cette commande (bouton invisible en BackOffice), voici la solution :

Note : Exemple sur une version Communautaire 1.2.1 (le nom de la table peut changer sur des versions supérieures)

1) Se connecter à la base de données du site (via PhpMyAdmin par exemple)

2) Rechercher la table “Sales_order_varchar”

3) Editer dans votre back-office, la commande en question :

Son id est le 9965

4) Retourner sur l’interface Phpmyadmin et cliquez sur l’onglet “Rechercher” puis taper le n° d’Id.

5) Cliquez pour éditer la 2ème ligne des statuts, ici en “Cancelled ”

6) Modifier le statut “Cancelled” en statut “Processing”

7) Cliquez sur le bouton “Exécuter”

8 ) Le bouton “Facture” Apparait, la facture peut être créée:

Cet article est une traduction des principales recommandations du Livre Blanc de Varien au sujet de l’optimisation des performances de Magento.

Planifier, déployer et configurer l’environnement de Magento Enterprise Edition nécessite sans aucun doute d’apporter une grande attention aux moindres détails afin d’en obtenir les meilleures performances. La plate-forme physique, la performance du réseau, la configuration et l’optimisation des différents services ainsi que la configuration avancée de Magento Enterprise Edition jouent tous un rôle important pour aboutir au meilleur rendement possible sur votre configuration spécifique. Ce qui suit est la revue des points essentiels abordés dans le livre blanc de Varien:

• Il est fortement recommandé d’optimiser les configurations Apache et MySQL. Cela peut permettre d’augmenter les performances de 55 à 70%, en particulier sur les pages dynamiques. MySQL et Apache sont en effet configurés par défaut pour utiliser beaucoup moins de ressources que ce qu’un serveur moyen peut désormais fournir, et ne sont par conséquent pas en mesure de prendre en charge un nombre élevé de transactions simultanées. Cela peut conduire à une charge irrégulière du serveur et un comportement général imprévisible.

• L’ajout d’un accélérateur PHP est un autre aspect important de la configuration de l’environnement de Magento Enterprise Edition. eAccelerator affiche de bons résultats avec une augmentation de 40% à 600%. D’après nos tests, APC est encore plus efficace affichant un gain de performance supplémentaire de 15 à 20% par rapport à eAccelerator.

• Activer le cache sur les sites de production est essentiel. La désactivation du cache peut provoquer un ralentissement de l’interface de la boutique d’un facteur de 5 à 6 et une réactivité moindre sous charge.

• Lors de la configuration de Magento Enterprise Edition sur un serveur unique, il est convenable d’utiliser le système de cache par défaut (basé sur le système de fichiers) ou alors APC, qui donne des résultats similaires. Toutefois, en cas d’installation sur des nœuds web multiples, il est préférable d’utiliser  memcached. En effet APC et le système de cache par fichiers requièrent une gestion supplémentaire pour synchroniser les données entre les nœuds.

• L’activation de la fonctionnalité Full Page Caching peut améliorer les performances de Magento Enterprise Edition pour toute page avec du contenu statique (page d’accueil ou autres pages CMS). Ainsi, si vous envisagez d’avoir une page d’accueil statique et que vous utilisez plusieurs pages d’arrivée votre site web, il est fortement recommandé d’activer la fonctionnalité Full Page Caching.

• Dans une configuration à serveur unique, il n’est pas nécessaire de modifier le système de stockage de sessions par défaut (système de fichiers), car il donne les meilleurs résultats. Toutefois, dans un environnement en cluster, si l’équilibreur de charge utilisé ne peut pas associer les demandes des clients avec des nœuds web spécifiques, en se basant sur l’adresse IP ou les cookies du client, il peut être nécessaire d’utiliser soit memcached, soit le stockage de sessions en base de données. Le stockage des sessions dans memcached donne des résultats proches de ceux du stockage par défaut (ou légèrement inférieurs, entre 1 et 2%). Le stockage de session en base de données devrait être utilisé dans un environnement de cluster seulement en dernier recours, dans le cas où le stockage memcached ne pourrait pas être utilisé.

• L’installation du module de Compilation de Magento Enterprise Edition et l’activation de la compilation peuvent donner un gain de performances supplémentaire de 10 à 15%.

• Si vous souhaitez installer et configurer le moteur de recherche Apache Solr, il est recommandé d’activer le support du moteur de recherche Solr dans les options de configuration de la recherche catalogue. La qualité de la recherche augmente de façon significative, même dans le cas où le catalogue est peu fourni, et on peut constater un petit gain de performance (pas plus de 25% sur la navigation catalogue et 14% sur la recherche).

• L’utilisation de processeurs multi-cœurs modernes et de disques durs rapides améliore davantage les résultats. Un serveur simple-cœur, de bas niveau, avec un unique disque dur SATA et 4 Go de RAM installés est capable de traiter environ 9 trans/sec lors des tests sur la page d’accueil et jusqu’à 4 trans/sec au cours d’une session client moyenne. Un serveur dual-core avec un disque dur SATA est capable de gérer 18 trans/sec sur page d’accueil et jusqu’à 7 trans/sec pour des tests d’URL de session client, tandis qu’un serveur 8-core avec des disques durs 15K en RAID1 peut gérer 38 trans/sec sur page d’accueil et environ 17 trans/sec pour des tests d’URL de session client, avec des centaines de sessions simultanées, ce qui permet de prendre en charge plus de chargements de pages pour plus de visiteurs.

Magento Enterprise Edition est la première plate-forme Open Source eCommerce basée sur une technologie solide qui vous donne la flexibilité, la configuration, et les performances dont vous avez besoin pour développer un canal en ligne qui répond aux besoins uniques de votre entreprise.

En prêtant attention à ces détails de configuration qui peuvent être très poussés, et avec quelques réglages minutieux, la solidité, stabilité et performances de  Magento Enterprise Edition vous donnent les moyens de servir de nombreux clients de façon dense et rentable, tout en vous offrant l’avance nécessaire pour vous différencier de vos concurrents… et rester devant eux !

Importer des données dans une plateforme a toujours été un vrai casse-tête pour les informaticiens. A plus forte raison lorsque c’est dans Magento, et plus généralement dans une base de données de type EAV (Entités/Attributs/Valeurs).

Pour rappel, et pour faire court, une base de données (ou au moins une partie de celle-ci, car une base de données peut combiner un modèle relationnel standard et le modèle EAV, suivant les données à stocker, et c’est le cas de Magento) architecturée selon le « modèle EAV » permet de standardiser le stockage des données via quelques concepts clés :
-    Des Entités
-    Des Attributs
-    Des Valeurs

Dans le cas de Magento, les données sont ainsi segmentées par type de données au sens « informatique » du terme (c’est-à-dire des entiers, des chaines de caractères, des nombres à virgules…etc.) plutôt que par type de données au sens « métier » du terme (c’est-à-dire une table « client », une table « adresse »…).
L’inconvénient, c’est qu’on aura un nombre de tables bien plus important que dans un modèle standard, donc que les appels entre elles se multiplieront, donc que les temps de réponse entre l’envoi d’une requête et la réception de la réponse seront plus longs, et donc que votre site mettra plus de temps à afficher une page.
L’avantage, c’est que pour ajouter des champs (par exemple la photo d’un client, son âge…etc), on n’aura pas à modifier la structure de la base de données, mais simplement à rajouter des enregistrements dans les tables existantes !…
Pour prendre un exemple (j’en vois au fond à gauche qui baillent près de leur radiateur !… ) :
On veut stocker en base de données les infos d’un client.

En modèle standard, ça donnerait :
Table CLIENT :

Tandis qu’en modèle EAV, on aurait quelque chose comme :
Table ENTITE_CLIENT :

Table ENTITE_CLIENT_CHAINES_CARACTERES :

Table ENTITES_CLIENT_ENTIERS :

Vous allez me dire : « Oulalaaa, c’est bien compliqué pour pas grand-chose… ». Compliqué, oui. Pour pas grand-chose, non.
L’énorme avantage est la stabilité de la base de données. En effet, Magento n’a de cesse de se développer et les intégrateurs comme Bysoft n’ont de cesse de recevoir des demandes d’extensions de la plateforme. Dans l’exemple précédent, rajouter un champ « Civilité » pour les clients reviendrait à ajouter une colonne dans la table « CLIENT » du modèle standard, c’est-à-dire à modifier la structure et l’architecture de la base de données. Dans le modèle EAV, il suffit de rajouter un type « civilité » et un enregistrement dans la table « ENTITE_CLIENT_CHAINES_CARACTERES », ce qui ne modifie pas la structure de la base de données, mais seulement le nombre d’enregistrements.
Le principal soucis étant donc la lenteur de Magento, Varien propose depuis la release 1.3.0, un « Flat catalogue », c’est-à-dire la mise en cache de la base de données suivant le « modèle relationnel », c’est-à-dire un modèle statique.

On s’égare on s’égare, j’en reviens à l’essentiel : Comment importer des données avec toutes ces tables qui s’entremêlent ?

Plusieurs voies possibles :
- Utiliser les profils d’import/exportMagento

o Avantages : modifiable directement en BackOffice, facilité, rapidité de mise en place

o Inconvénients : limitation dans les entités importables et exportables, lent

-    Utiliser les webservices Magento

o    Avantages : facilité, rapidité de mise en place, appels directs et synchrones, évolution de l’API, aucune connaissance très poussée du code à avoir

o    Inconvénients : limitation à l’API ou nécessité de créer les webservices manquants, très lent lors du traitement de milliers d’appels

-    Utiliser les classes et méthodes existantes Magento et créer son propre script Magento

o    Avantages : mise en place assez rapide, évolution correcte avec les releases de Magento

o    Inconvénients : bonnes connaissances du code Magento nécessaire, assez lent lors du traitement de milliers d’appels

-    Insérer / mettre à jour directement les données en Base de données par des requêtes SQL

o    Avantages : très rapide lors du traitement de milliers d’appels, pas d’API, de classes ou de méthodes à créer

o    Inconvénients : compatibilité avec les releases suivantes de Magento à valider, Très bonne connaissance du code et de la Base de données de Magento nécessaire

La méthode à employer dépend ensuite :
-    Du type de données
-    Du nombre de données en base
-    De la fréquence de mise à jour des données
-    Des possibilités du client (présence d’un ERP ? saisie manuelle ? appels automatisables ou manuels ? le client a-t-il des développeurs pour mettre en place des appels webservices dans les applications internes ?…etc)
-    Du budget

Pour prendre un cas d’école, voici l’architecture choisie pour l’un de nos clients principaux sur Magento :
-    Import / mise à jour massif des fiches produits (simples et configurables) au format CSV, de manière asynchrone (plusieurs milliers voire dizaines de milliers de références à chaque import)
-    Import / mise à jour des catégories en webservices, de manière synchrone
-    Import / mise à jour des images produits au format CSV, de manière asynchrone
-    Assignation des produits simples aux produits configurables au format CSV, de manière asynchrone
-    Récupération des clients en webservices, de manière synchrone
-    Mise à jour des clients en webservices, de manière synchrone
-    Récupération des commandes en webservices, de manière synchrone
-    Facturation en webservices, de manière synchrone
-    Expéditions en webservices, de manière synchrone
Typiquement pour ce client, le BackOffice de Magento n’est pas du tout utilisé (ou ponctuellement, pour seulement en modifier la configuration). Les données sont constamment échangées avec l’ERP, dans lequel tout est centralisé (clients et ventes des autres sites du groupe, ventes des magasins physiques, facturation, expédition…).

Au vu de la quantité de données transitant, et après des tests et échanges auprès de Varien, la solution qui s’est imposée pour les imports massifs a été l’import direct en Base de données. Solution la plus rapide, elle a toutefois nécessité beaucoup de recherche et de tests pour garantir l’intégrité des données et la pérennité de la base, en association directe avec l’éditeur.

La V1 est maintenant pleinement opérationnelle, et le site en production. La V2 est en cours, avec au menu : des optimisations dans le chaînage des différents imports, une amélioration des fichiers de log et des optimisations de rapidité d’exécution.
Tant qu’on est en plein dedans, une petite astuce pour améliorer les temps d’import, désactiver les index sur les tables impactées, et les réactiver ensuite… Un exemple simple :
Juste avant de lancer l’import : ALTER TABLE nom_de_la_table DISABLE KEYS
Juste après l’import : ALTER TABLE nom_de_la_table ENABLE KEYS
C’est tout bête, mais ça permet de gagner un temps précieux lorsqu’on travaille sur des dizaines de milliers de références !…

Pour conclure, le transfert synchrone et asynchrone de données entre une plateforme Ecommerce (que ça soit Magento ou une autre), reste la principale problématique complexe à mettre en œuvre, très critique pour l’architecture d’un site de vente en ligne. Cette partie doit être clairement identifiée, soupesée et parfaitement architecturée, en prenant en compte tous les éléments pouvant l’impacter. Vont dépendre de ces choix préalables la fiabilité de votre plateforme, sa pérennité à long terme, l’intégrité des données, les perspectives d’évolution futures, les coûts de maintenance futurs, la rapidité du site. Tous ces éléments sont extrêmement critiques et ne doivent pas être pris à la légère. Un site dont les données ne sont pas à jour, ou dont les pages ne se chargent pas assez rapidement est clairement voué à l’échec vu l’agressivité et la concurrence du marché actuel.

Les problématiques des clients étant toutes différentes, nous ne recommanderons jamais assez de réfléchir à l’avance à ce que vous voulez mettre en place, et à ce que vous visez à terme. Il ne s’agit pas de partir tête baissée sur une plateforme parce qu’elle est la moins chère et parce que l’intégrateur vous a promis une livraison en 3 jours clés en main et le café offert… Prenez conseil, adressez-vous à des professionnels qui sauront comprendre votre métier et vos besoins pour définir avec vous l’architecture la plus adaptée (et pas forcément la plus chère… ). Un audit de deux jours dans vos locaux par un architecte Magento vous fera très certainement gagner des jours, des semaines, voire des mois dans le futur, parce qu’il vous aura conseillé la bonne architecture et vous aura indiqué les pièges qui jalonnent la route des entrepreneurs Ecommerce…

Dévoilé aujourd’hui officiellement  sur la toile, le Pavillon tricolore dispose désormais de son site Internet pour représenter la France à travers le monde. Reposant sur la plateforme CMS Open source SPIP, le site du Pavillon est décliné en trois langues: français, anglais et chinois.

Visitez-le sur www.pavillon-france.fr !

Le site du Journal du Net met en avant la nouvelle application webisée E-Spectre de l’ARCEP : un véritable “cadastre des fréquences” en ligne.

L’ARCEP a confié la mission à BYSOFT pour mettre à disposition les informations sur l’utilisation du spectre hertzien, une énorme base de données dotée d’un système de recherche multi-critères (zones géographiques, bandes de fréquences et types d’application). Une solution basée sur des technologies ouvertes pour permettre des évolutions simples de l’application, avec une conception objet obligatoire.

Retrouvez l’article complet sur le site du Journal du Net ici

Retrouvez le détail du projet sur la fiche référence client Bysoft ainsi que le descriptif de la solution apportée ici