Beschreibung SuperX-IVS-Modul

SuperX-Admin-Handbuch IVS-Modul

www.MemText.de     Supportadresse support@superx-projekt.de

http://www.superx-projekt.de

Sun, Sun Microsystems, Solaris, Java, JavaServer Web Development Kit, JDBC und JavaServer Pages sind eingetragene Warenzeichen von Sun Microsystems, Inc. UNIX ist ein eingetragenes Warenzeichen von X/Open Company, Ltd. Windows, WindowsNT, Win32, VBScript und Office 2000 sind eingetragene Warenzeichen von Microsoft Corp. Linux ist eingetragenes Warenzeichen von Linus Torvalds. Alle weiteren Produktnamen sind Warenzeichen der jeweiligen Hersteller.

Dieses Produkt beinhaltet Software, die von der Apache Software Foundation ( http://www.apache.org/ ) entwickelt wurde.

SuperX wird unter der deutschen Variante der GPL-Lizenz von dem Land Nordrhein-Westfalen, vertreten durch die FernUniversität Hagen, diese wiederum vertreten durch die Geschäftsstelle der Initiative CampusSource bei der FernUniversität Hagen, Feithstraße 142, D-58084 Hagen vertrieben ( www.campussource.de ). Details zu den Lizenzbedingungen finden Sie im Kernmodul-Archiv (/lizenz.txt) oder unter http://www.campussource.de/lizenz/ . Ergänzende Hinweise finden Sie auf der Projekthomepage unter http://www.superx-projekt.de .

1 Einführung

Das Berichtssystem SuperX ist ein sog. Data Warehouse, d.h. beiliebig viele Datenquellen werden unter einer einheitlichen Auswertungsschnittstelle zur Verfügung gestellt. Da jede Hochschule unterschiedliche Datenquellen besitzt und in SuperX übernehmen will, bereiten wir für jede Datenquelle ein Modul vor, z.B. ein COB-Modul oder ein IVS-Modul.

Die Module enthalten die wichtigsten Prozeduren, Tabellen und Abfragen für die jeweilige Datenquelle. Folgende Tabellen sind generell zu unterscheiden:

• • Datentabellen enthalten die entladenen Basisdaten  

• • Hilfstabellen enthalten aggregierte Datentabellen und werden von den Abfragen genutzt. Durch Hilfstabellen wird die Performance der Abfragen besser. 

• • Schlüsseltabellen enthalten Schlüssel und Metadaten, z.B. Anklageklassen. 

Das IVS-Modul besteht im Endzustand aus Tabellen, Prozeduren und Abfragen.

Hinweis: Bei diesen Tabellen handelt es sich nur um einen kleinen Auszug aus dem Datenmodell in FSV-GX / IVS. Das Modul ist also nur ein "Minimal"-Paket, das dazu dient, den Anlagespiegel zu erzeugen. Zu einem späteren Zeitpunkt kann das Modul erweitert werden.

Neuigkeiten zu dieser Version finden Sie im Abschnitt Versionshistorie .

Falls es bei der Implementation des IVS-Moduls zu Problemen kommt, können Sie sich unter www.superx-projekt.de informieren. Oder mailen Sie uns direkt:

Supportadresse allgemein:
support@superx-projekt.de

2 Hintergrund FSV-GX Modul IVS Erweiterung

Das SuperX IVS-Modul ist nur mit einer FSV Version nutzbar, die alle Grundlagen für den Anlagenspiegel bereitstellt.

• • Erzeugung der Datengrundlage für den Anlagespiegel (Tabelle ivasp in FSV-GX und ivasp_bga in HIS-FIBU) inkl. Prüfroutine 

• • Konzept und Realisierung der Pflege von wertbeständigen Gütern im Anlagespiegel.
    Achtung: dies ist technisch erst im kommenden FSV-Release (Geplant: 06-2009) möglich. 

Dabei ist die Anmerkung im FSV-IVS-Handbuch zu beachten:

***

    *   Inventarisierte Güter dürfen nicht mit einer Anzahl > 1 verbucht werden.

    *   Der IVS-Anlagenspiegel berücksichtigt keine Umbuchungen. Es kann also sein, daß in einer Kostenstelle ein Gerät enthalten ist, das früher einer anderen Kostenstelle gehörte. Die früher erzeugten Abschreibungen für dieses Gerät werden dann für die frühere Kostenstelle ausgewiesen.

    * Auf der letzten Seite des IVS-Anlagenspiegels werden Summen über alle Gruppierungen hinweg angezeigt, also die Daten der gesamten Hochschule, falls bei der Suche nicht über das Jahr hinaus Einschränkungen vorgenommen wurden. Da auf diese Weise Umbuchungen innerhalb der Hochschule keine Rolle mehr spielen, kann mittels der Gesamtsumme die Plausibilität des Anlagenspiegels überprüft werden!

***

Das bedeutet: Die einzelnen Zeilen des Anlagenspiegels werden den genannten Berechnungen nicht immer gerecht. Immer passen müssten die Werte allerdings in der Gesamtsumme am Ende des Anlagenspiegels, sonst stimmt etwas nicht. Ausnahme: Da die Abschreibungen in den beiden Spalten nicht theoretisch berechnet, sondern tatsächlich addiert werden, stimmen noch eine zeitlang die "bis"-Werte nicht, sondern dürften regelmäßig zu niedrig sein. Grund: Irgendwann in der Vergangenheit hat die Hochschule den ersten Abschreibunglauf überhaupt durchgeführt, z.B. für das Jahr 2004. Dann gibt es für die Vorjahre von 2004 keine Abschreibungen, die in die Addition mit einfließen können. Bei den Restwerten werden diese Beträge aber natürlich berücksichtigt. Außerdem können die auf Abgänge entfallenden Abschreibungen nicht herausgerechnet werden.

Im Beispiel wird sich diese scheinbare Inkonsistenz erst dann erledigt haben, wenn es keine Geräte mit Inbetriebnahmedatum vor 2004 mehr im Bestand geben wird.

3 Installation des IVS-Moduls

3.1 Voraussetzungen

Das IVS-Modul läuft serverseitig unter folgenden Voraussetzungen:

• • Informix Dynamic Server 7.31 oder höher bzw. Postgres 7.3 oder höher 

• • Betriebssystem Linux (Suse oder Redhat) oder Cygwin mit Bourne Again Shell (bash).  

• • Das SuperX-Kernmodul 3.5 oder höher 1  

• • Als Datenquelle sind Scripte für HISFSV 11.x oder höher unter Informix bzw. Postgres mitgeliefert. Die Schnittstelle kann aber auch aus anderen Datenquellen bedient werden. 

   

3.2 Kurzanleitung

Folgende Arbeitsschritte sind in der typischen Umgebung (IVS läuft unter Informix / Postgres) notwendig:

1. 1. Zunächst entpacken Sie das Archiv ivs<<Versionsnr>>_superx_<<Encodierung>>_<<Datenbanksystem>>.tar.gz als User superx (nicht als root) an der Stelle $SUPERX_DIR. Die Variable <<Encodierung>> kann "iso" oder "utf8" sein. Die Locale beim Entpacken (Variable LANG) sollte dieser Encodierung entsprechen.  

2. 2. Einrichtung der IVS-bezogenen Umgebungsvariablen - Prüfen Sie ob in Ihrer $SUPERX_DIR/db/bin/SQL_ENV alle Einträge aus SQL_ENV.IVS.sam vorhanden sind, ggfs. rüberkopieren ). Aktivieren Sie die Umgebung mit
   . $SUPERX_DIR/db/bin/SQL_ENV  

