[Allegro] ORDER: "Auftraggeber" bei Bestellung

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eger, liebe Liste,


> ich würde folgenden Weg gehen:
> 
> - Die Bestellung setzt einen Titelsatz voraus, dem ein 
>   Bestellsatz zugeordnet ist.
> - Auf den Titel wird eine (Titel-)Vormerkung angelegt.
> - Wenn ein Exemplar nach Bestelleingang inventarisiert wird,
>   wird die Titelvormerkung wirksam und das Exemplar sofort 
>   reserviert. Danach entspricht der Ablauf dem Üblichen.
> 
> Eine Reservierung oder Vormerkung gegen Stornierung
> durch den Leser zu schützen / zu sperren scheint interessant.
> Könnte der Zustand "Vormerkung auf Titel, zu dem es noch kein
> Exemplar gibt" evtl. als Sperrbedingung verwendet werden?


D.h. was den Geschaeftsgang angeht: Im Formular fuer die Bestellung den
Auftraggeber-Vormerker abfragen, wurde etwas eingegeben, dann wird automatisch
ein Datensatz fuer eine titelgebundene Vormerkung angelegt.

Vorteil 1: wird ein anderes Exemplar schneller frei als die Bestellung
  einlaeuft, kommt der Besteller u.U. schneller an die Literatur

Nachteil 1: Der Besteller wollte eigentlich ein "eigenes" frisches
  Exemplar fuer den langfristigen dienstlichen Gebrauch

Nachteil 2: Das erfordert ALF(-Vormerkungen) obwohl man u.U.
  mit ALFA-(Entleihen) auskaeme.

Nachteil 3: Nach meinem Eindruck werden in der konkreten Bibliothek
  die Auftraggeber einer Bestellung sofort bei Eingang telefonisch
  benachrichtigt, bei normalen Vormerkungen waere man wohl etwas
  laessiger

Vergleich von "Vorteil 1" und "Nachteil 1" zeigt, dass es wohl schwer
sein wird, eine universelle Loesung zu implementieren...

Auch wenn jede Bibliothek diesen Fall wohl analog irgendeinem anderen
Fall abhandelt, wuerde ich dazu tendieren, ihn systemseitig recht lange
als "verschieden" zu behandeln (und damit die systemseitige Festlegung
vermeiden, dass es stets und Bibliotheksunabhaengig dieser oder jener
Fall ist)


> Von den Lösungen zum Auftraggeber (AG) <-> Leser-Problem:
> 
> A) Person als Leser und AG doppelt führen (trivial)
> B) eine "intelligente" Erkennung in die Parameter, die Leser
>    UND AG erkennt und unterscheidet
> C) Leser und AG erhalten gleiche Satzstruktur 
> 
> würde ich B) aussondern.
> 
> C) fände ich für die Zukunft interessant: Was wäre, wenn man 
> für Auftraggeber die Leserstammsatz- struktur verwenden würde? 
> (Voraussetzung: DOS-ORDER wird nicht mehr eingesetzt) 
> Institutionen sind als "Leser" nicht ungewöhnlich.

Hier muss man wohl zunaechst einmal Formatexegese betreiben.
Die "Auftraggeber" des DOS-ORDER sind wohl niemals als natuerliche
Personen gedacht gewesen, sondern die Filialen etc., die andere
Systeme derzeit meist als "Mandanten" bezeichnen (ebenfalls niemals
natuerliche Personen ;-)

Institutionen als Leser sind tatsaechlich nicht ungewoehnlich, wegen
realer Benutzungsordnungen aber i.A. nicht zugelassen. D.h. es leiht
dann doch immer die Person X aus und alle wissen dass das fuer die
Institution Y ist (was natuerlich bedeutet, dass im Satz fuer den Leser
insbesondere Raum fuer die vollen institutionellen Angaben sein muss).
Ganz anders kann das aber aussehen, wenn eine Art "kleine Fernleihe"
praktiziert wird...

