komplexe Berechnungen von abhängigen Datenbankfeldern

[Ferber]

Hi Marabu und Emilio !

Das Problem interessiert mich deshalb, weil ich ähnlichen Themenkreis programmiere.

Habe untersucht was rein und was rausgehen soll, und das tabellarisch dargestellt.

Delphi-Quellcode:

Nur als Quellcode weils da so schön untereinander steht

Rein     : AltEK,  AltBP,  AltLVP,  AltLVPBrutto,  AltMarge,  AltMargeProz,  AltLVPProv,   MwSt,  ProvSatz,  Zuschlag
Raus     : AendEK, AendBP, AendLVP, AendLVPBrutto, AendMarge, AendMargeProz, AendLVPProv
Raus/Rein: NeuEK,  NeuBP,  NeuLVP,  NeuLVPBrutto,  NeuMarge,  NeuMargeProz,  NeuLVPProv

Die Neu...-Varaiblen sollen ja Ein/Ausgabe-Felder werden, was sie ja bisher noch nicht sind,
und dann wird das eigentliche Dilemma erst beginnen, da ja die übrigen Felder aktualisiert werden müssen.

@Emilio: Du wirst um das Objektorientierte und Properties IMHO nicht herumkommen.

Beispielsweise sollten ja alle Neu...-Variablen auf den Wert der Alt-Variablen initialisiert werden.
Beim Verändern einzelner Neu...-Werte mussen unterschiedlichste Berechnungen durchgeführt werden.

Schlimm wirds besonders dann, wenn noch die Änderungsfelder Ein/Ausgabefelder werden sollen.

Na viel Spass

[marabu]

Hallo Otto,

warum willst du ein rein funktionales Problem unbedingt objekt-orientiert angehen? Hast du dir schon überlegt, wie du deinen Beispiel-Code so erweiterst, dass er benutzerdefinierte Zielgrößen berücksichtigt?

Freundliche Grüße vom marabu

[Emilio]

Hi @all,

so funzt es, wenn alles in der UnitMain untergebracht ist:

Delphi-Quellcode:

interface

... 

    procedure DBLookupComboBox1CloseUp(Sender: TObject);                    
    procedure cxTextEdit1KeyPress(Sender: TObject; var Key: Char);
    procedure cxLookupComboBox1PropertiesCloseUp(Sender: TObject);
    function f_bpneu(ekneu: Extended; zuschlag: Extended): Extended;
    function f_ekaender(ekneu: Extended; EKAlt: Extended): Extended;
    function f_bpaender(bpneu: Extended; BPAlt: Extended): Extended;
    function f_lvpneu(ekneu: Extended): Extended;
    function f_lvpaender(lvpneu: Extended; LVPAlt: Extended): Extended;
    function f_bruttolvpneu(lvpneu: Extended; MwSt: Extended): Extended;
    function f_bruttolvpaender(bruttolvpneu: Extended; BruttoLVPAlt: Extended): Extended;
    function f_margeEneu(ekneu: Extended; lvpneu: Extended): Extended;
    function f_margeEaender(margeEneu: Extended; MargeEAlt: Extended): Extended;
    function f_margeprozneu(ekneu: Extended; lvpneu: Extended): Extended;
    function f_margeprozaender(margeEneu: Extended; MargeEAlt: Extended): Extended;
    function f_provlvpneu(bpneu: Extended; lvpneu: Extended; ProvSatz: Extended): Extended;
    function f_provlvpaender(provlvpneu: Extended; ProvLVPAlt: Extended): Extended;

...

implementation

var
  ekneu, zuschlag, bpneu, EKAlt, ekaender, BPAlt, bpaender, lvpneu, LVPAlt, lvpaender, bruttolvpneu,
  MwSt, BruttoLVPAlt, bruttolvpaender, margeEneu, MargeEAlt, margeEaender, margeprozneu,
  margeprozaender, provlvpneu, ProvSatz, provlvpaender, ProvLVPAlt : Extended;

...

function TForm1.f_bpneu(ekneu: Extended; zuschlag: Extended): Extended;
  begin
    Result := ekneu + (ekneu * zuschlag / 100);
  end;

function TForm1.f_ekaender(ekneu: Extended; EKAlt: Extended):Extended;
  begin
    Result := ((ekneu/EKAlt)-1)*100;
  end;

function TForm1.f_bpaender(bpneu:Extended; BPAlt: Extended):Extended;
  begin
    Result := ((bpneu/BPAlt)-1)*100;
  end;

