Office: (Office 2010) Faktura-Programm

Hallo alle miteinander,

ich habe mal angefangen, eine Faktura-DB in Access zu erstellen.
Bevor ich aber nun weiter mache, wollte ich wissen, ob die Tabellenstruktur und Beziehungen so OK sind.

www.j-rupp.net/Faktura DB.accdb

Außerdem wäre ich über weitere Unterstützung echt super dankbar!
(Ich werde jetzt gleich noch meinen "Plan" posten.)

Viele Grüße,
user_1234

:)

 

--> Kundendatenbank (Fertig)
--> Artikeldatenbank (Fertig)
--> Automatische PLZ/Ort (Datenbank fertig, Formular...nicht fertig)

Meine 'Vision' ;-):
Auftrag anlegen, dazu dann rechnung, Angebot etc. drucken können


Was ich jetzt noch brauche(???):

1. Berichte aus den Formularen "Vorgänge"/ "Vorgangdetails" erstellen
2. Eingabeformulare für Artikel, Kunden etc. (einfach...)
3. Evtl. Übersichtsseite aller Vorgänge, sodass man einen auswählen kann und genauer betrachten kann?

Ich hoffe ich konnte mein Vorhaben recht 'anschaulich' und verständlich beschreiben...*rolleyes.gif*

Viele Grüße und schonmal Vielen Dank!

 

Hi,

da hast du dir viel vorgenommen.

Zum Datenmodell:

• Was haben die Kundendaten (Name, Adresse etc) in der Auftragstabelle zu suchen? Die verweist doch auf die Kunden!
• PLZ und Ort sind nicht ganz so einfach wie du das glaubst. Es gibt mehrere Orte zur gleichen PLZ. Es gibt PLZ für Großkunden und für Postfächer, wo dann der Ort nur virtuell ist. Und v.a. ändert sich das auch mal. Ich würde das nicht einbauen, sondern online bei der Post checken.
• Die MwSt ist bei den Aufträgen schlichtweg falsch. Sie gehört in die Einzelposten, da es grundsätzlich Artikel mit unterschiedlichen MwSt-Sätzen in einem Auftrag geben kann (auch wenn das vielleicht selten ist oder bei euch so nicht auftritt: die nächste Reform kommt bestimmt).
• Die Einheit und der Artikelname in den Auftragsdetails sind nicht richtig. Wenn sich diese Daten beim selben Artikel ändern dürften, dann brauchetst du keine Artikeltabelle.Wenn Artikel 4711 heute in kg und morgen in m abgerechnet wird, dann ist das ein anderer Artikel in der Artikeltabelle.
• Deine Tabellenstruktur lässt bisher nur Aufträge zu. Wo willst du die Anfragen, Angebote, Rechnungen, ggf. Bestellungen beim Lieferanten, Mahnungen, den freien Schriftverkehr ablegen? Dir fehlt eine Tabelle "Dokumente", wo alle (!) diese Dokumentarten vorkommen können. Einige davon, z.B. Rechnungen, haben dann Posten, also Artikel-Menge-Preis-Zeilen; andere nicht.
• Ich lege mal einen Plan der relevanten Tabellen von meiner Bauabrechnungs-DB bei, das ist sehr ähnlich. Vielleicht inspiriert es dich.

PS: Willkommen im Forum *hands

 

Vielen, vielen Dank, Martin!

Die habe ich drin, damit sich meine Vorstellung vom erstellen eines Berichts später vereinfachen lässt (Ich wollte ohne Abfrage arbeiten.)

Das mit den Postleitzahlen - OK! Da hab' ich ech nicht drüber nachgedacht --> Ab und Weg damit! ;-)

Mit der MwSt das müsste ich mir nochmal überlegen -> BIsher arbeiten wir genauso und auch in orgaMax z.B. wird die MwSt. doch erst zum Schluss draufgerechnet?

