Ältere Plattform

Lösung

Online bearbeiten

In diesem Abschnitt werden APIs, Benutzerexits, Services und weitere Komponenten beschrieben, die an der Implementierung der Funktion beteiligt sind.

Beim Laden der Anwendung wird die Regel Auf Web-Geschäfts-UI anzuwendendes Motiv eingelesen, wodurch das vom Administrator für das Unternehmen festgelegte Motiv abgerufen und die Benutzerschnittstelle entsprechend angezeigt wird. Informationen zum Auswählen eines Motivs für Ihr Unternehmen finden Sie unter Anzeigeoptionen konfigurieren. Sie können jedoch keine neuen Motive für die Anwendung Sterling Store Engagement über die Benutzerschnittstelle Sterling Business Center erstellen.

Um die Motive zu erstellen, die Sie in Sterling Business Centerauswählen können, verwenden Sie daher die manageCommonCode -API mit dem Codetyp WEB_STORE_THEME. Nachdem der Administrator ein Motiv aus den verfügbaren Optionen ausgewählt hat, wird das Motiv für die Regel WSC_STORE_THEMEals persistent definiert. Wenn die Anwendung Sterling Store Engagement geladen wird, wird die getRuleDetails -API mit dem Regelnamen WSC_STORE_THEME aufgerufen, um das Motiv für das Unternehmen einzurichten.

Wenn ein Kunde in einem Geschäft erscheint, um zuvor erworbene Produkte zurückzugeben, kann das Verkaufspersonal nach einer der folgenden Methoden über das Portlet Produkte retournieren einen Retourenauftrag erstellen:

