Seminardatenbank erstellen, Probleme mit Dokumente zählen

[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?

[Rob Green]

das letztere ist ein Ansatz von vielen, beim Speichern einer Buchung abzuchecken, ob ein Plätzchen noch frei ist oder nicht.

Den key zu bilden? Nun ja, wenn man ein Buchungsdoc hat, steht dann im ID-Feld drin: "Seminar_Word_Nummer_181"..das sollte es Key reichen. Dieser Key wird natürlich im Hauptdoc angelegt.

Wenn Du mit echten Antworten = Buchungsdocs arbeitest, zählst Du eben alle Responses, dann brauchst Du wiederum den Key nicht mehr.

zB aus Help
ViewKlasse
Dim db As New NotesDatabase( "Troy", "gonotes.nsf" )
Dim view As NotesView
Dim doc As NotesDocument
Dim response As NotesDocument
Set view = db.GetView( "Main View" )
Set doc = view.GetFirstDocument
Set response = view.GetChild( doc )

DocKlasse
Set notesDocumentCollection = notesDocument.Responses
=>
 doc As NotesDocument, folderName As String )
  Dim collection As NotesDocumentCollection
  Dim currentResponse As NotesDocument
  Set collection = doc.Responses
  Set currentResponse = collection.GetFirstDocument
  ' Put immediate responses to doc into the folder
  ' If there are none, sub exits and returns to calling sub
  While Not ( currentResponse Is Nothing )
    Call currentResponse.PutInFolder( folderName )
    ' Recursive call to put immediate responses to
    ' currentResponse in folder
    Call PutAllResponsesInFolder _
    ( currentResponse, folderName )
    Set currentResponse = collection.GetNextDocument _
    ( currentResponse )
  Wend

[feel_x]

Mal ne ganz dumme Frage:
Wenn ich das Hauptdokument verschiebe, verschicben sich auch alle Antwortdokumente, richtig?

:)

ich hab hier nur die englische Hilfe.. und die ist nichtmal volltextindiziert. Blöde Admins.

das heißt, ich erstelle ein "Seminardokument", und beim speichern werden automatisch Antwortdokumente in Höhe der "Gesamtanzahl Plätze" mit dem Status "ungebucht" erstellt.
Klingt doch als Ansatz schonmal ganz gut.

Oki, das reicht mir für den Anfang.

Dank und Gruß,
felix s.

[Rob Green]

was verstehst Du unter "verschieben", wohin:
in eine "View" = das Select bestimmt die anzuzeigenden Docs
in einen "Ordner" = der User bestimmt die anzuzeigenden Docs...nimmt man das Hauptdoc und hat man eine Spalte mit anzuzeigenden Responses, werden diese automatisch "mit übernommen"

[feel_x]

Ich denke, eine View reicht.
Es geht um die abgelaufenen bzw. gehaltenen Seminare.
Diese werden am Tag des Seminares in der Ansicht der buchbaren Seminare "unsichtbar" und tauchen dann im Archiv auf..
oder doch einen Archiv-Ordner. Dann hat man nicht alle neuen und alten Dokumente durcheinander und muss sich weniger um die Auswahl kümmern :)

doch, so mach ich's.
Das wird dann übersichtlicher, wenn die Anzahl der Dokumente richtig groß wird.

[feel_x]

Wenn Du mit echten Antworten = Buchungsdocs arbeitest, zählst Du eben alle Responses, dann brauchst Du wiederum den Key nicht mehr.

Hallo mal wieder
Ich komme mit der Funktionialität nicht weiter.
Habe immer noch das Problem, dass ich mit Dokumentenanzahlen nicht rechnen kann.
Die Formeln @docchildren oder descendants lassen sich ja nur zur Anzeige in einer Ansicht benutzen.
Wenn ich anzeigen lassen will: 6 von 10 Plätzen belegt.. wie mache ich das am besten?
Und: Die Formel, die Du mir aus der Hilfe kopiert hast: Wo kann ich die einsetzen, damit ich was damit anfangen kann?
Ich bekomme immer nur Errors..

