Benutzer-Werkzeuge

Webseiten-Werkzeuge


features:order-management

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
features:order-management [11.09.2013 ]
172.16.1.171 [Verkaufsaktionen (Campaigns)]
features:order-management [20.11.2014 ]
dstore [Verkaufsaktionen (Campaigns)]
Zeile 1: Zeile 1:
 +====== Auftragsverwaltung ======
  
 +Die Auftragsverwaltung des dStore umfasst alle wichtigen Prozesse die direkt (wie Warenkörbe und Auftragsanlage) oder indirekt (wie Preis-Ermittlung,​ Prüfung auf Lieferbarkeit,​ Bestimmung von Versandkosten etc.) mit Aufträgen zu tun haben.
 +
 +Zur Auftragsverwaltung zählen auch Prozesse rund um Guthaben und Gutscheincodes,​ sowie die Verkaufskampagnen (kurz: Campaigns).
 +
 +Das admin_SmartGate stellt bereits Standardmasken für die Eingabe von Aufträgen bereit (z.B. für Sachbearbeiter im Call-Center). ​
 +===== Verkaufsaktionen ("​Campaigns"​) =====
 +
 +Die sogenannten Campaigns bieten eine einfache Möglichkeit komplexe Verkaufsaktionen über eine grafische Oberfläche innerhalb des admin_SmartGates zu erstellen. ​
 +
 +Verkaufsaktionen haben immer einen oder mehrere Zeiträume (frei definierbare wie auch wiederkehrende) zu denen diese aktiv sind. Weiter haben Verkaufsaktionen Bedingungen die eintreffen müssen damit Kunden von der Aktion in Form von "​Benefits"​ profitieren.
 +
 +Als kombinierbare Bedingungen stehen zur Verfügung:
 +
 +  * Minimale Anzahl Artikel
 +  * Artikel-Merkmale (z.B. Marke, Preis, Bestand etc.)
 +  * Artikel-Kategorien
 +  * Gültiger Gutschein-Code ("​Voucher-Code"​) einer Gutschein-Aktion
 +  * Einzelpreis und/oder gesamter Warenkorb-Wert
 +  * Zahlungs- und Versandarten (sowohl bestimmte als auch bestimmte NICHT)
 +  * Zu- bzw. Nichtzugehörigkeit zu Kundengruppen
 +
 +Als kombinierbare Benefits stehen zur Verfügung:
 +
 +  * Prozentuale und absolute Rabatte, dabei kann bestimmt werden ob der Rabatt auf den gesamten Auftrag, nur die "​Aktions-Artikel"​ oder auf andere Artikel mit festlegbaren Artikelbedingungen gewährt werden soll.
 +    * Beispiel: Beim Kauf einer Hose der Marke x wird ein ebenfalls gekauftes T-Shirt der Marken x,y und z mit x % rabattiert
 +  * Versand- und/oder Zahlungskostenbefreiung. ​
 +    * Beispiel: Bekleidungsprodukte sind jeden Montag ab einem Warenkorbwert von 50 EUR nach Eingabe eines Codes für Lieferungen innerhalb Deutschlands versandkostenfrei
 +  * Bonus-Artikel : Es können Sets von Produkten definiert werden, aus denen der Kunde sich ein oder mehrere Artikel aussuchen darf, die er kostenlos erhält
 +  * Bundle-Preise : Der Kunde erhält eine bestimmte Kombination von Produkten zu einem vergünstigten Preis (Festpreis oder Rabatt). Beispiele : 4 Bücher des Autors X zum Preis Y oder Beim Kauf von 3 Artikeln der Marke X gibt es den günstigsten umsonst (oder zum halben Preis).
 +
 +Die Verkaufsaktionen sind dynamisch und nicht Batch-gesteuert,​ d.h. die Bedingungen werden immer zur Laufzeit geprüft. Das bedeutet insbesondere,​ dass während der Gültigkeitszeiträume von Aktionen Artikel, auf die die Aktionsbedingungen zutreffen, hinzukommen oder verschwinden können und damit auch ihre eventuell als "​Benefit"​ vergebenen Rabatte. Im Gegensatz zu Batch-gesteuerten Aktionen gibt es somit keine Verzögerungen bzw. sind keine weiteren manuellen Eingriffe notwendig.
 +===== Gutschein-Codes =====
 +
 +Im dStore existieren zwei Arten von Gutscheinen,​ Prepaid-Codes und Voucher-Codes. Prepaid-Codes dienen dazu, gekauftes "​Guthaben"​ abzubilden. Voucher-Codes hingegen sind Gutscheine, die im Rahmen einer Verkaufskampagne als Bedingung verwendet werden können.
 +
 +Typische Anwendungsbeispiele für Voucher-Codes sind:
 +
 +  * Aktionen (Newsletter,​ Print-Kampagnen),​ bei denen ein fester Code für eine bestimmte Anzahl Einlösungen während eines bestimmten Zeitraums einen Rabatt erzeugt.
 +  * Codelisten zum Druck auf Werbeträger,​ wobei jeder Code nur einmalig einlösbar ist. 
 +
 +Die Prepaid-Codes bilden den klassischen Prozess eines Kaufgutscheins ab: Kunde A kauft einen Geschenkgutschein. Kunde B löst diesen ein und erhält den Betrag auf seinem Guthabenkonto gutgeschrieben. Wenn Kunde B nun einen Kauf tätigt, kann er den Rechnungsbetrag mit seinem Guthaben verrechnen lassen. ​
 +
 +===== Guthabenkonten =====
 +
 +Für Kunden kann ein Guthaben-Konto geführt werden, um z.B. aus Prepaid-Codes oder stornierten bzw. retournierten Artikeln entstandenes Guthaben mit späteren Aufträgen verrechnen zu können. Dabei kann für jedes Konto die Währung festgelegt werden, in der das Konto geführt werden soll und das Konto kann per Status inaktiv gestellt oder gesperrt werden.
 +
 +Das Guthaben kann auch durch manuelle Zu- bzw. Abbuchungen durch autorisierte Sachbearbeiter verändert werden. Sämtliche Transaktionen werden protokolliert und sind nachvollziehbar.
 +
 +===== Warenkorb =====
 +
 +Bis zum Anlegen des eigentlichen Auftrags werden die ausgewählten Produkte in einem Warenkorb gesammelt – unabhängig davon, ob dies der Kunde selbst (Onlineshop) oder ein Sachbearbeiter (Auftragsmaske im admin_SmartGate) tut. Der Inhalt des Warenkorbs und die Personendaten des Kunden wirken sich wiederum auf eine Reihe von Faktoren aus, z. B. Zahlungs- und Versandart, Verkaufs-Aktionen und Rabatte. ​
 +
 +Aus einem Warenkorb kann nun ein Auftrag oder ein Angebot generiert werden. Angebote werden wie Aufträge in einem „frühen Status“ (siehe „Auftragsstatus“) verwaltet.
 +===== Zahlungs- und Versandarten =====
 +
 +Die dStore SmartEngine erlaubt es, für jede Personen- und Artikelgruppe die jeweils möglichen Zahlungs- und Versandarten sowie die entsprechenden Kosten festzulegen. So kann beispielsweise die Zahlung per Lastschrift auf bestimmte Regionen begrenzt oder der Artikelversand in bestimmte Länder verhindert werden. Auch eine versandkostenfreie Lieferung bei Überschreiten eines Mindestbestellbetrags lässt sich auf diese Weise realisieren.
 +
 +Die Höhe der Zahlungs- und Versandkosten können im Voraus für Zeiträume festgelegt werden. Es ist im Rahmen der Verkaufskampagnen möglich die Zahlungs- und/oder Versandkostenfreiheit als "​Benefit"​ wegfallen zu lassen.
 +
 +Zu jeder Zahlungs- und Versandart können zudem eine Kurzbezeichnung und eine Beschreibung (ggf. in verschiedenen Sprachen) hinterlegt werden. Schließlich kann für jede Zahlungs- und Versandart festgelegt werden, welche Daten unbedingt vom Kunden erfragt werden müssen (der Bankeinzug erfordert beispielsweise das Vorliegen von Bankleitzahl und Kontonummer).
 +
 +Bei der Ermittlung der je nach Person und Warenkorb möglichen Zahlungs- und Versandarten werden folgende Parameter berücksichtigt:​
 +
 +  * Artikelgruppen:​ Enthält der Warenkorb Artikel aus einer Artikelgruppe,​ für die bestimmte Zahlungs- und Versandarten vorgegeben sind?
 +  * Region: Gehört das Land, aus dem der Kunde stammt bzw. in das geliefert werden soll, zu einer Region (z. B. Europa, Benelux), für die bestimmte ​  ​Zahlungs- und Versandarten vorgegeben sind?
 +  * Warenwert: Liegt der Wert der Waren (unter Berücksichtigung der Rabatte) im Warenkorb innerhalb eines Bereichs, für den bestimmte Zahlungs- und Versandarten hinterlegt sind?
 +
 +Die Durchführung des Inkassos erfolgt abhängig von der Zahlungsart entweder über das angebundene Warenwirtschaftssystem oder über einen angebundenen Payment-Dienstleister. Ebenfalls unterstützt hier das action_SmartGate mit voreingestellten Schnittstellen.
 +
 +Die Versandverfolgung erfolgt über entsprechende Auftragsstatuswechsel und anhand der Tracking-Informationen.
 +===== Auftrag =====
 +
 +Ein Auftrag wird generiert aus der Person und ihrem Warenkorb sowie aus Versandart, Zahlungsart und Lieferanschrift. Neben der eindeutigen,​ vom System erzeugten Auftragsnummer besteht die Möglichkeit,​ einem Auftrag mehrere Fremd-Auftragsnummern zuzuordnen (bis auf Positionsebene). Dies ist etwa dann erforderlich,​ wenn ein Auftrag auf mehrere Logistiker verteilt wird.
 +
 +Jedem Auftrag ist eine Währung zugewiesen. Die Statistiken werden in der Standardwährung (in Netto) geführt.
 +
 +Es kann ein Liefertermin für den Auftrag festgelegt werden.
 +
 +===== Auftragsinformationen =====
 +
 +Jedem Auftrag und jeder Position eines Auftrags können beliebige Informationen beigefügt werden. Dabei kann es sich um zusätzliche Hinweise für den Kunden handeln, oft bilden diese Informationen aber auch die Grundlage für verschiedene Berichte. Häufige Informationstypen sind:
 +
 +  * Media-Code: Aus welchem Katalog stammt die Auftragsposition?​
 +  * Werbeaktion:​ Aufgrund welcher Werbeaktion (z. B. Anzeigenkampagne in überregionaler Zeitung) kam der Auftrag zustande?
 +  * Lieferscheinnummer:​ Auf welchem (Fremd-)Lieferschein taucht die Auftragsposition auf?
 +  * Seriennummer:​ Für RMA-Zwecke (Return Merchandise Authorization) und bei Retouren kann geprüft werden, ob die gleiche Ware zurückgesendet wurde.
 +  * Paket-Trackingnummer:​ In welchen Paketen wurden die einzelnen Auftragspositionen versendet?
 +  * Vertreter-Kennzeichen:​ Für die Provisionierung der Vertreter kann ein Auftrag entsprechend gekennzeichnet und somit beim Reporting berücksichtigt werden.
 +  * Promo-Code: Wird im Onlineshop verwendet, um die Vermittlung eines Kunden durch eine „Verlinkung“ zu kennzeichnen (z. B. Banner, Affiliate-Plattformen).
 +  * Freie Texte: Vom Sachbearbeiter eingegebene Texte auf Auftrags- oder Positionsebene.
 +
 +===== Auftragsstatus =====
 +
 +Der Auftragsstatus ist das zentrale Merkmal, anhand dessen die Abarbeitung eines Auftrags verfolgt und kontrolliert werden kann. Im dStore hat nicht der Auftrag einen Status, sondern jede Auftragsposition. Diese Status können individuell eingerichtet werden, die Regeln für ihren Wechsel sind benutzerbezogen konfigurierbar. So darf z. B. nur die Retourenabteilung einen Statuswechsel von „ausgeliefert“ auf „Retoure akzeptiert“ vornehmen.
 +
 +Typische Anwendungsfälle für Auftragsstatus auf Positionsebene sind:
 +
 +  * Angenommen
 +  * Wird gepackt
 +  * Ausgeliefert
 +  * Storniert
 +
 +Bei jedem Statuswechsel können Überprüfungen bzw. Aktionen in Abhängigkeit vom erreichten Status konfiguriert werden. Dadurch kann die Weiterverarbeitung des Auftrags transaktionssicher und in Echtzeit erfolgen. Typische Überprüfungen oder Aktionen sind Kriterienprüfungen wie z. B. Kundenkreditlimit,​ Kundensperrung,​ evtl. Auftragssplitting in Abhängigkeit vom erwarteten Wareneingang,​ Queuing von Aufträgen und Bevorzugung von Eilaufträgen.
 +
 +Über die Statuswechsel der Auftragspositionen wird eine Historie geführt. Daher ist für jede Position sekundengenau nachvollziehbar,​ wer den Statuswechsel durchgeführt hat. Sowohl manuelle Statuswechsel (Sachbearbeiter,​ Kunde) als auch automatische Statuswechsel (Schnittstellen) werden aufgezeichnet.
 +
 +Für den Kunden kann pro Status eine „öffentliche Beschreibung“ festgelegt werden. Diese wird beispielsweise immer dann verwendet, wenn der Kunde im Onlineshop im „Mein Konto“-Bereich seine Aufträge verfolgt. Dort liest er dann z. B. statt „Kreditlimit erreicht“ die Meldung „Auftrag in Bearbeitung“.
 +
 +===== Auftragsclearing =====
 +
 +Es kommt immer wieder vor, dass Unklarheiten bei der Auftragsabwicklung auftreten oder ein Sachbearbeiter Einblick in einen Auftrag nehmen soll. Klassische Fälle dafür sind:
 +
 +  * Onlineshop-Aufträge über einem bestimmten Betrag
 +  * Bestandsdifferenzen,​ die zum Anhalten des Auftrags führen
 +  * Fehlgeschlagene Zahlungen
 +
 +Im admin_SmartGate können solche Aufträge gefiltert und entsprechend bearbeitet werden. Dieses Auftragsclearing kann auf verschiedene Sachbearbeiter verteilt werden (z. B. Mitarbeiter in Finanzbuchhaltung oder Logistik). Die Bearbeitung besteht meist im Korrigieren falscher Daten und im Weitersetzen des Auftragsstatus. Auch diese Statuswechsel werden, wie im vorigen Abschnitt, beschrieben vom System protokolliert.
 +
 +===== Retouren =====
 +
 +Die Bearbeitung von Retouren ist eine spezielle Form des Auftragsclearing. Dabei werden zurückgesendete Auftragspositionen in einen speziellen Status gesetzt. Anhand dieser und nachfolgender Statuswechsel können auch der Bestand automatisch korrigiert und die Bestellumsatz-Statistiken angepasst werden.
 +
 +Sofern vom gewünscht, kann der Fortschritt der Retourenbearbeitung vom Kunden verfolgt werden. Eine typische, sichtbare Abfolge ist: „Retoure angenommen“,​ „Retoure in Bearbeitung“,​ „Gutschrift“.
 +
 +
 +===== Schnittstellen =====
 +
 +Das [[:​xml|xml_SmartGate]] stellt eine Schnittstelle zum Export von Aufträgen in Fremdsysteme (z. B. Lagerverwaltungssysteme) und zum Einlesen entsprechender Rückmeldungen bereit.
 +
 +Der Export umfasst die gesamten Daten eines Auftrags. Dies sind u. a. Rechungs- und Lieferadresse,​ Versand- und Zahlungsart,​ Auftragskopf und -positionen. Mehrere Aufträge können in einem Dokument zusammengefasst werden.
 +
 +Typische Rückmeldungen von Fremdsystemen betreffen den Auftragsstatus („wird gepackt“, „wurde ausgeliefert“),​ die Auftragsinformationen (z. B. Paketnummern) oder beinhalten die Auftrags- bzw. Kundennummern im Fremdsystem.
features/order-management.txt · Zuletzt geändert: 20.11.2014 von dstore