Wenn ein Kunde mit Produkten in einem Geschäft erscheint, die zurückzugeben werden sollen, kann das Verkaufspersonal über das Portlet "Produkte retournieren" einen Retourenauftrag eröffnen. Das Verkaufspersonal kann nach einer der folgenden Methoden nach den Produkten suchen, die zum Retourenauftrag hinzugefügt werden sollen:
  • Nach Vertriebsauftrag suchen:

    Wenn der Kunde einen Beleg hat, kann das Verkaufspersonal anhand der Auftragsnummer suchen oder einen Barcode auf dem Beleg scannen.

    • Wenn das Verkaufspersonal den Barcode des Wareneingangs scannt, wird die API translatebar code aufgerufen, um die Auftragsnummer abzurufen. Die API getOrderList wird mit der Auftragsnummer aufgerufen, um so die Details zum Auftrag abzurufen.
      • Wenn die API translatebar code keine Übersetzung zurückgibt, wird die API getOrderList mit der ursprünglichen Eingabe für die API translatebar code aufgerufen, oder das Verkaufspersonal kann zur Hauptanzeige zurückkehren und die Auftragsnummer manuell eingeben.
      • Wenn mehrere Übersetzungen von der translatebar code API zurückgegeben werden, wird eine entsprechende Fehlernachricht angezeigt.
      • Wenn von der API getOrderList keine Aufträge zurückgemeldet werden, wird eine entsprechende Fehlernachricht angezeigt.
      • Wenn von der API getOrderList mehrere Aufträge zurückgemeldet werden, werden diese aufgelistet, sodass das Verkaufspersonal den Auftrag auswählen kann, zu dem das Retourenprodukt gehört.
      • Wenn von der API getOrderList ein einzelner Auftrag zurückgemeldet wird, wird die Seite Produkte zu Retoure hinzufügen angezeigt.
    • Wenn das Verkaufspersonal die Auftragsnummer manuell eingibt, wird die API getOrderList aufgerufen, um die Details zum Auftrag abzurufen.
      • Wenn von der API getOrderList ein einzelner Auftrag zurückgemeldet wird, wird die Seite Produkte zu Retoure hinzufügen angezeigt.
      • Wenn von der API getOrderList mehrere Aufträge zurückgemeldet werden, werden diese aufgelistet, sodass das Verkaufspersonal den Auftrag auswählen kann, zu dem das Retourenprodukt gehört.
      • Wenn von der API getOrderList keine Aufträge zurückgemeldet werden, wird eine entsprechende Fehlernachricht angezeigt.
    Erweiterte Auftragssuche:

    Das Verkaufspersonal kann eine erweiterte Suche nach Aufträgen ausführen und dabei zusätzliche Suchkriterien wie Vorname, Nachname, E-Mail, Telefonnummer, Postleitzahl oder Zahlungsart verwenden. Wenn das Verkaufspersonal beispielsweise die Zahlungsmethode als eines der Kriterien auswählt,getPaymentTypeListAPI wird aufgerufen, um alle Zahlungsarten über dieCallingEnterpriseCodeAttribut für das Geschäft. Die vom Verkaufspersonal ausgewählte Zahlungsart wird zusammen mit anderen Suchkriterien als Eingabe an diegetOrderListAPI zum Abrufen der übereinstimmenden Aufträge.

  • Als Ergebnis der Suche wird eine feste Anzahl Aufträge angezeigt. Wenn mehr Aufträge zum Laden vorliegen, wird eine entsprechende Nachricht angezeigt, in der das Verkaufspersonal dazu aufgefordert wird, die Suche einzugrenzen. Das Verkaufspersonal kann dann mithilfe der Filteroption das Suchergebnis eingrenzen.
  • Bei der Suche werden bestätigte Aufträge und Auftragsentwürfe aufgelistet, die von registrierten und nicht registrierten Kunden platziert wurden. Die Auftragsliste enthält Details wie Auftragsnummer, Anzahl der Produkte, Auftragskanal, Name des Geschäfts (im Falle eines Kaufs im Geschäft), Datum, Auftragsvolumen, Status, Name des Kunden usw.
  • Von der API getCompleteOrderLineList werden (zusammen mit der Anzahl der restlichen Produkte im Auftrag) für maximal zwei Produkte Bilder zurückgemeldet.
  • Nach Kunden suchen:

    Wenn der Kunde keinen Beleg hat, kann das Verkaufspersonal nach einem Kunden mit einer Telefonnummer im Suchfeld suchen, nachdem Kunde als Eingangspunkt im Portlet Produkte zurückgeben ausgewählt wurde. Für die Suche nach einem Kunden kann das Verkaufspersonal das Symbol Auftrag antippen und dann Kunde auswählen. Wenn Kunde als Einstiegspunkt ausgewählt wird, wird die Option zum Scannen ausgeblendet. Das Verkaufspersonal kann die Telefonnummer des Kunden eingeben und auf Suchen klicken.

    • Wenn das Verkaufspersonal auf "Suchen" klickt, wird die API getCompleteCustomerList aufgerufen, um Kunden mit Daten abzurufen, die den Suchkriterien entsprechen.
      • Wenn mehrere Kunden zurückgemeldet werden, wird eine Liste angezeigt, aus der das Verkaufspersonal dann auswählen kann. Für jeden in dieser Liste enthaltenen Kunden werden Adresse, Telefonnummer und E-Mail-Adresse angezeigt, sodass das Verkaufspersonal in der Lage ist, den richtigen Kunden auszuwählen.

        Das Verkaufspersonal wählt den richtigen Kunden aus und aktiviert dann "Aufträge anzeigen". Die API getOrdersList wird aufgerufen, um alle Vertriebsaufträge im Zusammenhang mit dem Konto des betreffenden Kunden abzurufen.

      • Wenn nur ein einzelner Kunde zurückgemeldet wird, wird die Seite Kundendetails mit allen Aufträgen im Zusammenhang mit dem Konto dieses Kunden angezeigt.
      • Wenn kein Kunde zurückgemeldet wird, wird die Nachricht Kein Kunde gefunden angezeigt. Das Verkaufspersonal kann dann eine andere Telefonnummer eingeben oder die Suche über "Produkt" oder "Auftrag" fortsetzen.
    Erweiterte Kundensuche:

    Das Verkaufspersonal kann eine erweiterte Suche nach Kunden ausführen und dabei zusätzliche Suchkriterien wie Vorname, Nachname, E-Mail, Telefonnummer, Postleitzahl oder die letzten vier Ziffern der Kreditkarte verwenden.

    Wenn vom Verkaufspersonal eine Suche durchgeführt wird, wird die API getCompleteCustomerList aufgerufen, um die enstprechenden Kunden abzurufen. Wenn der gewünschte Kunde dann identifiziert ist, kann das Verkaufspersonal für diesen Kunden auf "Aufträge anzeigen" klicken. Anschließend wird die API getOrderList aufgerufen, um die zu diesem Kunden gehörenden Aufträge abzurufen. Es werden sowohl Auftragsentwürfe als auch bestätigte Aufträge angezeigt. Nachdem das Verkaufspersonal den Vertriebsauftrag identifiziert hat, für den ein Retourenauftrag erstellt werden muss, kann das Verkaufspersonal die Produkte auswählen, die der Kunde zurückgeben möchte, und einen Retourenauftrag erstellen.

  • Von der API getCompleteOrderLineList werden (zusammen mit der Anzahl der restlichen Produkte im Auftrag) für maximal zwei Produkte Bilder zurückgemeldet.
  • Filter-Option

    Das Verkaufspersonal kann Aufträge filtern, entweder direkt bei der Auftragssuche oder über die Statistik der Kundenaufträge. Das Verkaufspersonal kann die Auftragsliste mit Kriterien wie dem Auftragszeitraum, dem Status und dem Auftragskanal filtern. Wenn das Verkaufspersonal die Filteroption anklickt, wird die API getCommonCodeList aufgerufen, um die Kontrollkästchen für den Eingabetyp zu belegen. Der jeweilige Auftragsstatus wird einer vordefinierten Liste in der Datei OrderStatusList.json im Ordner <WAR>\ngstore\shared\order\ entnommen. Die Datei ist konfigurierbar, sodass Sie die Statusangaben bei Bedarf anpassen können. Das Verkaufspersonal kann Im Geschäft suchen auswählen, um nur nach Aufträgen zu suchen, die vom aktuellen Geschäft erstellt wurden.

    Wenn das Verkaufspersonal die passenden Filterkriterien auswählt und die entsprechenden Filter anwendet, werden die Filterkriterien an die API getOrderList weitergeleitet, um die Aufträge abzurufen, die den eingegebenen Kriterien entsprechen. Auftragsstatus, Auftragszeitraum, Code der Verkäuferorganisation und eine komplexe Abfrage mit dem passenden EntryType-Attribut werden zum Abrufen der Aufträge als Eingabe an die API getOrderList weitergeleitet. Für den Store-Kanal ist EntryType gleich Store, für den Call Center-Kanal ist EntryType gleich CallCenter.

  • Nach Produkten suchen:

    Wenn ein Kunde nicht über einen Beleg verfügt, nicht im Geschäft registriert ist oder im Geschäft registriert ist, der Auftrag aber trotzdem nicht gefunden werden kann, kann das Verkaufspersonal den Retourenprozess durch Suchen nach einem Produkt beginnen. Das wird als Blindretoure bezeichnet. Das Verkaufspersonal kann nur dann eine Blindretoure erstellen, wenn die Regel "Blindretoure von Produkt gestatten" aktiviert ist. Diese Regel ist standardmäßig aktiviert. Bei einer Blindretoure kann das Verkaufspersonal entweder den Barcode des Produkts scannen, das der Kunde zurückgeben möchte, oder die Produkt-ID oder Schlüsselwörter eingeben, um nach dem Produkt zu suchen.

    • Wenn das Verkaufspersonal ein Produkt scannt, wird die API getCompleteItemList aufgerufen, um den Barcode zu übersetzen und das Produkt zurückzugeben.
      • Wenn ein einzelnes Produkt von der API zurückgemeldet wird, wird die Seite Produkte zu Retoure hinzufügen angezeigt. Die API getCompleteItemList wird aufgerufen, um Produktdetails abzurufen, und das Verkaufspersonal kann das Produkt zum Retourenauftrag hinzufügen.
        Das Verkaufspersonal kann auf die Schaltfläche "Teilen" klicken, um die Produktdetails für den Kunden freizugeben. Im Popup-Fenster "Teilen" kann das Verkaufspersonal die Produktdetails standardmäßig per E-Mail teilen. Die registrierte E-Mail-Adresse des Kunden wird automatisch eingetragen. Wenn die E-Mail-Adresse nicht vorhanden ist, kann das Verkaufspersonal manuell eine E-Mail-Adresse eingeben. Wenn das Verkaufspersonal auf die Schaltfläche 'E-Mail' klickt, werden die Produktdetails an den Kunden gesendet. Ebenso kann das Verkaufspersonal Produktdetails an mehrere E-Mail-Adressen senden, indem es die E-Mail-Adressen manuell eingibt.
        Hinweis: Sie können auch mehrere Optionen für die gemeinsame Nutzung durch Anpassung hinzufügen. Ebenso können Sie den Standard-E-Mail-Service nach Bedarf anpassen.
        Wenn das Verkaufspersonal nicht über die Ressourcenberechtigung Email Product details verfügt und die Schaltfläche "Teilen" nur über die E-Mail-Option verfügt, wird die Schaltfläche "Teilen" nicht angezeigt.
      • Werden von der API getCompleteItemList mehrere Produkte zurückgemeldet, wird eine entsprechende Fehlernachricht angezeigt.
      • Werden von der API getCompleteItemList keine Produkte zurückgemeldet, wird die API searchCatalogIndex aufgerufen und die Seite Produktliste wird angezeigt.
    • Wenn das Verkaufspersonal Schlüsselwörter eingibt und dann auf Suchen klickt, wird die API searchCatalogIndex aufgerufen, um Produkte zu laden, die dem Schlüsselwort entsprechen. Außerdem wird die Anzeige Artikelliste mit allen übereinstimmenden Artikeln angezeigt. Aus dieser Liste kann der korrekte Artikel ausgewählt und zum Retourenauftrag hinzugefügt werden.