function TForm1.f_lvpneu(ekneu: Extended):Extended;
  begin
    Result := ekneu/55*100;
  end;

function TForm1.f_lvpaender(lvpneu: Extended; LVPAlt: Extended): Extended;
  begin
    Result := lvpneu-LVPAlt;
  end;

function TForm1.f_bruttolvpneu(lvpneu: Extended; MwSt: Extended): Extended;
  begin
    Result := lvpneu + (lvpneu*MwSt/100);
  end;

function TForm1.f_bruttolvpaender(bruttolvpneu: Extended; BruttoLVPAlt: Extended):Extended;
  begin
    Result := ((bruttolvpneu/BruttoLVPAlt)-1)*100;
  end;

function TForm1.f_margeEneu(ekneu: Extended; lvpneu: Extended): Extended;
  begin
    Result := lvpneu-ekneu;
  end;

Function TForm1.f_margeEaender(margeEneu: Extended; MargeEAlt: Extended): Extended;
  begin
    Result := margeEneu-MArgeEAlt;
  end;

Function TForm1.f_margeprozneu(ekneu: Extended; lvpneu: Extended): Extended;
  begin
    Result := (1-(ekneu/lvpneu))*100;
  end;

function TForm1.f_margeprozaender(margeEneu: Extended; MargeEAlt: Extended): Extended;
  begin
    Result :=((margeEneu/MargeEAlt)-1)*100;
  end;

function TForm1.f_provlvpneu(bpneu: Extended; lvpneu: Extended; ProvSatz: Extended): Extended;
  begin
    Result := (lvpneu-bpneu)*ProvSatz/100;
  end;

function TForm1.f_provlvpaender(provlvpneu: Extended; ProvLVPAlt: Extended): Extended;
  begin
    Result := ((provlvpneu/ProvLVPAlt)-1)*100;
  end;



  
procedure TForm1.cxLookupComboBox1PropertiesCloseUp(Sender: TObject);

begin                                                                Beispielwerte
  ekneu := StrToFloat(cxTextEdit1.Text);                             1000,00 
  zuschlag := StrToFloat(cxLookupComboBox1.Text);                    10,00
  bpneu := f_bpneu(ekneu, zuschlag);                                 1100,00
  EKAlt := qrypli.Fieldbyname('EK').AsFloat;                         900,00
  ekaender := f_ekaender(ekneu, EKalt);                              11,11 (%)
  BPAlt := qrypli.Fieldbyname('BP').AsFloat;                         980,00
  bpaender := f_bpaender(bpneu, BPAlt);                              12,24 (%)   
  lvpneu := f_lvpneu(ekneu);                                         1818,18
  LVPAlt := qrypli.Fieldbyname('LVP').AsFloat;                       1600,00
  lvpaender := f_lvpaender(lvpneu, LVPAlt);                          218,18
  MwSt := qrypli.Fieldbyname('MwStSatz').AsFloat;                    16,00
  bruttolvpneu := f_bruttolvpneu(lvpneu, MwSt);                      2109,09 
  BruttoLVPAlt := qrypli.Fieldbyname('BruttoLVP').AsFloat;           1856,00
  bruttolvpaender := f_bruttolvpaender(bruttolvpneu, BruttoLVPAlt);  13,64 (%)
  margeEneu := f_margeEneu(ekneu, lvpneu);                           818,18
  MargeEAlt := qrypli.Fieldbyname('MARGE').AsFloat;                  700,00
  margeEaender := f_margeEaender(margeEneu, MargeEAlt);              118,18  
  margeprozneu := f_margeprozneu(ekneu, lvpneu);                     45,00 (%)
  margeprozaender := f_margeprozaender(margeEneu, MargeEAlt);        16,88 (%) 
  ProvSatz := qrypli.Fieldbyname('PSatz').AsFloat;                   5,00
  provlvpneu := f_provlvpneu(bpneu, lvpneu, ProvSatz);               35,91
  ProvLVPAlt := qrypli.Fieldbyname('ProvLVP').AsFloat;               31,00 
  provlvpaender := f_provlvpaender(provlvpneu, ProvLVPAlt);          15,84 (%)


  cxTextEdit1.Text := Format('%8.2f', [ekneu]);
  cxLabel14.Caption := Format('EUR ' + '%8.2f', [bpneu]);
  cxLabel15.Caption := Format('%4.2f', [ekaender]) + '%';
  cxLabel18.Caption := Format('%4.2f', [bpaender]) + '%';
  cxTextEdit5.Text := Format('EUR ' + '%8.2f', [lvpneu]);
  cxLabel19.Caption := Format('%m', [lvpaender]);
  cxTextEdit4.Text := Format('EUR ' + '%8.2f', [bruttolvpneu]);
  cxLabel24.Caption := Format('%4.2f', [bruttolvpaender]) + '%';
  cxTextEdit2.Text := Format('EUR ' + '%8.2f', [margeEneu]);
  cxLabel25.Caption := Format('%m', [margeEaender]);
  cxTextEdit3.Text := Format('%5.2f', [margeprozneu]) + '%';
  cxLabel26.Caption := Format('%4.2f', [margeprozaender]) + '%';
  cxTextEdit6.Text := Format('EUR ' + '%8.2f', [provlvpneu]);
  cxLabel27.Caption := Format('%4.2f', [provlvpaender]) + '%';

