In Bearbeitung [WAWI-34634] Rabatt auf Zahlungsarten

[Rico Giesler]

Und wenn du nun aber in unterschiedlichen Shops die Kundengruppen gleich benannt hast?
Oder einfach nur einen Shop für Socken und einen für Käse, aber in beiden arbeitest du nur mit B2C also nur Endkunden?
Wie gesagt, es ist leider nicht so einfach da eine allgemeingültige Lösung zu finden die auch für alle Kunden passt.
Wenn du eine kreative Lösung hast die alles mögliche mit abdeckt und für jeden User einfach zu handhaben ist, gern her damit. 🙂
Ich hab auch viel hin und herüberlegt und letztendlich ist der Workflow die flexibelste Option.

 

[Matze_G]

Warum so kompliziert? Es wäre doch sicher ganz einfach möglich für die manuelle Auftragseingabe einen Button "Rabatt" einzufügen. Soll der Auftrag rabattiert werden, drückt man drauf, es öffnet sich ein kleines Fensterchen, man kann den Rabatt eingeben (vielleicht sogar optional als feste Summe Preisnachlass), zusätzlich noch einen kleinen Text und der Haken, ob Versandkosten mit rabattiert werden sollen. Das ganze wird dann als Freitextposition eingefügt. Ändert man den Auftrag, löscht man die vorher erstellte Position und drückt wieder auf den Knopf.
Das würde schon die meisten Anforderungen abdecken und ist absolut flexibel und Arbeitszeit sparend, weil der Taschenrechner in der Schublade bleiben kann.
Als Krönung könnte man natürlich auch schon Rabatte vordefinieren, die man in dem Fensterchen einfach auswählen kann.
Ich denke, dass das keine große Herausforderung an die Programmierung ist.
LG

 

[Rico Giesler]

Gleiches wäre aber auch schon per Workflow möglich. 🙂

 

[Matze_G]

Naja, Zuordnung von Versand- und Zahlart wären ja auch per Workflow möglich, sind aber auch da integriert, wo es hingehört, nämlich in die Auftragsmaske😉

Halte es da mal wie hier:

@Rico Giesler Jaja, die Workflows sind klasse.
Ich versuche halt nur bei Themen von denen ich meine, das es eigentlich der Job von JTL ist, die Arbeit auch auf JTL abzuwälzen. Und dieses Thema empfinde ich einfach als nicht zu Ende gedacht / gearbeitet. Oder gibt es irgendeine gute Begründung dafür, dass ein und dasselbe Thema im Shop gänzlich anders behandelt und dargestellt wird als in der Wawi?
Hier der Deal:
Überzeuge mich und ich schreibe den Workflow.
Habt ihr keine guten Argumente, macht ihr eure Hausaufgaben und programmiert das sauber zu Ende.

Wenn ihr einen kreativen Vorschlag habt wie man das sinnvoll umsetzen kann so dass es immer passt, dann sind die Kollegen gern offen da eine Lösung zu implementieren. 🙂

Du wolltest einen einfachen Vorschlag, und das wäre einer.

 

[Manuel Pietzsch]

Hi,

diese einfache Pflege wäre deutlich einfacher umzusetzen, also unabhängig von Versand- und Zahlungsart.

Schaut mal ob ich es hier richtig wiedergegeben habe: https://issues.jtl-software.de/issues/WAWI-34634

Wäre nice wenn ihr dann auch voten könnt.

Gruß

Manuel

 

[fibergirl]

Wie ist die Lösung denn jetzt mit Auftrag 2.0?

Ich würde schon im Falle von Vorkasse per Workflow eine Zahlungsart-Position einfügen (wenn es noch keine gibt) und per Workflow den jeweiligen Rabatt ausrechnen und eintragen.
Damit es analog wie beim Shop aussieht.
Nur - es geht nicht.
Man kann nur Frei- oder Artikelpositionen einfügen. Keine Zahlungsartposition.

Oder andersherum bei Ändern der Zahlungsart (oder immer) die automatische Positon vom Shop entfernen und durch die entsprechende Wawi-Zahlart (Vorkasse mit Skonto) ersetzen.
Geht aber auch nicht per Workflow.

Hm, wie macht man das mit wenig Handarbeit?
Ich seh das schon schiefgehen: Vorkasse-Rabattposition kommt vom Shop, Mitarbeiter stellt um auf Rechnung (mit Skonto), ohne die Position zu löschen (übersehen) => Chaos.