Produkte zu Retoure hinzufügen

Hinweis:

Bei der Anzeige des Bildschirms " Produkte zur Rückgabe hinzufügen" unter Windows™ Version 8.1 kann es zu Bildschirmflackern kommen.

Nachdem der zu retournierende Auftrag identifiziert ist, wird dem Verkaufspersonal die Seite Produkte zu Retoure hinzufügen angezeigt. Die API getCompleteOrderDetails wird aufgerufen, um die Auftragsdetails abzurufen, und die API getCompleteOrderLineList wird aufgerufen, um die Produktdetails abzurufen. Die folgende Logik wird ausgeführt:
  • Die Details zu jedem einzelnen Produkt werden angezeigt (u. a. die Angabe, ob das Produkt retournierbar ist oder nicht). Wenn der Auftrag keine retournierbaren Produkte enthält, kann das Verkaufspersonal auch keinen Retourenauftrag einrichten.
  • Wenn beim Abrufen von Artikeln die Regel YCD_SHOW_RESHIP_ON_RETURN_ENTRY inaktiviert ist, werden nur Produkte mit dem Attribut ReshipParentLineKey mit dem Wert null abgerufen. Um sicherzustellen, dass keine Produkte abgerufen werden, die neu versandt werden sollen, wird ReshipParentLineKeyQryType auf ISNULL gesetzt.
  • Das Verkaufspersonal kann auf das Symbol Suchen klicken, um die Suchmethode für einen Auftrag zu ändern, und kann dann nach einem Kunden, einem Auftrag oder einem Produkt suchen. Das Verkaufspersonal kann über die Suche nach anderen Vertriebsaufträgen Produkte aus mehreren Vertriebsaufträgen zu einem einzelnen Retourenauftrag hinzufügen.
  • Die Ausführungsmethode für ein Retourenprodukt wird auf CARRY festgelegt.

In der Anzeige Produkte zu Retoure hinzufügen werden die Produkte nach retournierbaren und nicht retournierbaren Produkten sortiert. Die retournierbaren Produkte werden zuerst aufgelistet, dann folgen die nicht retournierbaren Produkte. Zu jedem Produkt werden alle Details angezeigt (u. a. eine Beschreibung, ein Bild, die Anzahl der Produkte, die retournierbar sind, und die Anzahl der Produkte, die bereits retourniert wurden usw.). Produkte können aus verschiedenen Gründen nicht retournierbar sein: Der Status des Produkts lässt keine Retoure zu, das Produkt verstößt gegen eine Retourenrichtlinie oder alle Bestände des Produkts wurden bereits vollständig zurückgegeben. Retourenrichtlinien werden in Sterling Business Centerfestgelegt und können an Ihre Geschäftsanforderungen angepasst werden.

Einige Retourenrichtlinien können aus einem bestimmten Grund nicht außer Kraft gesetzt werden, und für das Produkt wird Kann nicht retourniert werden angezeigt. Einige Retourenrichtlinien können vom Verkaufspersonal dagegen mit entsprechender Berechtigung außer Kraft gesetzt werden. Für das Produkt wird Überschreibung erforderlich angezeigt. Wenn ein Produkt eingescannt wird und es liegen Verstöße gegen die Retourenrichtlinie vor, wird das Fenster Produkt außerhalb der Retourenrichtlinie geöffnet. Wenn die Möglichkeit besteht, den Verstoß gegen die Retourenrichtlinie außer Kraft zu setzen, kann vom Manager ein entsprechender Überschreibungscode eingegeben werden. Voraussetzung dafür ist, dass es für den Genehmigungsplan nur einen Genehmiger gibt und dass der Genehmigungsplan bei allen Verstößen gegen die Retourenrichtlinie gilt. Weitere Informationen finden Sie unter Retourenrichtlinienverstöße überschreiben . Wenn die Überschreibung erfolgreich ist, wird für das Produkt Zu Retoure hinzufügen angezeigt, und für dieses Produkt ist dann so lange keine weitere Überschreibung erforderlich, bis der Retourenauftrag abgebrochen wird und das Verkaufspersonal für dasselbe Produkt einen neuen Retourenauftrag erstellt.

Bei Produkten, die zurückgegeben werden können, kann das Verkaufspersonal auf Zur Rückgabe hinzufügen klicken oder den Barcode des Produkts scannen. Die API translatebar code wird aufgerufen, wenn das Verkaufspersonal ein Produkt scannt. Wenn eine gültige Übersetzung zurückgemeldet wird, wird über die API getCompleteOrderLineList für das Produkt die passende Auftragsposition abgerufen. Wenn es sich bei der passenden Auftragsposition um eine retournierbare Position handelt, wird die API createOrder aufgerufen, um einen Retourenauftragsentwurf zu erstellen. Diese API wird nur beim ersten Mal aufgerufen. Wenn ein Produkt zum zweiten Mal oder öfter hinzugefügt wird, wird die API changeOrder aufgerufen, um den Retourenauftragsentwurf zu aktualisieren. Wenn das Verkaufspersonal sich dazu entschließt, ein Produkt zu einer Retoure hinzuzufügen, wird immer jeweils eine Einheit des Produkts hinzugefügt. Sollen mehrere Einheiten ein und desselben Produkts retourniert werden, muss das Verkaufspersonal für jedes einzelne Produkt auf Zu Retoure hinzufügen klicken.

