This is an old revision of the document!
Local Shop : General configuration
Introduction
The shop must be generally configured with vendor information in order to operate.
Path: Site administration/plugins/local plugins/shop
The configuration involves four set sections and a certain amount of variable sections depending on the number of payment plug-ins installed.
Global settings
Be careful: navigation sequence implicates all front office screens. Some combinations can generate shop malfunctions, such as, for example, attempting to display an invoice before a payment. There are consequently certain rules that need to be followed, notably:
Pre-payment steps:
shop : establish the cart
purchaserequ : collect product parameters
users : enter information on seats
customer : collect customer information / existing customer login
order : order summary
Payment steps (or steps after payment):
payment : payment or redirect to a payment interface
produce : digital production of purchased products
invoice : presentation of invoice or pro forma invoice
Note : The multi-currency shop operation is planned, but still requires some finalisation. (Utilisation de plusieurs devises dans la même instance de catalogue.)
Test mode : Si ce mode est activé, alors toutes les interfaces de paiement activées le sont sur les paramètres de bac à sable des différents partenaires de paiement. De plus l'usage de la phase de paiement est interdite aux personnes non connectées et non administrateur. Cependant, les transactions effectuées en mode test généreront des enregistrements effectifs de factures et de produits. Il peut être nécessaire de procéder à une réinitialisation des transactions avant la mise en production effective de la boutique.
If this mode is enabled, then all payment interfaces are enabled based on the sandbox parameters of the different payment partners. Furthermore, persons who are not logged in or who are not administrators are prohibited from payment phase use. Transactions made in test mode however will generate actual records of invoices and products. Transactions might have to be reinitialised before the shop is actually in production.
Hide products if not available : Défaut : No. If enabled, unavailable products (because of checking rules, despite still being advertised for sale) will not be displayed at all. Otherwise, the products will be displayed masked and without the order button.
Discount settings
The Moodle shop handles a three-tiered discount system. A discount can only be attributed by logged in users based on certain capabilities at system level.
The discount is applied to the order total and is triggered by a sales threshold. A customer can benefit from a more or less significant discount according to the level of discount they earn by right, but the trigger threshold remains unique. (You cannot tier up different automatic discounts according to cart amount).
To modulate prices according to local quantities with a product, view the settings for a single product.
Only one discount threshold can be applied at a time (discounts are therefore not cumulative).
Discount threshold: This threshold must be provided in current shop currency. Users must have local/shop:discountagreed capability to benefit from it.
Discount rate: Is expressed as a % of total order amount.
Second discount rate: This rate is applied to logged in users with local/shop:seconddiscountagreedcapability. You can, for example, create a site role with this capability and have this role attributed via a badge to identify preferred customers.
Third discount rate: Likewise, a third discount rate can be triggered for local/shop:thirddiscountagreedcapability.
Vendor name: Vendor name displayed on screens
Vendor address: Mailing address displayed
Postal code: Postal code displayed
Vendor city/town: City/town displayed on screens
Vendor country: Country displayed
Vendor email: Direct email
Email support: Support contacts on screen or on documents
Telephone support
Lastly, accounting information is used to display any different data on documents produced (purchase orders, pro forma invoices, invoices, etc.)
Vendor identifier: Register of business names identifier or any other official vendor identifier.
Vendor accounts department address: Official address appearing on documents.
Accounts department postal code: Postal Code appearing on documents.
Accounts department city/town: City/town appearing on documents.
Accounts department country: Country appearing on documents.
Each installed payment plug-in can add a set of parameters dedicated to this plug-in functioning. Here are some examples.
Mercanet configuration option
The Mercanet interface is the interface used by BNP and banks in that same group.
Ogone configuration option
Ogone (now Ingénico), is a multi-bank payment intermediary that can centralise payments received via a unique interface for several different banking systems.
Paypal
System Pay PLUS
System Pay PLUS, developed by ATOS, is the payment system used by Caisse d'Epargne, the Banques Populaires, and banks in that group.
Notifications
Introduction
The vendor’s banking information is used for offline payment procedures to provide bank details for interbank transfers or for issuing cheques. This information is found in your bank documentation.
Appareance
Experimental
These features are enabled but still subject to change.
Use shipping : Default: No: If enabled, delivery charges are handled.
Use sales delegation: Default: No: If enabled, users can own products and sell them on their own behalf.
Use master/slave catalogues: Default: No. If enabled, master/slave catalogues are handled.
Use renewable products: Default: No: If enabled, renewable products are handled.
Credits