3. 3. Benennen Sie die Datei $SUPERX_DIR/db/module/ivs/rohdaten/IVS_ENV.sam nach IVS_ENV um und passen Sie die Umgebungsvariablen für den FSV-Datenbankrechner an.  

4. 4. Entscheiden Sie sich zunächst für ein "Push"- oder "Pull"-Verfahrne beim Entladen. Die häufigsten Modi sind erfahrungsgemäß: "Push" bei IVS unter Informix (Unix), "Pull" bei allen andere Systemen.
   Beim Entladen aus IVS unter Informix im "Push"-Modus: Kopieren sie den Verzeichnisinhalt unter $SUPERX_DIR/db/module/ivs/rohdaten zum IVS-Rechner, bzw. mounten Sie das Verzeichnis auf dem SuperX-Rechner 2 . Laden und testen Sie dann die Umgebung in IVS_ENV.
   Beim Entladen aus IVS unter Postgres im "Pull"-Modus: Laden Sie die Umgebung in IVS_ENV und richten Sie mit dem propadmin.x die Datenbankverbindung zum IVS-Rechner ein. Achten Sie bei Postgres darauf, dass bei FSV ab Version 12 die Variable
   JDBC_PARAM="set search_path to mbs;"
   gestetzt sein muss (siehe Musterdatei IVS_ENV.sam ). 

