Paramétrer la boutique
Le code en place, la base prête, reste le réglage de la boutique dans le back-office. C'est du paramétrage, pas du développement, mais il y a quelques passages obligés et un ou deux réflexes qui évitent les mauvaises surprises le jour de la mise en ligne. Tout ce qui suit se fait dans l'admin nopCommerce, sous Configuration.
La livraison
nopCommerce ne sait pas calculer des frais d'expédition tout seul : il faut d'abord installer un plugin de calcul, depuis Configuration > Plugins locaux. Dans la grande majorité de nos boutiques, on prend le plugin manuel "Fixed or By Weight and By Total", qui couvre aussi bien un tarif forfaitaire qu'un calcul au poids. Une fois installé, on l'active dans les méthodes de calcul, puis on définit les méthodes de livraison concrètes proposées au client, leur coût, et leurs éventuelles restrictions (par poids, par destination).
Le paiement
Là encore, tout passe par des plugins qu'on installe et active selon les moyens de paiement retenus avec le client.
Le cas le plus fréquent chez nous, c'est Saferpay, la passerelle de paiement suisse, pour laquelle on a notre propre plugin maison "Spektrum Saferpay". On l'installe, on l'active comme moyen de paiement, et on le configure avec les identifiants Saferpay du client (qui vivent dans Guardian, pas dans un mail).
nopCommerce permet aussi de restreindre un moyen de paiement par pays, ce qui est utile quand un client ne veut accepter certaines cartes ou méthodes que dans une zone donnée.
Les taxes
C'est la partie qui demande le plus d'attention, parce qu'une erreur de TVA se voit immédiatement sur les prix affichés. La logique se construit en trois temps : on crée d'abord des catégories de taxes (les différents taux qu'on devra appliquer), on active la TVA pour les pays concernés, puis on branche un fournisseur de taxes qui fait le lien entre une catégorie et un taux. Pour nos boutiques, on utilise presque toujours le fournisseur manuel, où l'on saisit les taux à la main pour le pays cible.
Dans les paramètres de taxation eux-mêmes, deux choix structurants à faire d'entrée : baser la taxe sur l'adresse de facturation (en laissant nopCommerce détecter le pays par l'adresse IP tant que le client n'a rien saisi), et décider si les prix saisis dans le catalogue sont TTC ou HT. Ce dernier point conditionne tout l'affichage et se change très mal une fois la boutique remplie, donc tranche-le tôt avec le client. Le reste (affichage des taxes dans le panier, taxes sur les frais de port et de paiement) se règle ensuite au cas par cas.
Référence
Le modèle de taxation de nopCommerce est dense. Quand un cas sort de l'ordinaire, la documentation officielle sur les taxes est claire et à jour.
Les conditions générales de vente
Au moment de payer, le client doit cocher qu'il accepte les CGV. On veut que ce lien renvoie vers une vraie page du site Umbraco, et non vers la fenêtre surgissante par défaut de nopCommerce. On désactive donc cette popup dans les paramètres généraux, puis on indique l'adresse de la page CGV via une ressource de langue dédiée (la clé spk.umbraco.termsofuse, dont la valeur est le lien absolu vers la page Umbraco). Comme c'est une ressource de langue, ça se gère proprement pour chaque langue du site.
Adapter le back-office pour le client
nopCommerce expose énormément d'écrans et d'options dont le client final n'a pas l'usage, et qui ne font que l'égarer ou lui donner l'occasion de casser quelque chose. On allège donc son interface, de deux manières selon ce qu'on veut masquer.
Pour retirer des sections entières du menu, on maintient deux versions du menu d'administration : la version complète, qu'on se réserve, et une version allégée pour le client. La vue du menu choisit laquelle charger en fonction du rôle de la personne connectée. Nous voyons tout, le client ne voit que ce qui le concerne.
Pour masquer un champ précis sur un écran (par exemple le fabricant sur une fiche produit, inutile pour beaucoup de boutiques), on intervient directement dans la vue concernée du back-office pour cacher le bloc aux non-administrateurs. C'est plus chirurgical, à réserver aux quelques champs qui parasitent vraiment la saisie.
Dans les deux cas, le principe est le même : on se base sur le rôle pour décider de ce qui s'affiche, et on garde un accès complet pour nous.

