August 13, 2022, 21:24:49

Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!


Datensätze nach im Formular eingegebene Nummer finden und abfragen

Begonnen von zorlayan, Juli 22, 2022, 19:02:08

⏪ vorheriges - nächstes ⏩

MzKlMu

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.
Gruß
Klaus

Beaker s.a.

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
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.

MzKlMu

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.
Gruß
Klaus

zorlayan

Hallo,
es wird keine Kommerzielle Datenbank :)
Soll ich die Datensätze durch die Formular eingeben und Testen? oder bauen wir zuerst Abfragen?

MzKlMu

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.)
Gruß
Klaus

zorlayan

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

MzKlMu

Gruß
Klaus

zorlayan

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

DF6GL

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.

zorlayan

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

DF6GL

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.




MzKlMu

Hallo,
@Franz
In 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.
Gruß
Klaus

DF6GL

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)
 

zorlayan

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.