# Backend eCom

How to set up — Click paths in the web backend

# 1. Setup

# Role and eCom Employee

## Summary

The eCom system requires its own employee with a dedicated role.

This role controls which functions the shop offers — just like with the field service client.

Without an eCom licence, the main menu item **eCom** does not appear in the web backend.

## Procedure

1. Ensure that an eCom licence is available.
2. Create the eCom employee under *Basic configuration > Employee*.
3. Check the box **Ist eCom** for this employee.
4. Create a role and assign it to the eCom employee.
5. Set the eCom-relevant rights in the role.
 

### The checkbox *Ist eCom*

This makes the employee the user under which the shop operates. Without it, the eCom system does not recognise the employee as its own — role and rights then remain ineffective, even though everything appears maintained.

> **Important:** Only **one single** employee may have this checkbox. A second eCom employee is not intended.

## Which rights must be set

You can recognise the eCom-relevant rights by the **blue cart symbol** behind the entry. Rights without this symbol do not affect the shop.

A complete list with the respective effect in the shop is available in the specification on the page *eCom rights at a glance*.

> **Important:** You define the **scope of functions** via the role, not the question of whether ordering is allowed. A customer with access can always order. If a customer should not be able to order, they need a **lock at the customer**. There is no right for this in the role, and it cannot be set in the backend either: it comes from the **ERP system** and is delivered with the customer data.
> 
> **Note:** How the lock affects the shop is currently under review. It has been observed that a locked customer can **submit** the order and receives a confirmation without an order being created. For the moment, do not rely on a lock to properly block the shop. See [Order completion](https://wiki.dedesales.de/books/leistungsbeschreibung-ecom/page/bestellabschluss) in the specification.

## E-mail address of the employee

The e-mail address stored for the eCom employee has a special significance: **In the test system, all shop e-mails go to this address**, not to the customer. This also applies to the e-mail with the visible password during registration.

The address is maintained under *Basic configuration > Employee*.

# Provision of Data

> **Attention, current limitation:** Provisioning of data currently does **not** work for pictures. If you have changed pictures — container, login graphic or logo — please use the **Rollout** button in the **Employee overview** instead. The limitation has been reported; as soon as it is fixed, the procedure described below will apply again.

## Summary

Amendments to the eCom configuration only take effect once the data has been provisioned.

The eCom system then automatically retrieves the provisioned data — depending on the setting every 15 or 30 Minutes.

The process is the same as with a normal client.

## Procedure

1. Change and Save configuration in the web backend.
2. Provision data.
3. Wait until the eCom system has retrieved the data.
 

## When the Pictures checkbox must be set

<table id="bkmrk-%C3%84nderung-haken-bilde"> <thead> <tr> <th>Amendment</th> <th>Pictures checkbox</th> </tr> </thead> <tbody> <tr> <td>Settings, Texts, Rights, Order templates</td> <td>not required</td> </tr> <tr> <td>Container with new or changed picture</td> <td>**required**</td> </tr> <tr> <td>Login graphic or shop logo</td> <td>**required**</td> </tr> </tbody> </table>

Without this checkbox, the pictures will not be transferred, although the rest of the configuration arrives.

## Most common error case

An uploaded picture does not appear in the shop. The cause is almost always one of the two:

- After uploading, it was **not Saved**. An uploaded picture initially only resides in the temp folder; only *Saving* moves it to the correct folder.
- It was provisioned **without the Pictures checkbox**.

# 2. Maintaining Marketing

# Create and position containers

## Summary

Containers are the advertising spaces of the shop. They are maintained under *eCom \\ Container*.

A container becomes effective in two steps: you create it, and you define how the area in which it appears is displayed.

What a container is, which link types exist, and which image dimensions apply are described in the service description on the page *Marketing-Container*.

## Create container

1. Open *eCom \\ Container*. The list shows all existing containers with position, type, link type, and status. Use **Create new container** to add another one; clicking on a row opens an existing one for editing.
2. Select **Container type**: *Image*, *Image with text*, or *Text with image*. See below.
3. Depending on the type, add **Image** and **Text**. If the image was created with AI, check **Image is AI generated** — see [Mark images as AI-generated](https://wiki.dedesales.de/books/backend-ecom/page/bilder-als-ki-generiert-kennzeichnen). The text can be formatted using the toolbar of the **Content** field. The image dimensions depend on the display type of the area, see below.
4. Set **Priority**. `1` appears first.
5. If the container should only appear for certain customers, select a **Customer list**. Without a customer list, it appears for all.
6. Set **Link type** and the associated target.
7. Set **Status** to *Released* — only then does the container appear in the shop.
8. Save.
9. Provide data — **with the Images checkbox**, otherwise the image will be missing in the shop.
 

Optionally, a display period can be set via **From** and **To**, for example for a limited-time promotion. Without an entry, there is no limitation.

## Select container type

<table id="bkmrk-typ-im-float-bereich"> <thead> <tr> <th>Type</th> <th>in float area</th> <th>in slider</th> </tr> </thead> <tbody> <tr> <td>Image</td> <td>image only</td> <td>image only</td> </tr> <tr> <td>Image with text</td> <td>text to the right of the image</td> <td>text below the image</td> </tr> <tr> <td>Text with image</td> <td>text to the left of the image</td> <td>text above the image</td> </tr> </tbody> </table>

The **Content** field includes its own toolbar for formatting.

When choosing the type, note in which **Type** the container appears: the same combination of image and text is displayed side by side in the float area and stacked in the slider. Text that fits next to the image in the float may appear differently above the image in the slider.

## Add image

Use a **square 900 × 900 pixel image for a float tile** — also for types with text. A tile with text is twice as wide, but the image inside remains the same size as in a tile without text. So you do not need a larger image.

> **Warning:** In the float area, the image can be **cropped left and right**. It fills the tile height, and if a neighbouring tile has a lot of text, the entire row becomes taller. Therefore, place the motif **centrally** and leave margins on the sides.

As a rule of thumb: **use rather wide images for the slider, square ones for the float area.**

For the **slider**, the required format depends on whether it switches automatically:

<table id="bkmrk-anzeige-intervall-em"> <thead> <tr> <th>Display interval</th> <th>Recommended image size</th> </tr> </thead> <tbody> <tr> <td><code>0</code> — no autoplay</td> <td>at least 630 pixels high, aspect ratio between about 1:1 and 2.3:1, for example 945 × 630</td> </tr> <tr> <td>greater than <code>0</code> — autoplay</td> <td>1500 × 500 pixels (3:1)</td> </tr> </tbody> </table>

The slider **does not crop**. If the aspect ratio does not fit, the image is scaled smaller and gets blank stripes — for the autoplay slider on the sides if the image is too tall, and top and bottom if it is too wide. A larger image frame does not help, only the correct ratio.

> **Warning:** If you change the Display interval later, the required image format of the containers at this position also changes. The complete size table is in the service description on the page *Marketing-Container*.

> **Warning:** For the link type *Order template*, the selected order template must be enabled for eCom. See [Enable order template for eCom](https://wiki.dedesales.de/books/backend-ecom/page/auftragsvorlage-fur-ecom-freischalten).

## If a container does not appear in the shop

Check in this order:

<table id="bkmrk-pr%C3%BCfen-hintergrund-s"> <thead> <tr> <th>Check</th> <th>Background</th> </tr> </thead> <tbody> <tr> <td>Is the **Status** set to *Released*?</td> <td>Only this status appears in the shop. *In progress*, *Completed*, and *Deleted* remain invisible.</td> </tr> <tr> <td>Is today within the **From / To** period?</td> <td>Empty fields mean no limitation.</td> </tr> <tr> <td>Does the **Culture** match the customer's language?</td> <td>In the multilingual shop, the container must be maintained per language.</td> </tr> <tr> <td>Were the data provided **with the Images checkbox**?</td> <td>Without this checkbox, the image is missing.</td> </tr> </tbody> </table>

A container that should no longer run does not have to be deleted — *Completed* removes it from the shop but keeps it in the list.

## Define display type of the area

1. Open *eCom \\ Container*, submenu **Items**.
2. For **Type of display** for the desired position — *Homepage top* or *Homepage bottom* — select **Slider** or **Float**.
3. For *Slider*: set in the field **Display interval** whether it switches automatically. See below.
4. Save and provide data.
 

### Display interval

The field appears only for *Slider*.

The value is entered in **milliseconds**: `3000` is three seconds.

<table id="bkmrk-wert-wirkung-0-der-s"> <thead> <tr> <th>Value</th> <th>Effect</th> </tr> </thead> <tbody> <tr> <td><code>0</code></td> <td>The slider does **not** switch automatically. Several cards are shown side by side; the customer navigates using the **arrows** left and right.</td> </tr> <tr> <td>greater than <code>0</code></td> <td>The slider switches automatically after this time. Only **one** card is visible at a time, with a **dot navigation** below.</td> </tr> </tbody> </table>

> **Warning:** The time applies **per image**, not for the entire cycle. With three containers and `3000`, each image is shown for three seconds; one cycle takes nine seconds.

Consider when setting: a short interval appears restless, and a container with text needs longer to read than a pure image.

**The switch pauses** as long as the customer’s mouse is over the slider or it is focused via keyboard. If the customer clicks a dot in the dot navigation, the slider **stops permanently** on that image and does not start again automatically. Therefore, do not expect every customer to see all containers — important content belongs on the first container or in the float area.

Both positions can be freely assigned: a slider at the top and a float area at the bottom is the usual combination, but the reverse or the same display type twice is also possible.

## Order of multiple containers

If multiple containers are in the same area, the **priority** determines the order. For a slider, the shop then shows arrows and dot navigation; for a float area, the containers are stacked from left to right.

# Maintain texts

## Summary

Under *eCom \\ Texte* you maintain the texts that the customer sees **in the shop** — legal texts, the cookie notification, and the confirmations after registration.

> **Distinction:** The texts of the **e-mails** are not here, but under *Basic configuration \\ Settings \\ E-Mail contents*. See [Setting up e-mail subscriptions and maintaining templates](https://wiki.dedesales.de/books/backend-ecom/page/e-mail-abos-einrichten-und-templates-pflegen).

For each block you can either store a **text** or a **URL**. If a URL is entered, the text is not displayed, but the link is opened.

## The available text blocks

The selection is made via the field **Type**:

<table id="bkmrk-textbaustein-wo-er-i"> <thead> <tr> <th>Text block</th> <th>Where it appears in the shop</th> </tr> </thead> <tbody> <tr> <td>Legal notice</td> <td>Footer, always visible</td> </tr> <tr> <td>Privacy policy</td> <td>Footer, always visible</td> </tr> <tr> <td>Terms and conditions</td> <td>Footer, only if content is stored</td> </tr> <tr> <td>Cookies</td> <td>Cookie confirmation on the login mask</td> </tr> <tr> <td>Support Hotline</td> <td>Footer, only if a text is stored</td> </tr> <tr> <td>Newsletter</td> <td>Footer, only if a text is stored</td> </tr> <tr> <td>Access request hint</td> <td>under the link *Access request?*</td> </tr> <tr> <td>Access request confirmation</td> <td>Message after submitting the access request</td> </tr> <tr> <td>Password forgotten confirmation</td> <td>Message after requesting a new password</td> </tr> <tr> <td>New customers reservation confirmation</td> <td>Message after submitting the form *Not a customer yet?*</td> </tr> </tbody> </table>

## Procedure

1. Open *eCom \\ Texte*.
2. Select the desired block in the field **Type**.
3. Either enter a text **or** enter a URL.
4. Save and provide data.
 

## The confirmation texts are your texts

Four blocks determine what the customer reads after an action: *Access request confirmation*, *Password forgotten confirmation*, *New customers reservation confirmation* and the hint under *Access request*.

The wordings quoted in the service description are the **delivery state**. You can completely replace them with your own formulations — for example, to add a telephone number for enquiries.

## When a URL is more useful

> **Important:** *Privacy policy* and *Legal notice* always appear in the shop **always**, even without maintained content — the customer then lands on a page with the wildcard text *"No content is currently stored for this type."* Both are mandatory information and should be filled before going live. The **Terms and conditions** behave differently: without content the entry does not appear at all.

For **Legal notice**, **Privacy policy** and **Terms and conditions** a URL is worthwhile: if you link the texts of your standard homepage, you only have to maintain them in one place.

For **Support Hotline** and **Newsletter** a text is more useful. Both menu items only appear in the shop if a text is stored — without text the menu item is missing.

## Text block "Access request hint"

You need this block if you have **not** set the setting *Not a customer yet?*. Then only *Access request?* appears on the login mask, and this block fills the associated hint — extendable with URLs.

Without the block the hint remains empty.

# Uploading Pictures

## Summary

Under *eCom \\ Pictures* you upload the two fixed graphics of the shop:

- the **graphic on the login page**
- your **logo for the menu bar**, which appears after the customer logs in
 

The required dimensions are listed in the service description on the *Marketing Container* page.

## Procedure

1. Open *eCom \\ Pictures*.
2. Select picture and perform **Upload**.
3. **Save.** This step is mandatory — see below.
4. Provide data, **with tick Pictures**.
 

## Why three steps are necessary

This is the most common stumbling block:

<table id="bkmrk-schritt-was-passiert"> <thead> <tr> <th>Step</th> <th>What happens</th> </tr> </thead> <tbody> <tr> <td>Upload</td> <td>The picture is in the **Temp folder**. It is not visible in the shop.</td> </tr> <tr> <td>Save</td> <td>The picture is moved to the correct folder.</td> </tr> <tr> <td>Provide with tick **Pictures**</td> <td>The picture is transferred to the shop.</td> </tr> </tbody> </table>

If one of the last two steps is skipped, the picture does not appear — even though the upload was successful and looks correct in the backend.

## Pictures created with AI

If a picture is marked as AI-generated, the shop displays the notice **AI GENERATED** above it. The tick **Picture is AI generated** is also available here under *eCom \\ Pictures*, not only at the container. See [Mark pictures as AI-generated](https://wiki.dedesales.de/books/backend-ecom/page/bilder-als-ki-generiert-kennzeichnen).

# Mark pictures as AI-generated

## Summary

From **version 19** onwards, a picture can be marked as *created with AI*. The shop then automatically displays the note **AI GENERATED** above the picture.

The marking is done with the checkbox **Picture is AI generated** below the picture. The checkbox is available in two places: under *eCom \\ Container* on the individual container and under *eCom \\ Pictures* for the fixed graphics of the shop.

How the note looks and where it appears is described in the service description on the *Marketing Container* page.

## Procedure for the container

1. Open *eCom \\ Container* and edit the container.
2. Upload the picture via **Add file**, if not already done.
3. Set the checkbox **Picture is AI generated** below the picture.
4. Save.
5. Provide data, **with checkbox Pictures**.
 

The checkbox is located directly below the picture preview, between **Picture upload** and **Content**.

## Procedure for the fixed graphics

You will find the same checkbox under *eCom \\ Pictures* for the login graphic and the logo. Procedure as with uploading — see [Uploading pictures](https://en.wiki.dedesales.de/books/backend-ecom/page/uploading-pictures) — additionally set the checkbox.

The marking always applies **per picture**, not once for the entire shop.

## If no note appears

<table id="bkmrk-pr%C3%BCfen-sie-hintergru"> <thead> <tr> <th>Check</th> <th>Background</th> </tr> </thead> <tbody> <tr> <td>Is the checkbox set **and saved**?</td> <td>Without saving, the change remains in the mask.</td> </tr> <tr> <td>Were the data subsequently provided **with checkbox Pictures**?</td> <td>As with every picture in the shop.</td> </tr> <tr> <td>Is the installation running on **version 19 or newer**?</td> <td>Older versions do not know the marking. The shop then displays the pictures normally, just without the note.</td> </tr> </tbody> </table>

## What this means for picture selection

The note is positioned **over** the picture, in the upper right corner. Therefore, choose a motif for marked pictures that does not have anything important there.

See [Marketing Container](https://wiki.dedesales.de/books/leistungsbeschreibung-ecom/page/marketing-container) in the service description.

# 3. Maintaining Discounts

# Creating and Evaluating Vouchers

## Summary

Vouchers are maintained under *eCom \\ Voucher management*.

A voucher is stored in the DeDeSales order as a **Header discount**. The usage rules and the effect in the order are described in the service description on the page *Vouchers and Special discounts*.

## Create voucher

1. Open *eCom \\ Voucher management* and add a voucher.
2. Select usage rule — one-time, multiple times, only on first order or once per customer.
3. Set discount value and specify whether it is charged **percentage** or as a **fixed value**.
4. Specify whether the voucher is **combinable with a Special discount**. See below.
5. Limit a period if necessary.
6. Save and provide data.
 

## What you specify when creating

Besides code and discount, four fields determine for whom and when the voucher applies:

<table id="bkmrk-feld-wirkung-von-%2F-b"> <thead> <tr> <th>Field</th> <th>Effect</th> </tr> </thead> <tbody> <tr> <td>From / until</td> <td>Validity period. Outside this, the shop reports *“The voucher has expired!”*</td> </tr> <tr> <td>Minimum order value</td> <td>The voucher only applies from this cart value. <code>0</code> means no limit.</td> </tr> <tr> <td>Type of customer selection</td> <td>restricts the group of customers, e.g. *all customers*</td> </tr> <tr> <td>Usability</td> <td>how often the code may be redeemed — one-time, multiple times, multiple times only on first order or multiple times only once per customer</td> </tr> </tbody> </table>

The discount is granted **only as a percentage** — the field is called *Discount %*.

## Combinable with a Special discount

<table id="bkmrk-wert-verhalten-im-sh"> <thead> <tr> <th>Value</th> <th>Behaviour in the shop</th> </tr> </thead> <tbody> <tr> <td>**Yes**</td> <td>Both discounts are added; the total goes as Header discount into the order.</td> </tr> <tr> <td>**No**</td> <td>The voucher is refused if the Special discount is higher than the voucher discount.</td> </tr> </tbody> </table>

With **No**, a comparison is made, not a blanket prohibition: If the voucher is better than the current Special discount, it is accepted. Only if the Special discount would be higher does the shop reject the voucher — the customer then keeps the cheaper Special discount.

## So that the customer can redeem the voucher

Additionally, the setting **Voucher input** under *eCom \\ Settings* must be enabled. This activates the input field in the Cart.

> **Attention:** Both places act independently. Without the *Voucher input* setting, there is no input field — the created voucher is then not redeemable, although it is valid.

## So that the discount arrives in the ERP system

> **Attention:** The Header discount only applies in your ERP system if your interface or your connector considers it. Also check how the interface is defined: fixed amounts are passed differently than percentage values.

## Evaluate who has used a voucher

1. Open *eCom \\ Voucher management*.
2. Select the desired voucher.
3. Switch to the tab **generated vouchers** on the left.
4. On the right, all vouchers that have been used appear.

# Create Special discounts

## Summary

Special discounts are maintained under *eCom \\ Special discounts*.

Unlike a voucher, a Special discount works **automatically** — the customer does not have to enter anything. It applies to all customers and all items in the specified period.

## Procedure

1. Open *eCom \\ Special discounts* and add a Special discount.
2. Set discount value and period.
3. Save and provide data.
 

## What to consider

- The Special discount **cannot be restricted to individual customers or items.** If you want that, you need a voucher with a Customer list or an Order template.
- It is stored like a voucher as a **Header discount** in the DeDeSales ORDER and is subject to the same reservations when transferring to the ERP system.
 

## If a voucher is redeemed in parallel

The behaviour is controlled not by the Special discount, but by the **voucher**. For each voucher it is determined whether it can be combined with a Special discount:

<table id="bkmrk-gutschein-kombinierb"> <thead> <tr> <th>Voucher combinable</th> <th>Behaviour</th> </tr> </thead> <tbody> <tr> <td>Yes</td> <td>Both discounts are added; the total goes as Header discount into the ORDER.</td> </tr> <tr> <td>No</td> <td>The voucher is refused if the Special discount is higher.</td> </tr> </tbody> </table>

When you start a Special discount, therefore check the ongoing vouchers — there it is decided whether the discounts add up.

# 4. Customers and Notifications

# Unlocking and Managing Registrations

## Summary

Under *eCom \\ eCom customer registration* you manage your customers' access.

The type has two lists: **open registrations** and **completed registrations**.

How the access model works and which e-mails are triggered is described in the service description on the *Access model* page.

## Open registrations

Here are the customers who **could not be registered automatically** because there were discrepancies in the registration compared to the master data from the ERP system.

Two options:

<table id="bkmrk-aktion-ergebnis-kund"> <thead> <tr> <th>Promotion</th> <th>Result</th> </tr> </thead> <tbody> <tr> <td>Unlock customer anyway</td> <td>The customer receives the e-mail *Registration - new password* and can log in.</td> </tr> <tr> <td>Delete registration</td> <td>The entry disappears, the customer does not receive access.</td> </tr> </tbody> </table>

A common cause is a missing or syntactically incorrect e-mail address in the customer master data. Cleaner than unlocking is then to **correct the address in the ERP system**. The customer then requests access again.

## Completed registrations

Here are all registered customers. Three options:

<table id="bkmrk-aktion-wann-sinnvoll"> <thead> <tr> <th>Promotion</th> <th>When useful</th> </tr> </thead> <tbody> <tr> <td>Change e-mail address</td> <td>The customer no longer has access to their stored address.</td> </tr> <tr> <td>Reset password</td> <td>The customer cannot log in and *Password forgotten* does not help.</td> </tr> <tr> <td>Delete registration</td> <td>Access should be revoked.</td> </tr> </tbody> </table>

## Special features regarding customer numbers

> **Not yet verified:** The following two points have not been checked.

- If your customer numbers contain **letters**, the names are displayed case-insensitively during registration.
- Customer numbers registered with a **space** appear without the space.
 

Either could be a possible reason why an entry seems to be missing when searching.

## So that you are informed of enquiries

The e-mail subscription **eCom - eCom customer registration** must be set up. Without this subscription, you will not be informed that a registration is waiting or that an address in the ERP system needs to be corrected.

# Setting up e-mail subscriptions and maintaining templates

## Summary

The shop's e-mail dispatch has two controls, and in case of problems, almost always one of these is the cause:

<table id="bkmrk-schraube-ort-steuert"> <thead> <tr> <th>Control</th> <th>Location</th> <th>Controls</th> </tr> </thead> <tbody> <tr> <td>**Subscription**</td> <td>*Administration \\ E-mail subscriptions*</td> <td>**who** receives an e-mail</td> </tr> <tr> <td>**Template**</td> <td>*Basic configuration \\ Settings \\ Manage e-mail contents*</td> <td>**what** it contains</td> </tr> </tbody> </table>

## Setting up subscriptions

For eCom, two groups of subscriptions are relevant, and this is the most important distinction in this chapter.

### Subscriptions that only concern eCom

These carry the prefix `eCom - `:

<table id="bkmrk-abo-typ-abonnent-erh"> <thead> <tr> <th>Subscription type</th> <th>Subscriber receives</th> <th>Mandatory</th> </tr> </thead> <tbody> <tr> <td><code>eCom &#45; Contact form</code></td> <td>Inquiries from the contact form</td> <td></td> </tr> <tr> <td><code>eCom &#45; Customer registration</code></td> <td>New customer inquiries and registrations with master data deviations</td> <td></td> </tr> <tr> <td><code>eCom &#45; Notification of failed ERP export</code></td> <td>Notification when a shop order could not be processed on the server</td> <td>**yes**</td> </tr> <tr> <td><code>eCom &#45; Create orders</code></td> <td>Notification about orders from the shop, with item listing in the mail text</td> <td></td> </tr> </tbody> </table>

### General subscriptions that also apply to eCom

These carry **no** prefix because they apply to the shop **and** normal operations. Known are:

<table id="bkmrk-abo-typ-wird-durch-d"> <thead> <tr> <th>Subscription type</th> <th>Triggered by the shop when</th> </tr> </thead> <tbody> <tr> <td><code>Dispatch of orders incl&#46; Excel</code></td> <td>every order — adds an Excel file to the order mail</td> </tr> <tr> <td><code>Customer master data change</code></td> <td>an address change via *My profile*</td> </tr> </tbody> </table>

> **Attention:** Filtering the subscription list by "eCom" shows only the first group. The general subscriptions are excluded — along with two notifications that the shop actually triggers. Therefore, go through the list once unfiltered when setting up.

To set up a subscription:

1. Open *Administration \\ E-mail subscriptions*.
2. Select subscription type and assign the responsible recipients.
3. Save.
 

> **Attention:** The subscription for the **failed ERP export** is mandatory. Without this subscription, no one notices that a customer order did not arrive in the ERP system.

## Maintaining templates

Under *Basic configuration \\ Settings \\ Manage e-mail contents*, select the template to edit via the **Type** field.

Relevant for eCom are:

<table id="bkmrk-template-typ-kontakt"> <thead> <tr> <th>Template type</th> </tr> </thead> <tbody> <tr> <td>Contact form</td> </tr> <tr> <td>Order</td> </tr> <tr> <td>Registration - new password</td> </tr> <tr> <td>Registration - Email new</td> </tr> <tr> <td>Password forgotten</td> </tr> <tr> <td>Reset password</td> </tr> <tr> <td>Registration of new customers</td> </tr> <tr> <td>Change e-mail</td> </tr> </tbody> </table>

## Which process triggers which e-mail

This table is the tool for the question "why is no e-mail coming" or "why is the wrong text inside":

> **Note:** The subscription *Customer master data change* resulted from merging two earlier subscriptions.

<table id="bkmrk-vorgang-im-shop-temp"> <thead> <tr> <th>Process in shop</th> <th>Template</th> <th>Sent via</th> <th>To customer</th> <th>To backoffice</th> </tr> </thead> <tbody> <tr> <td>Not a customer yet?</td> <td>Registration of new customers</td> <td>Subscription *eCom - Customer registration*</td> <td></td> <td>x</td> </tr> <tr> <td>Not a customer yet?, master data deviating</td> <td>Registration - Email new</td> <td>Subscription *eCom - Customer registration*</td> <td></td> <td>x</td> </tr> <tr> <td>Not a customer yet?, master data correct</td> <td>Registration - new password</td> <td>Subscription *eCom - Customer registration*</td> <td>x</td> <td>x</td> </tr> <tr> <td>Access manually enabled</td> <td>Registration - new password</td> <td>Subscription *eCom - Customer registration*</td> <td>x</td> <td>x</td> </tr> <tr> <td>Password forgotten</td> <td>Password forgotten</td> <td>without subscription</td> <td>x</td> <td></td> </tr> <tr> <td>Click on the link in this e-mail</td> <td>Reset password</td> <td>without subscription</td> <td>x</td> <td></td> </tr> <tr> <td>Order</td> <td>Order</td> <td>Subscription *eCom - Create orders*</td> <td>x</td> <td>x</td> </tr> <tr> <td>Contact form</td> <td>Contact form</td> <td>Subscription *eCom - Contact form*</td> <td></td> <td>x</td> </tr> <tr> <td>Order faulty</td> <td>—</td> <td>Subscription *eCom - Notification of failed ERP export*</td> <td></td> <td>x</td> </tr> <tr> <td>Address change in shop</td> <td>no template</td> <td>Subscription *Customer master data change*</td> <td></td> <td>x</td> </tr> <tr> <td>Change password in shop</td> <td>—</td> <td>no e-mail</td> <td></td> <td></td> </tr> <tr> <td>Change e-mail address in shop</td> <td>Change e-mail</td> <td>without subscription</td> <td>x</td> <td></td> </tr> </tbody> </table>

## Excel file for order mail

The order mail can additionally include the items as an **Excel file** attachment. For this, **two** subscriptions are necessary:

<table id="bkmrk-abo-wirkung-ecom---a"> <thead> <tr> <th>Subscription</th> <th>Effect</th> </tr> </thead> <tbody> <tr> <td><code>eCom &#45; Create orders</code></td> <td>The order mail is sent at all, with item listing in the text.</td> </tr> <tr> <td><code>Dispatch of orders incl&#46; Excel</code></td> <td>The Excel file is generated and attached.</td> </tr> </tbody> </table>

Without the second subscription, the mail comes **without Excel**.

The structure of the Excel file is **fixed** and cannot be configured.

`Dispatch of orders incl. Excel` belongs to the general subscriptions without prefix — see above.

For many backoffices, the Excel is the file actually worked with. If someone reports the order mail is unusable, the missing second subscription is the first place to check.

## Behaviour in the test system

In the test system, e-mails **do not go to the customer**, but to the eCom employee's e-mail address from *Basic configuration \\ Employees*. This also applies to the e-mail with the visible password.

## Which address customer mails go to

The recipient is always the **e-mail address of the eCom user**, i.e. the shop access — not the address from the customer master data. If the customer changes it in the shop via *Change e-mail address*, from the confirmation on all further mails go to the new address. The master data remain unaffected.

This is confirmed for *Password forgotten* and the *Order confirmation*.

> **In the test system**, all mails go to the eCom employee's address. The text then states *"The e-mail recipients were rewritten in the test system! The original e-mail recipients were: …"* — this allows reading the actual recipient without needing a second mailbox.

## What the order confirmation contains for the customer

In the delivery state, the mail to the customer contains only a short thank you — **no items, no totals, no discount**.

This can be changed on two levels:

<table id="bkmrk-was-wo-wer-wortlaut-"> <thead> <tr> <th>What</th> <th>Where</th> <th>Who</th> </tr> </thead> <tbody> <tr> <td>**Wording** of the e-mail</td> <td>*Basic configuration \\ Settings \\ E-mail contents*</td> <td>Yourself</td> </tr> <tr> <td>**Item listing** in the customer mail</td> <td>Own template</td> <td>Your project manager at DeDeNet</td> </tr> </tbody> </table>

The items can thus be sent along — for this a template is stored, and this is handled by the project manager. Please contact your Contact at DeDeNet for this.

The **internal** notification to the backoffice, however, lists the items by default.

## Subject lines differ from template names

This is shown when resetting the password:

<table id="bkmrk-template-betreff-der"> <thead> <tr> <th>Template</th> <th>Subject of the e-mail</th> </tr> </thead> <tbody> <tr> <td>Password forgotten</td> <td>*Request - Reset password*</td> </tr> <tr> <td>Reset password</td> <td>*Confirmation - Password reset*</td> </tr> </tbody> </table>

Anyone wanting to assign an e-mail to a template based on its subject looks under a different name. For the other templates, the subject is not recorded.

# 5. Further Configuration

# Extend menu and maintain contact reasons

## Summary

Two small configurations that concern the footer and the contact form of the shop.

## Create custom menu items

Via *eCom \\ Menu extension* you create additional menu items for the shop. They appear in the **second column of the footer** — **separately for each language**.

1. Open *eCom \\ Menu extension*.
2. Select language.
3. Create and fill menu item.
4. Save and provide data.
 

Typical examples from a running system are menu items like *eCom user manual* or *Newsletter*.

## Maintain contact reasons

The selection list in the shop's contact form comes from a code table.

1. Open *Basic configuration \\ Code table*.
2. Select type **eCom contact reason**.
3. Maintain the desired contact reasons.
4. Save and provide data.
 

Without maintained contact reasons, the customer has no selection in the contact form.

To ensure that enquiries reach you, the e-mail subscription **eCom - contact form** must also be set up.

# Activate Order template for eCom

## Summary

Order templates only appear in the shop if you activate them there. This is done under *Order support \\ Order template* in the **eCom** section of the respective template.

The fields of this section and their meaning are described in the service description.

## Procedure

1. Open *Order support \\ Order template* and select the template.
2. In the **eCom** section, set the **Display**:
 
<table id="bkmrk-wert-wirkung-keine-e"> <thead> <tr> <th>Value</th> <th>Effect</th> </tr> </thead> <tbody> <tr> <td>None</td> <td>does not appear in the shop (default)</td> </tr> <tr> <td>Start menu</td> <td>appears in the product groups menu</td> </tr> <tr> <td>Highlight menu</td> <td>appears in the Start menu **and** in the Highlight menu</td> </tr> </tbody> </table>

3. If necessary, set **Valid from** and **Valid until**. This controls the shop period independently of the client.
4. If necessary, set **Prefix** and **Name** for the display in the shop.
5. Save and provide data.
 

## Why separate appointments for the shop make sense

The field force usually sees promotions a few days before the start to prepare and plan appointments. For the shop, you usually do not want this — the promotion should only appear on the start day.

This is exactly what **Valid from** and **Valid until** in the eCom section are for: they override the period of the client.

## Why a separate name makes sense

If the order template has a name intended for the field force — for example with internal notes or condition information — you can override it customer-optimised for the shop via the **Name** field.

## Only for the shop, not for the field force

The checkbox **Not for field force** makes the template available exclusively in the eCom system.

## Limit assortment to an item list

The checkbox *For the selected customers of this customer list, display only the items of the item list in the eCom system* acts like a closed listing: the customers of this template may only access, search for, and order the items of the item list.

> **Warning:** If a customer appears in **multiple** order templates with this checkbox, the eCom system makes a **random selection** of which one applies. A mixture of several item lists is not possible. Ensure that each customer appears in only one such template.

## What does not arrive in the shop

**No modules** are available in the eCom system. Modules assigned to the order template are not displayed in the shop — regardless of which they are.

# Maintaining Client Values for eCom

## Summary

Some values that control the order completion in the shop are not located in eCom, but under *Basic configuration \\ Clients*.

The basic rule: **Client values apply to all channels**, that is, for both Client and Shop together — unless eCom deviates via a subsequent setting.

Two value lists are the exception and carry their own **eCom flag**.

## The two value lists with eCom flag

Affected are **Free carriage limit** and **Freight costs**. Both lists have the columns `Value`, `Currency` and `eCom`.

> If active, the value applies only to eCom. If not active, only to the DeDeSales Client.

> **Attention:** The flag is a **switch, not an addition.** A row applies either to the Shop or to the Client, never to both. Anyone who wants to supply both channels needs **two rows** — one with the flag and one without. If the eCom row is missing, the Shop has no value.

Both lists include a currency. With multiple currencies, you therefore need one row per currency — and that again per channel.

## Procedure

1. Open *Basic configuration \\ Clients* and select the client.
2. Go to the value list **Free carriage limit** or **Freight costs**.
3. Create a row for the Client — **without** the eCom flag.
4. Create a row for the Shop — **with** the eCom flag.
5. Repeat for each currency if there are multiple currencies.
6. Save and provide data.
 

## Interaction of Free carriage limit and Freight costs

Below the Free carriage limit, freight costs are calculated; above it, they are not.

The calculated freight costs appear in the Cart as a separate line — above the item you have stored under *eCom \\ Settings* as the **Freight costs Item**. This setting therefore contains the **Item number**, not the amount.

## Values without eCom flag

These fields of the client apply to all channels:

<table id="bkmrk-feld-bekannte-wirkun"> <thead> <tr> <th>Field</th> <th>Known effect</th> </tr> </thead> <tbody> <tr> <td>Minimum order value</td> <td>**Does not apply in the Shop** — this general value is not read during order completion, but only used for export. For the Shop, the value in the **eCom tab** applies. See below.</td> </tr> <tr> <td>Minimum delivery period in days</td> <td>Controls the earliest possible date of delivery.</td> </tr> <tr> <td>Maximum item value</td> <td>Is calculated, but the message does **not** reach the customer — it is an enquiry, and the Shop skips enquiries. See below.</td> </tr> <tr> <td>Warning at quantity</td> <td>Similarly: is calculated, but the enquiry does **not** reach the customer. See below.</td> </tr> <tr> <td>Holiday ID</td> <td>**Applies in the Shop.** Determines the public holiday calendar for calculating the earliest possible date of delivery — one day is added for each public holiday encountered.</td> </tr> <tr> <td>Minimum order value (warning)</td> <td>**Does not apply in the Shop** — the value is not filled anywhere and would remain invisible as an enquiry anyway.</td> </tr> <tr> <td>Minimum order quantity</td> <td>**Does not apply in the Shop** — only in the sales client. See below.</td> </tr> <tr> <td>Minimum order unit</td> <td>The **unit** to which the minimum order quantity refers — for example *pcs* or *crt*. Not a numeric value. Also applies only in the Client.</td> </tr> </tbody> </table>

### The minimum order value appears twice

There are *two* minimum order values at the client: one general and one in the **eCom tab**. For the Shop, only the value in the eCom tab counts — the general one is not read during order completion.

<table id="bkmrk-wert-wirkung-im-shop"> <thead> <tr> <th>Value</th> <th>Effect in Shop</th> </tr> </thead> <tbody> <tr> <td>Minimum order value, **eCom tab**</td> <td>**applies**</td> </tr> <tr> <td>Minimum order value, general</td> <td>none — only for export</td> </tr> <tr> <td>Minimum order value of the debtor</td> <td>only in a special case, see [Order completion](https://wiki.dedesales.de/books/leistungsbeschreibung-ecom/page/bestellabschluss)</td> </tr> <tr> <td>Minimum order value (warning)</td> <td>none</td> </tr> </tbody> </table>

> **Attention:** This is the most common confusion on this page. Anyone who maintains the value limit for the Shop in the general field wonders why nothing happens — and finds the error hard to detect because the value is correctly saved.

### Why two fields are calculated but nothing appears

*Maximum item value* and *Warning at quantity* are actually evaluated server-side. However, their message is an **enquiry** — a message that someone in the sales client confirms to proceed.

In the Shop, there is no one who could do this. Therefore, the Shop **always skips enquiries**. This is a deliberate decision, not an error.

<table id="bkmrk-feld-vertriebsclient"> <thead> <tr> <th>Field</th> <th>Sales client</th> <th>old Shop</th> <th>new Shop</th> </tr> </thead> <tbody> <tr> <td>Maximum item value</td> <td>applies</td> <td>message was visible</td> <td>invisible</td> </tr> <tr> <td>Warning at quantity</td> <td>applies</td> <td>message was visible</td> <td>invisible</td> </tr> </tbody> </table>

The fields are therefore **not non-functional** — they just no longer have effect where the customer would see them. Anyone maintaining them for the Shop should know that they remain without consequences there.

### Minimum order quantity: no effect in the Shop

The two fields belong together — a check only takes place if **both** are filled — and they can be combined with the debtor value. However, none of this reaches the Shop:

- When loading the Cart, the undercutting is **calculated** and a notice text is generated (*"The minimum order quantity has not been reached ..."*).
- The interface through which the Cart retrieves its notices does **not output** this text. It is therefore lost before it reaches the Shop.
- The order completion only checks the minimum order **value** in euros, not quantity. Therefore, an order is never blocked by this.
 

This is not a peculiarity of the new Shop — the gap already exists in the existing web interface and thus applied equally to the old Shop.

**For the setup, this means:** The two fields may be maintained, but they then only apply in the order entry of the sales client.

# Maintain Settings

## Summary

Under *eCom \\ Settings* you configure the behaviour of the shop.

Which settings exist, what values they take, and what they do is described in the specification on the page *Settings at a Glance*. This page only describes the procedure and the places where mistakes are commonly made.

## Procedure

1. Open *eCom \\ Settings*.
2. Change setting.
3. Save.
4. Provide data.
 

A change takes effect at the earliest after the next shop retrieval interval, i.e. after 15 or 30 minutes.

## Settings that only take effect together with another place

This is the most common source of errors: the setting is set, but the second place is missing.

<table id="bkmrk-einstellung-braucht-"> <thead> <tr> <th>Setting</th> <th>Also requires</th> </tr> </thead> <tbody> <tr> <td>Voucher input</td> <td>a created voucher under *eCom \\ Voucher management*</td> </tr> <tr> <td>Freight costs item</td> <td>Freight costs and Free carriage limit as client values **with eCom flag**</td> </tr> <tr> <td>Apply minimum order value from debtor</td> <td>delivered debtor data; otherwise the client value applies</td> </tr> <tr> <td>Default language</td> <td>Item texts and product group texts in the selected culture</td> </tr> <tr> <td>Not a customer yet?, checkbox removed</td> <td>the text block *Access request – General Information* under *eCom \\ Texts*</td> </tr> </tbody> </table>

## Change shop colours via CSS

The colouring is stored as free text in the field **CSS**. The colours are given as CSS variables in HSL notation.

For switching to your corporate colour, usually two values are sufficient:

1. `--primary` set to your corporate colour — dark shade.
2. `--primary-soft` set to the same hue angle, but very light.
 

The HSL notation is `hsl(hue saturation lightness)`. To make it lighter or darker in the same colour, you only change the **last** value. Variables with `var(--primary)` automatically take the value of the main colour.

> **Warning:** Each colour has a `-foreground` colour, i.e. the text colour on it. Ensure sufficient contrast, otherwise text in the shop becomes unreadable.

### The page background

Previously, the shop generated a **background gradient** from `--primary`. This could only be disabled by manually setting its two endpoints `--verlauf-warm` and `--verlauf-kalt` to the same colour.

There is now a dedicated variable. Both endpoints point to `--shop-hintergrund`, which in turn points to `--primary-soft`:

```css
--shop-hintergrund: var(--primary-soft); --verlauf-warm: var(--shop-hintergrund); --verlauf-kalt: var(--shop-hintergrund); 
```

Because both endpoints have the **same** value, in the default state **no gradient is visible** — the background is solid. And because the value is linked to `--primary-soft`, it automatically adapts to the corporate colour: Whoever changes `--primary-soft` gets the matching background.

**Set a different background.** Now only **one** line is needed instead of two:

```css
:root { --shop-hintergrund: hsl(0 0% 100%); } 
```

**Want a gradient.** Set `--verlauf-warm` and `--verlauf-kalt` individually to two **different** colours and leave `--shop-hintergrund` untouched.

> **Note on colour choice:** A strong main colour appears much stronger over large areas than on a button. Because the background is linked to `--primary-soft` — the **light** shade — this is less noticeable than before. Still, check the result on the finished shop before fixing the colour.

### The default state and a counterexample

The shop is delivered in **orange**. Next to it is a blue palette as an example for a change — both are based on **one** hue angle:

<table id="bkmrk-variable-orange-%28aus"> <thead> <tr> <th>Variable</th> <th>Orange (default)</th> <th>Blue (example)</th> </tr> </thead> <tbody> <tr> <td><code>&#45;&#45;primary</code></td> <td><code>hsl&#40;27 87&#37; 49&#37;&#41;</code></td> <td><code>hsl&#40;215 100&#37; 25&#37;&#41;</code></td> </tr> <tr> <td><code>&#45;&#45;primary&#45;soft</code></td> <td><code>hsl&#40;27 87&#37; 94&#37;&#41;</code></td> <td><code>hsl&#40;215 100&#37; 94&#37;&#41;</code></td> </tr> <tr> <td><code>&#45;&#45;secondary</code></td> <td><code>hsl&#40;36 82&#37; 50&#37;&#41;</code></td> <td><code>hsl&#40;211 100&#37; 40&#37;&#41;</code></td> </tr> <tr> <td><code>&#45;&#45;accent</code></td> <td>like <code>&#45;&#45;primary</code></td> <td>like <code>&#45;&#45;primary</code></td> </tr> <tr> <td><code>&#45;&#45;ring</code></td> <td>like <code>&#45;&#45;primary</code></td> <td>like <code>&#45;&#45;primary</code></td> </tr> <tr> <td><code>&#45;&#45;shop&#45;hintergrund</code></td> <td><code>var&#40;&#45;&#45;primary&#45;soft&#41;</code></td> <td>freely selectable</td> </tr> <tr> <td><code>&#45;&#45;verlauf&#45;warm</code>, <code>&#45;&#45;verlauf&#45;kalt</code></td> <td>both <code>var&#40;&#45;&#45;shop&#45;hintergrund&#41;</code></td> <td>both <code>hsl&#40;0 0&#37; 100&#37;&#41;</code> — white, so no visible gradient</td> </tr> </tbody> </table>

From `--primary` to `--primary-soft` the hue and saturation remain **the same**; only the **lightness** jumps — for orange from 49 to 94 per cent, for blue from 25 to 94. This is exactly how the notation is intended: one colour, two lightness levels.

`--secondary` differs slightly in both cases — a few degrees in hue and a lighter level. This is enough to set off secondary elements without introducing a second colour.

> **Note:** `--accent` and `--ring` take the main colour. If you do not explicitly want them different, you do not have to set them. In practice, there are thus **three** values: `--primary`, `--primary-soft` and `--secondary`.

The complete list of variables is in the specification.