The shop must be generally configured with seller 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.

• Default front office navigation: This setting indicates the sequencing order of front office screens. The shop stores all pre-purchase data during a session. This data can be in a different order according to the business or what the operator wants.

Be careful: navigation sequence implicates all front office screens. Some combinations can generate shop malfunctions, such as, for example, attempting to display a bill before a payment. There are consequently certain rules that need to be followed, notably:

• Differentiate between “pre-payment” screens and “after payment” screens
• Provide the bill after payment

Pre-payment steps:

• shop : establish the cart
• purchaserequ : collect product settings
• 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 bill or pro forma bill

• Default currency : Selects the currency given for the shop.

Note : The multi-currency shop operation is planned, but still requires some finalisation. (Use of several currencies in the same catalogue instance.)

• Test mode : 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 conducted in test mode however will generate actual records of invoices and products. You might have to reset transactions before live implementation of the shop.

• Test lock override : If this mode is enabled, then the test mode purchase lock is lifted to complete a transaction.

• Max items : Determine the max. size of list displays in the back office.

• Hide products if unavailable : Défaut : No. If enabled, unavailable products (for availability check reasons, but yet published for sale) will not be shown at all on front. If disabled, they still appear just shaded and without the order button.

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: A threshold that triggers the effectivity of the discount. Users must have local/shop:discountagreed capability to benefit from it.
• Discount rate: Is expressed as a % of total order amount.A discount rate applied on the overall amount. May be applied inconditionally if customer has the local/shop:discountagreed capability on.
• Second discount rate: This rate is applied to logged in users : A discount rate applied when customer has the local/shop:seconddiscountagreed capability on 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.

• Seller name: Seller name displayed on screens.
• Seller address : physical adress.
• Seller postal/zip code: Zip code displayed for the seller identity.
• Seller city/town : City of the merchant.
• Seller country: Country displayed.
• Seller email: Direct email.
• Mailing adress support: Mail address of the customer support team.
• Phone support number: Phone number of the customer support team.

Lastly, accounting information is used to display any different data on documents produced (purchase orders, pro forma bills, bills, etc.)

• Seller Registrar ID: The official company registrar ID of the seller.
• Seller Billing address: Address of seller’s accountant.
• Seller Billing Zip Code: Zip code of accountant.
• Seller Billing city/town : City of accountant.
• Seller Billing country: Country of accountant.
• Seller Logo : the logo that will be printed on bills and orders.

Each installed payment plug-in can add a set of settings dedicated to this plug-in. Here are some examples.

The Mercanet interface is the interface used by BNP and banks in that same group.

Ogone (now Ingénico), is a multi-bank payment intermediary that can centralise payments received via a unique interface for several different banking systems.

When using test mode, you will send all purchases to the Paypal sandbox. Paypal sandbox do NOT automate the IPN process (asynchronous return to merchant site) and you will have to simulate it using the Paypal IPN Simulator. The IPN end point of this site is : http://ma.formation-enligne.com/local/shop/paymodes/paypal/paypal_ipn.php.

System Pay PLUS, developed by ATOS, is the payment system used by Caisse d'Epargne, the Banques Populaires, and banks in that group.

• Pre sales notifications : Enable or disable the order input notification.

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.

• Bank name :Bank company name
• Bank code :Bank code of the merchant
• Bank office: Agency code
• Bank Account : Agency code
• Bank account key :Account key of the merchant
• IBAN : The IBAN number of the merchant
• BIC : BIC identification code of the merchant's bank
• VAT European Intracommunautary:European VAT number

Cette section permet de gérer l'apparence des produits en front-office

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 : The Moodle shop is also designed to be a marketplace for course authors. This feature will only be available in the extended version of the shop (PRO). The sales delegation provides that the catalogue products can belong to delegate seller accounts (generally associated with the course author) so that the platform can manage sales on behalf of the author. Representatives will have access to a portion of the back office in order to monitor sales management.
• Use master/slave catalogues: Default: No. If enabled, master/slave catalogues are handled.
• Use renewable products: Default: No: If enabled, renewable products are handled.

• Valéry Frémaux (valery@activeprolearn.com) Conception - Developments - Documentation
• Florence Labord (florence@activeprolearn.com) Fonctionnal review - Tests - Documentation

back to local shop composant - Back to catalogue