Office: (Office 2000) Verknüpfungen für Rechnungserstellung

Hallo,
ich möchte in Access 2000 eine Rechnung erstellen (ich verfüge auch über Access 2010, kenne mich hier aber nicht so aus).

In Access 2000 habe ich folgende Tabellen erstellt:
Bestellung (autokey: BestellNr)
Artikel (autokey:ArtikelNr)
verknüpft über Bestelldetails (Zahl, key, BestellNr + ArtikelNr)

Bis hierhin klappt alles gut.

Nun kommt meine nächste Tabelle:
Rechnung (autokey: Re-Nr)

Die bisherigen Bestelldaten sollen hier mit verknüpft werden. Füge ich allerdings zur Tabelle Rechnung das Feld BestellNr klappt das nicht. Verknüpfe ich die Tabelle Rechnung mit einer Abfrage Bestellung, klappt das auch nicht.

Kann mit bitte Jemand helfen. Vielen Dank dafür.

:)

 

Hi und willkommen im Forum,

ich vermute Du möchtest aus einer Bestellung nun eine Rechnung erzeugen, richtig?
Sind diese tatsächlich getrennt voneinander bzw. welche weiteren Informationen benötigst Du bei den Rechnungen?

Wenn Rechnungen eine eigene Entität sind, muss die Bestellnummer als Fremdschlüsselfeld in die Tabelle aufgenommen werden.
Vmtl. wird das dann eine 1:1 Beziehung, da es ja zu einer Bestellung vmtl. nur genau eine Rechnung geben kann/wird, oder?
Mahnungen, etc. aussen vor; die müssten dann ggf. separat erfasst werden.

 

Teilrechnungen?
Sammelrechnungen?

Glaube hier müssten mehr Infos her, wie aus Bestellungen Rechnungen werden (können und sollen).

 

Also der einfachste Weg ist, bei den Bestelldetails ein Feld für die Rechnungs ID vorzusehen (logischerweise gibt es auch andere Wege).

Rechnungen sind eigenen Entitäten und stehen in diesen Fall 1:N zu den Bestelldetails.
Die Tabelle Rechnungen sollte zumindest Rechnungsnummer, Kundennummer, Datum, Betrag usw. enthalten.

Bei der Bestellungstabelle fehlen dann natürlich auch noch Daten wie zumindestens
Kunde und Datum, ansonsten macht die Tabelle keinen Sinn.

LG Markus

 

Du hast Recht, ich möchte aus der Bestellung eine Rechnung erzeugen.
Dabei muß folgendes berücksichtigt werden:
1. Die Rechnung kann sich auf die gesamte Bestellung beziehen.
2. Es kann auch sein, daß eine 1. Rechnung nur bestimmte Positionen der Bestellung berechnet, später dann mit der 2. Rechnung der Rest der Bestellung berechnet wird.

Die Tabelle Rechnung hat eine eigene Entität, d.h. Autowert = ReNr

Wenn ich in der Rechnung ein Feld BestellNr einbaue, dann muß ich ja - um im frmRechnungen auch Artikel und Artikelpreise aus den Bestelldetails zu erhalten hier ein Verknüpfung herstellen. Die Verknüpfung zw. Rechnung + Bestellung klappt. Aber verknüpfe ich zusätzlich Bestellung + Bestelldetails + Artikel geht nichts mehr.

 

Rechnungsnummer ist in den Bestelldetails:
Eine Rechnung enthält alle Daten einer Bestellung.
Eine Rechnung enthält nur einen Teil einer Bestellung.
Eine Rechnung enthält Daten aus mehreren ganzen oder mehreren teilen von Bestellungen.

Bestellnummer ist in den Rechnungen:
Ein Rechnung enthält alle Daten einer Bestellung.

Du musst jetzt entscheiden, was du willst.
Beides geht mit unterschiedlichen Möglichkeiten wie oben angeführt.
Aber entweder oder.
LGM

 