Die folgende Logik wird ausgeführt:
  • Das Attribut EntryType in der API createOrder wird auf Store eingestellt.
  • Die API getCompleteOrderDetails wird aufgerufen, um die Kundeninformationen aus dem Vertriebsauftrag abzurufen. Die Kundeninformationen werden entweder an die API createOrder oder an die API changeOrder weitergegeben, um zum Retourenauftrag hinzugefügt zu werden.
  • Die API getCompleteOrderDetails ruft das Attribut OrderLineKey des Vertriebsauftrags ab. Dieses Attribut wird anschließend entweder über die API createOrder oder die API changeOrder im Element DerivedFrom an den Retourenauftrag weitergegeben.

Das Verkaufspersonal kann sich die Produkte in einem Retourenauftrag jederzeit anschauen und muss dazu nur auf den Mini-Einkaufswagen klicken. Über den Mini-Einkaufswagen werden die im Wagen enthaltenen Produkte und deren Mengen angezeigt. Das Verkaufspersonal kann zwar die Produkte aus dem Retourenauftrag im Mini-Einkaufswagen entfernen, nicht aber individuell die Menge des betreffenden Produkts vergrößern oder verkleinern.

Produkte zu Blindretoure hinzufügen

Wenn der Kunde nicht über einen Beleg verfügt und kein registrierter Kunde ist, sucht das Verkaufspersonal nach dem Produkt. Wenn das richtige Produkt dann identifiziert ist, kann das Verkaufspersonal auf Zu Retoure hinzufügen klicken. Die folgende Logik wird ausgeführt:
  • Bei einer Blindretoure wird die API getLowestPrice aufgerufen, um den niedrigsten Stückpreis für ein Produkt abzurufen. Der niedrigste Preis basiert auf der Regel PRICING_BLIND_RETURN_DAYS, die dazu verwendet wird, das Attribut NumberOfDaysInPast für die Suche nach dem niedrigsten Preis für das Produkt zu konfigurieren. Wird kein Wert für diese Regel angegeben, lautet der Standardwert 90 Tage. Der niedrigste Preis im Zeitraum zwischen dem Datum, an dem das Verkaufspersonal den Retourenauftrag erzeugt, und der (konfigurierten) Anzahl zurückliegender Tage wird als Retourenproduktpreis angezeigt.
  • Die API createOrder wird aufgerufen, um (falls nicht bereits geschehen) den Retourenauftrag zu erstellen. Die API changeOrder wird aufgerufen, um Produkte zu einem bereits erstellten Retourenauftrag hinzuzufügen.
Für Blindretouren werden nur manuelle Produktpakete unterstützt. Wenn konfigurierbare Produktpakete hinzugefügt werden, wird eine Fehlernachricht ausgegeben.

Das Verkaufspersonal kann sich jederzeit durch Klicken auf den Mini-Einkaufswagen darüber informieren, welche Produkte in dem Retourenauftrag enthalten sind. Die API getCompleteOrderLineList wird aufgerufen, um die Liste der in dem Einkaufswagen enthaltenen Produkte abzurufen. Neben jedem Produkt ist ein Symbol X zu sehen, über das das Verkaufspersonal das betreffende Produkt löschen kann.

Wenn das Verkaufspersonal auf das Symbol X klickt, wird die modifyFulfillmentOptions -API mit dem Attribut Action aufgerufen, das auf REMOVE gesetzt ist, um das Produkt zu löschen. Wenn das Produkt gelöscht ist, wird der Mini-Einkaufswagen aktualisiert.

Retourenliste

Wenn alle Produkte zu einer Retoure hinzugefügt wurden, kann das Verkaufspersonal zur nächsten Anzeige navigieren, um Retourengründe für die Produkte hinzuzufügen. Anschließend klickt das Verkaufspersonal auf Fortfahren. Die API getCompleteOrderDetails wird aufgerufen, um die Kopfzeileninformationen und die Auftragssummeninformationen abzurufen. Die API getCompleteOrderLineList wird aufgerufen, um die Auftragspositionsinformationen in der Anzeige Returns List anzuzeigen. Die API processReturnOrder wird aufgerufen, um (falls zutreffend) Preisnachlässe und Gebühren vom Vertriebsauftrag in den Retourenauftrag zu kopieren.

Für jeden Artikel, der retourniert wird, muss ein Retourengrund angegeben werden. Rückgabegründe werden in Sterling Business Center konfiguriert und die getCommonCodeList -API wird mit dem Attribut CodeType aufgerufen, das auf RETURN_REASON gesetzt ist, um die Rückgabegründe abzurufen. Das Popup-Fenster Retourengrund hinzufügen wird angezeigt, wenn die Anzeige Retourenliste geladen wird, und das Verkaufspersonal muss Retourengründe eingeben. Die Retourenprodukte können unterschiedliche Retourengründe haben oder das Verkaufspersonal kann ein und denselben Retourengrund auf alle Retourenprodukte anwenden. Wenn es unterschiedliche Retourengründe gibt, werden die betreffenden Produkte angezeigt und das Verkaufspersonal kann jedem einzelnen Produkt einen individuellen Retourengrund zuweisen. Wenn sich das Verkaufspersonal dazu entschließt, die Retourengründe erst später auszuwählen, kann dazu dann für jedes Produkt auf Retourengrund hinzufügen geklickt werden. Das Popup-Fenster Retourengrund hinzufügen wird angezeigt. Hier kann das Verkaufspersonal dann den Retourengrund auswählen.

Wenn das Verkaufspersonal alle erforderlichen Details in das Fenster "Retourengrund hinzufügen" eingegeben hat und auf OK klickt, wird die API changeOrder aufgerufen, um den Auftrag mit den Retourengründen zu aktualisieren.

Wenn ein Produkt aus dem Retourenauftrag entfernt werden muss, kann das Verkaufspersonal auf das Symbol Löschen klicken und die API changeOrder wird aufgerufen, um das Produkt aus dem Retourenauftrag zu entfernen.

