# Finalisation de la commande

## Aperçu

Lors de la finalisation de la commande, le client complète la commande et l'envoie.

Les positions proviennent du panier, ici s'ajoutent les données d'en-tête : date de livraison, adresse de livraison, numéro de commande et textes.

Les champs affichés sont contrôlés par les droits du rôle eCom. La possibilité d'envoyer la commande est en outre déterminée par plusieurs seuils de valeur issus du mandant et des paramètres.

## Champs

<table id="bkmrk-feld-recht-referenz-"> <thead> <tr> <th>Champ</th> <th>Droit</th> <th>Référence</th> </tr> </thead> <tbody> <tr> <td>Date de livraison</td> <td> </td> <td>Paramètre *Liefertermineingabe* : Non · Optionnel · Obligatoire. **Pas** le droit homonyme du rôle, voir ci-dessous</td> </tr> <tr> <td>Adresse de livraison, sélection dans une liste</td> <td><code>AUFTRAG &#47; Kopf &#47; Lieferadresse&#44; Auswahl aus Datenbank</code></td> <td> </td> </tr> <tr> <td>Adresse de livraison, saisir une nouvelle adresse</td> <td><code>AUFTRAG &#47; Kopf &#47; Lieferadresse&#44; Erfassung einer neuen Adresse</code></td> <td> </td> </tr> <tr> <td>Adresse de livraison obligatoire</td> <td><code>AUFTRAG &#47; Kopf &#47; Lieferadresse Pflicht</code></td> <td> </td> </tr> <tr> <td>Votre numéro de commande</td> <td><code>AUFTRAG &#47; Kopf &#47; Kundenauftragsnummer</code> : Non · Optionnel · Obligatoire</td> <td>Paramètre *Kundenauftragsnummer generieren*</td> </tr> <tr> <td>Texte commande usage ext.</td> <td><code>AUFTRAG &#47; Kopf &#47; Auftragkopf – Auftragstext extern</code></td> <td> </td> </tr> <tr> <td>Commentaire cde interne</td> <td><code>AUFTRAG &#47; Kopf &#47; Auftragkopf – Auftragstext intern</code></td> <td> </td> </tr> <tr> <td>Texte préparation de commande</td> <td><code>AUFTRAG &#47; Kopf &#47; Kommissioniertext</code></td> <td>Libellé *Auftragskopf – Kommissioniertext*</td> </tr> <tr> <td>Remarque</td> <td> </td> <td> </td> </tr> <tr> <td>Infos livraison</td> <td> </td> <td>Libellé dans la boutique ; dans les droits *Auslieferertext*</td> </tr> </tbody> </table>

### Ordre à l'écran

La page est **à deux colonnes**. À gauche les saisies, à droite le résumé du panier.

<table id="bkmrk-reihenfolge-links-be"> <thead> <tr> <th>Ordre à gauche</th> <th>Libellé dans la boutique</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>**Adresse de livraison** — en texte, à côté le bouton **Modifier**</td> </tr> <tr> <td>2</td> <td>**Date de livraison souhaitée** — champ date avec le caractère de remplacement *Veuillez choisir svp*</td> </tr> <tr> <td>3</td> <td>**Votre numéro de commande**</td> </tr> <tr> <td>4</td> <td>**Remarque**</td> </tr> <tr> <td>5</td> <td>**En-tête de commande - Texte commande usage ext.**</td> </tr> <tr> <td>6</td> <td>**Infos livraison**</td> </tr> <tr> <td>7</td> <td>**En-tête de commande - Texte préparation de commande**</td> </tr> <tr> <td>8</td> <td>**Incoterms** et **USt-ID** — petites lignes de texte sans champ de saisie</td> </tr> <tr> <td>9</td> <td>Bouton **Commander de manière contraignante** sur toute la largeur de la colonne</td> </tr> </tbody> </table>

À droite se trouve la carte du panier avec les positions, la **somme totale** et en dessous l'indication grise de remise.