5. 5. Ausführen des Entladescripts $SUPERX_DIR/db/module/IVS/rohdaten/ivs_unload.x für die Basisdaten. Ggf. Kopieren des Rohdaten-Verzeichnis der entladenen IVS-Daten nach $SUPERX_DIR/db/module/ivs/rohdaten
   Ein Scripte dafür heißt ivs_copy.x  

6. 6. Laden Sie für die folgenden Schritte die Umgebung für SuperX
   . $SUPERX_DIR/db/bin/SQL_ENV
   Erzeugen des IVS-Moduls in der SuperX-Datenbank:
   $SUPERX_DIR/db/module/ivs/ivs_modul_erzeugen.x
   Falls ein Fehler auftritt, versuchen Sie die Ursache zu beheben, starten Sie dann
   $SUPERX_DIR/db/module/ivs/ivs_modul_entfernen.x
   (etwaige Fehler können normalerweise ignoriert werden)
   und anschließend erneut
   $SUPERX_DIR/db/module/ivs/ivs_modul_erzeugen.x
    

7. 7. Nur wenn Sie Tomcat auf einem separaten Rechner betreiben: Fügen Sie den Inhalt der Datei
   $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/ivs_dbforms_config_<<pg für Postgres oder ids für Informix)>>.xml vom Kommentar "<!--Hier beginnt Moduldefinition-->" bis zum Kommentar "<!--Hier endet Moduldefinition-->" in Ihre dbforms-config.xml ein.
   Danach starten Sie Tomcat neu. 

8. 8. Übernahme der entladenen IVS-Daten nach SuperX:
   $SUPERX_DIR/db/module/ivs/ivs_update.x
    

9. 9. Prüfen des Update, Testen der Abfragen 

10. 10. Schritt 10 kann jede Nacht wiederholt werden. Dazu muss der Entladerhythmus geplant werden, und die Cronjobs werden eingerichtet.  

3.3 Installation des IVS-Moduls

Zunächst müssen die Rohdaten aus IVS entladen werden. Danach wird die Umgebung eingerichtet, und das Modul kann installiert werden.

3.3.1 Entladen der IVS-Daten

3.3.1.1 Allgemeines

Beim Entladen der IVS-Daten werden Datentabellen und Schlüsseltabellen entladen, um sie nach SuperX zu übernehmen.

Wichtig ist, daß der Anlagespiegel für die komplette Hochschule in IVS generiert wurde. Eine Anleitung dazu finden Sie hier:

http://wiki.his.de/mediawiki/index.php/Inventarverwaltung#Dialog_zur_Selektion_der_Daten_f.C3.BCr_einen_Anlagenspiegel

Falls dieser Dialog nicht verfügbar ist, konfigurieren Sie ihn bitte in eine Aufgabe hinein, z.B. in die Aufgabe "Inventarisierung". Sie können auch die vorkonfigurierte Aufgabe "IVS   -Anlagenspiegel" importieren und einem Menü hinzufügen. Nach der Verwendung des Dialogs "IVS - Auswertung für Anlagenspiegel" ist die Tabelle "ivasp" gefüllt.