Das habe ich auch gemacht, um später das erstellen eines Berichts zu vereinfachen...(Ich habe ja eine Auftrags-Nr. Mit der kann ich Aufträge und Auftragdetails in Verbindung bringen. Dann wollte ich mit einem Button einen Befehl wie hier einbauen: FAQ5Berichte Das würde doch gehen, oder? Das mit m und kg passiert uns nicht, eig. immer die selbe Einheit.
P.S.: Die Felder kann man doch auch dazu nutzen das alte Aufträge (Vorgänge) bei Änderung eines Artikels nicht verfälscht werden, oder?

Du hast Recht, allerdings wollte ich nur "Vorgänge" [Keine Aufträge -> Falscher Name] anlegen. Zu jedem einzelnen Vorgang soll ich dann mit Buttons bestimmen können: "Angebot drucken", "Lieferschein drucken" und "Rechnung drucken". Die Zuordnung dass nich alle Positionen sondern nur die im Formular aktuell gewählten Positionen gedruckt werden, wollte ich wie oben der Link beschreibt lösen...

EDIT: Ich hätte auch nicht gegen eine Abfrage, nur hab ich wirklich 0 Ahnung davon...

Und wegen dem Bild: Vielen Dank!

Grüße

 

Das ist unzulässig vereinfacht. Zum Kunden darf es jederzeit nur genau eine "Stamminfo" geben (Name, Adresse etc). Diese Angaben können sich ändern, z.B. durch Umzug, Heirat etc. In deinem Aufbau müsste das in Auftrag und Kundentabelle nachgezogen werden. Ein Paradebeispiel für eine Update-Anomalie (Anomalie (Informatik) – Wikipedia).

Zum Schluss schon, aber nicht für den Auftrag, sondern für die Posten, aus denen er besteht. Nimm mal einen Supermarkt-Kassenzettel zur Hand. Da stehen oft Kennzeichen für die MWst drauf, z.B. 7% für Zeitschriften und Lebensmittel, 19% für den Rest. Wohlgemerkt: auf einem Kassenzettel (= 1 Vorgang) mehrere MwSt-Sätze. Jeder Posten hat seinen MwSt-Satz.

Das einzige, was sich bei einer Artikelnummer ändern darf, ist der Preis. Der Preis zum Zeitpunkt des Umsatzes wird dann auch zu recht in die Posten kopiert, denn der Preis der Artikels in der Artikeltabelle kann und darf sich geändert haben. Da ist also die Annahme "anhand der Artikelnummer kann ich alle Artikeldaten aus der Artikeltabelle holen" falsch. Aber für alle anderen Artikelinfos (Name, Einheit etc) ist die Annahme richtig. Daher wird nur der preis historisiert, aber Name und Einheit nicht.

Das unterstellt, dass Angebot, Lieferschein und Rechnung eines Vorgangs immer die gleichen Posten enthalten. Das halte ich für unzutreffend, denn der Kunde kann abändern ("5 x 4711 angeboten, aber 8x 9826 bestellt"). Ihr könntet den Vorgang dann zwar abändern, aber es geht verloren, dass ursprünglich was anderes in Rede stand. Auch bei Rechnungen ist das u.U. anders (10 bestellt, 8 geliefert wegen Lieferproblemen; da könnt ihr auch nur 8 abrechnen, aber 2 kommen noch. Die sind dann aber "weggeändert").

Das ist ja auch kein Drama. Aber mit wenig Fachwissen eine produktionsrelevante Datenbank aufbauen ist gefährlich. Würdest du von einem Bäcker dein Haus bauen lassen?

Einfachheit ist nicht unbedingt maßgeblich beim Datenbankdesign. Richtig muss es sein, sonst bricht das zusammen.

 

Ok, das würde also für mich jetzt heißen (Wenn ich das richtig verstehe!):

• Tabellen "Vorgänge" (Ehem. Aufträge) und "Vorgangdetails (Ehem. Auftragdetails) komplett löschen
• Tabelle "Angebote" + "Angebotdetails" anlegen
• Tabelle "Lieferscheine" + "Lieferscheindetails" anlegen
• Tabelle "Rechnungen" + "Rechnungdetails" anlegen

In die Tabelle Angebote: Angebots_ID, Angebots-Nr, Angebotsdatum, Kunden-Nr, Zahlungsbedingung
In die Tabelle Angebotsdetails: ID, Angebots_ID, Art-Nr, Art-Preis

Für Rechnungen und Lieferscheine dann jeweils genauso, aber mit Rechnungs_ID etc. statt Angebots_ID.

Jetzt stellt sich mir noch eine Frage: Die AutoWert Felder (..._ID) sind ja gänzlich ungeeignet für z.B. zu druckende Rechnungsnr. etc... Wie stelle ich denn jetzt die generierung einer fortlaufenden Rechnungs-Nr. an?

Wieder vielen Dank + Grüße ;-)

 

