Office: (Office 2007) Eine Adressentabelle für alles Adresstypen

Hallo,
der Link funktioniert nicht mehr. Außerdem benötige ich eine MDB.
Wenn Du die PLZ Tabelle verkleinerst, kannst Du die DB auch im Forum hier hochladen.

Was verstehst Du an dem Vorschlag mit der Historie nicht ?


PS:
Ich habe Bekannte/Verwandte in Lambrecht und wohne nur ein paar KM weg von Dir. *grins

 

Hallo gpswanderer,
nochmal vielen herzlichen Dank für die investierte Zeit und Ratschläge.
Die Nachschlagefelder in den Tabellen mache ich rückgängig. Begründung verstanden!
Zur Versionskette:
Eigentlich bin ich Metaller. Ich programmiere hier und da Siemens LOGO! und etwas S7. Mit Datenbanken habe ich nur am Rande zu tun. Also schaut man sich an, wie es andere machen. Als Vorbild dient mir das kommerzielle Warenwirtschaftsprogramm GS-Office von SAGE. In diesem Programm werden Vorgänge (Angebote, Lieferscheine, …) weiter verarbeitet zu: z.B. Rechnungen usw. Die Altvorgänge bleiben komplett bestehen. Mit allen Details. Wie in den großen Softwarelösungen könnte ich abfragen, welche Differenzen es zwischen Angebot und Buchung / Rechnung gibt.
So wie ich es angegangen bin, wäre das eine 1:1 Kopie von GS-Office.
Jeder Vorgangstype hat einen eigenen Nummernkreis. Bei Rechnungen schreibt das Finanzamt eine lückenlose Nummernvergabe vor. Daher das Feld „LetzteNr“ pro Vorgangstype.
Die mögliche Handhabung in Formularen wurde bereits getestet.

Zu deinem Vorschlag:
Es wäre „nur“ zu sehen, dass der Vorgang einen Vorgänger hatte. Welchen Inhalt der Vorgänger hatte, ist nicht mehr ersichtlich. Über diese lückenlose Nachvollziehbarkeit kann man diskutieren. Welche (Rechnungs)nummer haben die Vorgänge bei deiner Lösung?
Wenn es nur EINEN Datensatz gibt, welche Nummer (Angebots-Nr., BuchungsNr., ….) hat dieser dann?
Sollte ich etwas falsch interpretieren, bitte widersprechen. Gerne auch per Telefon.

Das Projekt ist mit der Erfassung von Buchungen und Rechnungen schreiben nicht abgeschlossen. Ziel ist es, auch die vorgeschriebenen monatlichen „Statistikmeldungen“ von der Datenbank erledigen zu lassen. Basis der Meldungen sind die Rechnungen (=tatsächliche Übernachtungen). Auf der Basis von Buchungen soll die Belegung visuell dargestellt werden und in diversen Portalen weitestgehend selbsttätig gepflegt werden. Neue Vorgänge sollen nur dann erzeugbar sein, wenn die FeWo im ausgewählten Zeitraum verfügbar ist.

Das, was irgendwann mal an „Datenbanklösung“ herauskommt, soll eine jedermann offenstehende Vorlage bieten. Unterstützer sind willkommen.

 

Hallo Forum,
Danke an alle, die sich bei diesem Thema beteiligt haben.
Für das Projekt verwende ich diese Beziehungen:



Auf meiner FeWo-Homepage veröffentliche in unter:
http://www.ferienwohnung-ohler.de/html/access.htm
den aktuellsten Stand.

 

Hallo,
sorry, ich habe das etwas aus den Augen verloren.

aber natürlich, kann man das nachvollziehen. Das Feld LfdNr enthält die jeweilige Nummer zum Vorgang. Die LfdNr kann abhängig vom Vorgangstyp automatisch hochgezählt werden. Und das wäre dann auch die zuletzt für diesen Typ verwendete Nummer.. Auch bei meinem Vorschlag ist es jederzeit möglich zu jedem Vorgang alle Nummern unabhängig anzuzeigen.
Die Tabelle mit den Vorgangstypen kannst Du um eine Spalte erweitern in der der Text für die Nummer abgelegt wird. Siehe Bild.

Alles wie gefordert machbar, lückenlos mit Datum und in einem Unterformular zur Tabelle "T2_Vorgaenge" sehr übersichtlich in der richtigen Reihenfolge darstellbar. Das Ufo dient auch gleichzeitig der Erfassung. In die Tabelle "T1_VorgangZuTyp" kann man noch einen Fremdschlüssel zum Vorgang einfügen, dann kannst Du für eine Abweichung des Angebots von der Buchung den geänderten Datensatz anlegen und dessen Schlüssel als Fremdschlüssel zum Vorgang "Buchung" speichern.

Das ist ein weit verbreiteter Irrtum. Es wird keine lückenlose Rechnungsnummer vorgeschrieben, eine Rechnungsnummer muss eindeutig sein und nicht lückenlos. Kannst Du in einschlägiger Literatur nachlesen. Die Suche über Google nach "lückenlose Rechnungsnummer" fördert entsprechendes zu Tage.
Aber auch bei meiner Version ist die lückenlose Nummer möglich (bzw. wird schon so gemacht), wenn auch nicht erforderlich.

 