Ich habe nun folgendes probiert:
tblRechnungen mit autokey ReNr + Long integer BestellNr verknüpft mit
tblBestellungen (BestellNr zu BestellNr)
das klappt

aber nun benötige ich ja noch die Artikel und Preise

Also habe ich die o.g. Verknüpfung der Tabellen erweitert um
tblBestelldetails (Long integer,key für BestellNr + ArtikelNr) und
tblArtikel (autokey ArtikelNr)

das klappt nicht

was mache ich falsch ?

 

Wenn sich eine Rechnung immer auf die Bestelldetails (die Positionen) einer Bestellung bezieht, muss dies in den Relationen berücksichtigt werden.

Sprich nur die Beziehung Rechnung-Bestellung reicht nicht; es muss noch eine weitere Beziehung zwischen RechnungZuBestellung-Bestellpositionen etabliert werden.

 

Zeig dein Beziehungsfenster.
LGM

 

Natürlich reicht eine Beziehung zw. Rechnung und Bestellung.
Aber es schränkt die Möglichkeiten ein, so wie ich es #6 angeführt habe,
das wäre nun nicht gerade praxistauglich.

Rechnung ->Bestellung ->Bestelldetails
oder
Rechnung -> Bestelldetails.

Das ist der einzigen Unterschied. oder siehst du das anders?
LGM

 

Du hast Recht... es sollte der Bezug zu den Bestelldetails reichen; über diese kommt man ggf. auch auf die Bestellnummer an sich.

 

Ich habe 2 Abfragen gebaut:

1. qryRE1= tblKunden (autokey KundenNr + Felder Kunde, Strasse, Plz, Ort) + tbl Rechnungen (autokey ReNummer, Long integer KundenNr + Felder Datum, BestellNr, ReEmpänger, Abteilung, Strasse, Plz, Ort) - Beziehung über KundenNr

2. qryRE2 = tblRechnungsdetails (Long integer key ReNummer + long integer key BestellNr + Felder ArtikelNr, Einzelpreis, Anzahl) +
tblArtikel (autokey ArtikeNr + Felder Artikel, Richtpreis -
Beziehung über ArtikelNr

Hauptformular = qryRE1, Unterformular = qryRE2
Im Formular wird zwar alles richtig angezeigt, aber ich kann keinen Datensatz hinzufügen.

Für den Rechnungsdruck habe ich eine neue Abfrage gebaut aus qryRE1 + qryRE2 = qryRechnungen100.

Auf Basis von qryRechnungen100 habe ich den reportRechnungen100 gebaut. Hier werden mir sämtliche Bestellungen angezeigt, d.h. nicht für die einzelne Rechnung die jeweiligen Bestellungen.

Was mache ich denn nur falsch. Ich verstehe es nicht. Danke für Deine Geduld.
LG Michael

 

Hallo Michael,
du bist zu schnell unterwegs.
in #6 habe ich eine Frage gestellt.
Bitte um Beantwortung, welches Modell du möchtest.


LGM

 

Ich würde da mit Rekursion rangehen. Die Bestelltabelle Journal taufen und Journalarten zuordnen (Angebot, Bestellung, Versand, Rechnung, Zahlungseingang, Mahnung, ...) zuordnen. In den Journaldetails kann man jederzeit Journaldetails von Vorgänger des Journals ermitteln (falls sie denn schon existieren). Das spart jede Menge Tabellen und Kopfzerbrechen. Spezielle, nur auf eine Journalart zutreffende Attribute ließen sich über 1:1 Tabellen verknüpfen.

 

tblRechnung sollte enthalten
RechnungNr
Kundennr,ReEmfpänger
Datum
UID
Nettosumme

?Steuern
?Fälligkeitsdatum

Abteilung, Strasse, Plz, Ort gehören eher nicht in die Rechnung. die beschreiben entweder Empfänger oder Kunden.
Das hat dann mit der Bestellung zu tun.

LGM