Domino 9 und frühere Versionen > Entwicklung

Seminardatenbank erstellen, Probleme mit Dokumente zählen

(1/4) > >>

feel_x:

Moin,

ich erstelle für den Fachbereich eine Seminardatenbank, die Seminare und die erforderlichen Anmeldedokumente sowie einfache Statistiken enthält.
Jetzt könnte man sich ja fertige Sachen als Demoversion besorgen, aber bei uns ist wichtig, dass das ganze von Anfang an überschaubar und pflegbar bleibt.

Folgende Frage:
Zum Aufbau der DB: Was wäre schlauer: Seminar als Hauptdokument und Anmeldungen als Antwortdokumente?
Dann könnte man nämlich per child count die Dokumente zählen, was gleich meine zweite Frage wäre, nämlich:
Man stelle sich vor, ich hätte ein Seminardokument, in dem ein Feld "Anzahl Freie Plätze" existiert, von dem nun die Anzahl der bereits gebuchten Seminare abgezogen werden soll.
Wie mache ich das, wenn ich keine Antwort-Hierarchie verwende?
Die Anzahl noch freier Plätze soll sowohl in den Seminardokumenten als auch in Ansichten angezeigt werden..

Hmhm. Ich will, wenn die Anzahl gebuchter Plätze gleich der Anzahl der Seminarplätze ist, die Dokumente in den Status "seminar voll" überführen.

Hat jemand eine Idee oder eine angefangene DB zu dem Thema?

;)

Gruß, Felix S.

Rob Green:
hm..in der Sandbox ist eine, aber nit so dolle:

http://www-10.lotus.com/ldd/sandbox.nsf/ecc552f1ab6e46e4852568a90055c4cd/4fdbafe0931d2ec985256b6e004f8ec6?OpenDocument&Highlight=0,training

Doch der Ansatz ist der, den Du auch präferierst:
Hauptdoc: Schulung
Antwort: Reservierung

feel_x:

Hm, ja, Danke
die ist ja schon mal ein Anfang. R4. aber zu gebrauchen.

Jetzt ist mein Problem eine Denkschwelle: Wie verfahre ich am besten, wenn gebuchte Dokumtene wieder storniert werden..
verschiebe ich dann den ganzen Antwortbaum?

In dem Moment, in dem die Anzahl gebuchte Plätze = Anzahl vorhandener Plätze ist, soll das Seminar ja zur Buchung geschlossen werden.

Hat jemand einen Denkanstoß für mich?
 ;)

feel_x

Rob Green:
Du mußt dazu im DB weiten QueryDocumentDelete einen Code einbauen, der den Zähler im Hauptdoc um -1 versetzt und dabei den Status von belegt auf frei stellt, wenn Du denn mit Stati im Hauptdoc arbeitest. Ich hatte das mal mit einem roten und einem grünen Icon in der View dem User signalisiert, das über das Hautpdoc gesetzt wurde. Sprich: auf der Dokumentzeile des Hauptdocs im View ist ein grünes Icon zu sehen, daß das Seminar noch nicht ausgebucht ist.
Storniert ein TN spätestens 2 Werktage vor Seminarbeginn, wurde im Hauptdoc der Zähler reduziert.

Es war mal angedacht, daß sich User auf eine Warteliste setzen lassen konnten, wenn das Seminar voll war und somit keine Buchung mehr möglich war. Die Buchung sollte dann dennoch gehen, nur eben mit dem Status "waiting"...warten auf eine Stornierung also....doch das wurde verworfen, da in der Praxis kein Buchungs Automatismus möglich war, wenn jemand nachträglich reingerutscht ist. Denn, der Mitarbeiter kann zuerst laut System wegen Vollbelegung nicht, also plant er seine Termine zum Zeitraum des Seminartermins eh anders, da er ja nicht hinkann. Wenn das Seminar wegen einem Storno dann plötzlich frei wird, muß er sich im Team und mit dem Chef  asap absprechen, ob er nun doch hingehen kann. Da am Ende nur noch eine Hinweisfunktion blieb, haben wir es ganz sein lassen...die Mitarbeiter, die wegen Vollbelegung nicht konnten, müssen eben jeden Tag selsbt reinschauen, on doch ein Plätzchen freigeworden ist.

Was Du auch  machen kannst: wenn das Seminar 12 Plätze hat, könntest Du im voraus 12 freie Buchungsslots = docs generieren, wobei die MA dann nur noch in ein freies Buchungsdoc gehen müssen, um sich dort einzutragen oder eben wieder auszutragen. Wichtig wird dann nicht mehr so sehr der Zähler im Hautpdoc, sondern Lockingmechanismen, die verhindern, daß 2 USer parallel einen freien Slot bebuchen können (Saveconflicts). Das kannman entweder lösen, indem man im Queryopen/Querymodechange/Postchange etwas einbaut oder aber beim Speichern auf einen Saveconflict abfragt und damit das Speichern des "Loosers" verhindert.

feel_x:
Klingt auch nicht schlecht.
Der Weg mit den 12 freien Dokumenten bei 12 Plätzen ist auch nicht unpraktisch, weil man dann den gesamten Anmeldeweg eines Seminares in einem Dokument abbilden könnte..
Hm. Klingt gut.
Müsste man nur dem User eine Auswahl übergeben, die nur jeweils ein Dokument anzeigt, damit er nicht überlegen muss, ob er Platz 1 oder Platz 8 nimmt ;)
hehe
Allerdings müsste ich trotzdem irgendwo eine Information zu "Mindestteilnehmerzahl" speichern, bei deren Unterschreitung das Seminar abgesagt werden muss..
Hm. Klasse. Wird immer komplizierter :)

Oh,
Jetzt bin ich gerade über das skript hier gestolpert:

Dim session As New NotesSession
Dim db As NotesDatabase
Dim view As NotesView
Dim vc As NotesViewEntryCollection
Set db = session.CurrentDatabase
Set view = db.GetView("bestaetigte Anmeldungen")
Set vc = view.GetAllEntriesByKey("Telefonmarketing")
Messagebox vc.Count

mit dem könnte man doch die gebuchten Doks zählen,
jetzt müsste man nur die Auswahl "Telefonmarketing" dynamisch machen, also je nach gewähltem Dokument müsste sich automatisch die "Seminarkategorie" (also den Key) ändern..
oder zum Beispiel eine jeweils Dok-ID, nach der man sucht.
und das ganze dann nicht per Messagebox ausgeben, sondern in einem Dokument/einer View oder per Agent..

oder?
Denke ich jetzt Mist?
:)

Navigation

[0] Themen-Index

[#] Nächste Seite