Hallo zusammen,
ich habe ein Formular [Rechnung] und eine Tabelle [Zahlungen]
in die Tabelle[Zahlungen] pflege ich die Datensätze aus dem Formular[Rechnung]
Beziehung: [Rechnung]1----n[RechnungsID]
Tabelle Besteht aus:
RechnungsID: Zahl (ist gleich mit RechNr aus dem Formular[Rechnung])
ZahlArt: Kurzer Text
ZahlWert: Währung
ZahlDatum: Datum/Uhrzeit
Unter ZahlArt kommen die Werte aus einem Kombinationsfeld aus einem anderen Formular durch Auswählen. Z.B. Bar, Überweisung oder Inzahlung
wenn ich eine neue Rechnung im Formular erstelle gebe ich den Zahlart in einem kleinen Formular.
Manchmal muss ich für eine Rechnung mehrere Zahlarten eingeben. Z.B. Bar: 100.-€, Überweisung: 200.-€ und Inzahlung: 1000.-€ und klicke ich auf dem "Speichern" Button zum das Ganze zu speichern in die Tabelle [Zahlung].
Ich möchte: Wenn für die aktuelle Rechnung einen Zahlart als "Inzahlung" gegeben wurde, nach Klicken auf [Speichern] Button sollte mir ein anderes Formular[Verkäufer] zum Speichern öffnen.
Die Datensätze aus der Tabelle habe ich in einer Abfrage per SQL Befehl rausfiltern können:
SELECT Zahlung.RechnungsID, Zahlung.ZahlArt
FROM Zahlung
WHERE (((Zahlung.RechnungsID)=[Formulare]![Rechnung]![RechNr]));
aber weiter kann ich nicht.
Kann bitte jemand weiter helfen um Abfragen ob "Inzahlung" in der gefilterten Datensätzen existiert, wenn ja dann docmd.openForm...usw
Vielen Dank,
Zorlayan
Hallo,
Du brauchst auch für die Zahlungen eine extra Tabelle, denn es gibt ja mehrere Zahlungen zu einer Rechnung.
Mir scheint, da gibt es Strukturprobleme.
Kannst Du bitte mal ein Bild des Beziehungsfensters hier zeigen?
Anmerkung:
Zitat von: undefinedZahlArt: Kurzer Text
Wenn die Zahlart aus einer Tabelle kommt, so ist die Zahlart über deren Primärschlüssel zu speichern. Das Feld muss demzufolge eine Zahl (Longinteger) sein und nicht "Kurzer Text".
Hallo,
die Tabelle ist vorhanden, mein Fehler, habe ausversehen anstelle RechnungsID, ZahlArt getippt. :)
die Beziehung wird über RechnungsID 1:n aufgebaut.
Hier ist das Bild in PDF Format.Beziehungen.pdf
Hallo,
die Beziehungen können so nicht funktionieren. KunID kann doch nicht die RechNr sein. Auch die 1:1 Beziehung kann nicht stimmen. Ein Kunde kann doch mehr als eine Rechnung haben und damit unterschiedliche RechNr. Das gleiche gilt sinngemäß auch für die Tabelle Auto, die AutoID kann doch keine Beziehung zur RechNr haben. Auch hier ist die 1:1 Beziehung sinnlos.
Was ist denn überhaupt der Unterschied der "Auto" Tabelle zur Tabelle "EKAutos" ?
Auch die Tabelle Zahlung ist suspekt. Ist die RechnungsID wirklich auch die RechNr ? Gemäß Beziehungen sind die gleich.
Die Felder "KunLand" und "VerLand" können ersatzlos gelöscht werden (mit den Beziehungen). Liegt der Ort fest, liegt automatisch auch das Land fest. Das gleiche gilt sinngemäß auch für die Marke, kann auch gelöscht werden, da das Modell immer auch automatisch auf die Marke verweist. Die Felder für den PSWert sind auch überflüssig. Die Leistungen von Autos werden in KW angegeben. Falls man die PS anzeigen will, lassen die sich leicht errechnen (Faktor 1,36)
Was soll eigentlich die Mehrwertsteuer beim Land ?
Was sind die Felder RechErkl1 bis 5 , was steht da drin ?
PS:
Bitte lade Bilder direkt als png/jpg hoch, PDF braucht man da nicht. Die Bilder kann man dirkt anzeigen.
Danke für all die Vorschläge aber die Datenbank dient Hauptsächlich zum Rechnung schreiben, bis jetzt funktioniert auch tadellos, wir haben am Anfang so besprochen für jedes Auto, eine Rechnung also die Beziehung Rechnung und Auto 1:1 ist ok. KundenNummer könnte man auch 1:N machen aber aktuell reicht uns dieses Modell.
Ich wollte einige Änderungen/Neuerungen zur bestehenden Datenbank machen daher brauche ich euren Rat zum Rausfiltern wie in meinem ersten Schreiben.
Ab September werde ich die Datenbank neu Designen und auch entsprechend Codieren solange ich es kann wenn ihr auch mitmachen möchtet gerne mit euch mit.Aber jetzt brauche ich die Lösung meiner Frage.
Vielen Dank für die Bemühungen.
VG
Zorlayan
Hallo,
Zitat von: undefinedKundenNummer könnte man auch 1:N machen aber aktuell reicht uns dieses Modell.
sorry, aber das ist doch Krampf. Du kannst Doch nicht die KunID als Rechnungsnummer verwenden. Wenn der gleiche Kunde noch mal ein Auto kauft, wird das die gleiche Rechnungsnummer, das darf doch nicht sein. Das passt doch hinten und vorn nicht.
Die Tabelle für das Auto ist auch ersatzlos überflüssig, Du hast doch schon eine Autotabelle (EKAutos).
Die ganzen Probleme die es da gibt dürften zum größten Teil auf die überflüssigen Tabellen, Felder und Beziehungen zurückzuführen sein.
Was Dein jetziges Problem ist, habe ich auch nicht richtig verstanden.
Okay, danke für die Infos.
Kannst du dann mir sagen welche Tabellen zu verwenden sind und wie die Beziehungen sein sollen?
Wie geschrieben ab September werde ich mit der neuen verbesserten Datenbank anfangen.
Aktuelles Problem ist:
Wenn für die aktuelle Rechnung einen Zahlart als "Inzahlung" gegeben wurde, nach Klicken auf [Speichern] Button sollte mir das Formular[Verkäufer] öffnen.
Die Datensätze aus der Tabelle habe ich in einer Abfrage per SQL Befehl rausfiltern können:
SELECT Zahlung.RechnungsID, Zahlung.ZahlArt
FROM Zahlung
WHERE (((Zahlung.RechnungsID)=[Formulare]![Rechnung]![RechNr]));
aber weiter kann ich nicht.
Danke
Hallo,
lediglich zur Frage:
Sub btnSpeichern_Click()
If Me!Zahlart = "Inzahlung" then
Docmd.Openform "Verkäufer",,, "RechnungsID = " & Me!RechNr ' sofern "RechnungsID" den Datentyp LONG aufweist
End If
End Sub
Hallo,
ZitatKannst du dann mir sagen welche Tabellen zu verwenden sind und wie die Beziehungen sein sollen?
Ich habe Dir doch in #3 Hinweise gegeben. Leider gehst Du auf diese Hinweise nicht weiter ein.
Ich hatte auch 4 Fragen, von denen Du keine beantwortet hast.
ZitatWas ist denn überhaupt der Unterschied der "Auto" Tabelle zur Tabelle "EKAutos" ?
Ist die RechnungsID wirklich auch die RechNr ?
Was soll eigentlich die Mehrwertsteuer beim Land ?
Was sind die Felder RechErkl1 bis 5 , was steht da drin ?
Was ist denn überhaupt der Unterschied der "Auto" Tabelle zur Tabelle "EKAutos" ?
-- In Auto gebe ich Autos die verkauft vorden sind
in EKAutos gebe ich die Autos die gekauft worden sind
Ist die RechnungsID wirklich auch die RechNr ?
--Ja, RechID ist die Rechnungsnummer
Was soll eigentlich die Mehrwertsteuer beim Land ?
--Zum feststellen für welches Land welche MwST Satz verwendet werden muss
Was sind die Felder RechErkl1 bis 5 , was steht da drin ?
--Da sind die Erklärungen für die Rechnung gespeichert z.b. TÜV neu, Schäden etc.
ich bin gerade dabei eine neue DB etwas strukturierter zu machen.
Soll ich hier posten?
Kann bitte jemand diese DB kontrollieren, seit 5 Stunden folgenden Fehler/Aktionen nicht lösen/finden :'(
ich kann die Datensätze durch Klicken auf dem Button(Rechnung Schreiben und Drucken) im Formular "frmRechnung", in die ZwischenTabelle "tblKunRechAuto" nicht hinzufügen ::)
Vielen Dank im Voraus.
Zorlayan
PS: Antworten für die andere 2 Fragen habe ich gerade gefunden.
=Sum([ZahlungsWert]) und
=Sum([KostensWert]) jeweils in einem Feld im Formularfuß
hätte nicht gedacht dass es so einfach wäre. ich habe die ganze Zeit versucht das rechte Ohr mit der linken Hand zu halten. lol ;)
PS2: Die Datenbank ist noch nicht ganz fertig also bitte nicht wundern :) mir wird sehr helfen wenn das geschilderte Problem erstmal behoben wird.
VG
Hallo,
Ohje, Du hast wieder viel zu früh mit Formularen angefangen. Das Datenmodell muss noch überarbeitet werden, das passt hinten und vorn nicht.
- Die Tabelle "tblKunRechAuto" ist ersatzlos überflüssig. Die Felder "AID" und "KID" gehören direkt in die Tabelle "tblRechnungen"
- Der Verkaufspreis und und die MWST gehören in die Rechnung
- Die Felder "Marke" und "PSWert" in der Autotabelle sind ersatzlos überflüssig. PS über KW und Marke leigt bereits über das Modell fest
- Zusammengsetzte Primärschlüssel in den Tabellen Kosten und Zahlungen sind Unsinn, warum hast du das gemacht ?
- Die Tabelle Zahlung gehört zur Rechnung und nicht zum Auto.
- Das Feld "Land" in der Kundentabelle wird dort nicht benötigt. Liegt der Ort fest, hat man automatisch auch da Land.
- Bei der Rechnung fehlt die Rechnungsnummer sowie ein feld für die Zahlungsbedingungen und ggf. für die Kontoinformationen.
- Keine Sonderzeichen (-) in Feldnamen verwenden.
- Den ID's sinnvolle Namen geben.
Was kommt in die Tabelle "tblKosten" ?
Was kommt in das Feld "Kosten" in der Autotabelle?
Ändere das mal und dann zeigtst Du noch mal das Beziehungsbild.
Und vorerst keine Formulare mehr machen.
Hallo Klaus,
schade, und ich hatte mich gefreut das ich endlich mal eine DB 50% selbstständig geschafft habe :o
ok, lösche alle Tabellen, Codes und erstelle nach deiner Erklärungen, danach schicke ich das Bild von Beziehungen zu.
Danke fürs Hilfen.
VG
Zorlayan
Zitat von: MzKlMu am Juli 28, 2022, 11:36:59Was kommt in die Tabelle "tblKosten" ?
Was kommt in das Feld "Kosten" in der Autotabelle?
in TblKosten möchte ich sehen welche Kosten ggf. Reparaturen einzelnen und als Summe für ein Auto zusätzlich gemacht wurde.
Hier das Bild von Beziehungen. Hoffentlich passt. :)
Hallo,
Zitat von: undefinedHoffentlich passt.
Noch nicht ganz, aber wir nähern uns der Zielgeraden. ;D
- Land in der Tabelle "tblKunden" löschen.
- Feld "Kosten" in Autotabelle löschen, dafür hast Du ja die Tabelle.
- Sonderzeichen (-) sind immer noch drin
- Die Tabelle "tblRechnungen" hat kein Beziehung zum Auto und keine zum Kunden.
- PSWert immer noch drin
- AutoID bei den Zahlungen überflüssig
- Beziehung zwischen Rechnung und Zahlung ist falsch rum (Die RechnungID muss als Fremdschlüssel in die Zahlungstabelle).
- Es könnte sinnvoll sein, für die Kostenart eine Tabelle anzulegen.
Brauchst Du die Anschrift des Verkäufers nicht ?
Danke ja, wir nähern uns :)
Zitat von: MzKlMu am Juli 28, 2022, 16:01:01- Land in der Tabelle "tblKunden" löschen. // Erledigt
- Feld "Kosten" in Autotabelle löschen, dafür hast Du ja die Tabelle. //Erledigt
- Sonderzeichen (-) sind immer noch drin //Sorry übersehen
- Die Tabelle "tblRechnungen" hat kein Beziehung zum Auto und keine zum Kunden. //noch frei keine Beziehung
- PSWert immer noch drin // Übersehen wieder :)
- AutoID bei den Zahlungen überflüssig //Mein Fehler
- Beziehung zwischen Rechnung und Zahlung ist falsch rum (Die RechnungID muss als Fremdschlüssel in die Zahlungstabelle). //Erledigt
- Es könnte sinnvoll sein, für die Kostenart eine Tabelle anzulegen. //Angelegt und Verbunden an tblKosten
Brauchst Du die Anschrift des Verkäufers nicht ? // Können wir eine neue Tabelle für die Verkäufer erstellen oder ein neuer Feld z.B. "Verkaeufer" "Ja7Nein" hinzufügen, weil eine Kunde kann gleichzeitig auch ein Verkäufer werden wenn er sein Auto als Inzahlung abgibt. ?? Was sagst du?
Hallo,
noch nicht ganz.
- Die Tabelle "tblRechnungen" hat kein Beziehung zum Auto und keine zum Kunden. Fehlt immer noch, Beziehung ist notwendig, die Felder sind doch vorhanden.
- Die Beziehung zwischen Kosten und Kostenart ist falsch rum.
- ZahlungenID in der Rechnung ist überflüssig.
- Wieso ist Zahlungsbedingungen eine ID ?
- Im Feld "EU-Land" ist das Sonderzeichen immer noch drin
- Die Verkäufer kommen auch in die Kundentabelle (Tabelle ggf. sinnvoll umbenennen)
- Verkäufer in der Autotabelle wird zum Fremdschlüssel zur Kundentabelle.
- Wieso nennst Du die Tabelle "tblZahlungstypen" aber das Fremdschlüsselfeld dazu "Zahlungsart" (unlogisch) ?
- Was ist StID in der Tabelle Kunden ?
Guten Morgen Klaus,
habe soweit alles korrigiert, verbessert.
Zitat von: MzKlMu am Juli 28, 2022, 17:37:28Hallo,
noch nicht ganz.
- Die Tabelle "tblRechnungen" hat kein Beziehung zum Auto und keine zum Kunden. Fehlt immer noch, Beziehung ist notwendig, die Felder sind doch vorhanden. ich dachte machen wir eine n:n Beziehung deswegen. Sorry :)
- Die Beziehung zwischen Kosten und Kostenart ist falsch rum. almählich verstehe ich die Verbindungen.
- ZahlungenID in der Rechnung ist überflüssig. weil wir die Tabelle direkt an RechnungenID verbunden haben.
- Wieso ist Zahlungsbedingungen eine ID ? Dachte für die Zahlungsbedingungen machen wir noch eine neue Tabelle
- Im Feld "EU-Land" ist das Sonderzeichen immer noch drin Erledigt, Sehschwäche :)
- Die Verkäufer kommen auch in die Kundentabelle (Tabelle ggf. sinnvoll umbenennen) mir keinen anderen sinnvollen außer KunVer eingefallen
- Verkäufer in der Autotabelle wird zum Fremdschlüssel zur Kundentabelle.also Verkäufer[Zahl], verbindet sich mit KunVerID 1:n ?
- Wieso nennst Du die Tabelle "tblZahlungstypen" aber das Fremdschlüsselfeld dazu "Zahlungsart" (unlogisch) ? Korrigiert, einheitlich jetzt
- Was ist StID in der Tabelle Kunden ? StID = SteuerID der Kunde oder Verkäufer wenn gewerblich sind
Hallo,
es wird weniger. ;D
Die Tabelle "tblRechnungen" ist die n:m Beziehung zwischen Kunde und Auto.
Eine Tabelle für die Zahlungsbedingungen macht nur Sinn, wenn es mehrere Zahlungsbedingungen gibt. Wenn ja, solltest Du diese anlegen und dann ist natürlich ...ID richtig.
"tblKunVer" kannst Du lassen.
Statt StID würde ich SteuerID schreiben, ist verständlicher und auf die 4 Buchstaben kommt es auch nicht an.
Dann noch folgendes:
Es ist vorteilhaft, wenn es in der ganzen DB keine Felder mit gleichen Feldnamen gibt.
Es ist auch (gerade für den Anfänger) sinnvoll, dass man Primärschlüsselfelder und Fremdschlüsselfelder zweifelsfrei unterscheiden kann. Daher sollten die FS Felder durch anhängen eines _F kenntlich gemacht werden.
Z.B. so: AnredeID und in der KunVer Tabelle dann AnredeID_F
Mache das mal noch bei allen FS Feldern.
Dann zeigst Du bitte noch mal das neue Bild.
Zitat von: MzKlMu am Juli 29, 2022, 12:18:29Die Tabelle "tblRechnungen" ist die n:m Beziehung zwischen Kunde und Auto. hoffentlich habe ich richtig gemacht wenn nicht bitte auf dem Bild zeichnen usw.
Eine Tabelle für die Zahlungsbedingungen macht nur Sinn, wenn es mehrere Zahlungsbedingungen gibt. Wenn ja, solltest Du diese anlegen und dann ist natürlich ...ID richtig. Eigentlich gibts keine Zahlugebedingungen sondern Zahlungsarten z.B. Bar Anzahlung, Rest Bar Bezahlung, Anzahlung als Bank Überweisung oder kompletten Betrag als Banküberweisung etc...sehe ich es falsch?
"tblKunVer" kannst Du lassen.jo
Statt StID würde ich SteuerID schreiben, ist verständlicher und auf die 4 Buchstaben kommt es auch nicht an.gemacht
Dann noch folgendes:
Es ist vorteilhaft, wenn es in der ganzen DB keine Felder mit gleichen Feldnamen gibt.soweit ich sehen kann gibts keine gleichen Feldernamen.
Es ist auch (gerade für den Anfänger) sinnvoll, dass man Primärschlüsselfelder und Fremdschlüsselfelder zweifelsfrei unterscheiden kann. Daher sollten die FS Felder durch anhängen eines _F kenntlich gemacht werden.wurde gemacht
Z.B. so: AnredeID und in der KunVer Tabelle dann AnredeID_F
Mache das mal noch bei allen FS Feldern.
Dann zeigst Du bitte noch mal das neue Bild.
Hallo,
Ich halte das noch nicht für schlüssig.
- tblVerKun
wenn ich schon versch. Personengruppen in einer Tabelle speichere,
was ja nicht falsch ist, sollten die aber ein Kennzeichen ihrer
Rolle haben.
- tblVerbindung
wozu?
ein VerKun kann zwar mehrere Rechnungen haben/bekommen, aber eine
Rechnung hat doch immer nur einen VerKun. Und wenn es mehrere Autos
auf einer Rechnung gibt muss eh eine Detailtabelle (RechPos) her.
Ansonsten gehören die beiden FK m.E. in die tblRechnungen. Durch den
FK zu tblVerKun werden diese dabei auch gleichzeitig als Einkaufs- bzw.
Verkaufsrechnung klassifiziert.
gruss ekkehard
Hallo Ekkehard,
Danke fürs mithelfen.
Zitat von: Beaker s.a. am Juli 29, 2022, 16:50:26Ich halte das noch nicht für schlüssig.
- tblVerKun
wenn ich schon versch. Personengruppen in einer Tabelle speichere,
was ja nicht falsch ist, sollten die aber ein Kennzeichen ihrer
Rolle haben. Eine Kunde kann duch Inzahlung seines Autos gleichzeitig auch Verkäufer werden. Ich denke es reicht auch aus wenn er auf der Rechnung ausgewählt werden kann.
- tblVerbindung
wozu?Die Tabelle "tblRechnungen" ist die n:m Beziehung zwischen Kunde und Auto. sagte Klaus und so habe ich n:m Beziehung erstellt. Habe ich Fehler?
ein VerKun kann zwar mehrere Rechnungen haben/bekommen, aber eine
Rechnung hat doch immer nur einen VerKun. Und wenn es mehrere Autos
auf einer Rechnung gibt muss eh eine Detailtabelle (RechPos) her.
Ansonsten gehören die beiden FK m.E. in die tblRechnungen. Durch den
FK zu tblVerKun werden diese dabei auch gleichzeitig als Einkaufs- bzw.
Verkaufsrechnung klassifiziert.
gruss ekkehard
Wie soll ich hiermit weiter verhalten?
Gruß
zorlayan
Hallo,
Zitat von: undefinedDie Tabelle "tblRechnungen" ist die n:m Beziehung zwischen Kunde und Auto. sagte Klaus
Ja, das habe ich gesagt. Aber wie gesagt, die Tabelle "tblRechnungen"
selbst ist die n:m Beziehung, von einer Verbindungstabelle habe ich nichts gesagt. Du hast doch die beiden Fremdschlüsselfelder zum Auto und zum Kunden bereits in der Rechnungstabelle. Also Tabelle "tblVerbindung" ersatzlos löschen und die Beziehungen direkt zur Rechnungstabelle erstellen. Siehe Bild, ..._F nicht vergessen.
Ein Kennzeichen ob Verkäufer oder Kunde ist auch mMn nicht notwendig, da die ja diese ja beides sein können.
PS:
Bitte unterlasse diese kompletten Zitate.
Markiere bei Bedarf einen Satz den Du als Zitat markierst. Deine Antwort dann darunter.
Zitate sind sparsam anzuwenden, da die Themen unnötigerweise verlängert (auf mehrere Seiten) werden.
sorry dann mein Missverständnis :(
Zwischen Tabelle gelöscht, Beziehungen erstellt und _F wurden geändert.
Schaut jetzt besser?
Womit mach ich weiter wenn dieser Schritt fertig ist?
Danke
zorlayan
Hallo,
@klaus ZitatEin Kennzeichen ob Verkäufer oder Kunde ist auch mMn nicht notwendig, da die ja diese ja beides sein können.
Stimmt, hatte ich nicht bedacht. Dann sollte man aber wenigstens
die Rechnungen typisieren. Muss man ja schon wegen der U-/VSt. aus-
einander halten.
@Zoryalan
ZitatSchaut jetzt besser?
Die Beziehung zwischen tblVerKun und tblAutos kann dann auch noch
weg. Die hast du jetzt ja schon über die tblRechnungen.
ZitatWomit mach ich weiter wenn dieser Schritt fertig ist?
Fang erst mal mit Formularen für die Stammdaten an.
gruss ekkehard
Hallo,
ZitatDann sollte man aber wenigstens die Rechnungen typisieren.
Ich bin bisher davon ausgegangen, dass nur Rechnungen für den Verkauf erstellt werden. Dann gibt es nur einen Rechnunstyp. Verkäufer_F ist nur rein informativ von wem das Auto gekauft wurde. Daher ist die Bezihung notwendig.
ok, dann fange ich die Formulare zu erstellen.
Letzter Status der Beziehungen ist im Bild.
DB_Bild_6.png
Formulare sind fertig
Formulare_1.png
Hallo,
da gibt es noch etwas Klärungsbedarf.
Willst Du auch die Rechnungen erfassen eines Verkäufers (also die die Ihr zahlen müsst) oder nur die die Ihr schreibt.
Wenn es nur um Eure geht, muss die Beziehung von KunVer zum Auto (über Verkäufer_F) wieder rein.
Lies dazu noch mal die #25
Auch das mit den Zahlungsbedingungen ist noch nicht ganz klar.
Unter Zahlungsbedingungen verstehe ich z.B. "Zahlbar innerhalb 14 Tagen mit 2% Skonto".
Zitat von: MzKlMu am Juli 30, 2022, 20:05:37Willst Du auch die Rechnungen erfassen eines Verkäufers (also die die Ihr zahlen müsst) oder nur die die Ihr schreibt. Eigentlich nicht aber ich will die Autos in die DB aufnehmen wenn jemand sein Auto als Inzahlung gibt und dafür ein anderes Auto kauft.
Auch das mit den Zahlungsbedingungen ist noch nicht ganz klar.
Unter Zahlungsbedingungen verstehe ich z.B. "Zahlbar innerhalb 14 Tagen mit 2% Skonto".Bisher haben wir diesen Option nicht verwendet aber schadet uns bestimmt nicht.
Manche Rechnungen an Kunden werden nicht sofort abgeglichen z.B. Man kauft ein Fahrzeug für 3000.-€ und zahlt 500.-€ als Bar Anzahlung und Rest von mir aus nach einer Woche, dies muss auf die Rechnung vermerkt werden damit man weißt welche Rechnungen noch offen sind. Können wir es über tblZahlungen steuern?
Hallo,
Na, ich weiss ja nicht, was das FA sagt, wenn es zu Ankäufen keinen
Beleg gibt.
Eine Inzahlungnahme ist ja nur ein verkürzter Vorgang der Rechnungs-
begleichung. So zu sagen ein zweimaliger, virtueller Besitzerwechsel
des Betrages. Kann man unter Zahlungen als Anzahlung buchen.
Die Zahlungsbedingung wäre dann "Anzahlung durch Inzahlungnahme, Rest
sofort/in x Tagen".
Wie die Zahlungen reinkommen spielt dann nur noch in der Tabelle
Zahlungen eine Rolle, nämlich ob sie in die Kasse oder auf ein Bankkonto
gebucht werden (1000/1200).
gruss ekkehard
Hallo,
@ekkehard
Wenn das wirklich ein FA sichere Buchungsdb werden soll, muss mit mehr Aufwand gemacht werden. Und ob da Access als Backend geeignet ist, wäre auch noch die Frage. Das FA verlangt von solcher Software z.B. auch eine nachgewiesene Manipulationssicherheit. Ich bin bisher davon ausgegengen, dass die DB nur der reinen Überwachung dient und die eigentliche Buchhaltung über ein echtes Buchhaltungsprgramm gemacht wird.
Wenn hier wirklich die Buchhaltung mit dieser Access DB gemacht werden soll, bin ich raus zumal wie gesagt Access da nicht mehr geeignet ist.
Hallo Klaus,
Zitatdie eigentliche Buchhaltung über ein echtes Buchhaltungsprogramm gemacht wird.
Davon gehe ich ja auch aus. Aber da braucht es eben für jede Buchung
einen Beleg. Und wenn eine Rechnung gebucht ist, kann ich die (auch
in Access) für eine weitere Bearbeitung (Manipulation) sperren.
gruss ekkehard
Hallo,
@ekkehard
ZitatDavon gehe ich ja auch aus.
Und warum bringst Du dann das FA ins Spiel. Das ist doch dann bedeutungslos. Und ob ich hier Belege habe oder nicht spielt auch keine Rolle.
Hallo,
es wird keine Kommerzielle Datenbank :)
Soll ich die Datensätze durch die Formular eingeben und Testen? oder bauen wir zuerst Abfragen?
Hallo,
Die Beziehung zu Verkäufer_F wieder einrichten (siehe #27).
Dann beginnst du mit den Formularen. Zuerst die für die reinen Stammdaten (KunVer, Autos usw.)
ZitatIch bin bisher davon ausgegangen, dass nur Rechnungen für den Verkauf erstellt werden. Dann gibt es nur einen Rechnunstyp. Verkäufer_F ist nur rein informativ von wem das Auto gekauft wurde. Daher ist die Bezihung notwendig.
Ja, es werden nur die Rechnungen geschrieben wenn wir Autos Verkaufen aber Inzahlung-Autos müssen auch in den Bestand addiert und auf der Verkauf-Rechnung angezeigt werden.
Schließlich werden sie auch irgendwann verkauft.
Also was soll ich jetzt? Den Verkäufer_F mit der KundenTabelle n:1 beziehen?
VG
Zorlayan
Hallo,
ja, so wie Du es schon mal hattest.
Einige Datensätze habe ich eingegeben, keine Beziehungsprobleme oder so.
Habe die frmRechnung Formular etwas modifiziert.
Anbei schicke ich die DB zu, bitte bei der Gelegenheit mal überprüfen.
Danke & VG
Zorlayan
Hallo,
Wenn Du erst mal ein bisschen Ordnung in das Beziehungsbild bringst, dann fällt sofort auf, dass die Beziehung tblKunVer.KunverID und tblAutos.Verkäufer_f sinnlos ist. Es fehlt dafür eine Tabelle tblVerkäufer, die für eine solche Beziehung nötig wäre. (Vorausgesetzt, ein Kunde kann nicht gleichzeitig ein firmen-interner Verkäufer sein.)
Was bedeutet "Ver" im Namen der Tabelle "tblKunVer"? Um keine Verwirrungen zu stiften, wäre "tblKunden" besser angebracht.
Hallo zusammen,
Kun(Kunden)Ver(Verkäufer), nach erster Überlegung war es nicht so, das wir sowohl Kunden auch Verkäufer in der selben Tabelle behalten?
Also neue Verkäufer-Tabelle(1) und eine Verbindung zu Rechnung(n) ?
VG
Zorlayan
Hallo,
das musst Du doch entscheiden können entspr. Deinen Arbeitsbedingungen...
Normalerweise ist ein Kunde etwas Anderes als ein Mitarbeiter... Wenn man beide in einer Tabelle führt, funktioniert das nur, wenn eine Typisierung dabei mitspielt, mit der der Unterschied, ob Kunde oder Mitarbeiter ermittelt werden kann.
Im aktuellen Fall würde ich auf zwei Tabellen "tblKunden" und "tblMitarbeiter" plädieren.
Wenn es möglich ist, dass ein Mitarbeiter auch ein Auto kaufen kann und damit wie ein Kunde behandelt werden muss, so ist dieser beiden Tabellen zu führen. Die dadurch entstehende Redundanz würde ich jetzt hier nicht beachten, weil vermutlich eine solche Situation eher selten auftritt. Aber wie gesagt, das hängt von Euerem Firmengebaren ab.
Hallo,
@FranzIn der Tabelle tblKunVer werden sowohl die Verkäufer als auch die Kunden/Käufer erfasst, denn ein Kunde kann auch Verkäufer sein wenn er z.B. ein Auto in Zahlung gibt, daher macht auch ein Typisierung keinen Sinn. Was soll das für ein Typ sein, wenn ein Kunde ein Auto in Zahlung gibt und er gleichzeitig ein neues/anderes Auto kauft? Die Beziehung zwischen tblKunVer und Verkäufer_F ist rein informativ damit man weis von wem das Auto gekauft wurde. Mit der Rechnung hat das nichts zu tun. Daher ist diese Beziehung notwendig und darf nicht gelöscht werden. Von Mitarbeitern war bisher noch gar nicht die Rede und sind auch gar nicht erfasst.
Das wurde alles schon mal diskutiert, siehe #15 ff.
Hallo,
ok, wenn man einen "Verkäufer" als einen "Auto-Lieferant" ansieht und nicht als Mitarbeiter in der Firma, der die Fz an den Mann (Kunden) bringen soll, dann mag das wohl stimmen. :D
Die anfänglichen Diskussionen darüber habe ich nicht alle nachgelesen.. 8)
Wie kommen wir zum "Mitarbeiter" oder meint ihr die Verkäufer? ???
Also es gibt Kunden an denen wir Autos verkaufen und es gibt auch Kunden von denen wir Autos als In Zahlung akzeptieren und ein anderes Auto verkaufen.
In solchen Situationen steht der Kunde gleichzeitig in zwei Positionen also sowohl als Kunde auch als Verkäufer mit gleichen Stammdaten.
Hallo,
vergiss einfach, was ich angemerkt hatte...
"Verkäufer" ist, bzw. war für mich nur missverständlich....