Wenn vom Verkaufspersonal eine Blindretoure erstellt wird, muss der Kunde in der Anzeige Retourenliste identifiziert werden. Dazu kann das Verkaufspersonal auf "Kunden identifizieren" klicken. Wenn der Kunde im System enthalten ist, kann das Verkaufspersonal nach ihm suchen. Ist das nicht der Fall, kann das Verkaufspersonal ein neues Kundenprofil erstellen.
  • Bestehender Kunde
    • Nach bestehenden Kunden kann über Vornamen, Nachnamen, E-Mail-Adresse oder Telefonnummer gesucht werden. Die API getCompleteCustomerList wird aufgerufen, um nach allen bestehenden Kunden zu suchen.
    • Wenn es bei bestehenden Kunden zusätzliche Adressangaben wie Rechnung an und Versand an gibt, werden diese bei der Suche des Verkaufspersonals nach einem Kunden angezeigt.
    • Wenn das Verkaufspersonal den richtigen Kunden gefunden hat und auf OK klickt, wird die API changeOrder aufgerufen, um die Kundendetails zu dem Auftrag hinzuzufügen. Wenn dem Kundenkonto eine Adresse zugeordnet ist, wird diese Adresse automatisch Versandadresse für den Auftrag.
  • Neukunde
    • Wenn für einen Kunden kein Datensatz gefunden werden kann oder wenn es sich um einen neuen Kunden handelt, kann das Verkaufspersonal über die Registerkarte "Neuer Kunde" einen neuen Konsumentenkunden anlegen.
    • Wenn das Verkaufspersonal Adressdetails für den Kunden eingegeben hat und die Registerkarte dann wieder verlässt, wird die folgende Logik ausgeführt:
      • Wenn das Verkaufspersonal dann auf OK geklickt hat, wird die API verifyAddress aufgerufen. Wenn der Benutzerexit YCDVerifyAddressWithAVSUE konfiguriert ist, wird die Adresse überprüft. Ist die Adresse ungültig oder es werden mehrere Adressen gefunden, die der eingegebenen Adresse entsprechen, wird der Benutzer dazu aufgefordert, entweder die ungültige Adresse zu ändern oder aus der Liste der übereinstimmenden Adressen die korrekte Adresse auszuwählen.
      • Nachdem eine gültige Adresse ausgewählt wurde, wird die API manageCustomer aufgerufen, um den Kunden zu erstellen.
      • Die API changeOrder wird aufgerufen, um die Kundendetails zum Retourenauftrag hinzuzufügen.
  • Sollen Kundeninformationen geändert werden, kann das Verkaufspersonal in der Kundenanzeige auf Kunden ändern klicken. Dabei werden dann die gleichen APIs aufgerufen wie beim Erstellen eines neuen Kunden. Außerdem kann das Verkaufspersonal die für den Auftrag ausgewählte Adresse ändern und dazu auf das Symbol Bearbeiten klicken. Das Popup-Fenster Versandadresse bearbeiten wird angezeigt, das Verkaufspersonal gibt die Adresse ein und klickt dann auf OK. Die API modifyFulfillmentOptions wird aufgerufen, um die Adresse zum Auftrag zu aktualisieren. Wenn die Adresse vom Verkaufspersonal bearbeitet wird, bezieht sich diese Änderung nur auf den Auftrag und wird nicht im Kundenkonto gespeichert.

Verstöße gegen Retourenrichtlinie übergehen

Wenn ein Produkt nicht retournierbar ist, das Verkaufspersonal aber darauf besteht, das Produkt in eine Retoure aufzunehmen, muss die Nichtbeachtung der Richtlinie übergangen werden. Retourenrichtlinien für Retourenprodukte werden in Sterling Business Centerfestgelegt. In der Retourenrichtlinie sind die Regeln für die Retourenprodukte definiert.
  • Wenn die Überschreibungsrichtlinie auf Allow Overridegesetzt ist, wird der Produktverstoß automatisch von der Anwendung überschrieben.
  • Wenn die Überschreibungsrichtlinie auf Do Not Allow Overridegesetzt ist, kann die Richtlinie nicht überschrieben werden. Das Verkaufspersonal kann die Retourenrichtlinie anzeigen lassen, um dem Kunden die Nichteinhaltung zu erklären.
  • Wenn die Retourenrichtlinie auf Allow Return Based on Approval Plangesetzt ist, sind Überschreibungen mit dem entsprechenden Genehmigungscode zulässig. Wenn das Verkaufspersonal für das Produkt, das gegen die Retourenrichtlinie verstößt, auf Überschreiben klickt, wird das Fenster Überschreiben angezeigt.
    • Die API getCommonCodeList wird mit dem Attribut CodeType mit dem Wert WSC_RETURN_OVERRIDE aufgerufen, um den Grund der Überschreibung abzurufen.
    • Das Verkaufspersonal muss einen Manager-Überschreibungscode eingeben.
    • Das Verkaufspersonal kann auf OK klicken, um den Retourengrund und den Überschreibungscode für den Auftrag zu speichern. Die API createOrder wird für den ersten Artikel aufgerufen, der zum Retourenauftrag hinzugefügt werden soll. Anschließend wird dann die API changeOrder für alle Produkte nach dem ersten Produkt aufgerufen, die zum Retourenauftrag hinzugefügt werden sollen.
    • Für einzelne Produkte können keine Überschreibungscodes eingegeben werden. Wenn ein Überschreibungscode eingegeben wird, werden alle Produkte mit Verstößen gegen die Retourenrichtlinie überschrieben. Wenn das Verkaufspersonal nicht alle Produkte im Retourenauftrag mit Verstößen gegen die Retourenrichtlinie überschreiben möchte, müssen zunächst die Produkte, die nicht überschrieben werden sollen, aus dem Retourenauftrag gelöscht werden, bevor dann die verbleibenden Produkte überschrieben werden können.
  • Nach erfolgreicher Ausführung der API createOrder oder changeOrder wird der Service YCD_ValidateReturnOverrideCode aufgerufen. Zum Überprüfen des Überschreibungscodes werden Auftragsobjekt, ausgewähltes Produkt, Retourengrund und Überschreibungscode in den Service eingegeben.
    • Sobald der Service aufgerufen ist, wird die API processReturnOrder aufgerufen, um die Verstöße in Bezug auf die Auftragsposition abzurufen.
  • Wenn der Service fehlerfrei funktioniert, werden alle Verstöße in Bezug auf das Produkt abgerufen. Die API recordApprovals wird für jeden Verstoß aufgerufen. Die ID des Verstoßes wird an die API weitergegeben und die API genehmigt die Überschreibung oder lehnt sie ab.
    • Wenn die API den Überschreibungscode bestätigt, wird der Status des Produkts in 1200 geändert. Wird die Genehmigung akzeptiert, wird die API createOrder oder changeOrder aufgerufen, um den Grund der Überschreibung zu erfassen.
    • Wenn die API den Überschreibungscode ablehnt, bleibt der Status des Produkts unverändert und die Überschreibung wird nicht zum Auftrag hinzugefügt.

Die Überprüfung der Richtlinien in Bezug auf Retouren und mögliche Überschreibungen muss für das Verkaufspersonal eingerichtet werden, damit dieses über eventuelle Verstöße informiert wird.