Ja, das wäre eine Lösung. Vielleicht solltest du bei den Lieferscheinen noch dazuschreiben, welcher Auftrag zugrundelage und bei den Rechnungen, welcher Lieferschein zugrundeliegt (oder mehrere, wenns mehrere sein können). Sonst stehen die Tabellenpärchen autonom nebeneinander.

Wenn du die 3 Haupt- und die 3 Untertabellen vergleichst, wird dir auffallen, dass der Aufbau immer ähnlich ist. Man könnte die Haupttabellen auch zusammenfassen zu einer Tabelle "Dokumente", und die Untertabellen zu einer Tabelle "Dokumentzeilen". Und schon bist du bei den gleichnamigen Tabellen meines Modells; einer m.E. besseren Lösung. In den Dokumenten gibt die Dokuemntart an, ob es ein Angebot, Auftrag oder Rechnungs ist. Danach steuert sich auch, was für Felder zwingend sind (z.B. braucht nur eine Rechnung eine UstG-gemäße Rechnungsnummer, aber eine Angebot nicht). Die Dokumentzeilen sagen dann von jedem Dokument (egal ob Angebot oder sonstwas), was für Posten aufgeführt sind.

Kurz: Angebot, Auftrag und Rechnung "schmecken im wesentlichen gleich". Dann können sie auch in die gleiche Tabelle. Details (RgNr Pflicht/Tabu) kann man im Eingabeformular regeln.


Und zur Rechnungsnummer: Siehe Demo "benutzerdefinierte Zähler" sowie die Forumssuche "Rechnungsnummer".

 

Bin jetzt gerade dabei, die DB zu ändern, ABER:
ICh will nicht nur vordefinierte Artikel eingeben können, sondern auch individuelle Positionen. Benötige ich dafür nicht doch die Felder "Bezeichnung", "Einheit" zusätzlich zur "Art-Nr"?

 

Es kann keine individuellen Artikel geben. Auch "Einmalartikel" müssen in die Artikeltabelle. Es ist wie bei Otto: "was nich im Katalog steht, hamwa nich". Punktum.

Man könnte erwägen, einen "Universalartikel" anzulegen, der bei Nutzung immer im Preis verändert wird. Das könnte z.B. für Kulanznachlässe o.ä. "Sonderartikel" nützlich sein. Aber dieser Artikel zeigt dann sehr merkwürdige Preisverläufe. Und er dürfte auch nur im Preis geändert werden.

An welche Individualartikel hast du gedacht?

 

Auch "Einmalartikel" müssen in die Artikeltabelle.
Nunja, OK. Die DB soll halt für einen Bekannten sein, der in der Maschinenindustrie tätig ist. Da gibt es schonmal so sachen wie "Aufbau der Maschine- Pauschale - 200€, manchmal aber auch 500€...Da muss er sich halt was anpassen.

Hier jetzt die aktualisierte DB - Jetzt müsste das Grundgerüst doch erstmal stimmen, oder? www.j-rupp.net/Faktura DB.accdb

P.S.: Dieses Forum ist echt TOP! *top

 

