MySQL Rechnungsverwaltung

dragonfight86

Mitglied
Hallo zusammen,
ich bräuchte bitte ein paar erfahrene Stimmen.

Ziel:
eine Programm mit dem ich alte Rechnungen einlesen und in einer DB speichern kann und zukünftig über das Programm auch neu erstellen kann.

Problem:
ich bin mir nicht sicher inwieweit meine entworfene DB sicher stellt das Kunden verschiedene Preise zahlen für die selbe Leistung sowie die gespeicherten Daten nicht durch neuere Daten überschrieben werden.

Also Beispiel Kunde 1 zahl pro Reinigung 25€ Kunde 2 zahlt 24,22€--> das habe ich versucht über einen Rabatt zu lösen

Code:
create database rechnungsverwaltung;
use rechnungsverwaltung;

create table Kunde (
KundenNummer integer primary key auto_increment,
Firma varchar(155),
Anrede varchar(20),
Vorname varchar(100),
Nachname varchar(100),
Strasse varchar(155),
Hausnummer varchar(10),
PLZ varchar(6),
Ort varchar(100),
Land varchar(100),
Rabatt float(2));

create table Preis(
PreisNummer integer primary key auto_increment,
Betrag float(2));

create table Leistung(
LeistungsNummer integer primary key auto_increment,
Bezeichnung varchar(255),
LeistungPreisNr integer,
foreign key (LeistungPreisNr)references Preis(PreisNummer));

create table Artikel(
ArtikelNummer integer primary key auto_increment,
Bezeichnung varchar(255),
ArtikelPreisNr integer,
foreign key(ArtikelPreisNr) references Preis(PreisNummer));

create table Rechnung(
RechnungsNummer integer primary key auto_increment,
Datum date,
Zahlungsziel date,
Netto float(2),
MehrwertsteuerSatz integer,
MwSt float(2),
Brutto float(2));

create table Rechnungsposition(
RechnungspositionsNummer integer auto_increment primary key,
Anzahl float(2),
Bezugsgröße float(2),
Satz float(2),
Betrag float(2),
Beschreibung varchar(255),

RPArtikelNummer integer,
foreign key(RPArtikelNummer) references Artikel(ArtikelNummer),

RPLeistungsNummer integer,
foreign key(RPLeistungsNummer) references Leistung(LeistungsNummer),

RPRechnung integer,
foreign key (RPRechnung) references Rechnung(RechnungsNummer));
 

Anhänge

  • SQL Script.pdf
    114,7 KB · Aufrufe: 3
  • Relationales Datenmodell.pdf
    196 KB · Aufrufe: 13

Tobse

Top Contributor
ich bin mir nicht sicher inwieweit meine entworfene DB sicher stellt das Kunden verschiedene Preise zahlen für die selbe Leistung
Das kann die Datenbank auch nicht sicherstellen. Dein Schema erlaubt es (da du ja je Rechnung und Rechnunsposition den Betrag einzeln speicherst); sicherstellen muss das die Software, die die Datensätz schreibt.
 

Dukel

Top Contributor
Warum zahlen die Kunden unterschiedliche Preise? Das muss ja einen Grund haben.
Gibt es hierfür Anforderungen an das Programm?

Geht es bei deinem Beispiel um eingelesene Rechnungen oder neue Rechnungen?
 

stg

Top Contributor
Kleiner Tipp am Rande: Beträge solltest du nicht in Euro sondern in Cent speichern (und nicht als Dezimalzahl sondern Ganzzahl)

Je nach Context eventuell sogar als "Zehntel-Cents" oder "Hundertstel-Cents" oder ...usw...

In deinem Fall kann das bereits interessant werden, wenn du Rabatte auf Einzelposten statt auf die gesamte Rechnung gewähren willst.
 

dragonfight86

Mitglied
Warum zahlen die Kunden unterschiedliche Preise? Das muss ja einen Grund haben.
Gibt es hierfür Anforderungen an das Programm?

Geht es bei deinem Beispiel um eingelesene Rechnungen oder neue Rechnungen?
Ja die gibt es.
Das Programm ist für eine Reinigungsfirma wo es je nach Wohnungsgröße, Aufwand und Kundenart (Bestands- oder Neukunde) unterschiedliche Preise gibt.
Es gibt also Kunden die z.B. pro Stunde zahlen oder Pauschal pro Monat oder pauschal pro Reinigung.

Sowohl als auch, die Rechnungen der letzten 5 Jahre sollen importiert werden und künftig werden auch Rechnungen geschrieben und gespeichert werden.