Wenn sich die Richtlinien in Bezug auf Retouren und mögliche Überschreibungen für ein Produkt überschneiden, wird eine entsprechende Fehlernachricht angezeigt und das Produkt wird nicht in den Retourenauftrag aufgenommen.

Umtauschprodukte hinzufügen

Ein Kunde hat die Möglichkeit, im Austausch für die Produkte, die als Retoure zurückgegeben werden, andere Produkte zu erwerben. Das Verkaufspersonal kann Umtauschprodukte entweder durch Einscannen eines Artikels oder durch Eingeben von Schlüsselwörtern im Fenster Umtausche hinzufügen. Wenn ein Schlüsselwort eingegeben oder ein Produkt gescannt wird, wird die folgende Logik ausgeführt:
  • Wenn das Verkaufspersonal ein auszutauschendes Produkt scannt, wird die API getCompleteItemList aufgerufen, um das Produkt abzurufen, und die Seite Produktdetails wird angezeigt. Ergibt die Suche kein Ergebnis, wird die API searchCatalogIndex aufgerufen, um Produkte aufzulisten.
  • Wenn das Verkaufspersonal Schlüsselwörter eingibt und dann auf das Symbol Suchen klickt, wird die API searchCatalogIndex aufgerufen, um übereinstimmende Produkte aufzulisten. Das richtige Produkt kann dann aus der Liste ausgewählt werden.
Das Verkaufspersonal kann auf die Schaltfläche "Teilen" klicken, um die Produktdetails für den Kunden freizugeben. Im Popup-Fenster "Teilen" kann das Verkaufspersonal die Produktdetails standardmäßig per E-Mail teilen. Die registrierte E-Mail-Adresse des Kunden wird automatisch eingetragen. Wenn die E-Mail-Adresse nicht vorhanden ist, kann das Verkaufspersonal manuell eine E-Mail-Adresse eingeben. Wenn das Verkaufspersonal auf die Schaltfläche 'E-Mail' klickt, werden die Produktdetails an den Kunden gesendet. Ebenso kann das Verkaufspersonal Produktdetails an mehrere E-Mail-Adressen senden, indem es die E-Mail-Adressen manuell eingibt.
Hinweis: Sie können auch mehrere Optionen für die gemeinsame Nutzung durch Anpassung hinzufügen. Ebenso können Sie den Standard-E-Mail-Service nach Bedarf anpassen.
Wenn das Verkaufspersonal nicht über die Ressourcenberechtigung Email Product details verfügt und die Schaltfläche "Teilen" nur über die E-Mail-Option verfügt, wird die Schaltfläche "Teilen" nicht angezeigt.

Wenn das richtige Produkt dann gefunden ist, kann das Verkaufspersonal auf Als Umtausch hinzufügen klicken, um das Produkt zum Umtauschauftrag hinzuzufügen.

Wenn das Produkt für den Austausch zum ersten Mal hinzugefügt wird, wird die API createOrder aufgerufen, um den Umtauschauftrag zu erstellen. Die folgende Logik wird ausgeführt:
  • Die API getCompleteOrderDetails wird aufgerufen, um das Attribut OrderHeaderKey aus dem Retourenauftrag abzurufen, das dann als Attribut ReturnOrderHeaderKeyForExchange an die API createOrder weitergeleitet wird.
  • Das Attribut ExchangeType in der API createOrder des Umtauschauftrags wird auf der Basis der Regel YCD_DEFAULT_EXCHANGE_TYPE gesetzt.

Nachdem ein Produkt zu einem Umtauschauftrag hinzugefügt worden ist, wird die Anzeige Retourenliste mit den hinzugefügten Umtauschprodukten geladen. Das Verkaufspersonal kann alle notwendigen Änderungen an einem Umtauschprodukt vornehmen und z. B. aus einem Produkt ein Geschenk machen, einen Gutschein anwenden, das Lieferverfahren ändern usw.

Zum Überschreiben des Preises für ein Umtauschprodukt kann das Verkaufspersonal das Bearbeitungssymbol auswählen. Wenn das Verkaufspersonal das Bearbeitungssymbol neben dem Stückpreis eines Umtauschprodukts auswählt, wird das Fenster "Preis überschreiben" angezeigt. Das Verkaufspersonal kann den neuen Preis und den Grund für die Preisüberschreibung eingeben und die Änderung anwenden.

Zum Abrufen der Überschreibungsgründe wird die API getCommonCodeList aufgerufen, wobei das Attribut CodeType auf YCD_PRICEOVERRIDEgesetzt ist. Wenn das Verkaufspersonal dann auf Anwenden klickt, wird die API modifyFulfillmentOptions aufgerufen, um den Listenpreis des Produkts zu überschreiben. Ursprünglicher und neuer Preis des Produkts werden angezeigt.

Zum Überschreiben des Preises für ein Produkt muss das Verkaufspersonal über die entsprechende Ressourcenberechtigung für die Aktion Preis überschreiben verfügen. Wenn diese Ressourcenberechtigung nicht vorliegt, wird das Symbol Preis überschreiben nicht angezeigt.

Für Umtauschprodukte können Geschenkoptionen zur Verfügung stehen. Für alle Produkte wird die Nachricht Produkt als Geschenk definieren angezeigt.

Dem Verkaufspersonal muss es bei Abwicklung des Umtauschauftrags möglich sein, Gutscheine entweder auf einzelne Umtauschprodukte oder auf den kompletten Umtauschauftrag anzuwenden. Das Verkaufspersonal kann einen Gutschein einscannen oder den Gutscheincode eingeben und dann die Eingabetaste drücken, um den Gutschein auf den Auftrag anzuwenden. Die API translatebar code wird aufgerufen, um den Coupon zu identifizieren. Wenn der Gutschein identifiziert ist, wird die API changeOrder aufgerufen, um den Gutschein auf den Auftrag anzuwenden.
  • Wenn der Gutschein erfolgreich auf den Auftrag angewendet wurde, wird die API getCompleteOrderDetails aufgerufen, um die Auftragsanzeige mit dem neuen Preis zu aktualisieren. Ist das nicht der Fall, wird eine Fehlernachricht ausgegeben.
  • Das Verkaufspersonal kann einen Gutschein durch Anklicken des X-Symbols neben dem Gutschein löschen. Zum Entfernen eines Gutscheins wird die API changeOrder mit dem Attribut ACTION mit dem Wert REMOVE im Element Promotion aufgerufen. Die API getCompleteOrderDetails wird aufgerufen, um die Seite mit den neuen Informationen zu aktualisieren.
