Neu Eigene Übersicht im Kundenstammblatt für durchschnittlichen Auftragswert/Röherlös/Zahlungsdauer

[Mapamann]

Hallo,

hat jemand zufällig schon eine Eigene Übersicht für so etwas gebastelt?
Ich hätte im Kundenstammblatt gern eine Übersicht, wie hoch der durchschnittliche Auftragswert, der Röherlös bzw. Gewinn sowie die Dauer der Zahlung dargestellt wird. Nach Möglichkeit noch bezogen auf Monat/Quartal/Jahr.

__________________________letzer Monat____aktuelles Quartal____letztes Quartal____aktuelles Jahr____letztes Jahr
Auftragswert ________________ xxxxx €

Gewinn_______________________xx %

Zahlungsdauer__________________xx Tage

wäre so etwas umsetzbar?

Hab mal noch paar Unterstriche eingesetzt, sonst passt die Formatierung nicht so ganz.

 

[frankell]

Hallo @Mapamann,

wenn Du SQL beherrschst, kannst Du relativ viel umsetzen, und Du wirst wahrscheinlich auch hier im Forum zumindest in die Nähe gehende Code-Schnipsel finden, anhand derer ne erste Grundlage geschafft ist.

Aber gleich vorweg: SQL-Abfragen sind nicht dazu gedacht, Matrix-Ausgaben zu produzieren, also eine Tabelle, wo auch die Zeilen unterschiedliche Bedeutungen haben können. Der Standard ist in Deinem Fall, dass alles zu einem Bezugsobjekt (hier der Kunde) in einer einzigen Reihe geschrieben wird, also mit den Spalten:
- letzter Monat Auftragswert
- letzter Monat Gewinn
- letzter Monat Zahlungsdauer
usw.

Das ist auch kein SQL-Hexenwerk, aber doch so, dass ich es hier nicht kostenlos posten würde.

Wenn Du Interesse daran hast, kannst Du mir gerne ein PM schreiben. Oder es findet sich wer anderes, der das hier postet.

 

[John]

Hexenwerk ist es nicht aber bereits wenn auch Stornos mit einfließen sollen, wird es schon aufwändig.

Zahlungsdauer in SQL? Mit Anzahlung, Teilzahlung? Viel Spaß...

Es gibt schon Gründe, wieso es die interne Statistik der Wawi "nicht bringt" und JTL Power-BI machen möchte.

 

[frankell]

Zahlungsdauer in SQL? Mit Anzahlung, Teilzahlung?

Ja, es gibt diverse Dinge zu beachten. Aber manche davon (wie gehe ich mit Stornos um, wie mit nicht-vollständigen Zahlungen) sind eher statistischer Natur und damit kaum eine Frage der Technik, sondern einfach der Entscheidung, was wie in die Statistik mit einfließt oder eben nicht. Je nachdem, wie komplex das Ergebnis dieser Entscheidung ist, wird es dann natürlich wieder (sehr) technisch. Wenn man aber bei den genannten Beispielen sagt, wir berücksichtigen Stornos und nicht-vollständige Zahlungen erst gar nicht, dann ist das einfach umzusetzen. Da idR nicht Leben und Tod von so einer Statistik abhängen, sondern sie nur einen groben Überblick bzw. eine Tendenz zeigen soll, reicht auch eine einfache Vorgehensweise.
Es ist das alte Dilemma der passenden Balance von Aufwand und Ertrag.