Ich habe diesbezüglich noch keine Erfahrungen sammeln können und Programmiere auch erst seid 6 Monaten aktiv.

Kleiner Tipp am Rande: Beträge solltest du nicht in Euro sondern in Cent speichern (und nicht als Dezimalzahl sondern Ganzzahl)
Okay werde ich umsetzen, danke für den Tipp. Das dient einer genaueren Berechnung später nehme ich an?

Das kann die Datenbank auch nicht sicherstellen. Dein Schema erlaubt es (da du ja je Rechnung und Rechnunsposition den Betrag einzeln speicherst); sicherstellen muss das die Software, die die Datensätz schreibt.

Okay,also vom Prinzip der Datenbank sollte ich später keine Probleme bekommen?

Und vielen Dank für eure Antworten
 

Dukel

Top Contributor
Du machst unterschiedliche Rechnungspositionen.
- Pauschal
- Größe
- Dauer

und rechnest dann z.B. für Kunde 1
- 1x Pauschal (25 €) = 25€
Für Kunde 2
- 2x Std (12€) = 24€
Für Kunde 3
- 60x Größe (pro qm 1€) = 60€

Zusätzlich kannst du noch einen Rabatt einbauen.
Für vorhandene Rechnungen muss dies aber auf den Rechnungen ersichtlich sein, was dort die Rechnungsgrundlage ist. Das hat ja dann auch rechtliche Gründe.
 

AndiE

Top Contributor
Ich würde ganz altbacken erst mal eine Use-Story schreiben. "Die Reinigungsfirma hat Kunden. Diese können Bestands- oder Neukunden sein, und sie haben mit der Firma verschiedene Bezahlungsmodelle ausgehandelt. Das kann z.B. Pauschalbetrag je Monat, Pauschalbetrag je Reinigung oder Zahlung nach gereinigter Fläche sein. Für jeden Kunden wird entsprechend der erbrachten Leistung und des vereinbarten Bezahlungsmodells eine Rechnung erstellt, die der Kunde bezahlen muss." Aus dieser Use-Story heraus würde ich die Datenbank so ändern, dass Kundenstatus und Bezahlungsmodell stärker sichtbar sind. Übrigens würde ich erstmal ohne Datenbank, sondern nur per OOP anfangen. Das hat den Vorteil, dass du dich nicht bei JDBC in den "insert" und "update"-Statements festbeißt, sondern die Sache erstmal zum Laufen bringen kannst. Dann kannst du da immer noch ORM unterziehen. Ich hätte bei deinem Schema auch bei den null-Zuständen im Mehrfachfremdschlüssel so meine Bauschschmerzen, aber das mag ja so funktionieren.
 

Dukel

Top Contributor
Ich würde mich nach sechs Monaten Erfahrung nicht gleich an ein Rechnungsprogramm wagen. Sowas wird schnell sehr komplex, teilweise gibt es Gesetzliche Anforderungen ...
 

Thallius

Top Contributor
Bedenke auch, dass Du in deiner Datenbank Personendaten verwaltest. Damit hast du ganz besondere Datenschutz Auflagen. Es ist nicht alles so einfach wie es aussieht. Nicht umsonst bekommen Profis für sowas richtig viel Geld...
 

Kababär

Top Contributor
Bedenke auch, dass Du in deiner Datenbank Personendaten verwaltest. Damit hast du ganz besondere Datenschutz Auflagen. Es ist nicht alles so einfach wie es aussieht. Nicht umsonst bekommen Profis für sowas richtig viel Geld...
Je nach Einsatzort der Software braucht man auch Lizensen, die sehr teuer sein können .. bspw. im Krankenhaus.
 

AndiE

Top Contributor
Das denke ich, ist ziemlich egal, siehe BDSG. Ich würde mich da nicht in die Nesseln setzen. Löse das doch einfach mit Kundennummern. Diese sind anonym, und keiner kann damit direkt feststellen, wer wie oft eine Leistung benutzt hat. Die Klaradresse brauchst du nur zur Rechnungslegung, und dann lässt die sich auch per Copy and Past einfügen. Wichtig ist natürlich, dass Kundennummern nicht folgerichtig sein sollen. Es geht niemanden was an, ob er der 1.2. oder x. Kunde ist. Besser ist z.B: 10000+13*17*x= Kundennummer. Bis 99999 kannst du dann ca. 400 Kunden verwalten. 10000, 10221, usw.
 

Meniskusschaden