> **Les libellés sont incohérents :** Le champ date s'appelle dans la boutique **Date de livraison souhaitée**, tandis que le paramètre dans le backend s'appelle *Liefertermineingabe*. Pour le texte de commande, c'est **Auftragkopf** sans s, pour le texte préparation de commande **Auftragskopf** avec s. Et le champ qui s'appelle dans les droits *Auslieferertext* porte dans la boutique le libellé **Ausliefertext**.

### Informations issues de la fiche client

À côté des champs de saisie, la finalisation de commande affiche les conditions liées au client :

<table id="bkmrk-angabe-beispiel-inco"> <thead> <tr> <th>Information</th> <th>Exemple</th> </tr> </thead> <tbody> <tr> <td>Incoterms</td> <td>Code avec traduction depuis la table de codes</td> </tr> <tr> <td>USt-ID</td> <td>Numéro d'identification TVA du client</td> </tr> <tr> <td>Conditions d'envoi</td> <td>Code avec traduction depuis la table de codes</td> </tr> <tr> <td>Conditions de paiement</td> <td>Code avec traduction depuis la table de codes</td> </tr> </tbody> </table>

Chacune de ces informations apparaît **seulement si elle est enregistrée chez le client**. Si les conditions d'envoi et de paiement ne sont pas renseignées, seuls les Incoterms et l'USt-ID sont affichés.

<table id="bkmrk-eigenschaft-verhalte"> <thead> <tr> <th>Propriété</th> <th>Comportement</th> </tr> </thead> <tbody> <tr> <td>Origine</td> <td>**Système ERP**, enregistré chez le client</td> </tr> <tr> <td>Modifiable dans la boutique</td> <td>**non** — affichage uniquement</td> </tr> <tr> <td>Libellé de la valeur</td> <td>traduisible via la **table de codes** associée</td> </tr> </tbody> </table>

> **Ne pas confondre avec les droits :** La zone `AUFTRAG / Kopf` comprend certes des droits nommés *Versandbedingungen*, *Zahlungsbedingungen* et *Zahlungsmethode*, mais ceux-ci ne sont **pas pertinents pour eCom**. Ils contrôlent la modification des conditions, ce qui n'est pas possible dans la boutique. L'affichage seul n'est lié à aucun droit.

### Résumé du panier

À droite des champs, la page affiche à nouveau le panier :

<table id="bkmrk-angabe-beispiel-je-p"> <thead> <tr> <th>Information</th> <th>Exemple</th> </tr> </thead> <tbody> <tr> <td>par position : désignation, quantité, montant</td> <td>*dedesales — 2× — 240,00 EUR*</td> </tr> <tr> <td>**Somme totale**</td> <td>*480,00 EUR*</td> </tr> </tbody> </table>

### Les remises ne sont pas déduites

Le bon et la remise spéciale ne réduisent **pas** la somme affichée. À la place, une indication grise apparaît sous le résumé pour chaque remise :

<table id="bkmrk-fall-hinweis-gutsche"> <thead> <tr> <th>Cas</th> <th>Indication</th> </tr> </thead> <tbody> <tr> <td>Bon utilisé</td> <td>« Le crédit de 3 % sera déduit uniquement sur la facture. »</td> </tr> <tr> <td>Remise spéciale active</td> <td>« La remise spéciale de 5 % sera déduite uniquement sur la facture. »</td> </tr> </tbody> </table>

C'est une **décision consciente**, pas une erreur : la remise est appliquée comme remise d'en-tête dans la commande et est prise en compte lors de la facturation.

Le client voit ainsi lors de la saisie des données d'en-tête ce qu'il commande — sans avoir à revenir au panier.

## Champs obligatoires

Trois informations peuvent être rendues obligatoires. Elles ont en commun que la vérification s'effectue **sur le serveur, uniquement lors de l'envoi**.

