Hallo, ich nehme an, ich muß dazu die Vorlage Statusänderung nehmen. Aber wo sage ich Gambio dass diese Vorlage versendet werden soll, sobald sich per API Aufruf der Status auf versandt ändert? Viele Grüße - Richard
Hallo! Nur kurz aus dem Stehgreif, es ist schon spät... Wenn Du per REST-API den Status änderst, dann schickst Du doch mit dem Datenblock unter anderem mit ob der Kunde benachrichtigt werden soll? https://developers.gambio.de/docs/4...gx3-api/reference/orders/update-order-status/ { "comment": "", "customerId": 1, "customerNotified": true, "dateAdded": "2015-11-06 12:22:39", "statusId": 1 } Wenn ich das richtig sehe: Wenn Du "customerNotified": true mitsendest, wird der Kunde informiert. Schickst du "customerNotified": false, nicht. Oder habe ich die Frage nicht richtig verstanden?
Nein, stimmt nicht. Da steht „customerNotified“, nicht „notifyCustomer“. Das Feld dient der Dokumentation einer bereits erfolgten Benachrichtigung, man kann damit keine E-Mail-Aussendung veranlassen. Das sind zwei getrennte Vorgänge: Erstens die Änderung des Bestellstatus (und Dokumentation der Änderung in der Bestellstatushistorie) und zweitens das Versenden von E-Mails. Für letzteres gibt es einen anderen Endpunkt: https://developers.gambio.de/docs/4.1.1.0_beta2/rest/gambio-gx3-api/reference/emails/send-email/
Ah, ok, danke für die Richtigstellung. Ich dachte dass der Shop bei Statusänderung auch glcih automatisch die Mail senden kann wenn gewünscht. Das heisst also dass man über die API eine eMail an den Käufer sendet die über die e-Mail ID im Shop definiert ist? Das heisst dann aber auch, dass man in der Bestellhistorie dann zwei Vorgänge hat: Eimal "Bestellung ist versendet, Kunde nicht informiert" und einem "E-Mail geschickt" - oder verknüpft das der Shop automatisch, wenn der Status auf "versendet" ist und die mit "versendet" verknüpfte e-Mail ID geschickt wurde? Steh diesbezüglich grade aufm Schlauch...
Nein, das sind wirklich zwei komplett getrennte Vorgänge. Das eine ist das Senden von E-Mails, das andere ist die Statusänderung. Die beiden sind nicht verzahnt und haben im Grunde nichts miteinander zu tun. Vor allem ist das Senden von E-Mails über das REST-API nicht an Kunden oder Bestellungen gebunden, sondern völlig generisch. Es gibt dabei auch keinen Zugang zu den Vorlagen; die email_id aus der Dokumentation ist optional und dient dazu, eine eigentlich bereits versendete Nachricht zu referenzieren, wenn diese erneut gesendet werden soll.
Kann man denn die Benachrichtigung des Kunden bei Statusänderung überhaupt über die REST-API auslösen?
Jein. Ich hatte das jetzt gar nicht für mich gefragt, sondern im Zuge der ursprünglichen Frage von Richard. Bei mir macht das die WaWi. Letztlich ist der Ansatz von euch gar nicht sooo falsch: Wer den Status per REST-API setzt, macht das ja in der Regel über eine Wawi, die dann ohnehin den anderen Kram macht Benachrichtigung etc...). Andererseits ist es aber natürlich nicht ganz konstistent, da ich eigentlich dachte, wenn man über die API was auslöst sollte das im Shop die selben Dinge machen wie die "manuelle" Funktion über das Backend...
Vielleicht war das missverständlich. Ich meinte nicht, dass man das Aussenden der E-Mail-Benachrichtigungen an die Bestellstatusänderung tackern sollte. Ganz im Gegenteil, ich finde das gut und richtig, dass das getrennt ist. Aber ich vermisse bei genauerem Hinsehen eine Möglichkeit, den Shop per REST-API zum Versenden von Standard-E-Mails auf Basis der Vorlagen zu veranlassen, z.B. eben Bestellstatusänderungsbenachrichtigungen oder einfach Bestellbestätigungen.
@BigRib Ein API Endpunkt um Bestellbestätigungen oder E-Mails mit Vorlagen zu senden ist bisher nicht geplant. Aber es wäre möglich, dass man in der API den Endpunkt der Statusänderung anpasst um hier wenn "customer_notified" auf true übergeben wird, automatisch die E-Mail für den Statuswechsel gesendet wird. Das werde ich gerne als Feature aufnehmen.
Ich würde das auch sofort nutzen. Weil das Verwalten der Mails scheint mir in meiner Wawi (VARIO) zu kompliziert. Aber... Wäre es nicht sinnvoller, ein weiteres Feld zu haben NOTIFY_CUSTOMER, damit das keine Änderung sondern Erweiterung der API wird?
@sirtet Das Feld "customerNotified" gibt es bereits in der API, aber es wird aktuell einfach keine E-Mail für die Statusänderung versendet, wenn der Wert per API gesetzt wird. Nach Außen wird sich an der API nichts verändern, sondern nur das der Wert "customerNotfied" ab dann auch interpretiert wird, also im Hintergrund die E-Mail für die Statusänderung dann auch wirklich gesendet wird. Man kann das über "customnerNotified": true oder false steuern.
Sorry daß ich den Thread erst jetzt gefunden habe. Das geht mit Mailbeez. Funktioniert super und nutze ich schon seit Jahren. https://www.mailbeez.de/dokumentation/mailbeez/notification_order_status
Ja, klar. Aber wird es nicht genau darum zu Problemen führen, wenn sich die Funktion ändert? Wenn eine WAWI damit bisher in den Shop synchronisiert "ist benachrichtigt", und ihr in Zukunft jedes Mal wenn das Feld übermittelt wird eine Mail sendet, dann... hmm... gibt das sicher irgendwann Probleme, wenn das Feld wiederholt übermittelt wird. Darum dachte ich, wär's besser ein neues Feld, das explizit sagt "bitte jetzt übermitteln". Aber geal, ihr werdet das schon vernünftig machen.