Skip to end of banner
Go to start of banner

Erwerbungsdaten in Exemplarsätzen ohne Bestellung - Funktionsanalyse

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Auf dieser Seite wird die Funktionsanalyse bezüglich der Erwerbungsdaten in Exemplarsätzen ohne Bestellung beschrieben.

Inhalt

Übersicht und Status

Status

FUNKTIONSANALYSE ABGESCHLOSSEN

Kategorie

FELD FUNKTION

Ersteller

SLUB DRESDEN 

Unterstützer

- 

Beginn

 

André Hohmann : FUNKTIONSANALYSE ABGESCHLOSSEN, weil die gewünschte Funktionalität vermutlich in Inventarisierung ohne Bestellung - Funktionsanalyse enthalten ist. Wenn sich die Vermutung bestätigt, muss die weitere Diskussion auf der Seite Inventarisierung ohne Bestellung - Funktionsanalyse fortgeführt werden.  

Funktionsanalyse

Beschreibung

In der SLUB Dresden werden bisher in den Exemplardaten bestimmte Erwerbungsdaten eingetragen, wenn keine Bestellung zu den Exemplaren vorhanden ist. Die Erwerbungsdaten werden in die gleichen Felder eingetragen, in die auch die Werte aus der Bestellung übernommen werden. Dadurch werden Auswertungen, Reports, vereinfacht, weil immer die gleichen Felder ausgewertet werden können. Dies betrifft: 

  • Erwerbungsdatum
  • Erwerbungsart
  • Lieferantencode + Lieferantenname + Verlinkung zum Lieferantendatensatz

Anwendungsfälle/-bereiche

  • Geschenke
  • Tausch
  • Retrokatalogisierung/konversion, ...

In FOLIO werden in den Exemplardaten die Erwerbungsdaten nur angezeigt, wenn eine Bestellung vorhanden ist. Es ist nicht möglich, Erwerbungsdaten zu erfassen, wenn keine Bestellung vorhanden ist. 

Möglichkeiten

Es stehen folgende Möglichkeiten zur Verfügung, um in FOLIO Erwerbungsdaten in Exemplaren ohne Bestellung zu erfassen. 

  1. Bearbeitung der Felder in dem Accordion "Erwerbung"
    • Die Felder in dem Accordion "Erwerbung" sind auch ohne Verknüpfung zur Bestellung verfügbar und können manuell bearbeitet werden. 
    • Die Felder haben intern und im UI dieselbe Bezeichnung wie bei der Verknüpfung zur Bestellung, um die Abfragen und Reports zu erleichtern
  2. Benutzerdefinierte Felder 
    • Benutzerdefinierte Felder könnten genutzt werden, um je nach Einrichtung die benötigten Felder zu konfigurieren
    • Dafür müsste das Jira-Ticket UXPROD-396 - Getting issue details... STATUS - Custom Fields unterstützt werden. Ticket für Inventory-Entitäten:  UXPROD-2211 - Getting issue details... STATUS
  3. Eigenes Akkordeon mit Auswahl Erwerbungstyp, Lieferantencode, ...
    • Es wird ein weiteres Accordion (zum Beispiel "Erwerbung ohne Bestellung") erstellt, das die gleichen Felder enthält wie das Accordion "Erwerbung", die jedoch manuell bearbeitet werden können
  4. Es werden Bestelldatensätze für alle Exemplare angelegt, so dass keine zusätzlichen Felder erstellt werden müssen
    • Diese Möglichkeit erfordert keine technische Entwicklung
  5. Erfassung der Bestelldaten in Holdings- oder Item-Notes (Felix Hemme)
    • In den Inventory-Settings werden Note Types für Holdings- oder Items angelegt, z. B. Erwerbungsart, Erwerbungsdatum, Lieferantencode
    • Beim Anlegen eines Holdings oder Items können die Anmerkungstypen ausgewählt und in diese Felder die entsprechenden Daten eingetragen werden
    • Zusätzlich kann man zur einfachen Abfrage der Datensätze ohne Bestellung in Orders einen Statistical Code anlegen, z. B. 
      • Statistical Code Type: ACQ (Erwerbung)
      • Statistical Code: Keine Bestellung in Orders
    • Zu prüfen: Wie können diese Daten in Statistiken eingehen?
  6. Erwerbungsdaten werden bei der Inventarisierung erfasst (aus Bestellung) mit Möglichkeit, auch ohne Bestellung zu inventarisieren

Herausforderungen und Vorteile

MöglichkeitVorteilHerausforderung
1
  • Nutzerfreundliche Erfassung der jeweiligen Werte
  • Auswertungen und Reports beziehen sich immer auf die gleichen Felder 
  • Manipulation der verlinkten Daten aus Bestellungen muss verhindert werden
  • Gegebenenfalls sind komplexe Aktualisierungen zwischen den Apps, ... notwendig
2
  • Flexible Konfiguration der jeweils benötigten Felder und Auswahlwerte
  • Bei Reports und Auswertungen müssen alle relevanten Felder korrekt berücksichtigt werden
3
  • Einheitlichkeit der Felder
  • Gegebenenfalls kann dadurch die Erstellung von Auswertungen und Reports erleichtert werden
  • Zusätzliche Entwicklungsarbeit
  • Unflexible Anwendung (Erweiterung, Anpassung... der Felder oder Auswahlwerte)
4
  • Keine technische Entwicklung möglich
  • Einheitliche Datenstruktur
  • Hoher Aufwand bezüglich der manuellen Erstellung der Bestellungen
  • Hoher Aufwand bei Migration der Altdaten ohne Bestellung → Müssen Bestellungen maschinell erzeugt werden?
5
  • Heute umsetzbar, keine zusätzliche Entwicklung erforderlich, pro Institution parametrisierbar
  • Notes speichern reinen Text, d. h. die Eingabe ist auch reiner Text. Man muss darauf achten, dass keine Tippfehler entstehen. Im ACQ und OUS nutzen wir dafür aktuell Autohotkey-Macros, das könnte hierfür auch eine Hilfe sein.
6
  • Eine gemeinsame Stelle fürs Reporting
  • Automatische Übernahme der Daten aus Bestellung und manuelle Eingabe vermutlich möglich
  • Eine Entwicklung ist notwendig

Weitere Informationen

Anforderungsanalyse

  • -

Relevante Funktionsanalysen

Besprechung in einer D-Gruppe

Relevante vorhandene Jira-Tickets

key summary type created updated due assignee reporter priority status resolution
Loading...
Refresh


  • No labels