<table id="bkmrk-angabe-gesteuert-%C3%BCbe"> <thead> <tr> <th>Information</th> <th>Contrôlé par</th> <th>Niveaux</th> </tr> </thead> <tbody> <tr> <td>Adresse de livraison</td> <td>Droit <code>AUFTRAG &#47; Kopf &#47; Lieferadresse Pflicht</code></td> <td>seulement **Oui/Non**</td> </tr> <tr> <td>Votre numéro de commande</td> <td>Droit <code>AUFTRAG &#47; Kopf &#47; Kundenauftragsnummer</code></td> <td>Non · Optionnel · Obligatoire</td> </tr> <tr> <td>Date de livraison</td> <td>Paramètre *Liefertermineingabe*</td> <td>Non · Optionnel · Obligatoire</td> </tr> </tbody> </table>

> **Important :** Les champs obligatoires ne sont **pas signalés** dans le formulaire — pas d'astérisque, pas de mise en évidence, pas d'indication technique d'obligation. Tous les champs ont le même aspect. Le client ne découvre qu'en cliquant sur *Commander de manière contraignante* qu'il manque quelque chose.

### En pratique, l'obligation est peu perceptible

Celui qui essaie le formulaire a rapidement l'impression qu'il n'y a **aucun** champ obligatoire. Ce n'est pas tout à fait faux — deux des trois informations sont remplies par le système lui-même avant la vérification :

<table id="bkmrk-angabe-warum-die-pfl"> <thead> <tr> <th>Information</th> <th>Pourquoi l'obligation est rarement remarquée</th> </tr> </thead> <tbody> <tr> <td>Date de livraison</td> <td>Si le paramètre est sur *Obligatoire*, le serveur insère dans un champ vide la date la plus proche possible.</td> </tr> <tr> <td>Votre numéro de commande</td> <td>Si *Kundenauftragsnummer generieren* est actif, le système génère lui-même un numéro si le champ est vide.</td> </tr> <tr> <td>**Adresse de livraison**</td> <td>Il n'y a **pas** de valeur de remplacement. C'est la seule des trois informations qui bloque réellement une commande.</td> </tr> </tbody> </table>

Avec le droit *Adresse de livraison obligatoire* activé et la génération de numéro active, seule l'adresse de livraison bloque. Si on retire le droit d'adresse, la commande passe — même si *Votre numéro de commande* est sur *Obligatoire*.

### Différences entre les niveaux dans la boutique

<table id="bkmrk-angabe-unterschied-z" style="width:100%;"> <thead> <tr> <th style="width:20.0189%;">Information</th> <th style="width:79.9811%;">Différence entre les niveaux</th> </tr> </thead> <tbody> <tr> <td style="width:20.0189%;">Votre numéro de commande</td> <td style="width:79.9811%;">*Optionnel* et *Obligatoire* ont le même aspect dans le formulaire : le champ apparaît sans indication d'obligation. Seul *Non* le masque.</td> </tr> <tr> <td style="width:20.0189%;">Date de livraison</td> <td style="width:79.9811%;">*Non* et *Optionnel* se comportent **de la même façon** — aucune vérification d'obligation n'a lieu.</td> </tr> </tbody> </table>

Le niveau ne décide donc pas de l'apparence du formulaire, mais seulement si la commande est rejetée à l'envoi.

### La date de livraison est réglée à deux endroits

C'est le piège de ce champ : il existe **deux** contrôles pour la date de livraison à différents endroits, avec des listes de choix différentes.

<table id="bkmrk-stelle-ort-werte-ein"> <thead> <tr> <th>Lieu</th> <th>Emplacement</th> <th>Valeurs</th> </tr> </thead> <tbody> <tr> <td>Paramètre *Liefertermineingabe*</td> <td>*eCom \\ Einstellungen*</td> <td>**trois** : Non · Optionnel · Obligatoire</td> </tr> <tr> <td>Droit date de livraison</td> <td>Rôle</td> <td>**cinq** : en plus *Obligatoire au début* et *Modèle automatique*</td> </tr> </tbody> </table>

Ce qui compte pour la boutique est le **paramètre eCom** — et seulement pour la vérification d'obligation, pas pour l'affichage. Le droit dans le rôle appartient au client commercial et n'a aucun effet dans la boutique ; ses deux valeurs supplémentaires n'existent pas là.