Für das Entladen gibt es ferner zwei Modi : Das "Pull"-Verfahren und das "Push"-Verfahren.

• • Beim "Pull"- Verfahren wird einer Benutzerkennung auf dem SuperX-Rechner Zugriffsrecht auf die IVS-Datenbank gegeben, und die Daten werden via TCP/IP aus dem Basissystem entladen. 

• • Beim "Push"- Verfahren werden die Entladescripte auf den IVS-Rechner kopiert und dort von einer Benutzerkennung auf dem IVS-Rechner ausgeführt. Die Rohdaten müssen dann auf den SuperX-Rechner kopiert werden. Dieses Verfahren klappt bei Informix unter Unix problemlos, bei Entladen aus Postgres müsste das komplette SuperX-Kernmodul installiert werden. 

Am einfachsten ist immer das "Pull"-Verfahren, das mit fast allen Quellsystemen funktioniert und wenig Konfiguration auf dem Quellsystem erfordert. Aufgrund von Sicherheitsvorkehrungen oder Netz-Infrastrukturen wählen aber viele Hochschulen das "Push"-Verfahren. Da derzeit Informix /Unix die gängigste Plattform an Hochschulen ist, ist dies auch kein Problem.

3.3.1.2 Einrichtung der Entladescripte

Das Entladescripte für die IVS-Tabellen liegen im Verzeichnis $SUPERX_DIR/db/module/IVS/rohdaten   und lautet ivs_unload.x

3.3.1.2.1 Entladen unter Postgres oder Informix / UNIX

Am einfachsten ist es, wenn Sie als User superx vom SuperX-Server direkt auf den FSV-Datenbankserver zugreifen und entladen können ("Pull"-Verfahren). Dann ist es sogar egal ob Sie IVS unter Informix f. Win., Informix f. Unix oder Postgres einsetzen; außerdem brauchen Sie die Dateien dann nicht vom IVS-Rechner nach SuperX kopieren.

Für Postgres ist dies auch deshalb die einfachste Lösung, weil zum Entladen aus Postgres die Bibliotheken des SuperX-Kernmoduls vorhanden sein müssen.

Für Informix ist auch das Entladen im "Push"-Verfahren möglich: kopieren Sie den gesamten Verzeichnisinhalt ab $IVS_PFAD/rohdaten auf den FSV-Rechner, geben Sie dem Script Ausführungsrechte. Die Scripte laufen nur, wenn die entsprechenden Umgebungsvariablen in der Datei IVS_ENV (im gleichen Verzeichnis, ein Muster liegt vor in IVS_ENV.sam) korrekt gesetzt sind, benennen Sie die Musterdatei um nach IVS_ENV und tragen die richtigen Umgebungsvariablen ein, z.B. den Pfad für $INFORMIXDIR ,

In der   IVS_ENV müssen   folgende Umgebungsvariablen gesetzt werden (defaults sind bereits vorbelegt, aber hier und da müssen Sie sicher ran):

Hintergrund der letzten beiden Variablen: Mit FSV 12 wurden die drei Datenbanken COB, SVA und MBS in einer Datenbank "hisrm"   integriert, und SQL-Zugriffe auf das jew. Segment werden immer mit dem Präfix " set search_path to <<Modulname>> " versehen. Damit wird unter Postgres das jew. Schema aktiviert.

Unter Postgres muss für das "Pull"-Verfahren beim Entladen die Datenbankverbindung in der Datei db-ivs.properties eingetragen werden (Muster für Postgres liegt bei in db- ivs_pg.properties.sam ). Dazu laden Sie einmal die Datei IVS_ENV mit den obigen Parameter, starten den SuperX-Propadmin (siehe Administrationshandbuch Kernmodul) und richten die Verbindung zum IVS-Server ein. Das Kennwort wird verschlüsselt gespeichert. Danach sind die Entladescripte für Postgres ausführbar.

