Stornos Rückvergütungen Email Status

[Pedalman]

Ich wollte den schon vorhandenen Beitrags-thread nicht nutzen, da ich eine Lösung bzw. Lösungswege von deutschen Nutzern für Deutschland suche. Ich hoffe, dass das in Ordnung geht.

Original: how to handle returns

 

Hallo

ich habe mir heute auch mal unseren workflow angesehen und mir so meine Gedanken gemacht. Das Problem ist bei uns, dass wir immer! eine Rechung dem Paket beilegen. Das handhaben wir so seid Jahren und ich halte es für gut, weil sonst immer wieder mal Kunden anrufen, nur wegen der fehlenden Rechnung. Auch rechtlich gesehen ist es so in Ordnung denke ich, denn nur via email eine Rechnung zu versenden...Aber vielleicht bin ich da altbacken.

 

Aber um eine Rechnung  aus zu drucken, muss die Order auf "bezahlt" stehen. Das hat zwei merkwürdige Konsequenzen:

a) Kunde bekommt eine email mit Inhalt, der hätte die Order bezahlt, obwohl er ja via 'Kredit' sprich Rechnungskauf eingekauft hat.

b) Überlegt der Kunde es sich anders und ich versende nicht, habe ich das Problem, dass schon eine Rechung erstellt wurde. In der Datenbank und beim Kunden, via Email. Ich habe es immer so verstanden, dass diese dann auch 'wieder aufgehoben werden muss' via Rückerstattung, damit alles stimmt. Sonst würde ja eine RE vorliegen, die nie bezahlt wurde. Aber eine Rückerstattung, wenn gar kein Geld transferiert wurde? Scheint mir auch nicht zu stimmen.

[Traumflug]

Da sollte man sich vielleicht nicht all zu sehr am Begriff "Rückerstattung" aufhalten. Technisch gesehen ist das einfach eine Rückabwicklung dessen, was vorher ausgestellt und bezahlt wurde.

[Occam]

On 11/11/2019 at 6:27 PM, Pedalman said:

Aber um eine Rechnung  aus zu drucken, muss die Order auf "bezahlt" stehen.

Das wäre mir jetzt neu, denn das lässt sich doch über die Status-Einstellungen regeln. Du kannst doch die Rechnungsgenerierung an die Auftragsbestätigung koppeln, indem du den automatischen Versand unterbindest und mit einem selbst erstellten Status "Auftragbestätigung" verknüpfst. Dann kannst du welbst entscheiden, wann der Kunde eine Rechnung sieht.

 Wenn du darüber hinaus die Bestellung auf Rechnung einer Kundengruppe "Stammkunden" zuweist, die Neukunden nicht angezeigt wird, dürfte der Anteil derjenigen, für die eine Rechnung ausgedruckt, aber dann doch nicht verschickt wird, denkbar gering sein.

Den Status "Bezahlt" bekommt die Bestellung natürlich erst nach Eingang des Rechnungsbetrages aut dem Konto. 

Im Übrigen gilt: Wenn der Kunde es sich anders überlegt, dann erfolgt eine Storno-Buchung, egal ob er gar nicht bestellt oder eine retournierte Lieferung ganz oder teilweise vergütet wird. In einem Fakturierungsprogramm würde man auch nicht anders verfahren. Andernfalls würdest du auch gar nicht deinen Dokumentationspflichten gerecht werden.

[Pedalman]

Als ich schrieb " Aber um eine Rechnung  aus zu drucken, muss die Order auf "bezahlt" stehen. ", da meinte ich es generell, also nicht wörtlich. Ich wollte damit sagen, wenn ich eine Rechnung generieren und ausdrucken will, so muss ich 'einen' Status haben, der auf bezahlt steht. Unsere Kunden, die auf Rechnung kaufen, bekommen ja auch eine Rechnung beigelegt...

Und somit habe ich natürlich auch immer mal wieder Rechnungen im Sytem (inkrementelle RE-Nr...), für die kein Geld geflossen ist.* Und somit sollte es auch richtig sein, dass ich diese dann ebenfalls via Teil-/Rückerstattung, welches ja für die Generierung des Rückerstattungsdokuments nötig ist, aufhebe.

Für diesen Vorgang brauche ich nicht das RMA System in TB aktivieren und eigentlich auch den Bestellstatus 'storniert' nicht.

 

*) entweder, weil der Kunde vor Versand vom Kauf zurücktritt, oder nach erhalt der Ware sich entscheidet zu Widerrufen oder Mängel feststellt und nicht zahlen will

Edited November 23, 2019 by Pedalman

[Occam]

5 hours ago, Pedalman said:

Ich wollte damit sagen, wenn ich eine Rechnung generieren und ausdrucken will, so muss ich 'einen' Status haben, der auf bezahlt steht.

Nochmals nein, das musst du nicht! Vielmehr kann die Rechnung auch für den Status "Bestellung storniert" aktiviert werden. Dazu reicht ein Mausklick auf das rote Kreuzchen in der Spalte Rechnung der Statusliste. Sobald eine Rechnung erzeugt wurde, ist auch der Button "Teilerstattung" verfügbar, über den eine Stornierung sämtlicher Posten vorgenommen werden kann. Dann lässt sich die Gutschrift erzeugen.

Das ist zugebenermaßen umständlich, entspricht aber durchaus den normalen Dokumentationspflichten.

Das Hauptproblem dürfte wohl eher sein, dass die Programmierer von TB ein komplettes Storno der Bestellung für unwahrscheinlich zu halten scheinen und auf den Button "Gesamterstattung", den es in PrestaShop noch gab, verzichtet haben. Deshalb muss die Stornierung  jedes Einzelpostens gesondert erfasst werden.  Das ist bei größerern Bestellungen umständlich und zeitraubend und sollte korrigiert werden.

Edited November 23, 2019 by Occam

[Pedalman]

Wie in alten Zeiten occam 🙂 Wir reden an einander vorbei. Aber ist meine Schuld. ... " muss ich 'einen' Status haben, der auf bezahlt steht. " damit meinte ich, einen Status, der die Bestellung als bezahlt=1 setzt in der db. Oder wie auch immer, Du hast es treffend ausgedrückt und geholfen. Danke sehr.

[Occam]

😃 Es gibt einen Status "Zahlung eingegangen". Aber den brauchst du doch gar nicht zu setzen! Und deswegen auch bei den Statuseinstellungen auch nicht anzuklicken!

[wakabayashi]

16 hours ago, Pedalman said:

Wir reden an einander vorbei.

So ist es... 

Du brauchst nicht mit bezahlt zu arbeiten, um eine Rechnung zu generieren. Folgendes sollte auch funktionieren:

 

[Pedalman]

Da hatte ich wohl was falsch in Erinnerung. Ich dachte immer, "Setze Bestellung auf "Bezahlt"" sorgt für mind. zwei Dinge: a) Rechnung wird generiert b) Statistik im Dashbooard arbeitet richtig

Sieht so aus, dass ich die Rechnung auch mit dem "Download der PDF Rechnung erlauben" generieren kann. Damit wäre das geklärt. Danke für den Screenshot!