> **Attention pour la configuration :** Celui qui veut l'obligation dans la boutique doit régler le **paramètre eCom** sur *Obligatoire*. Un droit réglé sur *Obligatoire* dans le rôle n'a aucun effet dans la boutique.

Le comportement attendu derrière *Modèle automatique* existe d'ailleurs aussi sans cette valeur : si le paramètre eCom est sur *Obligatoire* et que le client laisse le champ vide, le serveur insère lui-même la **date la plus proche possible** — la vérification d'obligation est ainsi satisfaite. Une saisie propre du client reste inchangée.

## Messages lors de l'envoi

Toutes les vérifications ne s'effectuent que lorsque le client clique sur **Commander de manière contraignante**. Jusqu'à ce moment, le formulaire ne signale rien.

Le message apparaît alors **en haut de la page**, entre le titre *Finalisation de la commande* et le formulaire : une boîte claire sur toute la largeur, bord gauche en rouge. Il **n'est pas placé au champ concerné** — le client doit déduire quel champ est visé à partir du texte.

<table id="bkmrk-ausl%C3%B6ser-meldung-wir"> <thead> <tr> <th>Déclencheur</th> <th>Message</th> <th>Effet</th> </tr> </thead> <tbody> <tr> <td>Date de livraison manquante</td> <td>« Aucun date de livraison n'a été indiquée. »</td> <td>bloque — **il est incertain que ce message puisse apparaître dans la boutique**, voir ci-dessous</td> </tr> <tr> <td>Date de livraison trop tôt</td> <td>« La date de livraison ne peut pas être respectée. » — souvent complété par « La date de livraison la plus proche est … »</td> <td>bloque</td> </tr> <tr> <td>Date de livraison avant la date de commande</td> <td>« La date de livraison ne peut pas être antérieure à la date de commande. »</td> <td>bloque</td> </tr> <tr> <td>Numéro de commande manquant</td> <td>« Aucun numéro de commande client n'a été indiqué. »</td> <td>bloque</td> </tr> <tr> <td>Adresse de livraison manquante ou plus valide</td> <td>« L'adresse de livraison est invalide. »</td> <td>bloque</td> </tr> <tr> <td>Champs manquants dans la nouvelle adresse de livraison saisie</td> <td>« Veuillez indiquer les champs suivants pour l'adresse de livraison temporaire : »</td> <td>bloque</td> </tr> <tr> <td>Code postal incorrect</td> <td>« Veuillez saisir un code postal correct. »</td> <td>bloque</td> </tr> <tr> <td>Pays manquant</td> <td>« Veuillez choisir un pays. »</td> <td>bloque</td> </tr> <tr> <td>Valeur minimale de commande non atteinte</td> <td>« La valeur minimale de commande de … n'a pas été atteinte. » avec montant inséré</td> <td>bloque</td> </tr> <tr> <td>Panier vide</td> <td>« Le panier est vide. »</td> <td>empêche l'envoi</td> </tr> </tbody> </table>

Deux autres messages concernent la limite franco de port. Ils apparaissent **dans le panier**, pas ici :

<table id="bkmrk-ausl%C3%B6ser-meldung-fra"> <thead> <tr> <th>Déclencheur</th> <th>Message</th> </tr> </thead> <tbody> <tr> <td>Limite franco de port atteinte</td> <td>« Livraison franco domicile »</td> </tr> <tr> <td>Limite franco de port non atteinte</td> <td>« La limite franco de port de … n'a pas été atteinte. »</td> </tr> </tbody> </table>

> **Attention :** Le même message apparaît aussi si le droit *Adresse de livraison obligatoire* est activé, mais que le client **ne peut pas du tout choisir d'adresse** — par exemple parce qu'aucune n'est enregistrée pour lui. Le texte parle alors d'une adresse invalide, bien qu'il n'y ait simplement aucune adresse à choisir. Celui qui active ce droit doit donc s'assurer que les clients ont aussi des adresses de livraison.