Hinweis: Die folgenden Typen von Gutscheinen werden nicht unterstützt:
  • Auf Versandkosten anwendbare Gutscheine
  • Auf spezielle Zahlungsarten anwendbare Gutscheine

Nachdem alle Produkte hinzugefügt worden sind und der Kunde identifiziert ist, kann das Verkaufspersonal (bei Bedarf) auf Erstattung klicken. Die API processReturnOrder wird mit dem Attribut ExecuteReturnPolicy aufgerufen, das auf Y gesetzt ist, um die Rückgabeprodukte zu validieren. Wenn Verstöße auftreten, wird das Popup-Fenster Product outside return policy geöffnet und das Verkaufspersonal muss einen Manager aufrufen, um einen Managerüberschreibungscode einzugeben, damit die Rückgabe zulässig ist. Alternativ dazu kann das Verkaufspersonal das Produkt aus dem Retourenauftrag entfernen. Wenn der Richtlinienverstoß nicht außer Kraft gesetzt werden kann, muss das Verkaufspersonal das Produkt aus dem Retourenauftrag entfernen, bevor mit den Zahlungen begonnen werden kann. Werden keine Verstöße festgestellt, wird das Fenster Zahlungen angezeigt.

Zahlungen

Wenn das Verkaufspersonal von der Anzeige Retourenliste zur Anzeige Zahlungen navigiert, wird die API processReturnOrder aufgerufen, um den Erstattungsbetrag zu berechnen. Wurden zuvor Zahlungsmethoden mit dem ursprünglichen Vertriebsauftrag gespeichert, werden die standardmäßigen Zahlungsmethoden für den Retourenauftrag durch die API processReturnOrder belegt. Die standardmäßigen Zahlungsmethoden für Retourenaufträge und der Erstattungsbetrag zu diesen Zahlungsmethoden richten sich nach den entsprechenden Zahlungsartkonfigurationen.

Wenn die Regel Default for Return aktiviert ist, wird die folgende Logik ausgeführt:
  • Es kann immer nur eine Zahlungsart als Standardzahlungsart für den Retourenprozess definiert sein.
  • Wenn eine Zahlungsart als Standardzahlungsart für Retouren definiert ist, wird im Rahmen einer Blindretoure der betreffende Betrag immer in dieser Zahlungsart zurückerstattet.
  • Wenn eine Zahlungsart, die für Vertriebsaufträge verwendet wurde, für Retouren nicht gültig ist, wird der betreffende Betrag immer mit der Standardzahlungsart zurückerstattet.
Wenn die Regel Valid for Return aktiviert ist, wird die folgende Logik ausgeführt:
  • Wenn die Zahlungsarten, die für Vertriebsaufträge verwendet wurden, für Retouren gültig sind, wird der betreffende Betrag bei den Retouren immer in denselben Zahlungsarten zurückerstattet. Wenn in den Vertriebsaufträgen mehrere Zahlungsarten verwendet werden, wird die Retourensequenz berücksichtigt, und der Betrag wird auf der Basis der Retourensequenz zurückerstattet.
  • Wenn die Zahlungsarten, die für Vertriebsaufträge verwendet wurden, für Retouren nicht gültig sind, werden die ungültigen Zahlungsarten bei Durchführung der Retouren in der Anzeige für die Erstattungen für Retouren nicht angezeigt. Allerdings kann der Benutzer die für Retouren ungültigen Zahlungsarten über den Link Neue Zahlungsweise hinzufügen auswählen und den Retourenprozess abschließen.
Wenn die Regel Credit Card Valid For Return aktiviert ist, wird der Betrag an eine Kreditkarte zurückerstattet. Wenn die Regel Credit Card Valid For Return inaktiviert ist, wird die Rückgabe auf alle Standardzahlungsmethoden zurückerstattet. Wenn vom Kunden eine andere als die standardmäßige Zahlungsmethode gewünscht wird, kann vom Verkaufspersonal eine neue Zahlungsmethode hinzugefügt werden. Wenn die Erstellung der Versandrechnung im Rahmen des Vertriebsauftrags erfolgt ist, wird das Attribut PlannedRefundAmount für die Zahlungsmethoden für Retourenaufträge bestückt.
Wenn im Auftrag keine Umtauschprodukte enthalten sind, wird die folgende Logik ausgeführt:
  • Der Erstattungsbetrag für den Retourenauftrag wird mit den standardmäßigen Zahlungsmethoden und dem entsprechenden Attribut PlannedRefundAmount für die einzelnen Zahlungsmethoden angezeigt.
  • Das Attribut GrandRefundTotal in der API processReturnOrder wird aufgerufen, um den dem Kunden zustehenden Erstattungsbetrag anzuzeigen.
  • Die API getCompleteOrderDetails wird dazu verwendet, die Details des Retourenauftrags abzurufen.
Wenn ein Umtauschauftrag für den Retourenauftrag existiert, wird die folgende Logik ausgeführt:
  • Die API getCompleteOrderDetails wird aufgerufen, um das Attribut GrandExchangeTotal zum Anzeigen der Umtauschauftragssumme und das Attribut GrandTotal zum Anzeigen der Summe für die Retouren- und Umtauschaufträge abzurufen.
  • Wenn der Betrag für das Attribut GrandRefundTotal positiv ist, erhält der Kunde eine Rückerstattung. Die standardmäßigen Zahlungsmethoden werden zusammen mit dem geplanten Erstattungsbetrag angezeigt.
  • Wenn der Betrag für das Attribut GrandRefundTotal negativ ist, schuldet der Kunde im Rahmen des Umtauschauftrags noch Geld. Wenn der Kunde in Bezug auf den Auftrag noch Geld schuldig ist, wird die API getCompleteOrderDetails aufgerufen, um das Attribut RemainingAmountToAuth vom Attribut ChargeTransactionDetails abzurufen und den vom Kunden zu zahlenden Restbetrag anzuzeigen. Wenn der Kunde in Bezug auf den Umtauschauftrag noch einen Restbetrag schuldet, sind keine standardmäßigen Zahlungsmethoden verfügbar.
  • Für die Erfassung der Zahlung wird die folgende Logik ausgeführt:
    • Die API capturePayment wird aufgerufen, um die Zahlung für den Umtauschauftrag zu erfassen.
    • Die API getPaymentList wird aufgerufen, um die akzeptierten Zahlungsarten abzurufen.
    • Die API getCommonCodeList wird mit dem Attribut CodeType mit dem Wert YCD_CREDIT_CARD_TYPE aufgerufen, um die akzeptierten Kreditkartentypen abzurufen. Die Informationen werden dann an die API getPaymentCardTypeList weitergeleitet, um die Liste der Zahlungskartentypen abzurufen.
    • Für Kreditkartenzahlungen wird das Attribut SecureAuthenticationCode an die API processOrderPayments weitergeleitet, um den CVV-Code zu allen Kreditkarten zu erfassen.
    • Aus Sicherheitsgründen werden die Kreditkartennummern in der Anwendung nicht angegeben. Stattdessen wird die Zahlung zwecks Verschlüsselung der Kartennummern durch den Sterling Sensitive Data Capture Server erfasst. Das Verkaufspersonal erhält den CVV-Code auf der Kreditkarte, von wo aus er zwar zwecks Autorisierung als transaktionsorientierte Informationen an die API processOrderPayments weitergeleitet wird, aber grundsätzlich nicht im System oder in Systemprotokollen erfasst wird.
    • Wenn bei der Verarbeitung der Zahlung Fehler auftreten, wird zur Anzeige einer entsprechenden Fehlernachricht in der Ausgabe entweder der API capturePayment oder der API processOrderPayments das Element ChargeTransactionDetails aufgerufen.
    • Wurde die Zahlung fehlerfrei verarbeitet, wird die API confirmDraftOrder aufgerufen, um die Zahlung zu bestätigen.