Top Contributor
Na ja, von den nächsten 1000 anstehenden ToDos in dieser Sache würde ich mich mit dem Problem ungefähr an Stelle 1012 beschäftigen.;) Ich würde mir da eher Sorgen machen, ob eine Individual-Programmierung für so eine kleine Firma wirklich die angemessene Lösung ist.
 

dragonfight86

Mitglied
Da ich im Rahmen meiner Umschulung ehe ein Projekt machen muss habe ich was sinnvolles gewählt. Das passt schon und hat auch noch Zeit....ich ahnte nicht das es ein derartig umfangreiches Projekt wird.
 

Meniskusschaden

Top Contributor
Ich wollte damit nur sagen, dass meines Erachtens das Thema Datenschutz in diesem Thread zu hoch gehängt wird. Kann durchaus sein, dass das ein gutes Ausbildungsprojekt wäre. Als Chef einer kleinen Reinigungsfirma würde ich es zwar nicht in Auftrag geben, aber darum geht es dann ja auch nicht.
 

AndiE

Top Contributor
Ich würde den Ball flach halten. Um die Funktion der Anwendung hinzubekommen, würde ich einfach anfangen. In doppelter Hinsicht. Mit den "einfachen Dingen", wie der GUI und dann schrittweise verbessern. Leider, muss ich sagen, hängt man in der Umschulung den Datenbankpart sehr hoch, bei uns hat man MS-Produkte dafür genutzt. Dummerweise hat das aber selten mit Programmierung zu tun, aber "Datenschutz" ist auch Teil der Ausbildung. Es ist einfach leichter, weniger Felder zu behandeln, und man vermeidet durch Kundennummern auch die Gefahr, dass durch Knacken der Datenbank persönliche Daten abgerufen werden können- da ja gar keine gespeichert sind. Es nutzt ja dem Angreifer wenig, zu erfahren, dass Nr. X bestimmte Leistungen bezogen hat, wenn der nicht weiß, wer X ist. Am besten du schließt dich dazu mit deinem Ausbilder kurz, ansonsten würde ich dir gleich TDD empfehlen. Leider hatten wir das selbst nicht in der Ausbildung, ich habe mich im Nachhinein damit beschäftigt und finde es aber toll.
 

Meniskusschaden

Top Contributor
Besser ist z.B: 10000+13*17*x= Kundennummer. Bis 99999 kannst du dann ca. 400 Kunden verwalten. 10000, 10221, usw.
Einen 100000er-Nummernkreis für nur 400 Kunden verbraten?:confused:
und man vermeidet durch Kundennummern auch die Gefahr, dass durch Knacken der Datenbank persönliche Daten abgerufen werden können- da ja gar keine gespeichert sind.
Man lässt sich also eine Software so programmieren, dass man Daten, die man braucht, lieber nicht speichern kann, damit ein potentieller Angreifer sie auch nicht bekommt? Hört sich nicht so attraktiv an. Ich würde mal schätzen, dass das ungefähr 0% der Firmen so machen.
Die Klaradresse brauchst du nur zur Rechnungslegung, und dann lässt die sich auch per Copy and Past einfügen.
Und von wo kopiert man die? Aus /null/dev weil das einbruchsicher ist? Bleibt wohl nur der Karteikasten. Danach druckt man die Rechnung also aus - mailen geht ja nicht - und speichert sie wieder ohne Adresse? Glaube nicht, dass das GoBD-konform ist. Viel Spaß bei der nächsten Außenprüfung vom Finanzamt. Im Gegensatz zum Datenschutzbeauftragten taucht das nämlich auch bei einer kleinen Reinigungsfirma früher oder später wirklich auf.;)
 

AndiE

Top Contributor
Ich weiß auch nicht, wie man sich das nach BDSG vorstellt. am einfachsten wäre es ja, mit zwei Datenbanken zu arbeiten. Immerhin sind ja verschiedene Rollen beteiligt, das eine ist der "Rechnungsverwalter" und das andere der "Rechnungsersteller".. Die Abspeicherung von Leistungen kann ja unter der Kundennummer erfolgen. Auch die Auswertung kann darüber gemacht werden. Nun kann diese Rechnungsverwaltung auch eine Datei ausspucken, die in einer zweiten Anwendung daraus den Brief erstellt, und dabei auf die zweite Datenbank mit den persönlichen Daten zugreift. Dann sind die Zugriffe darauf durch Rollen getrennt. Beide arbeiten jeweils mit einer eigenen Datenbank. Die Daten kann man mit XML oder so zwischen den Anwendungen übergeben. Klar kann man auch elektronisch eine Tourenliste erstellen, wo die Aufträge des Tages drin sind. Die erhält dann zwar die Adresse, aber man kann daraus keine Daten schöpfen. Das ist zwar nicht schön oder elegant, aber vielleicht der Situation angemessen.
 