Hinweis: Anders als Informix hat Postgres hat eine eigene, vom Basissystem unabhängige Benutzerverwaltung. Daher brauchen Sie den User, den Sie zum Entladen aus Postgres nutzen, nicht auf dem SuperX- oder IVS-Rechner auf Betriebssystem-Ebene einrichten. Sie können also z.B. auf dem SuperX-Rechner zum Entladen aus IVS die Kennung IVS des Postgres- Rechners verwenden. Oder Sie richten in der IVS -Datenbank den Benutzer SuperX ein und geben ihm Leserecht auf die Tabellen sowie das Recht, Tabellen und Stored Procedures anzulegen.

Dann starten Sie das Script ivs_unload.x . Wenn es gelaufen ist, müssten die Dateien im unl -Verzeichnis stehen. Prüfen Sie dann bitte, ob dort Dateien mit 0 bytes stehen. Die Logdatei heisst IVS_unload.err .

3.3.1.2.2 Entladen unter Windows

Beim Einsatz von HISFSV unter Windows ( Postgres f. Win.   oder Informix f. Win) können dann via "Pull"-Verfahren (s.o.) entladen werden. Bei Systemen außer Informix muss in diesem Falle über jdbc entladen werden.

3.3.2 Erzeugen des IVS-Moduls

Die entladenen IVS-Daten müssen für die Installation in SuperX im Verzeichnis $SUPERX_DIR/db/module/ivs/rohdaten/unl stehen (auf dieses Verzeichnis zeigt die Umgebungsvariable IVS_LOAD_PFAD. Kopieren Sie die Daten dorthin, oder mounten Sie das Verzeichnis vom FSV-Rechner als NFS- oder Samba-Share)

Die Umgebungsvariablen des IVS-Moduls müssen in der Datei $SUPERX_DIR/db/bin/SQL_ENV eingetragen sein. Prüfen Sie, ob alle Einträge in der Musterdatei $SUPERX_DIR/db/bin/SQL_ENV_ivs.sam auch in Ihrer SQL_ENV vorhanden sind.

Standardmäßig brauchen Sie an diesen Parametern nichts ändern, lediglich der IVS_LOAD_PFAD und die Emailadressen für Logdateien müssen ggf. angepasst werden.

Danach ist das IVS-Modul installationsbereit.

1. 1. Melden Sie sich als Benutzer superx an, laden Sie die Umgebung mit
   . $SUPERX_DIR/db/bin/SQL_ENV  

2. 2. Wechseln Sie ins Verzeichnis
   cd $IVS_PFAD  

3. 3. Starten Sie das Skript
   ivs_modul_erzeugen.x
    

Neben dem Erstellen der Tabellen und Hinzufügen der Prozeduren und Abfragemasken, werden auch Einträge in den Themenbaum und die Tabelle sachgebiete gemacht.

Außerdem erhalten die Administrator-User superx und admin Zugriffsrechte für die neuen Sachgebiete Inventar und Administration Inventar

Falls ein Fehler auftritt, versuchen Sie die Ursache zu beheben, starten Sie dann
$SUPERX_DIR/db/module/ivs/ivs_modul_entfernen.x

(etwaige Fehler können dabei normalerweise ignoriert werden)
und anschließend erneut
$SUPERX_DIR/db/module/ivs/ivs_modul_erzeugen.x

3.3.3 Konfiguration nach der Installation

Einige Konfigurationen können nach der Installation vorgenommen werden. Im einfachsten Fall werden einfach nur Schalter in der Konstanten-Tabelle in SuperX unterschiedlich einge stellt . Schwieriger, aber gleichzeitig wesentlich flexibler ist die Konfiguration durch Zwischenschaltung beliebiger SQL-Befehle während oder nach dem Update.

Für alle wichtigen Konfigurationstabellen gibt es spezielle Bearbeitungsmasken; diese bekommen Sie, wenn Sie als Administrator im XML-Frontend die Maske Prüfprotokoll Inventar aufrufen und von dort einen der Links in der rechten Seitenleiste aufrufen.

3.3.3.1 Konstanten

Nach der Installation müssen ein paar Schlüssel kontrolliert bzw. angepasst werden. Die Konstanten aus dem IVS-Modul sind:

Sie sehen in der ersten Spalte der Tabelle die Vorbelegungen. Vor dem ersten Update in SuperX müssen diese Parameter jeweils gesetzt werden. Sie müssen dazu die Tabelle konstanten bearbeiten. Eine Bearbeitungsmaske bekommen Sie, wenn Sie im XML-Frontend die Maske Prüfprotokoll Inventar aufrufen und von dort den Link "Konstanten" aufrufen. Alter nativ können Sie die Konstanten in der Datenbank direkt bearbeiten, z.B. mit isql, psql oder einem beliebigen anderen Datenbank-Client.

3.3.3.2 Hochschulspezifische Anpassungen beim Update

Es sind bei Bedarf auch Anpassungen der Daten per SQL-Skript möglich. Hier wird auf das Kernmodulhandbuch sowie als Beispiel das Handbuch zum SOS-Modul verwiesen.

Insbesondere hat es sich gezeigt, dass in FSV nicht alle Datensätze mit einer Kostenstelle versehen werden, in SuperX wird dafür der oberste Knoten des Kostenstellenbaums eingetragen (root), falls Sie für diese Datensätze eine andere Kostenstelle eintragen wollen, tragen Sie z.B. in $IVS_PFAD/preparation.sql ein

update ivs_asp_neu set asp_kostenstelle='xyz' where asp_kostenstelle is null;

3.3.3.3 Anpassungen zur Inventarliste

Es gibt eine Repository-Variable CUSTOM_27050 in der definiert ist, welche Spalten bei detaillierter und kompakt-Ansicht dargestellt werden soll.

Standardmäßig kontrolliert der Bericht die Kostenstellenberechtigung auf die Spalte ivst_inst.

Wenn eine andere Spalte zur Kostenstellenkontrolle benutzt werden soll, kann man in der CUSTOM_27050 eine definieren, z.B.

<#assign kostenstellenfeld='splitkst'/>

3.3.4 Upgrade des IVS-Moduls

Zum Upgrade bzw. zum Zurücksetzen des Moduls auf den Auslieferungszustand entpacken Sie das Paket in $SUPERX_DIR und gehen in das Verzeichnis $SUPERX_DIR/db/module/ivs/upgrade und führen das Script aus:

ivs_upgrade.x

Die Logdatei lautet upgrade.log , im Mandantenfähigen Betrieb " upgrade<<MANDANTID>>.log ".

Wenn Sie einen separaten Tomcat-Rechner betreiben, müssen Sie das SVA-Paket dort ebenfalls entpacken, und vom Datenbankserver die Datei $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/dbforms-config.xml an die gleiche Stelle auf den Tomcat Rechner kopieren. Ein nochmaliges Ausführen des Upgrade Scriptes ist nicht nötig, weil dies nur die Datenbank betrifft.

3.4 Einladen der IVS-Daten nach SuperX

Zum Übernahme der Basisdaten nach SuperX wird das Script $IVS_PFAD/ivs_update.x . gestartet. Darin werden die Datentabellen gefüllt bzw.aktualisiert, und die Hilfstabellen neu erzeugt.

Bei der Installation ist es sinnvoll, zuerst einen Testlauf mit nur wenigen Rohdaten zu machen. Geben Sie dazu im Verzeichnis $IVS_PFAD ein:
ivs_shrink.x

Die Rohdaten werden auf 100 Sätze pro Tabelle reduziert. Prüfen Sie zunächst, ob das Ladescript ohne Fehler gelaufen ist. Wenn kein Fehler aufgetreten ist, machen Sie die Verkürzung der Rohdaten rückgängig mit
ivs_unshrink.x

Danach können Sie den "richtigen" Update starten.

3.4.1 Erste Datenkontrolle

3.4.1.1 Validierung gegen den FSV Anlagespiegel

Nach dem ersten Update in SuperX IVS sollten Sie die Gültigkeit des Anlagespiegels prüfen.   Hier ein Muster der Ausgabe in FSV:

 

