Mitgliederverwaltung - Hilfe bei der Erstellung sauberen Codes

ErfinderDesRades schrieb:

Neues Konzept: Aufschläge jeder Art sind besondere Artikel, und werden beim Einkauf als Extra-Einkauf-Positionen zugefügt.
So wie im Supermarkt der FlaschenPfand eine Extra-Position auffm Bon ist.

D.h.
Es gibt den Artikel Angelmarke DAV Erwachsen 1 Jahr - 73 Euro
und den Artikel Verzug - 5 Euro
Ich muss ja aber trotzdem (beim Artikel) irgendwo speichern, ab wann der Verzug hinzukommt).
Also wenn der Verein nächstes Jahr sagt, der Verzug entfällt, oder wird fällig bereits ab dem 01.03. muss das ja änderbar sein.
Wie stelle ich das mit deiner Version an? Würdest du dann auch eine Datumsspalte machen?

ErfinderDesRades schrieb:

Eben wie mittm FlaschenPfand: Der Kassierer tippt nur das Bier ein, und die Logik packt den richtigen Pfand dazu auffn Bon.

Hmm, so hatte ich das mit meinem DataSet Vorschlag vor.

DerSmurf schrieb:

Eine AllowNull Spalte "Verzugsdatum" - um zu speichern ab wann Verzug fällig ist. Mit IsMarke.VerzugsdatumNull kann ich abfragen ob überhaupt Verzug anfällt.
Decimal Spalte Verzugsgebühren - um zu speichern wie hoch der Verzug ist