Das geht ja auch. Aber der Artikel heißt dann "Festpreis" oder "Individuelle Vereinbarung" und kostet 1 EUR. Ein Festpreis von 200 EUR für einen Auftrag enthält dann einfach eine Menge von 200 von diesem Artikel. Und der Kommentar "Aufbau der Maschine- Pauschale" ist dann der "Auftragsinhalt" (oder wie du das nennen magst, halt eine Ein-Satz-Freitext-Angabe, was gemacht wurde), der im Auftrag/Dokument als Titel eingegeben werden kann.

Unschön wäre auch machbar, die Menge auf 1 zu lassen und den Preis für diesen Spezialartikel eingeben zu lassen.

 

Manchmal sieht man den Wald vor lauter Bäumen nicht...*tongue.gif*
Daran habe ich garnicht gedacht - Gut das es dich gibt...

Ich habe ja ein Feld "Fußtext". Da soll er einfach eintippen
"Festpreise: Aufbau der Maschine, Anfahrt..."

Ich werde dann jetzt mal anfangen, Formulare und entsprechende Unterformulare zu entwerfen.

Bis denne

 

So, ich habe jetzt im Prinzip alles fertig (Wenn ich das richtig sehe) und würde erstmal nurnoch die entsprechenden Berichte benötigen.

http://www.j-rupp.net/Faktura DB.accdb

Im Formular "Dokumente" habe ich eine "KomboBox" mit dem Namen 'Dokumentart'. Außerdem wird im diesem Formular als auch im entsprechendem Unterformular die aktuelle "DK_ID" angezeigt (Im Unterformular ausgeblendet). Ebenfalls gibt es eine SPalte mit diesem Namen in beiden Tabellen (Dokumente & Dokumentpositionen). Damit lassen sich ja die Datensätze zuordnen...

Nun würde ich hingehen und einen Button im Formular "Dokumente" einfügen, mit folgender Ereignisprozedur:

Code:

Würde das klappen? (Also dass er nur die aktuellen Datensätze druckt?)

 

Versuchs, und du wirst es wissen. Testen ist dein Job. *Smilie Der Code sieht technisch ok aus. Aber wozu ein Bericht? Der i8st nur zum Ausdrucken. Auswählen kannst du damit nix.

Wenns nicht klappt, meld dich... *biggrin.gif*

 

Dann werd' ich das wohl tun! *wink.gif*
Es klappt nämlich nicht...

Ich möchte jetzt gerne einen Bericht per Button erstellen können, der nicht alle Datensätze der Tabelle "Dokumente" & "Dokumentpositionen" enthält, sondern nur die, mit der "DK_ID" deren andere Daten gerade im Formular angezeigt werden.

--> Ich möchte nur die Daten in den Bericht übernehmen, die gerade im Formular angezeigt werden.
(Und natürlich bräuchte ich später im Bericht noch Bezeichnung und Einheit der entsprechenden Artikel-Nr. Die Daten wären ja in der TB "Artikel" hinterlegt...)

Ich steh' gerade ech aufm' Schlauch...
-----------------------------------------------------------------------------------------------------------------------------------------------------------
EDIT

Also, Naja. Ich habe mich vor längerer Zeit schonmal mit dem selben Thema befasst. Das, was dabei herum gekommen ist, ist 'recht gut'.
(Gut, sind auch noch die Sachen wie PLZ, Artikelname in den Vorgangdetails etc. falsch, das könnte man aber ja ändern.)

Vorallem sind in dieser DB schon Berichte und sonnstiges fertig.
Nur eben wieder das Problem, dass alle Datensätze gedruckt werden...Evtl. könnte mir ja mal jemand helfen bzw. die Sachen so stricken,
dass die Datenübergabe an den Bericht richtig funktioniert --> Das ist eig. mein größtes Problem!

Hier mal die DB: www.j-rupp.net/Rechnung_Entwurf.accdb

Viele Grüße und Danke im Voraus!