unschön ist noch :
- das Feld cxTextEdit1, in welches der ekneu vom user eingetragen wird, sollte nach dem Eintragen formatiert werden ('EUR' + '%8.2f'); krieg ich aber(noch) nicht hin, da ich diesen Wert ja roh brauche.
- der Wert [ekaender] sollte besser als OnChange- oder OnEditValueChanged-Event(in cxTextEdit1) erscheinen - also aus der Combobox-procedure raus - krieg ich auch noch hin ...

jetzt kommt's:

Wie bereits erwähnt, kann es sein, dass der User mit dem lvpneu nicht einverstanden ist und diesen überschreibt. Dann sollten sich 10 Werte ändern (alle außer (ekneu), (bpneu), (ekaender), [bpaender]). Womöglich will er aber auch eine "fixe" Marge vorgeben und nur einen lvpneu ...

Also ich erkenne die Anforderungen, den Kram aufzusplitten als notwendig an.

Als erstes versuche ich jetzt den Code so umzustricken, dass er dem Beispiel von Marabu folgt und ich erkenne was ich im ersten Anlauf versaubeutelt habe.

Der Saft sei mit mir!

VG
Emilio

[Emilio]

Es funzt!!!

Hi Marabu, hi Ferber,

mit ordentlich Konzentration und reichlich Kaffee habe ich es geschafft, das Beispiel von Marabu richtig zu übersetzen - keine Warnhinweise, keine Fehlermeldungen und alle Eregebnisse da und richtig - freu!

@Marabu,
gehe ich richtig in der Annahme, dass ich für die anderen bereits erwähnten Möglichkeiten (also User hat andere Ausgangswerte als den neuen EK oder will Anpassungen überdie EditFelder vornehmen) weitere CalcRules erstelle oder wäre das zu einfach ...?

@Ferber,
wenngleich Marabu Deinen Vorschlag für 'unangemessen' hält, könntest Du Deinen Weg etwas weiter ausführen?

Schönes Wochenende und vielen herzlichen Dank für Eure Hilfe

VG
Emilio

[thomasw]

sorry, bitte löschen...

[Emilio]

Zitat von thomasw:

sorry, bitte löschen...

Sorry - was löschen ?

[marabu]

Hallo Emilio,

Zitat von Emilio:

gehe ich richtig in der Annahme, dass ich für die anderen bereits erwähnten Möglichkeiten (also User hat andere Ausgangswerte als den neuen EK oder will Anpassungen über die EditFelder vornehmen) weitere CalcRules erstelle?

du brauchst keine neue Berechnungsvorschrift, wenn sich nur die Eingangswerte ändern. Nur wenn deine Funktionen anders verkettet werden ergibt sich daraus auch eine andere Berechnungsvorschrift.

Zur Verdeutlichung ein einfaches Beispiel: Ein Quader hat drei Seiten (a,b, und c) und ein Volumen V. Aus jeweils drei Eingabewerten lässt sich der vierte berechnen. Es ergeben sich vier triviale Rechenvorschriften. Trivial, weil alle Vorschriften nur von Konstanten abhängig sind:

• V = f(a,b,c) = a * b * c
• a = f(V,b,c) = V / (b * c)
• b = f(V,a,c) = V / (a * c)
• c = f(V,a,b) = V / (a * b)