Ich prüfe die Spalte auf IstNull, wenn sie null ist gibts kein Verzug (kein Pfand).
Wenn ein Datum drin steht, wird geprüft, ob das in der Zukunft, oder Vergangenheit liegt und der Wert aus der Row Verzugsgebühren hinzugefügt, oder eben nicht. Das kann ich ja mithilfe der Logik als eigene Position anzeigen.
Für die Abrechnung speichere ich ja "Verzug" (boolean) in der Table Einkaufsposition (wobei ich hier ja dann auch eine Row für die Höhe der Verzugsgebühren einfügen sollte.

Ich kann also mit meiner DBNull Row drei Werte speichern (kein Verzug, kein Verzug wegen rechtzeitig gekauft, und Verzug.

Warum funktioniert das nicht / Warum ist das schlecht?

Ja, OK. Mir leuchtet ein, dass

ErfinderDesRades schrieb:

Also die Relationen ergeben mir Sinn, aber so einige der Spalten:
EinkaufPosition muss die Spalten haben: ID, MarkeID, EinkaufID, Anzahl - nicht mehr oder weniger.

Eine Einkaufsposition nur über Relationen verfügen sollte. Alle weiteren zu speichernden Felder sollten sich dann in den entsprechenden Tables befinden, aber nicht in der Einnkaufsposition.
string Markennummer sollte eine Vereinfachung sein. (Erklärung am Ende des Posts)
Aber ich Liste mal auf, was ich überhaupt speichern möchte, damit wir eine Lösung für die Marke DataTable finden (welche dann im übrigen wohl doch in Artikel umbenannt werden sollte - weil sie ja nicht nur Marken speichert).

Ich teile die Marken mal in drei Gruppen - jede Gruppe hat eigene "Spezialanforderungen"
Gruppe1 Fischereiabgabemarken

• Fischereiabgabe Erwachsen 1 Jahr - 12 Euro
• Fischereiabgabe Erwachsen 5 Jahre - 40 Euro
• Fischereiabgabe Jugen (bis 18) - 2,50€
• Ausweis zum einkleben der Marken - 0 Euro (hier passen mehr als 1 Marke rein, beim Markenkauf also nicht erforderlich, wenn Kunde bereits einen hat)

hier gibt es keinerlei Besonderheiten

Gruppe 2 DAV Marken

• DAV Erwachsen - 73 Euro
• DAV Jugend - 20 Euro
• Asuweis zum einkleben der Marke - 1 Euro (wie oben nicht immer erforderlich)

Besonderheit 1: ab dem 01.04. zahlt jeder Markenkäufer 5 Euro on Top (Verzug)
Besonderheit 2: neue Mitglieder (im letzten Jahr keine Marke gekauft) zahlen 5 Euro on Top (unabhängig vom Kaufdatum) (Neuanmeldung)
Besonderheit 3: Es wird nur einmal 5 Euro Zuschlag fällig, Ein Neumitglied zahlt also NICHT Neuanmeldung + Verzug
Besonderheit 2.1: vom Neumitglied muss eine Datenschutzerklärung unterschrieben werden, hier muss das Programm dran erinnern.

Gruppe 3 Sachsen Anhalt und Mecklenburg

• Mecklenburg Karte - 10,50 Euro
• Sachsen Anhalt Karte - 10,50 Euro

Besonderheit 1: alle Marken sind mit einer eindeutigen Nummer versehen, welche beim Verkauf gespeichert werden muss.
Also ich muss wissen, dass Karl Heinz Sachsen Anhalt Karte Nummer 2021095 gekauft hat.
Hierfür war Einkaufsposition.Markennummer gedacht.
Besonderheit 2: Beide Marken dürfen nur ausgegeben werden, wenn der Kunde einen Fischereischein hat.
(Person.Fischereischeinnummer). Fischereischeine verkaufe ich nicht. Also wenn der Kunde keinen hat, gibts diese Marke nicht.

Für Gruppe 1 ist alles klar - da gibts ja nix weiter zu beachten.
Für Gruppe 2 ergeben sich dann die Artikel

• Erwachsenen Marken
• Jugend Marke
• Ausweis
• Verzug
• Neuanmeldung

Die Posten Verzug und Neuanmeldung müssten dann von der BusinessLogic hinzugefügt werden, wenn die entsprechenden Bedingungen erfült sind.
Im groben ist mir klar, wie das funktionieren soll. Also wenn ich eine Marke verkauft rattert meine Logik die alten Käufe der Person durch.
Gibt es keinen im letzten Jahr, isser neu.
Ebenso beim Verzug. Wenn beim Verkauf DatumVonHeute > Verzugsdatum, muss er Verzug bezahlen.
Aber wie stelle ich es an, dass die BusinessLogik das eben nur bei DAV Marken macht und eben nicht bei Fischereiabgabemarken?
Hier brauche ich doch dann noch extra boolean Spalten - Verzug und Neuanmeldung, oder nicht?
Und wie halt ich das ganze dynamisch? Wenn ich in 3 Jahren DAV Marken für zwei Vereine verkaufe und Verein 1 nimmt 5 Euro Verzug, Verein 2 nimmt 3 Euro Verzug und keine Aufnahmegebühr?

In Gruppe 3 ist eben das Problem, dass jede Karte eine eigene Nummer hat. Also eigentlich ist damit jede Karte ein eigener Artikel.
Aber das wäre ja mega lästig, wenn ich jede Karte aufgrund ihrer individuellen Nummer als eigene Artikel Position einpflegen müsste.
(Deswegen die Row in Einkaufsposition).

Und noch am Rande zur Anzahl:
Eine Anzahl würde ich gänzlich ignorieren, denn diese ist immer 1.
Zwar kann Gustav für sich selbst 2 Fischereiabgabemarken kaufen. Aber das macht keinen Sinn.
Denn was er dieses Jahr bei mir kaufen kann, ist eine Marke die für 2021 (1 Jahr), oder für die Jahre 2021 bis 2025 (5 Jahre) gültig ist.
Kauft er zwei mal die Jahresmarke, darf er damit auch nur in 2021 angeln, nicht in 2021 und 2022.
In der Regel will Gustav, wenn er 2 gleiche Marken kauft, eine für sich und eine für seine Frau.
Dann muss ich ja aber speichern, dass Gustav eine kauft und Sieglinde kauft eine.
Denn es sind immer die Adressdaten des Anglers zu speichern (nicht des Käufers)

Find ich gut.
Aber reicht das, oder brauche ich eine Tabelle besonderheit?
Denn im Falle von Besonderheit = 1 - also DAV, muss ich ja in der BL hinterlegen was zu tun ist und könnte das nicht dynamisch ändern.
Oder kann ich das wohl?

Edit: Also im Moment sind keine Änderungen geplant, aber es wäre schön, wenn ich nicht in den code muss, wenn Verein 2 über mich seine Marken mit anderen Bedingungen verkauft.


und wo ist die nummer der SA und MV Marken zu speichern?

Im DataSet habe ich die Table Einkaufsposition entsprechend geändert.
Außerdem eine Table Artikelbesonderheit hinzugefügt, diese verweist auf die Artikeltable.
Aber ich verstehe das Konzept dahinter nicht.
Also ich verstehe, dass ich mit meinem Dts jetzt für jeden Artikel beliebig viele Besonderheiten speichern kann.
(So wie ich für jede Person beliebige viele Einkäufe mit beliebig vielen Einkaufspositionen speichern kann.)
Aber mir ist nicht klar, wie ich jetzt in der Ausführung des Programmes einpflege, dass eben ab dem 01.04. bei DAV Marken 5 Euro dazu kommen.
Kannst du mir sagen, ob das Dts so korrekt ist?

Außerdem wäre es schön, wenn das hier gegen ist:

DerSmurf schrieb:

Edit: Also im Moment sind keine Änderungen geplant, aber es wäre schön, wenn ich nicht in den code muss, wenn Verein 2 über mich seine Marken mit anderen Bedingungen verkauft.

Aber wenn ich die BEsonderheit codiere und die Programmlogik weiß was zu tun ist, ist dies ja nur im Code änderbar.
Wenn also der Verzug nächstes Jahr statt 5 Euro, 7 Euro kostet, müsste ich das in meiner BL ändern. Kommt der Verzug erst ab 01.05. zum tragen, muss ich in den Code.
Wäre es nicht denkbar eine unverknüpfte DataTable zu erstellen, aus der die BL dann ausliest was zu tun ist?
Also z.B. mit dem Rows ID, Code, Name, Datum, Kosten.
Dann könnte meine BL den enstprechenden "Besonderheit Code" in dieser Table suchen. So wären ein eventuelles Datum, oder eben die Kosten dieser Besonderheit einstellbar.
Außerdem könnte es dann einen Verzug1 und einen Verzug2 geben. Ggf. mit einem anderem Datum, oder anderen Kosten.

ErfinderDesRades schrieb:

Und die MarkenNummern müssen in eine weitere Tabelle MarkenNr, mit FK auf EinkaufPosition.

Warum eine neue Table, mit nur einer Row? Und nicht direkt in die Einkaufsposition?
Es kann ja eh nur eine Markennummer pro Einkaufsposition geben.

ErfinderDesRades schrieb:

wie wärs mit einer Einverständniserklärung für personalisierte Werbung?

Ginge übrigens problemlos. Da aber eh nur jeder zehnte liest, was er da unterschreibt, kann ich auch direkt meine Bankverbindung, mit entsprechender Kostenaufstellung unterschreiben lassen.

Das DataSet habe ich soweit bearbeitet.

Aber das hier verstehe ich nicht:

ErfinderDesRades schrieb:

Und die MarkenNummern müssen in eine weitere Tabelle MarkenNr, mit FK auf EinkaufPosition.

Es gitb ja pro Einkaufsposition maximal eine Markennummer.
Warum dann in eine separate Tabelle mit FK auf die Einkaufsposition und nicht einfach direkt als Row in die Einkaufsposition? Wenns keine Nummer gibt, lass ich halt leer.

Edit: Artikel.BesonderheitCode hat als DefalutValue die 0
Edit2: Die Tabelle Besonderheit habe ich ein Einstellungen umbenannt. Hier kann ich ja noch andere Dinge wie z.B. DGV Spaltenbreiten und Gedöns speichern.

Das heißt, es ist unschön, wenn ich eine Row habe, in der in 95% der Fälle nichts steht.
Mit der extra Tabelle erzeuge ich nur einen Eintrag, wenn es auch einen gibt.
Das leuchtet mir ein.

Dann mache ich mich jetzt mal an ein bisschen Code und melde mich, wenns ich mit den Einstellungen (Artikel hinzufügen, Lieferanten hinzufügen, usw.) fertig bin.

Hey Leute. Ich scheitere irgendwie gerade an den Einstellungen.
Ich möchte in den Settings die "eigenenDaten" änderbar machen.
Also dtsAngelmarken.eigeneDaten

Dazu prüfe ich beim Start des Programmes erst einmal, ob es überhaupt eine entsprechende Row gibt und lege ggf. eine an.

Dann habe ich auf meiner Form drei gebundene Textboxen für die DataTable (Firmenname, Straße, Ort) und einen speichern Button mit folgendem Code:

Wenn ich aber eine Änderung an einer der drei Rows vornehme, und speichern klicke, habe ich beim nächsten Start, wieder die alten Werte.
Wenn ich das ganze Schrittweise durch gehe, sieht alles gut aus. Wo ist hier mein Denkfehler?

Nein, leider nicht.
Die xml ist eingebunden (wobei das doch egal sein müsste, die Datei wird ja beim verlassen des Programmes geschrieben.)
Es funktioniert aber auch das hinzufügen / ändern von Personen.
Also wenn ich hier Personen hinzufüge, oder bearbeite, sind diese beim nächsten Programmstart noch da. Das speichern ansich funktioniert also.
Ich glaube auch nicht, dass mein Code fehlerhaft ist.
Kann es sein, dass dieses Verhalten (also das nicht speichern), durch die Helpers von @ErfinderDesRades hervorgerufen werden?
Also dass ich evtl. mehr machen muss, als nur die Row in der Bindingsource zu ändern?