Ankündigung

Einklappen
Keine Ankündigung bisher.

Berechnungen speichern und anwenden

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Berechnungen speichern und anwenden

    Hallo

    Ich kämpfe etwas mit Positionen und Abrechnungen.
    Das Problem ist, dass es viele Möglichkeiten gibt, aber keine feste Struktur.
    Der Benutzer kann Items selbst definieren. Das sieht dann so aus, dass er eine Menge angeben kann, dazu einen Faktor, welcher bei der Anwendung dann aus der Ressource genommen wird, einen Preis, Konten und eine Fälligkeit.
    Zum Beispiel 1.25 x Personen pro Tag x 10.99 von Konto Kunde zu Konto Betreiber mit Fälligkeit "bis Start".
    Das Item ist nur eine Art Vorlage, welche angewendet wird.

    Wird eine Ressource erzeugt, wird das Item angewendet und daraus ergibt sich dann 1.25 x (5 Personen x 3 Tage = 15) x 10.99 = 206,06 vom Kunden an den Betreiber zu bezahlen, bis zum Beginn.

    Wenn eine Ressource erstellt wird, prüfe ich ob in der Tabelle angewendete Item Vorlagen die Vorlage vorhanden ist, ansonsten erstelle ich die Vorlage und speichere nicht die ID der originalen Vorlage sondern der "Kopie". Sollte irgendwann die Vorlage geändert werden, so kann die Ressource dennoch mit den damaligen Einstellungen neu berechnet werden. Zudem kann man nachvollziehen, wie es damals zu der Berechnung kam.

    Soweit ist das alles kein Problem. Jetzt kommen aber die komplexeren Teile.
    Items können (ein Level) Sub-Childs haben. Hat ein Item Unterelemente, werde diese berechnet und als Preis für Item genutzt.

    Auf der einen Seite kann es vorkommen, dass von einem Item etwas aufgeteilt werden muss.
    Zum Beispiel Eintritt:
    Kunde zahlt (Menge) 1x (Faktor) 2 Erwachsene pro Tag x (Preis) 50.00 von Konto Kunde an Konto Betreiber mit Fälligkeit bis Einlass.
    Der Kunde hat über eine Plattform gebucht. Diese bekommt, sobald der Kunde vor Ort bezahlt hat, einen Anteil.
    In dem Ticket ist auch eine Spezialshow enthalten, wofür ein Partner eine Provision bekommt.

    Rechnung könnte also sein für 4 Erwachsene:
    2x (Eintritt) 50.00 - (Plattformprovision) 10% - (Partnerprovision) = Einnahmen
    Oder
    2x 50.00 - 10% = Plattformprovision von Konto Betreiber an Konto Plattform, wenn der Gast bezahlt hat
    2x 50.00 - 5% = Partnerprovision von Konto Betreiber an Konto Partner, wenn der Gast bezahlt hat.
    Oder aber auch:
    2x 50.00 x 0.03 = Transaktionsgebühr von Konto Betreiber an Konto Betreiber, wenn Zahlungsmethode Transaktionsgebühr hat.
    2x 50.00 - Transaktionsgebühr x 0.05 = Partnerprovision

    Also was in welcher Reihenfolge berechnet wird ist undefiniert und auch ob Prozente oder Preise. Provision könnte auch ein fester Preis pro Erwachsener sein.


    Und dann gibt es noch etwas Gegenteiliges, bei dem die Items genutzt werden um den Endpreis zu berechnen, wobei der Endpreis nicht von einem Konto bezahlt wird sondern einzelne Posten aus unterschiedlichen Konten bezahlt werden und manche Items erst fällig werden, wenn ein vorheriges Item bezahlt wurde oder wenn die Widerrufsfrist abgelaufen ist.

    Was das ganze noch etwas komplexer macht, sind die unterschiedlichen Steuersätze.
    Aktuell wird eine Software genutzt, in der es ein paar vordefinierte Felder gibt, welche die Summe enthalten. Berechnungen müssen von den Benutzern mit dem Taschenrechner selbst gemacht werden und sind häufig falsch, da jede Show (um bei meinem Beispiel zu bleiben) andere Preise für Eintritt, Snacks, Drinks etc. hat. Bei manchen Shows sind die Drinks inklusive, bei anderen zahlt der Partner die Snacks usw.
    Wenn man ein Angebot verschickt, stehen dort auch nur Endpreise (was ok ist). Ein anderer Benutzer versteht aber nicht, wie es zu diesem Endpreis für die Snacks gekommen ist.
    Die Abrechnungen zu erstellen ist sehr Zeitaufwändig und voller Fehler, da sich auch immer wieder etwas an einer Show ändert und mit jedem Partner andere Konditionen vereinbart sind. Der eine bekommt Provision auf die Einnahmen, der andere bekommt Festpreis pro Besucher und wieder ein anderer bekommt Prozente nach Abzug von Plattform und Transaktionsgebühren.
    Hinzu kommt dann noch eine überbuchte Show, wo der Kunde eine andere Show angeboten bekommt, obwohl die Zahlungen und Provisionen schon für die andere Show verbucht wurden usw.

    Es macht keinen Sinn eine Dienstleistung/Position fest zu definieren. Abgesehen von ein paar wenigen Dienstleistungen wie Eintritt und vielleicht Snacks, können sich alle anderen Angebote ändern, eingestellt werden oder es kommen neue hinzu. Das ist auch der Grund, warum die aktuelle Tabelle für die Ressource über 150 Felder hat und alle paar Wochen weiter wächst. Vor einem Jahr hat es mit 15 Feldern angefangen.
    Und dann kommt noch hinzu, dass bei manchen Shows in bestimmten Räumen keine Snacks erlaubt sind oder bei anderen keine alkoholischen Getränke usw.

    Hatte noch nie einen soll komplexen Fall, bei dem ich Tage benötige um die Struktur aufzubauen und am Ende jedes mal feststelle, dass es so doch keine saubere Lösung ist.
    Spätestens wenn es dann darum geht, eine benutzerfreundliche Darstellung zu entwerfen, die auch einfach verständlich ist, merke ich, dass es wieder zu komplex erstellt wurde und die Benutzer zu viele Fragen haben werden.
    Der Unterschied zwischen dem richtigen Wort und dem beinahe richtigen ist derselbe Unterschied wie zwischen dem Blitz und einem Glühwürmchen.

  • #2
    Eine schöne Geschichte... ist die Moral, das absolute Freiheit und Flexibilität ins Chaos führt?

    Ich weiß nicht, wie ich es anders beschreiben sollte. Es gibt keine Regeln, keine festen Definitionen, alles ist erlaubt - wundert mich nicht, das es zu kompliziert und zu fehleranfällig wird.
    Wenn sich die Benutzer alles selber ausdenken dürfen, aber dabei keinen Regeln unterliegen, führt das zwangsläufig zu Inkonsistenz. Die Welt funktioniert auch nicht so...
    Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

    Kommentar


    • #3
      Um hier eine vernünftige Lösung zu finden braucht man sicherlich theoretisches Wissen, erstens über die Preismodelle und deren Verknüpfungsmöglichkeiten und dann darüber, wie man deren Anwendung sinnvoll programmiert. Ich kann mir nicht vorstellen - und du merkst es ja selbst -, dass man sich das in ein paar Tagen alles allein ausdenken kann.

      Ich habe mal diesen Text kurz angelesen, der sich mit Preismodellen befasst. Da findest Du sicherlich einige Deiner Probleme wieder:

      https://subs.emis.de/LNI/Proceedings...nElekPordk.pdf

      Hier geht es zwar um die "Modellierung von Preisinformationen in elektronischen
      Produktkatalogen". Die Grundlagen sind aber auch für Dein Projekt anwendbar.

      Textbeispiel:
      2.4 Zu- und Abschläge
      Zu- und Abschläge sind ein mächtiges Instrumentarium, um Preisdifferenzierung zu be-
      treiben. Analog dazu ist die Komplexität der notwendigen Preismodelle zu sehen: sie
      reicht von einfachen Multiplikationsfaktoren bis hin zu äußerst komplexen Beziehungen.
      [AllowOrCharge]
      Die Berechnung von Zu- und Abschlägen erfolgt auf einer Basis [BaseType], die identi-
      fiziert, wie die Zu- oder Abschläge in die Preisberechnung einfließen. Es lassen sich fünf
      verschiedene Verfahren unterscheiden, die jeweils sowohl Preisminderungen als auch
      Preiserhöhungen realisieren:
      - Relativ, Prozent: der Zu-/Abschlag wird über einen Faktor mit dem zuvor er-
      mittelten Preis multipliziert (z.B. 10% Rabatt pro Produkt). [PercentageFactor]
      - Relativ, Betrag: der Zu-/Abschlag wird mit einem Fixwert auf den zuvor ermittelten
      Preis addiert (z.B. 10 € Versandpauschale). [MonetaryAmount]
      - Absolut: der zuvor ermittelte Preis wird durch den Zu-/Abschlag ersetzt. Dies kann
      auch unter Berücksichtigung von Regeln erfolgen. Besonders häufig sind Min-
      /Max-Regeln, also z.B. ist der niedrigere Betrag des zuvor ermittelten Preises und
      des Zu-/Abschlags zu verwenden. [MonetaryAmount]
      - Natural: die Anzahl der gelieferten Produkte differiert kostenneutral von der Anzahl
      der bestellten Produkte (z.B. Naturalrabatte). [Quantity]
      Es kommt also darauf an, wie hoch man die Sache aufhängen will oder muss..
      Gibt es ein theoretisches Konzept bei denen, die die Preismodelle für die Veranstaltungen entwickeln? Dann gibt es sicher auch Konzepte für die Arbeit damit. Vermutlich auch schon fertige Lösungen.

      Die Bereitstellung eines Baukastens für die Entwicklung von Preismodellen, die man dann beliebig einsetzen kann, ist vermutlich Stoff für eine Dissertation.

      Ich würde empfehlen zunächst mal eine klar strukturierte Aufgabenstellung zu entwickeln, bevor man überhaupt eine Zeile programmiert.

      Kommentar


      • #4
        Zitat von SteiniKeule Beitrag anzeigen
        Ich kämpfe etwas mit Positionen und Abrechnungen.
        Das Problem ist, dass es viele Möglichkeiten gibt, aber keine feste Struktur.
        Ich kenne das Problem. In meinem Fall waren es fantasievolle Marketingabteilungen, die immer wildere Konstrukte zu Rabattierung, Kombinatorik, Kundenbewertung, Kundengewinnung, .. erdacht haben. Immer mit dem gleichen Ziel ...
        An irgendeinem Punkt muss man das grundlegend anpacken und auch dem Kunden vermitteln, egal ob hausintern oder extern. Dabei ist es natürlich nicht unerheblich, ob man freie Hand hat oder mit Abrechnungskomponenten arbeitet, die nicht oder begrenzt zu beeinflussen sind.
        Ich kann nur allgemein zu den vielen Punkten 2 3 Sachen sagen:
        Ein Kunde, der selbst "basteln" kann, muss schon dort die Möglichkeit haben, Endpreise anhand von Beispieldaten nachzuvollziehen. Es muss also auf Basis des Preismodells, exemplarischen Bestell- Kunden- und Produktdaten ein endgültiges Angebot erstellbar sein. Kurz, es muss einen deterministischen Weg der Preisberechnung geben und es muss zu jedem Zeitpunkt klar sein, welcher das ist. (Auch wenn es später neue, andere, "bessere" (weil günstiger oder so) geben kann.) Formal ist die Antwort also einfach. Es muss eine Formel geben und es müssen alle Parameter der Formel immer bekannt und nachvollziehbar sein.
        Das hat Konsequenzen für die Modellierung. Eine nicht unbedingt offensichtliche wäre z.B. die Denormalisierung bestimmter Angaben oder sagen wir netter, die Historisierung. Dies kann einzelne Parameter betreffen, die Formel selbst natürlich, bis hin zu Kundenratings, falls die Formel einbezogen werden (und z.B. durch geplatzte Zahlungen oder Altkundenbonus, Großkundenbonus, .. variieren)
        Außerdem ist es relativ unpraktikabel, fortwährende Änderungen an der Rabattierung durch immer neue Modelländerungen zu ermöglichen. Kleine Missverständnisse in der Semantik von Modelländerungen führen ungewollten oder unmöglichen Berechnungsgrundlagen.. 100(e) Spalten für optionale Parameter, die mal horizontal mal vertikal in Aggregationen zum Einsatz kommen, machen dann selbst simple Formeln u.U. schwer nachvollziehbar.
        Notausgang: Es muss minimal modelliert werden, dass jeder (Einzel-)Fall jenseits der vorgesehenen Formeln durch Sachbearbeiter im Verhandlungsweg (Kulanz, Fehllieferung, geänderte Zahlungsmodalitäten, ..) eindeutig und dauerhaft gelöst werden kann.
        Ein konkreter Modellierungsansatz ist bei hinreichend absehbarer Komplexität vielleicht die Nutzung flexibler Modellvarianten. Konkret wäre das die Persistierung von Formel, Parametern und Basisdaten (Historisierung) mittels JSON, KV Modell oder sogar XML inkl. Validierungsschema.
        Ob man sich das antun will, ist eine Frage von Kosten/Nutzen.
        Zu solchen dynamischen Verfahren gehört dann sicher nicht nur die Implementierung des Verfahrens selbst, sondern auch die transparenter Beispielrechnung (Stichprobe) und am Ende auch systematische Tests.

        Kommentar

        Lädt...
        X