Und was Ottos Vorschlag mit den Objekten angeht, so möchte ich folgendes klarstellen, weil es vielleicht nicht richtig rüber gekommen ist: Ein nicht triviales Kalkulationsmodell besteht aus einer Vielzahl von Berechnungsvorschriften (v) und modell-spezifischen Verkettungen (v1 = f1 nach f2 nach f3; v2 = f4 nach f2 nach f3; etc.). Dieses funktionale Gebilde kommt sehr gut ohne Objekt-Orientierung aus. Ganz anders die dazu passende Benutzerschnittstelle. Mit zunehmender Komplexität des Modells wird da ein OO-Ansatz unentbehrlich. Vielleicht wollte Otto darauf hinweisen und ich habe ihn nicht gleich verstanden. Es täte mir leid.

Freundliche Grüße vom marabu

[Ferber]

Ja, manchmal kann das ziemlich komplex werden.

Nachdem ich das Ganze überschlafen hab dachte ich mir schon,
dass der OO-Ansatz doch ein 'mit Kanonen auf Spatzen schiessen' ist.

Eine grosse Mühsal ist halt die ganze Herumformatiererei.

Ich hab deshalb in meinem Komponentenfundus gekramt, was gefunden, und Überarbeitet.
Dabei hab ich natürlich ersteinmal alles Kaputtgemacht bevor's wieder gelaufen ist,
aber jetzt haben die Edits auch Label (von BDS abgespranzt).
Natürlich bin ich nachher draufgekommen dass ich den falschen Vorfahren erwischt habe,
sollte vielleicht endlich mal zumindest auf D7 umsteigen, aber so funzts wenigstens auch in D5.

Es ist ein Set von EditKomponenten, die weit mehr können als TEdit.
Vor allem gibt's die Eigenschaft 'Value', die direkt zugewiesen werden kann, der Text wird Formatiert.

Ich stell das hier als Open-Source herein, bitte ausprobieren und testen.
Ein Testbeispiel ist auch dabei.

Liebe Grüsse vom 'Ferber'

[Emilio]

@Marabu,

Zitat:

Ganz anders die dazu passende Benutzerschnittstelle. Mit zunehmender Komplexität des Modells wird da ein OO-Ansatz unentbehrlich.

Benutzerschnittstelle - das ist das Stichwort:

Es gibt ingesamt 5 Edit-Felder in die der User Werte eingeben könnte (ekneu, lvpneu, bruttolvpneu, MargeE und Marge%).

Der ekneu kann z.B. über 3 Wege zustande kommen:

- User-Eintrag im ekneu Edit-Feld
- User-Eintrag im lvpneu-Feld und MargeE- oder Marge%-Feld (Berechnung)
- User-Eintrag im bruttolvpneu-Feld und MargeE- oder Marge%-Feld (Berechnung)

der lvp kann z.B. über 5 Wege zustande kommen:
- User-Eintrag im lvpneu Edit-Feld
- User-Eintrag im ekneu-Feld + Auswahl des zuschlag aus der Combobox (Auto-Vorschlag wie in CalcRule01)
- User-Eintrag im bruttolvp-Feld (Berechnung)
- User-Eintrag im ekneu-Feld und MargeE- oder Marge%-Feld (Berechnung)
- User-Eintrag im bruttolvpneu-Feld und MargeE- oder Marge%-Feld (Berechnung)

Die 7 Werte, welche die Änderungen neu gegen Alt ausdrücken (ekaender, xyaender, etc.) werden eigentlich immer dann benötigt, wenn zum passenden Alt-Wert ein neu-Wert eingegeben oder errechnet und angezeigt wird.

Mit den genannten Wegen decke ich jedoch nur die "primär"-Eingabe ab; Nicht erfasst sind Änderungen, die der User nach der Primär-Eingabe vornehmen möchte (z.B. den bruttolvpneu runden/glätten, die Marge prozentual anpassen, etc.).
Das hieße, nach der Ergänzung des Codes für die primär-Eingaben noch 7 onChange-Events mit unterschiedlichen "Calcrules" bauen - oder nicht? Irgendwie werde ich das Gefühl nicht los, dass ich das bisherige Konstrukt zerfleddern muß, um den User-Wünschen gerecht zu werden. Ich grübel weiter.

Falls jemand noch 'n Tipp hat - ich freue mich!

VG
Emilio

[Ferber]

Das Thema ist ja ein richtiger Dauerbrenner -

Zitat von Emilio:

Der ekneu kann z.B. über 3 Wege zustande kommen:

- User-Eintrag im ekneu Edit-Feld
- User-Eintrag im lvpneu-Feld und MargeE- oder Marge%-Feld (Berechnung)
- User-Eintrag im bruttolvpneu-Feld und MargeE- oder Marge%-Feld (Berechnung)

