Beantwortet Zahlungsziel und Skonto an Kunde gebunden

[SaR]

Eine Einstellungsmöglichkeit, die ich schon seit Jahren vermisse, ist, dass sich die Zahlungskonditionen an den Kunden binden lassen. Über Zahlungsarten ist es zu pauschal, im Kundenmenü selbst, zu wenig. Beispiel: "14 Tage 3% oder 30 Tage netto" kann ich nicht umsetzen, zumal ich auch keine Möglichkeit sehe, das so auf der Rechnung als Text auszugeben. Ideal würde mir erscheinen, wenn es einen Bereich á la Zahlungsarten gäbe, wo sich verschiedene Zahlungskonditionen hinterlegen ließen und man diese beim Kunde einfach auswählen kann.

Hat einer von Euch vielleicht einen schlauen Rat für mich?

Danke im Voraus

 

[Garten-Nutzer]

Hat einer von Euch vielleicht einen schlauen Rat für mich?

Ich frage jetzt einfach mal:
Dir ist bewusst, dass du unter Zahlungen -> Zahlungsarten die verschiedenen Zahlungsarten anlegen (Fürs Skonto) kannst oder? Beim Kunden selber legst du das reine Zahlungsziel ohne alles fest. Hier kannst du ihm auch beispielsweise die "Zahlungsart": "14 Tage 3 % Skonto" angeben.

Auf der Rechnung kannst du die Werte entsprechend auslesen und mittels Formeln beliebig anzeigen lassen. Die relevanten Werte sind:
str$(Report.Customer.PaymentMethod.CashDiscountValidity,0,0) = Skonto Tage
str$(Report.Customer.PaymentMethod.CashDiscount,0,0) = Skonto in %
str$(Report.Customer.TermOfPayment,0,0) = Netto Zahlungsziel in Tagen
LocCurrL$(Report.TotalGrossPrice, @InvoiceCulture) = Rechnungssumme brutto

Mit den Werten kann man natürlich auch rechnen. Wir haben beispielsweise die Vorlage so eingestellt, das der Kunde sehen kann, welchen Betrag er mit Skonto bezahlen muss und auch bis wann. Das selbe auch ohne Skonto.
Alles entsprechend Formel gesteuert. Sprich ich muss dem Kunden nur ein Zahlungsziel und einen eventuellen Skonto-Betrag angeben. Den Rest macht die Wawi alleine.

Hoffe ich konnte dir helfen.

Gruß

Garten-Nutzer

 

[SaR]

Hab Dank!
Ja klar, ist mir bewusst. Aber da wir sehr unterschiedliche Zahlungsziele speziell bei den Offline-Kunden (Großhandel) verwenden, muss ich jetzt z.B. die Zahlungsziele grob in den Zahlungsarten vordefinieren (Überweisung bei Erhalt, 8 Tage, 30 Tage etc.) und dann beim Kunden selbst eins dieser vordefinierten ZZ zuweisen und Skontosatz mit Ablauffrist einstellen.

Dies dann wiederum fehlerfrei im Formular ausgeben, ist ein eigener Stunt. Danke hier für die Skript-Vorlagen.

Mir erscheint dies halt in der jetzigen Form sehr umständlich und fehleranfällig. Zumal ich in der Zahlungsart ein Skontodefinieren kann und dann noch beim Kunden selbst. Welches Skonto hat jetzt die höhere Priorität? Ist der Kunde auch Online-Kunde (oder wird es), wie wird ihm dann seine Zahlungsart angezeigt?

 

[Garten-Nutzer]

Ja klar, ist mir bewusst. Aber da wir sehr unterschiedliche Zahlungsziele speziell bei den Offline-Kunden (Großhandel) verwenden, muss ich jetzt z.B. die Zahlungsziele grob in den Zahlungsarten vordefinieren (Überweisung bei Erhalt, 8 Tage, 30 Tage etc.) und dann beim Kunden selbst eins dieser vordefinierten ZZ zuweisen und Skontosatz mit Ablauffrist einstellen.

Du musst bei den Zahlungsarten nur das Skonto angeben, sprich "8 Tage 1 %" "14 Tage 3 %" usw.

Dies dann wiederum fehlerfrei im Formular ausgeben, ist ein eigener Stunt. Danke hier für die Skript-Vorlagen.