Wenn die Einschränkung If Refund Amount is für eine Zahlungsart für einen bestimmten Erstattungsbetrag festgelegt ist, erfolgt die Erstattung über die Zahlungsart, die in der Einschränkung Refund Using Payment Type angegeben ist. Wenn beispielsweise ein Vertriebsauftrag der Kreditkartenzahlungsart zugeordnet ist, kann eine Einschränkung so festgelegt werden, dass der Erstattungsbetrag bei einer Retoure des Auftrags als Scheck erfolgen muss, wenn die Auftragssumme 1.000 US-Dollar übersteigt. Wenn die Auftragssumme nicht über 1.000 US-Dollar liegt, kann die Einschränkung so festgelegt werden, dass die Erstattung über eine Guthabenkarte erfolgt. Bei diesem Beispiel muss für die Einschränkung Refund to new payment type der Wert SVC (Store Value Card, Guthabenkarte) für die Zahlungsart 'Kreditkarte' festgelegt werden, und als Einschränkung muss angegeben sein, dass die Auftragssumme bei der Zahlungsart 'SVC' weniger als 1.000 US-Dollar beträgt. Wenn für die Regeln Default for Return und Refund to a new payment type der Wert ON für eine Zahlungsart festgelegt ist, wird die als Refund to new payment type festgelegte Zahlungsart berücksichtigt, wenn das Verkaufspersonal eine Blindretoure durchführt.

Die API processOrderPayments wird aufgerufen, um die Rückerstattung für den Kunden in Echtzeit zu verarbeiten. Wenn bei der Verarbeitung der Zahlung Fehler auftreten, wird zur Anzeige einer entsprechenden Fehlernachricht in der Ausgabe entweder der API capturePayment oder der API processOrderPayments das Element chargeTransactionDetails aufgerufen. Wurde die Zahlung fehlerfrei verarbeitet, wird die API confirmDraftOrder aufgerufen, um den Auftrag zu bestätigen.

Hinweis: Wenn das Verkaufspersonal bei der Eingabe von Zahlungsinformationen zur Seite Returns list zurückkehrt, gehen alle eingegebenen Zahlungsinformationen verloren. Bei Auftragsentwürfen werden Zahlungen nicht gespeichert.

Retouren- oder Umtauschauftragsübersicht anzeigen

Bei erfolgreichem Abschluss des Zahlungsvorgangs kann sich das Verkaufspersonal die Retourenübersicht oder die Umtauschübersicht anschauen. Die API getCompleteOrderDetails wird aufgerufen, um alle Details zu Retouren- und Umtauschaufträgen abzurufen. Die API getCompleteOrderLineList wird aufgerufen, um alle Details zu Retouren- und Umtauschprodukten abzurufen.

Das Verkaufspersonal kann für den Kunden einen Beleg drucken. Wenn sich das Verkaufspersonal dazu entschließt, den Beleg zu drucken, wird der Service StoreReturnReceipt_95 aufgerufen, um die Details des zu druckenden Retourenauftrags zu senden.

Alternativ dazu kann sich der Kunde den Retourenbeleg auch an eine E-Mail-Adresse senden lassen. Dann wird der Service YCD_StoreReturnEmail aufgerufen, um die Retourenauftragsdetails abzurufen und die E-Mail zu senden.

Wenn das Verkaufspersonal auf Fertig klickt, wird das Fenster Retourenort aufzeichnen angezeigt. Die API getReturnDispositionList wird aufgerufen, um die Retourenorte aufzuzeichnen. Das Verkaufspersonal kann angeben, ob alle Retourenprodukte an ein und demselben Retourenort aufbewahrt werden sollen. Die folgende Logik wird ausgeführt:
  • Wenn alle Produkte an ein und demselben Retourenort aufbewahrt werden sollen, wird in dem Fenster ein Menü angezeigt, über das der Retourenort ausgewählt werden kann. Hier muss das Verkaufspersonal den Retourenort auswählen.
  • Wenn die Produkte an verschiedenen Retourenorten aufbewahrt werden sollen, wird in dem Fenster für jedes Produkt ein Retourenortmenü angezeigt. Hier muss das Verkaufspersonal für jedes Produkt einen Retourenort auswählen.
  • Um die Retourenorte für die Produkte zu speichern, klickt das Verkaufspersonal auf OK. Die API changeOrder wird aufgerufen, um die Änderungen am Retourenauftrag zu speichern.
Nachdem die Retourenorte vom Verkaufspersonal ausgewählt und für den Retourenauftrag gespeichert wurden, wird die Startseite angezeigt.

Retouren- oder Umtauschauftrag abbrechen

Wenn sich das Verkaufspersonal dazu entschließt, einen Retouren- oder Umtauschauftrag abzubrechen, wird die API deleteOrder mit dem Attribut OrderHeaderKey aufgerufen, um den Auftrag zu löschen. Wenn das Verkaufspersonal nach Löschen des Auftrags für eines der Produkte eine Retoure ausführen muss, muss dazu ein neuer Retourenauftrag erstellt werden. Wenn zuvor ein Überschreibungscode erforderlich war, muss dieser Überschreibungscode erneut eingegeben werden.