[feel_x]

was verstehst Du unter "verschieben", wohin:
in eine "View" = das Select bestimmt die anzuzeigenden Docs
in einen "Ordner" = der User bestimmt die anzuzeigenden Docs...nimmt man das Hauptdoc und hat man eine Spalte mit anzuzeigenden Responses, werden diese automatisch "mit übernommen"

Also: Ein Teilnehmer meldet sich zum Seminar an,
zur Berechnung wird im Seminardokument (Hauptdokument)
ein Wert runtergezählt (verfügbare Plätze).
Jetzt ist das Problem, dass der User ja seine Seminarteilnahme auch wieder stornieren können soll.
Mache ich mittels Aktion und Agent.
Frage ist: Wie kann ich verhindern, dass der User sein Anmeldedokument einfach löscht, ohne den Button zu drücken?
In dem Fall würde ja das Hauptdokument nicht wieder hochgezählt werden.. wie kann ich ein reines "delete" verhindern?

[ata]

... im Datenbankscript gibt es dazu das Event

QueryDocumentDelete

... die Variable Continue auf False setzen

continue = False

... somit sind generell alle Löschungen unterbunden. wenn du es einschränken möchtest, mußt du eben noch die entsprechenden Fälle behandeln...

ata

[feel_x]

hm.
Ein User soll ein Dokument nicht direkt löschen können,
sondern nur einen Agenten anstoßen dürfen, der die Löschung vornimmt und ein paar Feldwerte ändert.

wie ist die Logik?
Der Agent muss also Löschrecht haben und der User muss den Agenten benutzen können?
Muss ich nachher mal ausprobieren..

[ata]

... der Agent muß mit einer ID signiert werden, welche die erforderlichen Rechte hat...


ata

[feel_x]

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.

Kann mir da nochmal jemand helfen?
Ich habe in der Seminar-DB aus der Sandbox das hier gefunden:
Was muss ich ändern: View "Class Description" und Feld "Current Enrollment"?
Oder ist das skript viel zu kompliziert und das wäre einfacher zu lösen?
Es geht darum, dass beim Hauptdokument ein Feld runtergezählt wird, wenn ein Antwortdokument erstellt wird..


Sub Click(Source As Button)
   Dim workspace As New NotesUIWorkspace
   Dim Session As New NotesSession
   Dim Db As NotesDatabase
   Dim View As NotesView
   Dim User As Variant
   Dim RegUIDoc As NotesUIDocument
   Dim RegDoc As NotesDocument
   Dim ClassDoc As NotesDocument
   Dim CurrentEnrollment As Variant
   Dim NewEnrollment As Variant
   Dim RefreshAgent As NotesAgent
   
   Set Db = Session.CurrentDatabase
   User = Session.UserName
   Set RegUIDoc = Workspace.CurrentDocument
   Set view = Db.GetView("ClassDescriptions")    
   Set RegDoc = RegUIDoc.Document
   Call RegUIDoc.Save
   
   Dim parentUnid As String
   parentUnid = RegDoc.ParentDocumentUNID
   Set ClassDoc = Db.GetDocumentByUNID( parentUnid)    
   CurrentEnrollment = ClassDoc.Enrollment  
   NewEnrollment = CurrentEnrollment(0) + 1
   ClassDoc.Enrollment = NewEnrollment
   Call ClassDoc.Save(False,False)
   Call RegUIDoc.Close
   Call View.Refresh
End Sub

[feel_x]

... der Agent muß mit einer ID signiert werden, welche die erforderlichen Rechte hat...


ata

wie mache ich das?
Muss ich die ID einer Person zum editieren des Agenten benutzen,
oder kann ich die ID an einer bestimmten Stelle manuell in den Agenten eintragen?

[ata]

... du kannst entweder den Agenten von einer Person speichern lassen, die entsprechende Rechte hat, oder die DB auf dem Server mit einer ID unterszeichen...

ata