Wenn du dich etwas mit Excel auskennst oder noch besser, etwas VBA kennst, dann ist die Vorlage schnell erstellt. Musst halt bei den IF-Formeln aufpassen und testen. Aber das ist einfacher als gedacht. Mein Tipp: Mach "Ordner" in den Bereichen und setze diese mittels IF auf aktiv / inaktiv, je nach Logik dahinter. Das ist einfacher als einen Block der sehr unlesbar wird.

Mir erscheint dies halt in der jetzigen Form sehr umständlich und fehleranfällig. Zumal ich in der Zahlungsart ein Skontodefinieren kann und dann noch beim Kunden selbst. Welches Skonto hat jetzt die höhere Priorität? Ist der Kunde auch Online-Kunde (oder wird es), wie wird ihm dann seine Zahlungsart angezeigt?

Der Rabatt in der Kundenansicht ist genau das, ein Rabatt. Es ist ein % Wert, der immer gezogen wird.

Das Skonto in den Zahlungsarten ist das richtige Skonto. Die Wawi hat hier sogar weitere Funktionen drin, die nicht offensichtlich sind. Wenn ein Kunde x % Skonto bei einem Auftrag hat (gesteuert über Zahlungsart) und du die Zahlung bekommst, kannst du hier den Betrag nach Skontoabzug eingeben. Ist der Betrag richtig wird die Wawi automatisch eine zweite Buchung mit dem Vermerk "Skontobuchung" vornehmen. Das klappt bei uns wunderbar und ja selbst bei einem Cent Unterschied wird das nicht gemacht, also doppelte Überprüfung ob das Skonto stimmt.

Natürlich wäre es toll, wenn man für die B2B Kunden das Skonto einfach mit in die Zahlungen im Kundenstamm hinterlegen kann. Aber JTL ist ja eher auf B2C ausgelegt. Kommt eventuell mal.

Sobald man einmal raus hat wie es geht, ist es einfacher. Klar SAP kann das von Haus aus... Nur SAP kostet "etwas" mehr als JTL-Wawi um es mal sehr nett zu sagen. Ich glaube jeder der schon mal ein SAP Angebot bekommen hat kann das verstehen.

 

[SaR]

Du musst bei den Zahlungsarten nur das Skonto angeben, sprich "8 Tage 1 %" "14 Tage 3 %" usw.


Wenn du dich etwas mit Excel auskennst oder noch besser, etwas VBA kennst, dann ist die Vorlage schnell erstellt. Musst halt bei den IF-Formeln aufpassen und testen. Aber das ist einfacher als gedacht. Mein Tipp: Mach "Ordner" in den Bereichen und setze diese mittels IF auf aktiv / inaktiv, je nach Logik dahinter. Das ist einfacher als einen Block der sehr unlesbar wird.


Der Rabatt in der Kundenansicht ist genau das, ein Rabatt. Es ist ein % Wert, der immer gezogen wird.

Das Skonto in den Zahlungsarten ist das richtige Skonto. Die Wawi hat hier sogar weitere Funktionen drin, die nicht offensichtlich sind. Wenn ein Kunde x % Skonto bei einem Auftrag hat (gesteuert über Zahlungsart) und du die Zahlung bekommst, kannst du hier den Betrag nach Skontoabzug eingeben. Ist der Betrag richtig wird die Wawi automatisch eine zweite Buchung mit dem Vermerk "Skontobuchung" vornehmen. Das klappt bei uns wunderbar und ja selbst bei einem Cent Unterschied wird das nicht gemacht, also doppelte Überprüfung ob das Skonto stimmt.

Natürlich wäre es toll, wenn man für die B2B Kunden das Skonto einfach mit in die Zahlungen im Kundenstamm hinterlegen kann. Aber JTL ist ja eher auf B2C ausgelegt. Kommt eventuell mal.

Sobald man einmal raus hat wie es geht, ist es einfacher. Klar SAP kann das von Haus aus... Nur SAP kostet "etwas" mehr als JTL-Wawi um es mal sehr nett zu sagen. Ich glaube jeder der schon mal ein SAP Angebot bekommen hat kann das verstehen.

Sorry für die späte Antwort - bin gerade im Spital und daher etwas gehandicapt.

Ja, mit dem Rabatt habe ich mich vertan. Inwieweit sich die Zahlungsziele untereinander auswirken, bin ich gerade am testen. Ansonsten ist es für diese Aufgabenstellung eigentlich egal ob der Kunde nur Offline oder auch Online kauft - bis auf die Anzeige im Shop.