der lvp kann z.B. über 5 Wege zustande kommen:
- User-Eintrag im lvpneu Edit-Feld
- User-Eintrag im ekneu-Feld + Auswahl des zuschlag aus der Combobox (Auto-Vorschlag wie in CalcRule01)
- User-Eintrag im bruttolvp-Feld (Berechnung)
- User-Eintrag im ekneu-Feld und MargeE- oder Marge%-Feld (Berechnung)
- User-Eintrag im bruttolvpneu-Feld und MargeE- oder Marge%-Feld (Berechnung)

Die 7 Werte, welche die Änderungen neu gegen Alt ausdrücken (ekaender, xyaender, etc.) werden eigentlich immer dann benötigt, wenn zum passenden Alt-Wert ein neu-Wert eingegeben oder errechnet und angezeigt wird.

Mit den genannten Wegen decke ich jedoch nur die "primär"-Eingabe ab; Nicht erfasst sind Änderungen, die der User nach der Primär-Eingabe vornehmen möchte (z.B. den bruttolvpneu runden/glätten, die Marge prozentual anpassen, etc.).
Das hieße, nach der Ergänzung des Codes für die primär-Eingaben noch 7 onChange-Events mit unterschiedlichen "Calcrules" bauen - oder nicht? Irgendwie werde ich das Gefühl nicht los, dass ich das bisherige Konstrukt zerfleddern muß, um den User-Wünschen gerecht zu werden. Ich grübel weiter.

Jetzt sieht die Sache schon recht übersichtlich aus !

@Emilio: Stell Dir nun vor, Du müsstest das Ganze nur in 7 Formeln kleiden, die alle anderen Variablen berechnen.
Falls Du auch der Meinung bist, dass das simpel ist, dann schau doch endlich meine Komponenten an !
Das sind quasi Variablen, die Dir den ganzen restlichen Schnickschnack abnehmen.
Nenne diese zB. EKNeu und verwende sie als EKNeu.Value.

Kurzbeschreibung aus den Units herauskopiert:

Delphi-Quellcode:

{ Unit MyEditPrim erweitert das etwas dümmliche TLabeledEdit um Eigenschaften und Ereignisse,
  die in der Praxis des Programmierens IMHO notwendig sind.

  TEditPrim ist Vorfahre für weitere, spezialisiertere EditKomponenten (siehe Unit MyEdit)

  Erweiterungen:

  property Alignment    Ausrichtung des Textes taLeftJustify, taCenter, taRightJustify

  property RedValues    Negative Werte werden rot dargestellt

  property ReturnIsTab  Eingabetaste ist wie Tab

  property OnChange     Änderung des Verhaltens. Wird nur durch Enter, Tab oder Verlassen des
                        Edits ausgelöst, nicht mehr bei jeder Zeichneingabe,
                        und auch dann nur, falls der Wert geändert wurde.
                        Validierung der Eingabe möglich.

  property OnIniData    Wird Aufgerufen um Variablen mit Value belegen zu können.

  property OnDrwData    Wird vor dem Zeichnen aufgerufen und erlaubt Änderungen von Farbe und Font

  Taste ESC stellt den ursprünglichen Wert des Feldes wieder her.
}
{ unit MyEdit leitet vom erweiterten TEditPrim, die spezialisierten Editfelder

  TEditString, TEditInteger, TEditFloat, TEditCurr, TEditProz und TEditDate ab.

  Basisverhalten siehe: Unit MyEditPrim.

  Jedes diese Editfelder hat die zusätzliche Eigenschaft 'Value',
  die dem DatenTyp entspricht.

  Nachkommastellen bei den entsprechend Datentypen sind einstellbar.
  Vorgabe bei Float und Currency: 2, bei Prozent: 0

  Zuweisungen zur Eigenschaft Value lösen das Ereignis OnChange NICHT aus.
  Zuweisungen zur Eigenschaft Text  lösen das Ereignis OnChange nach wie vor aus.

  Zusätzliche Eigenschaft NullValues - wie Excel Nullwerte anzeigen, Vorgabe false.

  Zusätzliches Ereignis OnInitData ermöglicht das initialisieren von Variablen.

  Validierung kann im Ereignis OnChange durchgeführt werden.

  TEditPrim wurde in separate Unit extrahiert, um die Übersichtlichkeit zu erhöhen.

  Die Erweiterung um weitere Datentypen ist in Unit MyEdit sehr einfach.
}

Edit: Die Komponenten gibts hier: EditKomponenten für die Praxis

Mit freundlichen Grüssen, Otto.