Es werden die Anlagedaten nach Kostenart aufgeführt.

In SuperX sieht das so aus (Beispieldaten):

 

Die Differenzen liegen in der Darstellung und sind nur marginal: Die Anlagedaten werden nach Kostenstelle und Kostenart gruppiert ausgegeben, wenn Sie die Hochschule auswählen, ist die Ausgabe mit der in FSV identisch.

Es hat sich gezeigt, dass in FSV nicht alle Datensätze mit einer Kostenstelle versehen werden, in SuperX wird dafür der oberste Knoten des Kostenstellenbaums eingetragen ( root ). Siehe Kapitel hochschulspez. Anpassungen .  

3.4.1.2 Validierung Anlagespiegel (kameral) auf Datenbankebene

  Mit folgendem SQL auf die MBS-Datenbank wird   der gesamte kamerale Anlagespiegel berechnet:

SELECT '' as hs_nr,

        '' as asp_id,

        '' as asp_invnr,

        '' as asp_akl_key,

        '' as asp_koa_nr,

        '' as asp_klass,

        '' as asp_inst,

        '' as asp_kostenstelle,

        sum(asp_preis_beginn) as asp_preis_beginn ,

        sum(asp_preis_zugang) as asp_preis_zugang,

        sum(asp_preis_abgang) as asp_preis_abgang ,

        sum(asp_preis_ende) as asp_preis_ende,

        sum(asp_afa_bis) as asp_afa_bis,

        sum(asp_afa_periode) as asp_afa_periode ,

        asp_haushaltsjahr ,

        sum(asp_restw_beginn) as asp_restw_beginn ,

        sum(asp_restw_ende) as asp_restw_ende

FROM ivasp

group by 15;

Beachten Sie daß die Tabelle in MBS bei jeder Erzeugung des Anlagespiegels geleert und neu berechnet wird. Es sind also in der Regel nur einzelne Haushaltsjahre sichtbar.

3.4.2 Fehlerbehandlung und Regelbetrieb

3.4.2.1 Logdateien

Eine Fehlerdatei steht in der Umgebungsvariable $IVS_PFAD/$IVS_ERRORDAT , die Vorbelegung ist " ivs_update.err ". Das Script ivs_update.x ruft mehrere Unterroutinen auf. Wenn in jeweils einem Script ein Fehler auftaucht, wird dies in der   Logdatei ausgewiesen.

3.4.2.2 Warnungen

Einige mögliche Inkonsistenzen in den Daten werden geprüft und falls sie auftreten in der   Maske "Prüfprotokoll Inventar" ausgegeben.

Problematisch könnte z.B. sein, wenn es im Anlagespiegel Kostenarten gibt, die nicht in der Schlüsseltabelle fikr enthalten sind, oder wenn Kostenstellen zum Zeitpunkt der Auswertung nicht mehr gültig sind.

3.4.2.3 Fehler "out of memory"

Wenn Sie den Anlagespiegel ausführen, kann es vorkommen dass ein Fehler "out of memory" auftritt und im Browser angezeigt wird. Die Ursache ist, dass der Anlagespiegel einen sehr umfangreichen Baum aus Kostenstellen und Kostenarten aufbaut und dafür große Arbeitsspeicherressourcen braucht. In diesem Falle müssen Sie den verfügbaren Arbeitsspeicher für Tomcat erhöhen, z.B. auf 950 MB

CATALINA_OPTS="-Xms100M -Xmx 950 M -Djava.awt.headless=true

export CATALINA_OPTS

3.4.2.4 Regelbetrieb und Einrichten des Cronjob

Im Regelbetrieb wird jede Nacht aus IVS entladen und das Entladedatum gesetzt. Die Daten werden von SuperX geladen, und bei erfolgreichem Laden wird das Datum in $IVS_LOAD_PFAD (Datei superx.datum ) verändert. Bei Ladefehlern in SuperX wird das Datum in $IVS_LOAD_PFAD von SuperX zurückgesetzt auf den vorherigen Stand ( superx.datum.alt ). Dies wiederum führt dazu, dass beim nächsten Entladen aus IVS das Datum des letzten erfolgreichen Ladens nach SuperX verwendet wird.

