Fehler durch das Update auf iTwo 4.0 Version 6.4.A

Durch das Update auf die neueste Version 6.4.A wurde in paar Fehler behoben, die für uns geringe Relevanz hatten. Vielmehr kam es durch das Update zu massiven Problemen.

Bei der Anlage von Leistungsermittlungen kommt folgender Fehler. „The INSERT statement conflicted with the FOREIGN KEY SAME TABLE constraint “BOQ_ITEM_FK10”. The conflict occurred in database DATABASENAME, table “dbo.BOQ_ITEM”. The statement has been terminated.

Durch diesen Fehler konnten sporadisch keine Leistungsermittlungen (LEs) angelegt werden. Das wiederum blockierte die das Freigeben von Rechnungen basierend auf Leistungsermittlungen.

Durch das Update wurde es wohl verpflichtend, dass jeder Kreditor eine „MwSt.-Geschäftsbuchungsgruppe“ hinterlegt hat. Nachdem wir das für jeden Kreditor jedes Geschäftspartners nachgeholt und auch für jede Rechnung und für jeden Vertrag eine „MwSt.-Geschäftsbuchungsgruppe“ ausgewählt hatten, klappte die Verknüpfung von Rechnungen mit Verträgen wieder. Zusätzlich wurde ein Workflow integriert, der bei Anlage eines Geschäftspartners automatisch eine Default-„MwSt.-Geschäftsbuchungsgruppe“ hinterlegt.

Die genaue Fehlermeldung ist leider nicht mehr vorhanden. Es war jedoch Pop-up mit einem Verweis auf einen Fremdschlüssel.

Durch das Fehlen der Verknüpfung mit Verträgen konnten keine Abschlagsketten aufgebaut werden! Renowate hatte bis zu diesem Zeitpunkt das Kreditoren-Attribut „MwSt.-Geschäftsbuchungsgruppe“ nicht benutzt oder generell benötigt.

Durch das Update wurde es wohl verpflichtend, dass jeder Kreditor eine „MwSt.-Geschäftsbuchungsgruppe“ hinterlegt hat. Nachdem wir das für jeden Kreditor jedes Geschäftspartners nachgeholt und auch für jede Rechnung und für jeden Vertrag eine „MwSt.-Geschäftsbuchungsgruppe“ ausgewählt hatten, klappte die Verknüpfung von Rechnungen mit Verträgen wieder. Zusätzlich wurde ein Workflow integriert, der bei Anlage eines Geschäftspartners automatisch eine Default-„MwSt.-Geschäftsbuchungsgruppe“ hinterlegt.

Der Endanwender sah keine Fehlermeldung, es wurden einfach keine Mails versendet. Durch triggern einer Mail-Action im Workflow-Designer wurde folgender Fehler sichtbar

iTwo 4.0 konnte keine einzige Mail mehr versenden. Unabhängig davon, ob es ein RIB-Workflow war oder eine Eigenentwicklung

Es musste im Menü „Anpassungen“ unter „Systemoptionen“ eine Einstellung auf 0 gesetzt werden. Da dies durch den zuständigen Consultant erfolgte, ist uns die genaue Einstellung nicht bekannt. Inzwischen sollte aber auch der Helpdesk dieses Problem beheben können. Der Bug in der Anwendung besteht natürlich weiterhin, nur sind die Auswirkungen nicht mehr sichtbar.

Eine Auswirkung der Lösung war es, dass zusätzlich das „Outlook-Symbol“ von der Rechten Leiste am iTwo Desktop verschwand.

Folgende Fehlermeldung taucht bei allen Aktionen auf, die auf einen Report zugreifen, welcher das Leistungsverzeichnis über die Funktion BOQ_SORTED_F abfragt:

„An insufficient number of arguments were supplied for the procedure or function “BOQ_SORTED_F”.

Die Funktion “BOQ_SORTED_F” wird nicht nur für die Generierung eigener Reports verwendet. Auch RIB nutzt diese Funktion in Reports um LVs zu generieren. Deshalb war nicht mehr möglich, Anfragen oder Verträge für Nachunternehmer zu generieren, da hier LVs angehängt werden.

Durch das Update wurde die Datenbank-Funktion “BOQ_SORTED_F” wohl von 3 auf 5 Attributen erweitert. Sprich, vor dem Update konnte die Funktion wie folgt aufgerufen werden:

SELECT *

FROM BOQ_SORTED_F('<int>1000002</int>','','')

Nach dem Update müssen 2 zusätzliche, leere Attribute hinzugefügt werden:

SELECT *

FROM BOQ_SORTED_F('<int>1000002</int>','','','','')

Durch diese Erweiterung bei jedem BOQ_SORTED_F Aufruf in jedem Report, konnten die Reports wieder generiert werden.

Nach solchen Fehlern stellt man sich direkt die Frage nach den Auswirkungen auf den Betrieb. Dabei muss der Aufbau der Umgebungen beachtet werden.

Bezieht man iTwo direkt von RIB als SaaS-Lösung, so hat man die Möglichkeit, ein getrenntes Test- und Live-System zu nutzen. Dabei werden dann komplett eigene Tenants aufgebaut, die mit eigenere Softwareversion und Datenbank laufen.

Die offensichtlichsten Vorteile dieser Lösung sind eine

Neben den extra Kosten ist auch das aufwändige „Synchron-halten“ der Systeme inkl. manuelles Staging von Änderungen als relevanter Nachteile zu erwähnen.

Der „kleine Bruder“ von 2 eigenen Installationen ist ein Mulit-Mandanten-Modell. Dabei werden 2 oder mehrere Mandanten (z.B. Test- und Live-Mandant) auf einer Installation aktiviert. Diese Mandanten teilen sich nicht nur die Datenbank, sondern auch grundlegende Daten wie z.B. Workflows, Konfigurationen (z.B. Verschiedene Status) oder auch Geschäftspartner. Die Vorteile hierbei sind das einfachem Staging und das Wegfallen der Kosten für eine 2. Installation. Jedoch sind die Nachteile nicht zu vernachlässigen:

Daraus folgt, dass eine 2. Installation der Multi-Mandanten-Lösung zu bevorzugen ist. Vorausgesetzt, die finanzielle und personelle Mehrbelastung durch weitere Lizenzkosten und Staging-Aufwände sind stemmbar.