[Allegro] ORDER: "Auftraggeber" bei Bestellung

Do Okt 8 12:22:52 CEST 2009

Hallo Herr Berger, Liebe Listenleserinnen und -leser,

Herr Berger schrieb u.a.:

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

das erfordert wohl einen neuen Vormerkungstyp 

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

Ja, wass will ich ? Ich muß mich wie immer entscheiden zwischen:
- einer kleinen, einfachen, dann aber speziell zugeschnittenen 
  Lösung (Q&D ;-)
oder
- einem allgemeinen Ansatz, der alle schon bekannten Varianten
  abdeckt und für neue leicht erweiterbar ist (und die
  "einfachen" Nutzungsvarianten als Teilmenge enthält)

Als Dienstleister strebt man doch Lösungen an, deren 
anwenderspezifische Bestandteile (die damit 'pro Anwender' zu 
pflegen sind) möglichst klein ausfallen.

Über die erste Alternative brauchen wir nicht zu reden, für
die Umsetzung der zweiten wäre zu entscheiden:
- Migration in vielen kleinen Teilschritten (der gegenwärtige Weg)
oder
- Entwurf einer komplett neuen Struktur (Software und Daten)

In der Summe würde die zweite Umsetzungsalternative viel Zeit 
sparen - wenn wir (Entwicklungsabteilung u. Dienstleister) es
schaffen, dafür eine neue Spezifikation abzustimmen.

Ich bin auf das Expertentreffen gespannt ...

Viele Grüße
Anando Eger

---------------------------------------------------------------------
Anando Eger Datenverarbeitung
Herr Dipl.-Ing. Anando Eger
Gustav-Voigt-Str. 24
01156 Dresden
Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
---------------------------------------------------------------------

On 8 Oct 2009 at 10:32, Thomas Berger wrote:

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