> **Remarque :** Pour la nouvelle adresse de livraison saisie, la boutique ne donne que la phrase d'introduction — la liste des champs manquants qui devrait suivre n'apparaît pas. Le client doit vérifier lui-même les champs.

### Les textes peuvent être adaptés

Tous les messages sauf *« Le panier est vide. »* sont des **textes traduisibles**, pas des chaînes codées en dur. Ils peuvent être administrativement remplacés par culture — la formulation ci-dessus est l'état de livraison.

Celui qui enregistre des formulations propres devrait le documenter : la documentation donne les textes standards.

## Les questions ne parviennent pas au client

Le système connaît en plus des vérifications bloquantes aussi des **questions** — messages que le contact dans le client commercial doit confirmer pour continuer.

Dans la boutique, il n'y a personne pour répondre à une telle question. La boutique **les ignore donc systématiquement**. C'est une décision consciente, pas une erreur.

La conséquence pratique : plusieurs champs mandants sont correctement calculés, mais leur message n'atteint jamais le client.

<table id="bkmrk-feld-verhalten-im-sh"> <thead> <tr> <th>Champ</th> <th>Comportement dans la boutique</th> </tr> </thead> <tbody> <tr> <td>Valeur de position maximale</td> <td>est calculée, la question est ignorée — le client ne voit rien</td> </tr> <tr> <td>Alerte à partir d'une quantité</td> <td>idem</td> </tr> <tr> <td>valeur minimale de commande (alerte)</td> <td>en plus : la valeur n'est jamais remplie et reste toujours à 0</td> </tr> </tbody> </table>

> **Remarque :** *Valeur de position maximale* et *Alerte à partir d'une quantité* n'ont donc pas d'effet dans la boutique — mais elles ne sont **pas inutiles**. Elles s'appliquent dans le client commercial, et dans l'ancienne boutique le message était même affiché au client. Il est seulement désactivé dans la nouvelle boutique.

## Ce qui limite la date de livraison

<table id="bkmrk-steuerung-ort-wirkun"> <thead> <tr> <th>Contrôle</th> <th>Emplacement</th> <th>Effet</th> </tr> </thead> <tbody> <tr> <td>Délai de livraison minimal en jours</td> <td>*Grundkonfiguration \\ Mandanten*</td> <td>Définit la date de livraison la plus proche possible.</td> </tr> <tr> <td>Sortie de livraison le jour de la commande</td> <td>*eCom \\ Einstellungen*, heure</td> <td>Définit jusqu'à quelle heure une commande doit être reçue pour être traitée le même jour.</td> </tr> <tr> <td>Liefertermineingabe</td> <td>*eCom \\ Einstellungen*</td> <td>Contrôle si le client doit saisir une date.</td> </tr> <tr> <td>FeiertagsID</td> <td>*Grundkonfiguration \\ Mandanten*</td> <td>Détermine le calendrier des jours fériés.</td> </tr> </tbody> </table>

### Comment la date la plus proche est calculée

Le point de départ est la date de commande plus le **Délai de livraison minimal en jours**. Les règles sont :

- **Les samedis et dimanches sont sautés.**
- Pour chaque **jour férié** rencontré, un jour supplémentaire est ajouté. Ces jours sont déterminés par le calendrier enregistré via la **FeiertagsID**.
- L'heure du paramètre *Sortie de livraison le jour de la commande* est prise en compte : si le client commande **avant**, la commande part le même jour et la date est avancée d'un jour. **Après**, elle est repoussée d'un jour.
 

La FeiertagsID a donc un effet réel dans la boutique — pas seulement dans le système ERP.

> **Important :** Le calendrier dans la boutique **ne bloque rien**. Week-ends, jours fériés et dates trop proches peuvent être sélectionnés et saisis. Ce n'est qu'à l'envoi que le serveur les refuse, avec le message *« La date de livraison ne peut pas être respectée. »* Une règle propre de préparation ou de transport pour un pays peut modifier le calcul.

## Affichage des prix après une demande de prix en direct