Hallo gpswanderer,
habe mir deine Beiträge mehrfach durchgelesen. Der Groschen ist aber immer noch nicht gefallen. Du schreibst „… das kopieren entfällt …“
Wenn es einen Vorgänger gibt, dann wird also „nur“ in der Tabelle T1_VorgangZuType“ ein weitere Satz ergänzt. Der Satz in „T2_Vorgänge“ wird ggfls. berichtigt, wenn es Änderungen gegeben hat. Dann wäre bekannt, welche Historie der Satz XY hat. Vom Speicherplatz ganz klar besser, wie den ganzen Datensatz in T2_Vorgänge nochmal zu speichern.
Den Sinn von LfdNr in T1_VorgangZuType (die Beschreibung im Entwurfsmodus habe ich gelesen) erschließt sich mir auch nicht.

Auf was soll bitte der Schlüssel zeigen, wenn es „nur“ einen Vorgang in T2_Vorgänge gibt? Das hängt mir zu hoch. Kannst Du das mir bitte mit Test-Datensätzen erklären?

Die letzte Nummer muss in der Tabelle T1_Vorgangstype direkt auslesbar sein.
Dein ScreenShot verwirrt mich mehr wie er klärt. Vermutlich ist gemeint, dass die Tabelle T1_Vorgangstype um das Feld „LetzteNr“ ergänzt wird. So ist es auch in der in Verwendung befindlichen Datenbank.

 

Hallo,

nein, das ist ganz sicher nicht gemeint.
Und warum solltest Du die letzte Nummer brauchen ?
In der Tabelle "T1_VorgangZuTyp" wird je ein Datensatz angelegt. Wenn das jetzt eine Rechnung ist mit der LfdNr 1234, so ist das doch bereits die letzte Nummer, wozu willst Du die noch mal extra speichern, Du brauchst doch nur den Maxwert dieser Nummer auszulesen und 1 zu addieren, fertig.
Auch in Deiner jetzigen DB ist das Speichern der letzten Nummer bereits überflüssig.

Das andere muss ich mir erst selbst noch mal überlegen, ich mache ja nicht ständig Datenbanken für Ferienwohnungen. Von daher, kann ich nicht ausschließen, dass ich auch etwas falsch verstanden habe. Aber nicht was die LfdNr betrifft, da halte ich meine Überlegungen für richtig.

Mal eine Frage:
Gibt es in der Tabelle "T"_Vorgaenge" Felder deren Inhalt unabhängig vom Vorgangstyp immer gleich bleiben ?


PS:
Deine nur gelegentlichen Einlassungen hier machen es einem Fremden auch nicht leichter den Anschluss zu wahren. Ich muss da immer wieder alles von vorn durchlesen.

 

Hallo gpswanderer,
sorry, das mit den Zeitabständen. Mir fehlt die Zeit, ununterbrochen daran zu arbeiten.
Zur Frage:

Die Frage verwundert mich. Ich verstehe deinen Entwurf so, dass es „nur“ einen Datensatz gibt. Der Gast frägt an (=Angebot), dann bucht er (=Buchung), dann zahlt er (=Rechnung) oder er storniert wieder (=Storno). Das alles mit EINEM Datensatz in T2_Vorgänge, aber mehreren Einträgen (Sätzen) in der Tabelle T1_VorgangZuType. Dieser Zusammenhang hatte ich in einem älteren Beitrag hinterfragt.
Wir machen es jetzt so:
Bitte überarbeite die Beziehungen und Tabellenfelder. Dann werden exemplarisch Datensätze angelegt:
1. Gast 1: Angebot Nr 1
2. Gast 2: Buchung Nr1
3. Gast 1: aus Angebot Nr 1 wird Buchung Nr 2
4. Gast 3: Buchung Nr 3
5. Gast 2: aus Buchung Nr 1 wird Storno Nr 1
6. Gast 1: aus Buchung Nr 3 wird Rechnung Nr 1
Damit werden die Zusammenhänge deutlich.
Einverstanden?

 

Hallo,

Die Frage ist so zu verstehen:
Wenn aus einem Angebot eine Buchung wird, welche Feldinhalte können sich dann ändern und welche Feldinhalte bleiben gleich ?
Das Feld Touristik z.B. ändert sich ja nicht wenn aus dem Angebot eine Buchung wird, oder ? Und die Frage ist jetzt gibt es noch mehr solcher Felder ?

Je nach Antwort, könnte sein, dass ich noch mal am Datenmodell schraube.

 

Hallo gpswanderer,
im Prinzip ändert sich keines der Felder: GastID2, ZahlerID2, FeWoID2, Anreise, Abreise, Touristik, wenn der Gast keine Änderungen will / vornimmt.
Ausnahmen:
AsTID2, DatumE (=Datum, wann der Satz bearbeitet wurde),
die Felder zum Vorgänger VorgangsIDalt, VorgangstypeIDalt
und natürlich auch die Vorgangsnummer VorgangsNr
sowie die Statusfelder: gespeichert, gedruckt, ok, gelöscht.

 

Hallo gpswanderer,
arbeiten Sie an der Struktur für das Projekt "FeWo"?
Wenn Ja würde ich auch Ihre Ergebnisse warten,
wenn Nein, wird die Datenbank auf der Basis der derzeitigen Datenstruktur weiter entwickelt.

 

Hallo Forum,
die Datenstruktur steht.
Änderungen an der Struktur sind jetzt nicht mehr geplant.
Jetzt werden die norwendigen Abfragen und Formulare entworfen.