'Problematisch' bleibt für mich weiterhin die Benennung der Zahlungsarten. Bei uns zahlt praktisch jeder Rechnungskunde per Überweisung. Also erstelle ich für jede Zahlungsart ein eigenes Zahlungsziel mit den jeweiligen Konditionen. Einmal z.B. 'bei Erhalt netto zahlbar', dann 'Zahlbar innerhalb 8 Tage netto', Zahlbar innerhalb 8 Tage mit 3% Skonto (oder 14 Tage netto)' usw. Natürlich muss ich die Zahlungsarten entsprechend. Das sieht dann ungefähr so aus: 'Überweisung', ÜW8nt', ÜW3-8' etc. Eine längeres netto-Zahlungsziel für bspw. 'ÜW3-8' wäre somit im Kundenstamm mit zusätzlich 14 Tage netto definiert. Soweit richtig?

So, nun die Ausgabe in Dokumenten, wie Rechnung. Dort erscheint natürlich bei Zahlungsart der eigentliche Name und nicht die Kondition (Beispiel Standardrechnung). Somit z.B. ÜW3-8, wobei hier das netto-ZZ (14T) fehlt. Praktisch kann man das aber so nicht auf einem Dokument ausgeben. Abgesehen davon muss man dem Skontowert noch eine Formatierung für % mitgeben.

Für Dokumente lautet meine Aufgabe nun, Baustein 'Zahlungsart' und Baustein 'Zahlungsziel' beim Personal zu schulen, damit sie, wenn neue Konditionen eingepflegt werden müssen, nicht jedes mal mich dazu brauchen. Und natürlich die Dokumentvorlagen so deppensicher zu gestalten (Abfrageblöcke mit Strings aus Variablen und Textschnippseln), damit möglichst jeder Eventualfall schon im Voraus abgedeckt ist. Wie ich das im Shop abdecke habe ich mir noch gar nicht angesehen. Darfst mir jetzt viel Spaß mit L&L wünschen...

Vielleicht verstehst Du jetzt, warum ich die jetzige Lösung als ein überholtes Erbe aus den Anfängen des WAWI bezeichne. Ist einfach mega-umständlich, sehr fehleranfällig, einarbeitungsintensiv und ausgesprochen rudimentär. Obendrein noch schlecht dokumentiert. Müsste ich all diese 'Kleinigkeiten' dazu noch extern nachbessern lassen, bekomme ich um den Lohn bald schon ein fertig gekauftes System á la BMD etc.... Und komme mir bitte nicht mit SAP - ein sauteures System für Masochisten

Was es meines Erachtens braucht, ist eine Basis-Zahlungsart für alle Kunden, die ich mit einer im Kundenstamm hinterlegten Zahlungsart mit Konditionen überschreiben kann. Dass es aber für JTL wahrscheinlich schwer ist, die alten Code-Blöcke mit all ihren Verzweigungen auf dieses Niveau umzubauen, kann ich mir schon vorstellen. Und deswegen auch keiner Bock hat, das anzugehen.

 

[Manuel Pietzsch]

Hi zusammen,

ich konnte dazu folgende Tickets bei uns finden:

• Kunden individuelle Skonti gewähren (https://issues.jtl-software.de/issues/WAWI-32441)
• Kundenspezifische Zahlungskonditionen (https://issues.jtl-software.de/issues/WAWI-51670)

Gruß

Manuel

 

[Garten-Nutzer]

Sorry für die späte Antwort - bin gerade im Spital und daher etwas gehandicapt.

Dann mal gute Besserung.

'Problematisch' bleibt für mich weiterhin die Benennung der Zahlungsarten. Bei uns zahlt praktisch jeder Rechnungskunde per Überweisung. Also erstelle ich für jede Zahlungsart ein eigenes Zahlungsziel mit den jeweiligen Konditionen. Einmal z.B. 'bei Erhalt netto zahlbar', dann 'Zahlbar innerhalb 8 Tage netto', Zahlbar innerhalb 8 Tage mit 3% Skonto (oder 14 Tage netto)' usw. Natürlich muss ich die Zahlungsarten entsprechend. Das sieht dann ungefähr so aus: 'Überweisung', ÜW8nt', ÜW3-8' etc. Eine längeres netto-Zahlungsziel für bspw. 'ÜW3-8' wäre somit im Kundenstamm mit zusätzlich 14 Tage netto definiert. Soweit richtig?

Das ist kein Problem. Du verwechselt da nämlich was. Das Zahlungsziel beim Kunden ist immer das Netto Zahlungsziel ohne Rabatte. in den Zahlungsarten legst du nur die Skonto Werte an. Dann machst du es einfach:
Du kannst dem Kunden beispielsweise 30 Tage Zahlungsziel im Kundenstamm geben und als "Zahlungsart" nimmst du dann "14 Tage 3%", in welcher, wie der Name vermuten lässt, drinsteht, dass es eine Rechnung sein kann (also Auslieferung vor Zahlungseingang auf ja) und halt 3 % Skonto bei 14 Tagen.

So, nun die Ausgabe in Dokumenten, wie Rechnung. Dort erscheint natürlich bei Zahlungsart der eigentliche Name und nicht die Kondition (Beispiel Standardrechnung). Somit z.B. ÜW3-8, wobei hier das netto-ZZ (14T) fehlt. Praktisch kann man das aber so nicht auf einem Dokument ausgeben. Abgesehen davon muss man dem Skontowert noch eine Formatierung für % mitgeben.

Das kannst du mit den oben genannten Werten erreichen. Die geben dir die dahinter liegende Zahl aus. Der Name ist fix, weil was interessiert mich der Name der Zahlungsart? "14 Tage 3 % Skonto, 30 Tage rein netto" ist als Zahlungsbedingung komplett ausreichend. Natürlich mit Werten ist das noch schöner, aber wie gesagt, wenn man die Vorlagen in JTL bearbeiten kann, kann man das auch.

Für Dokumente lautet meine Aufgabe nun, Baustein 'Zahlungsart' und Baustein 'Zahlungsziel' beim Personal zu schulen, damit sie, wenn neue Konditionen eingepflegt werden müssen, nicht jedes mal mich dazu brauchen. Und natürlich die Dokumentvorlagen so deppensicher zu gestalten (Abfrageblöcke mit Strings aus Variablen und Textschnippseln), damit möglichst jeder Eventualfall schon im Voraus abgedeckt ist. Wie ich das im Shop abdecke habe ich mir noch gar nicht angesehen. Darfst mir jetzt viel Spaß mit L&L wünschen...

Ist einfacher als du denkst, denn du brauchst ja nur die 4 oben stehenden Variablen. Der Rest wird zusammengesetzt.

Vielleicht verstehst Du jetzt, warum ich die jetzige Lösung als ein überholtes Erbe aus den Anfängen des WAWI bezeichne. Ist einfach mega-umständlich, sehr fehleranfällig, einarbeitungsintensiv und ausgesprochen rudimentär. Obendrein noch schlecht dokumentiert. Müsste ich all diese 'Kleinigkeiten' dazu noch extern nachbessern lassen, bekomme ich um den Lohn bald schon ein fertig gekauftes System á la BMD etc.... Und komme mir bitte nicht mit SAP - ein sauteures System für Masochisten

Ich verstehe dich sehr gut, ich sage nur "Rechnungstext (veraltet)". Wir müssen uns halt immer daran erinnern, dass die Wawi komplett kostenlos ist. Wir bezahlen nix. Da darf man auch mal meckern.

Was es meines Erachtens braucht, ist eine Basis-Zahlungsart für alle Kunden, die ich mit einer im Kundenstamm hinterlegten Zahlungsart mit Konditionen überschreiben kann. Dass es aber für JTL wahrscheinlich schwer ist, die alten Code-Blöcke mit all ihren Verzweigungen auf dieses Niveau umzubauen, kann ich mir schon vorstellen. Und deswegen auch keiner Bock hat, das anzugehen.

Diese Logik würde das System komplizierter machen. Diese Logik würde bei dir noch etwas mehr Arbeit bedeuten, denn du kannst " Druckvorlagen"-Sets anlegen. Da kannst du natürlich ein "Basis"-Teil machen und das dem Kunden zuordnen.
Achtung: Die Druckvorlagen-Sets sind nicht modular. Heißt du kannst damit nicht rechnen. Es ist aber für Sachen wie "Zahlbar sofort ohne Abzug" durchaus möglich.
Die Logik kann ja überprüfen ob ein Zahlungsziel hinterlegt ist und wenn ja, die Druckvorlage ignorieren und den Code nutzen.

Wir haben früher auch mit den Druckvorlagen gearbeitet, aber sind jetzt auf das Zahlungsziel + Skonto umgestiegen. Da beides im Kundenstamm hinterlegt ist, ist dies auch in neuen Aufträgen, egal ob Online / Offline kein Problem.