Preise ändern ohne alte Preise zu löschen!

Computer: Software & Programmierung Microsoft Access
#1

Hallo zusammen!

Ich erstelle gerade eine Datenbank für ein Transportunternehmen.
Access 2007.
Ich hab eine Tabelle angelegt in der die verschiedenen Positionen sprich Arbeiten und der dazugehörige Preis gespeichert werden. Diese werden dann per kombifeld ausgewählt und so der Rechnung hinzugefügt. Funktioniert problemlos.
Mein Problem ist jetzt, das dieses Unternehmen jedes Jahr neue Preise vorgeschrieben bekommt. Das heißt, am Jahresbeginn, müsste der Benutzer die jeweiligen Preise ändern können, ohne das die anderen Rechnungen verändert werden.
Soweit ich weiß, kann man irgendwie die Datenbank per Abfrage archivieren, so das weiter nach alten Rechnungen gesucht werden kann, aber die Datensätze von der Preisänderung nicht betroffen sind.

Kann mir bitte jemand beschreiben wie das funktioniert?
Danke euch
LG Andreas

#2

Vom Datum abhängig machen

Preise vorgeschrieben bekommt. Das heißt, am Jahresbeginn,
müsste der Benutzer die jeweiligen Preise ändern können, ohne
das die anderen Rechnungen verändert werden.

Eben nicht ändern, sondern nur entweder mit Alt-Preis „gültig bis“ oder (sicherer) mit Neu-Preis „gültig ab“ arbeiten.

Gruß

Stefan

#3

Moin, Andreas,

Soweit ich weiß, kann man irgendwie die Datenbank per Abfrage
archivieren

jein. Natürlich gibt es die sogenannte Aktualisierungsabfrage, die hilft hier aber nicht weiter.

Die einzige saubere Lösung ist eine Änderung der Datenstruktur: Preise zusammen mit dem Gültigkeitszeitraum ablegen, aus dem Rechnungssatz auf den Ident der Preistabelle verweisen.

**Artikel** (<u>ArtikelNr</u>, Bezeichnung, ...)
**Preis** (<u>PreisId</u>, FS\_ArtikelNr, Betrag, Gültig\_von, Gültig\_bis, ...)
**Rechnungsposten** (<u>RechnungspostenId</u>, FS\_Preis\_Id, ...)

Gruß Ralf

#4

Also sehe ich das richtig das ich eine eigene Tabelle für den Preis anlegen muss mit PreisID, Betrag, gültig bis. Muss ich das dann per VBA programmieren, wann welcher Preis der richtige ist? So ganz versteh ich das nicht.
Ich beschreibe mal meinen bisherigen Aufbau!

tblRechnungen
*RechnungsNr
-KundenID
-Rechnungsdatum

tblRechnungsdetails
*RechnungsdetailID
-RechnungsNr (Fremdschlüssel tblRechnungen)
-Datum
-Baustelle
-PositionID (Fremdschlüssel tblPositionen)
-Anzahl

tblPositionen
*PositionID
-Bezeichnung
-Einheit
-Preis

Jetzt soll ich eine weitere Tabelle mit dem Preis einfügen, mit einer Beziehung auf tblPositionen?

#5

Hi Andy,

Muss ich das dann per VBA programmieren, wann welcher
Preis der richtige ist?

der gute Datenbanker bietet dem Sachbearbeiter nur die Preise zur Auswahl an, die zur Zeit der Bepreisung gültig sind. Also per Dropdown passende Preise bereitstellen.

Jetzt soll ich eine weitere Tabelle mit dem Preis einfügen,
mit einer Beziehung auf tblPositionen?

Genau, wobei anstatt Preis in tblPositionen der Key der Preistabelle als FS eingetragen wird.

Abgesehen davon: Ich kenne Rechnung nur als Rechnung > Rechnungsposition. Wozu dient die Zwischenstufe Rechnungsdetails?