Si le client a déclenché une demande de prix en direct dans le panier, cela a aussi un effet ici.

La somme porte alors la mention **(Live Preis)** — voir ci-dessus.

Le **texte d'information sur les prix nets** issu du paramètre *KIP anzeigen* n'apparaît pas sur cette page.

> **À clarifier :** S'il s'agit d'un effet de la demande de prix en direct ou si la finalisation de commande ne montre jamais cette indication. Dans le panier, elle restait visible après la demande, ici elle manque.

Si le client modifie ensuite le panier, les prix en direct expirent. Voir [Panier](https://fr.wiki.dedesales.de/books/description-des-prestations-ecom/page/panier).

## Ce qui contrôle la valeur de commande

Il y a **quatre** champs avec une valeur minimale. Pour la boutique, un seul compte.

<table id="bkmrk-feld-ort-wirkung-im-"> <thead> <tr> <th>Champ</th> <th>Emplacement</th> <th>Effet dans la boutique</th> </tr> </thead> <tbody> <tr> <td>**Valeur de commande minimale, onglet eCom**</td> <td>*Grundkonfiguration \\ Mandanten*, onglet **eCom**</td> <td>**C'est la valeur qui s'applique.**</td> </tr> <tr> <td>Valeur de commande minimale</td> <td>*Grundkonfiguration \\ Mandanten*, général</td> <td>**aucun** — n'est pas lu dans la finalisation de commande, utilisé seulement pour l'export</td> </tr> <tr> <td>Valeur minimale de commande du débiteur</td> <td>chez le débiteur</td> <td>seulement dans un cas particulier, voir ci-dessous</td> </tr> <tr> <td>valeur minimale de commande (alerte)</td> <td>*Grundkonfiguration \\ Mandanten*</td> <td>**aucun** — la valeur n'est remplie nulle part et resterait de toute façon invisible comme question</td> </tr> </tbody> </table>

> **Important :** La *valeur de commande minimale* générale du mandant semble être l'endroit évident, mais n'a pas d'effet dans la boutique. Celui qui veut fixer une limite pour la boutique doit la saisir dans l'**onglet eCom**. C'est la confusion la plus fréquente à cet endroit.

### Quand la valeur du débiteur s'applique

La valeur chez le débiteur s'applique seulement si **deux** paramètres mandants sont réunis :

- *Utiliser la valeur minimale de commande au lieu de la limite franco de port* est actif, **et**
- le paramètre de question *valeur minimale de commande* est réglé sur **Blocage commande**, pas sur *Afficher alerte*.
 

Ce n'est que dans ce cas qu'une valeur supérieure à 0 enregistrée chez le débiteur s'applique. Dans tous les autres cas — ce qui est la norme — c'est la valeur de l'onglet eCom qui s'applique.

> **À clarifier :** Dans les paramètres eCom, il y a une case *Appliquer la valeur minimale de commande du débiteur*. Les conditions réellement vérifiées par la boutique sont celles mentionnées ci-dessus — cette case n'en fait pas partie. Il est ouvert de savoir si elle agit ailleurs ou si c'est la même option sous un autre nom.

### Comment le calcul est fait

<table id="bkmrk-frage-antwort-netto-"> <thead> <tr> <th>Question</th> <th>Réponse</th> </tr> </thead> <tbody> <tr> <td>net ou brut ?</td> <td>**net** — même somme quantité fois prix que dans le panier</td> </tr> <tr> <td>les frais d'expédition comptent-ils ?</td> <td>**non** — la vérification a lieu avant que les frais d'expédition ne soient calculés</td> </tr> </tbody> </table>

## Frais d'expédition

<table id="bkmrk-steuerung-ort-ecom-k"> <thead> <tr> <th>Contrôle</th> <th>Emplacement</th> <th>Indicateur eCom</th> </tr> </thead> <tbody> <tr> <td>Limite franco de port</td> <td>*Grundkonfiguration \\ Mandanten*, liste de valeurs</td> <td>**oui**</td> </tr> <tr> <td>Frais d'expédition</td> <td>*Grundkonfiguration \\ Mandanten*, liste de valeurs</td> <td>**oui**</td> </tr> <tr> <td>Article frais d'expédition</td> <td>*eCom \\ Einstellungen*</td> <td>—</td> </tr> </tbody> </table>

- En dessous de la limite franco de port, les frais d'expédition sont calculés, au-dessus non.
- Dans le panier, les frais d'expédition sont une **valeur d'affichage** — la ligne *frais d'expédition en sus* est sous la somme et n'est pas incluse.
- C'est seulement à l'envoi qu'ils deviennent une **vraie position de commande** avec l'article frais d'expédition enregistré, quantité 1 et le montant comme prix.
 

> **Attention :** Si l'*article frais d'expédition* est **vide**, le calcul **s'arrête silencieusement**. Aucun message d'erreur n'apparaît, et la commande est créée normalement — juste sans frais d'expédition. Celui qui veut calculer les frais doit donc saisir l'article ; une absence de saisie passe inaperçue.

> **Attention :** Pour la limite franco de port et les frais d'expédition, l'indicateur eCom est un commutateur, pas un ajout. Une ligne s'applique soit à la boutique, soit au client. Si la ligne eCom manque, la boutique n'a pas de valeur. Voir le livre *Backend eCom*.

## Génération automatique de votre numéro de commande

Si le paramètre *Kundenauftragsnummer generieren* est actif et que le champ est **vide** à l'envoi, le système génère lui-même un numéro.

<table id="bkmrk-eigenschaft-verhalte-1"> <thead> <tr> <th>Propriété</th> <th>Comportement</th> </tr> </thead> <tbody> <tr> <td>Schéma</td> <td>**ID de commande, barre oblique, date** — par exemple <code>12345&#47;21&#46;09&#46;2026</code></td> </tr> <tr> <td>Quand</td> <td>indépendamment du droit — même avec *Non* et *Optionnel*</td> </tr> <tr> <td>Saisie propre</td> <td>reste inchangée ; la génération ne se fait que dans un champ vide</td> </tr> <tr> <td>Visibilité</td> <td>**seulement après l'envoi**, par exemple sur la confirmation — pas prérempli dans le formulaire</td> </tr> </tbody> </table>

Cela explique aussi pourquoi l'obligation sur *Votre numéro de commande* avec ce paramètre n'est jamais remarquée : le champ est déjà rempli au moment de la vérification.

## Structure et déroulement

La finalisation de commande est **une seule page**, pas un processus en plusieurs étapes.

<table id="bkmrk-name-funktion-sichtb"> <thead> <tr> <th>Nom</th> <th>Fonction</th> <th>Visibilité</th> </tr> </thead> <tbody> <tr> <td>Commander de manière contraignante</td> <td>Envoie la commande et crée la commande.</td> <td>toujours</td> </tr> </tbody> </table>

> **Attention :** Il n'y a **pas de bouton retour**. Tant que *Commander de manière contraignante* n'est pas cliqué, le client ne peut revenir au panier que via la fonction retour du navigateur.

## Confirmation

Après l'envoi, la boutique passe à une **page propre**. Au centre se trouve une boîte avec un texte de remerciement, le **numéro de commande** et le bouton **Continuer vos achats**. Les champs de saisie et le résumé du panier ne sont plus visibles.

## Si le client ne peut pas du tout commander

Ce qui compte est le **blocage commande** chez le client. C'est le seul blocage que la boutique vérifie — un *blocage livraison* n'est pas pris en compte.

Le blocage vient du système ERP et ne peut pas être réglé dans le backend eCom.

<table id="bkmrk-eigenschaft-verhalte-2"> <thead> <tr> <th>Propriété</th> <th>Comportement</th> </tr> </thead> <tbody> <tr> <td>Vérifié</td> <td>exclusivement le **blocage commande**</td> </tr> <tr> <td>Quand</td> <td>**uniquement à l'envoi** — pas à la connexion ni à l'ajout au panier</td> </tr> <tr> <td>Conséquence</td> <td>Aucune **commande créée**.</td> </tr> </tbody> </table>

Un client bloqué peut donc faire ses achats jusqu'au bout et ne découvrir le blocage qu'à la fin. En outre, la boutique vérifie le blocage commande lors de la **demande de prix en direct** dans le panier — c'est un endroit différent de la finalisation de commande.

### Observations faites

Pour un client avec blocage commande :

<table id="bkmrk-beobachtung-ergebnis"> <thead> <tr> <th>Observation</th> <th>Résultat</th> </tr> </thead> <tbody> <tr> <td>Envoyer la commande</td> <td>**possible** — pas de message, pas de blocage</td> </tr> <tr> <td>Page de confirmation</td> <td>apparue, avec un **numéro de commande**</td> </tr> <tr> <td>Commande dans le système</td> <td>introuvable pour ce numéro **non trouvé**</td> </tr> <tr> <td>Prix dans la boutique</td> <td>**aucun** — mais cela n'a **rien à voir avec le blocage**, voir ci-dessous</td> </tr> </tbody> </table>

Le blocage ne bloque donc **pas** la commande. Il se manifeste autrement que prévu, et le client reçoit une confirmation qui ne correspond apparemment à aucune commande.

Les prix manquants ne sont **pas une conséquence du blocage** : l'affichage normal des prix dans le catalogue et le panier n'est pas du tout affecté par le blocage commande. Pour ce client test, c'était donc dû aux **conditions**, pas au système eCom.

> **Pas encore définitivement établi :** Le panier observé contenait des positions sans prix. Il est ouvert de savoir si cela influence aussi la finalisation de commande.

> **Attention :** Jusqu'à ce que ce soit clarifié, personne ne devrait compter sur un blocage commande qui bloque proprement la boutique.

## Blocage commande sur la commande finalisée

À distinguer du blocage sur la **commande finalisée**. Il ne bloque pas la commande, mais concerne seulement le **traitement ultérieur** : la commande est transmise au système ERP, mais doit y être traitée ou débloquée manuellement.

La condition qui déclenche un blocage est contrôlée par les règles de blocage du rôle. Pour la boutique, sont notamment pertinents *Marquer toutes les commandes avec blocage commande* et *Valeur minimale de commande non atteinte*.

La liste complète se trouve sur la page *eCom-Rechte im Überblick*.

## Après l'envoi

<table id="bkmrk-vorgang-erl%C3%A4uterung-"> <thead> <tr> <th>Processus</th> <th>Explication</th> </tr> </thead> <tbody> <tr> <td>Commande</td> <td>La commande est créée comme une commande DeDeSales régulière.</td> </tr> <tr> <td>Confirmation au client</td> <td>E-mail via le modèle *Bestellung*, envoyé via l'abonnement *eCom - Aufträge anlegen*. Le destinataire est la **adresse e-mail de l'accès boutique**, pas celle de la fiche client. Le texte ne contient dans l'état de livraison **ni positions ni montants** — seulement un remerciement. Le texte peut être modifié sous *Grundkonfiguration \\ Einstellungen \\ E-Mail Inhalte* ; pour une **liste des positions**, un modèle propre est nécessaire, que le chef de projet dépose chez DeDeNet.</td> </tr> <tr> <td>Notification interne</td> <td>Via le même abonnement, avec **liste des positions** dans le texte du mail. Via le paramètre *Envoyer le mail de commande aussi en copie aux contacts siège*, il est aussi envoyé en copie aux collaborateurs assignés au client.</td> </tr> <tr> <td>Fichier Excel avec les positions</td> <td>Seulement si l'abonnement *Envoi des commandes incl. Excel* est aussi activé. Sans cet abonnement, le mail arrive sans pièce jointe.</td> </tr> <tr> <td>Cas d'erreur</td> <td>Si la commande ne peut pas être traitée sur le serveur, l'abonnement obligatoire *eCom - Benachrichtigung bei fehlgeschlagenem ERP Export* informe le service sédentaire.</td> </tr> </tbody></table>