JStein52

Top Contributor
am einfachsten wäre es ja, mit zwei Datenbanken zu arbeiten. Immerhin sind ja verschiedene Rollen beteiligt, das eine ist der "Rechnungsverwalter" und das andere der "Rechnungsersteller"..
Wenn du persönliche Daten speicherst ist das ziemlich wurscht ob du die in einer "Datei"/"Datenbank" speicherst oder in mehreren. Und deine zwei Rollen sind im Zweifelsfall jeweils der Inhaber der Reinigungsfirma und ein Bezug der Daten untereinander ist herstellbar. Und beim Datenschutz geht es ausserdem nicht darum diese gegen Hacker gesichert aufzubewahren (das wäre Datensicherheit und hat mit Themen wie Verschlüsselung usw. zu tun) sondern es geht darum dass man personenbezogene Daten nur nach festgelegten Richtlinien erheben und speichern darf. Eine Einführung ist hier: https://de.wikipedia.org/wiki/Bundesdatenschutzgesetz
 

JStein52

Top Contributor
Um das Thema noch ein bisschen weiter zu spinnen:
- man kann auch mit Excel (nur als Beispiel) personenbezogene Daten erfassen und speichern. Wird jetzt der Excel-Entwickler gehängt oder der Chef der Reinigungsfirma der dies macht ? Oder wird gar keiner gehängt weil der Chef in seinen allgemeinen Geschäftsbedingungen drin stehen hat dass man mit der Speicherung seiner erfassten Daten zum Zecke der Rechnungserstellung (oder was auch immer) einverstanden ist ? Wir alle klicken das an wenn wir irgendwo was bestellen. Wisst ihr was ihr zugestimmt habt als ihr euch für dieses Forum registriert habt ?
 

dragonfight86

Mitglied
Also das sind viele interessante Ansätze, ich denke nicht das das speichern von Kundendaten das große Problem ist. Ich denke wenn man die Datenbank verschlüsselt hat man seinen Teil zur Sicherheit getan denn der PC ist in einem abgeschlossenem Raum, nicht über ein Netzwerk erreichbar, PW geschützt und dann die DB verschlüsselt.
 

Thallius

Top Contributor
Also das sind viele interessante Ansätze, ich denke nicht das das speichern von Kundendaten das große Problem ist. Ich denke wenn man die Datenbank verschlüsselt hat man seinen Teil zur Sicherheit getan denn der PC ist in einem abgeschlossenem Raum, nicht über ein Netzwerk erreichbar, PW geschützt und dann die DB verschlüsselt.

Dummerweise ist es ziemlich schwierig in einer verschlüsselten Datenbank Teilstrings zu suchen. Also Autovervollständigung oder Suchen mit Wildcard ist nahezu unmöglich.
 

Dukel

Top Contributor
Ich glaube das ganze mit anonymen und verschlüsselten Daten wegen der Kundendaten ist übertrieben. Andere Warenwirtschaftsprogramme oder CRM Software speichern Kundendaten auch unverschlüsselt.

Aber um das gesetzlich korrekt zu machen braucht man Infos. Diese bekommt man bei seinem Rechtsbeistand seiner Wahl.
 

JuKu

Top Contributor
Ich glaube das ganze mit anonymen und verschlüsselten Daten wegen der Kundendaten ist übertrieben. Andere Warenwirtschaftsprogramme oder CRM Software speichern Kundendaten auch unverschlüsselt.

Sehe ich genauso!
Außerdem erlaubt das Gesetz diese Datenspeicherung und schreibt sie sogar vor!
Dem Finanzamt muss man jeden Kunden vorlegen können, die mögen gar keine anonymen Daten.

Ich finde in diesem Thread wird einfach übertrieben. Wir sollten uns lieber auf das technische fokusieren.
Es ist kein Problem, eine solche Anwendung zu erstellen und sie ist auch nicht "komplex".
Am besten arbeitest du aber nicht mit einem ORM, das macht die Anwendung nur 1. lahm und 2. alles für deinen Use Case komplizierter.
Stattdessen mit PreparedStatements arbeiten.
 

JuKu

Top Contributor
Übrigens benötigst du folgende Tabellen, um flexibel zu sein:
- Kunden
- Rechnungen
- Rechnungsposten
- Leistungen (= Artikel)
 

Neue Themen


Oben