Zweite Frage zum Verständnis (vielleicht die wichtigere): Welches Objekt hat überhaupt einen Preis? Mir geht sowas wie die Artikelnummer ab.

Gruß Ralf

#6

Abgesehen davon: Ich kenne Rechnung nur als Rechnung
> Rechnungsposition. Wozu dient die Zwischenstufe
Rechnungsdetails?

Ich habe es so gelöst. Einmal eine Tabelle die die Rechnungsnummer den Kunden und das Rechnungsdatum enthält.
Dann eine Detail Tabelle in der man die verschiedenen Positionen per Dropdown einfügen kann. Diese Positionen habe ich wiederum in eine eigene Tabelle gespeichert. Ich habe es deswegen so gemacht, weil es für mich in weiterer Folge leichter macht den Benutzer alte Rechnungen wieder aufzurufen. Ich habe so eine Maske die für alle Arbeiten bzw. Positionen gleich ist.

Zweite Frage zum Verständnis (vielleicht die wichtigere):
Welches Objekt hat überhaupt einen Preis? Mir geht sowas wie
die Artikelnummer ab.

Dieses Unternehmen bietet verschiedene Güter an. Der Schotter zum Beispiel kann einmal pro Tonne aber einmal auch pro m³ verrechnet werden. Es kann aber auch der Fall sein, das das Unternehmen nur den Stundensatz für den LKW verrechnet. Mir scheint das es der Benutzer so einfacher hat einfach seine Güter und Dienstleistungen in eine Tabelle einzugeben, und dann einfach nur per Dropdown auszuwählen. Die Einheit bzw der Preis werden dadurch automatisch aufgerufen und in die Rechnung eingefügt.

Meine Frage:
Wenn ich das richtig verstehe muss ich dann über den Nachschlageassistent einstellen, das mir Preise dessen Gültigkeit abgelaufen ist nicht mehr in der Liste angezeigt werden?

#7

Hi Andy,

Wenn ich das richtig verstehe muss ich dann über den
Nachschlageassistent einstellen, das mir Preise dessen
Gültigkeit abgelaufen ist nicht mehr in der Liste angezeigt
werden?

den Nachschlageassistenten kenne ich leider nicht, mein Office ist schon ein wenig älter. Aber wenn das angeboten wird - klar.

Gruß Ralf

ps: Was Du als Position bezeichnest, heißt üblicherweise Leistungsverzeichnis, und die Details zur rechnung heißen oft Rechnungsoosition. Ist aber nur Brauch, keine Vorschrift.

#8

Ich werd mich dann mal dransetzen und probieren was ich umsetzen kann. Ich dank dir schon mal für deine Hilfe Ralf.
LG Andy

#9

Hallo,

wenn mit der Applikation Rechnungen erfasst werden sollen, dann solltest Du bedenken, dass hierfür jede Menge gesetzliche Bestimmungen gelten, die in der Anwendung umgesetzt sein müssen. Und Rechnungen nachträglich aus Positionsdaten eines Artikel-/Leistungsstamms zusammenzubauen, ist da keine gute Idee. Die tatsächlich in der Rechung stehenden Positionen müssen im Zeitpunkt der Erstellung aus den Stammdaten in die Rechnung kopiert werden, damit nachträgliche Stammdatenänderungen nicht zu Änderungen der Rechnung führen. Da normalerweise in einer Rechnung individuelle Abweichungen von Stammdaten möglich sind, reicht es nicht aus, dort einfach Gültigkeitsdaten zu vereinbaren. D.h. der einmalige Sonderpreis für den guten Kumpel, der Hinweis auf eine Verrechnung, die für x-Baustellen geltenden abweichenden Lieferadressen, … stehen ja nicht in den Stammdaten.

Und wenn die Rechnungspositionen aus den Stammdaten kopiert werden, gibt es hinterher auch keine Probleme die komplette Rechnung unabhängig von einer inzwischen geänderten Adresse des Kunden oder angepasster Preise wieder im Original auf den Bildschirm zu bekommen.

Gruß vom Wiz