[und zu meinem urspruenglichen Problem: Es ist durchaus eine Abteilung/
ein Projekt als "Auftraggeber" im ORDER-Sinn denkbar und gleichzeitig
ein konkreter Mitarbeiter dieser Abteilung als Besteller-Vormerker.
Man kann zwar oft die ORDER-Auftraggeber als Kontingente modellieren
(und umgekehrt), aber nicht immer, das ist oft jenseits des Einflusses
der Bibliothek und dadurch bestimmt, welche "Zahlen" sie nach oben
liefern muss (und kann sich ueberraschend haeufig aendern :-(]


> Das Ändern der Flexe und Parameterdateien wäre recht leicht zu 
> bewerkstelligen, das Teilfeld l (klein Ell) ist im Leserstamm 
> noch frei, die Zweitadresse im Leserstamm könnte als Lieferadresse 
> Verwendung finden.
> Die Datenkonvertierung müßte nur alle Auftraggeberstämme in 
> Leserstammsätze konvertieren. Diese könnten sogar die AG-Kürzel
> als "Lesernummer" behalten.
> 
> Weiterer Vorteil: Es würden sich für den Schriftverkehr auf Grund
> der gleichen Satzstruktur bessere Modularisierungsmöglichkeiten
> ergeben.

Genau wie Sie sehe ich keine Schwierigkeit, sowohl "Auftraggeber" (in
welcher Bedeutung fuer die jeweilige Bibliothek das jeweils aufgefasst
werden mag) als auch Leser aus demselben Pool von Personen / Koerperschaften
und "Personen fuer Koerperschaften" etc. zu bedienen.

Vermutlich kommt man nicht umhin (vgl. auch meine urspruengliche Mail zur
hardcodierten Leserklasse 5 als Kandidaten fuer die Teilnahme an Umlauf-
verfahren) im Stammsatz eine von der bekanntlich frei vergebbaren
Leserklasse unabhaengige Codierung (bzw. Vergabe von kumulierenden "Attributen")
fuer die Geschaeftsgangssteuerung einzufuehren (interne vs. externe Nutzer
und/oder "Auftraggeberfaehigkeit", "Verteilerfaehigkeit", ...).

Ich koennte mir vorstellen, in einem Unterfeld in Form von vielen, durch Spatium
getrennten Kuerzeln den Datensatz zu charakterisieren, folgende koennten dabei
systemseitig reserviert sein:

KOR  - Institution (Einfluss auf Anrede)
DUZ  - geduzte Person in Anrede (Kinder, Kollegen)

INT  - Interne (Mitarbeiter)
EXT  - Externe

AFT  - Als Auftraggeber erlaubt

UML  - Fuer Umlauf erlaubt

...

Leider kennen die Formulare keine Checkboxes, daher muss manuell eingegeben
werden...

Hier gibt es dann in jeweils viele Interdependenzen, die mangels einer
Sprache fuer Geschaeftsgangssteuerung dann u.U. individuell programmiert
werden muessen. Wenn z.B. in einer Bibliothek "INT" direkt AFT und UML
impliziert, oder "EXT" sofort eine bestimmte Leserklasse bedeutet, waere
es Quatsch, pleonastische Eingaben zu erfordern (die dann nur die Chance
bergen, in Bezug auf die konkreten Geschaeftsgaenge der konkreten Bibliothek
widerspruechliche Information in die Datensaetze zu bringen). Aber eine
flexgesteuerte? Nachbearbeitung der Eingaben fuer dieses Feld koennte alle
individuellen Regeln in einer Flexdatei zusammenfassen, so dass Eingriffe
in die diversen Flexe von ALF und ORDER nur noetig werden, wenn man lokal
weitere Attribute einfuehrt.

[Wir haben nur beschraenkte Moeglichkeiten, bei konkreten Eingaben Flexe
zu triggern, und die PV als wirklich schwierig zu parametrierender Bereich
in den Indexparametern scheidet m.E. voellig aus, um solche "weichen",
anwendungsspezifischen Regeln zu realisieren. Die Flexsprache gibt uns
auch keine Moeglichkeit, gezielt darauf zu testen, ob einzelne Kategorien
oder Unterfelder geaendert wurden. Wenn man aber die Bearbeitung der
Regeln zur "Geschaeftsgslogik" (also implizite Abhaengigkeiten fuer die
spaetere Verarbeitung explizit machen) als Flex-Include anlegt, kommt
man m.E. mit der Einbindung in onforms.flx, input.flx und wenige Stellen
innerhalb des ALF/ORDER/ZAboM-Flexverhaus aus. Damit waere das auch
schoen "gekapselt", d.h. wenn mittelfristig doch noch eine Syntax fuer
die Abbildung von Geschaeftsgaengen gefunden wird ("attr=EXT => lklass=3"),
muss nur dieses Flex-Include ausgetauscht werden...]

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBSs2jlmITJZieluOzAQLQ0AQAl4OfffDA6pFT+2h9SHmkEG/oMIH6xgan
s1anGdI/cwltc+vmab6TE5dN7uM8Y6scUqPC/3iO2lwQZZHYy6EyzT2Adyb7W9mv
L/qlcgKvat9HIVt4HeIBYHZlLdQD9QC80IwqaouvvCf8IdOG5wyo3nkZ3G+lhBFD
QQlgIgFhJf4=
=BJ1w
-----END PGP SIGNATURE-----