Cronjob-Syntax

Beim regelmäßigen Update wird der IVS-Update über Cronjobs erledigt. Dazu muss ein Script erzeugt werden, dass die Umgebungsvariablen von SuperX lädt, und dann das Script $SUPERX_DIR/db/module/ivs/ivs_update.x startet. Ein Beispielscript liegt in ivs_update_cron.x.sam . Dieses fügen Sie in die Crontab ein. Die Syntax kann z.B. so aussehen:

Der IVS-Update wird Di-Sa morgens um 4:00 Uhr ausgeführt.

3.5 Entfernen des IVS-Moduls

Wenn Sie das IVS-Modul nicht mehr benötigen, starten Sie das Script
$SUPERX_DIR/db/module/ivs/ivs_modul_entfernen.x.
Dieses Script löscht alle Tabellen, Prozeduren und Abfragen aus der Datenbank, und löscht auch die Einträge im Themenbaum. Danach können Sie den Pfad $SUPERX_DIR/db/module/ivs löschen.

Wenn Sie nur die Inhalte der Daten- und Hilfstabellen des IVS-Moduls löschen wollen (z.B. aus Datenschutzgründen), ohne das ganze Modul zu deinstallieren, können Sie dies mit folgendem Befehl tun:

DOSQL $SUPERX_DIR/db/module/ivs/ivs_purge_pg.sql (für Postgres)
bzw.
DOSQL $SUPERX_DIR/db/module/ivs_purge_ids.sql (für Informix)

4 Bestandteile des IVS-Moduls

Die Daten werden aus dem Basissystem extrahiert, und die resultierenden Datentabellen werden mit Schlüsseln verknüpft. Teilweise wird auf Tabellen aus dem SuperX-COB-Modul (für die Kostenarten ).

Für die Datenübernahme ist der berechnete Anlagespiegel und anhängige Schlüsseltabellen vorgesehen:

1. 1 Anlagespiegel (Tabellen ivasp und ivasp_bga ) 

2. 2 Kostenstellen (Tabelle inst ) 

3. 3 Kostenarten (Tabelle fikr ) 

4. 4 Anlageklassen (Tabelle akl_bw ) 

5. 5 Klassifikation / Warengruppe (Tabelle klas ) 

Bei Hochschulen, die HIS-FIBU nutzen, wird über einen Systemschalter nicht die Tabelle ivasp ausgelesen, sondern die Tabelle ivasp_bga . (Da hierzu bisher ein Pilotanwender fehlte, muss dies noch in einem zukünftigen Release angepasst werden).

5 Versionshistorie des IVS-Moduls

0.6rc3 (04/2011)

• • Maske "Prüfprotokoll Inventar" verbessert 

• • Neue Konstanten  

• • IVS_VONBIS_INST: Sollen die Gültigkeitszeiträume bei Kostenstellen ausgewertet werden? 

• • IVS_VONBIS_FIKR: Sollen die Gültigkeitszeiträume bei Kostenarten ausgewertet werden? 

• • IVS_ASP_COMPUTE: Soll der Anlagespiegel im nächtlichen Update neu berechnet werden? 

0.6rc2 (06/2010)

Anlagespiegel korrigiert: Bezugsjahr und Haushaltsjahr getrennt

0.6rc1 (11/2009)

1   Kernmodul+ Handbücher beziehen Sie über http://download.superx-projekt.de

2   Es gibt mehrere Möglichkeiten zum Entladen der Rohdaten. Es ist z.B. auch möglich, dem User der SuperX-Datenbank direkten Zugang zum FSV-Rechner zu geben und die Entladescripte direkt auf dem SuperX-Rechner zu starten; dies bietet sich z.B. an, wenn Sie SOS unter Postgres oder Informix f. Windows NT betreiben.

3   Eine Anleitung zur generellen Planung des Datenaustauschs finden Sie im Administrationshandbuch des Kernmoduls.