Individuelle Anpassungen

Erklärung des Zusammenspiels

Beispiel einer einfachen StoredProcedures (STP)

ServicePacks (Sprints) vs Major Update

1. Bei Major Updates (2013, 2014) werden immer ALLE Dateien neu installiert (überschrieben), also auch alle Reports und alle STPs auf der DB.

2. Bei ServicePacks werden nur die Dateien ausgetauscht welche Korrekturen beinhalten. Das können auch Reports oder STPs sein.

Individuelle Reports

Der häufigste Fall ist, dass für Kunden Reports im Layout (Darstellung) angepasst werden oder dass kleinere Berechnungen welche im Report enthalten sind, angepasst werden

Individuelle Reports müssen im dafür eigens vorgesehen Verzeichnis gespeichert werden.

Dieses Verzeichnis wird in den Einstellungen definiert und gilt für alle Applikationen.

Einstellungen 2/3:

Die Priorität ist so, dass die Sage 200 Applikationen IMMER zuerst im indiv-Verzeichnis nach dem Report-File (.rpt) suchen und erst danach im Standard-Verzeichnis.

Somit umgeht man die Gefahr, dass die Reports oder STPs bei einem nächsten Update mit den Standard-Dateien überschrieben werden.

Individuelle Stored Procedures zu den Reports

Hinter jedem Report liegt eine STP welche die Daten aufbereitet. In einigen Fällen kann es sein, dass die Aufbereitung angepasst werden muss und dies wird dann in der STP geändert.

Die Standard-Proc darf jedoch NIE geändert werden. Die Standard-Proc MUSS kopiert und umbenannt werden und diese danach im Report-File hinterlegt werden. Somit ist also auch der Report individuell und muss im dafür vorgesehen Verzeichnis abgelegt werden.

Somit umgeht man die Gefahr, dass die Reports oder STPs bei einem nächsten Update mit den Standard-Dateien überschrieben werden.

Wording Report-Prozeduren

Das nachfolgende Vorgehen ist auch anzuwenden, wenn der Kunde bereits eine angepasste Prozedur im Einsatz hat und ein SP installiert wird. Die Prozedur muss wie nachfolgend erwähnt umbenannt und mit dem entsprechenden Report verknüpft werden.

Vorgehen für individuelle Reportprozeduren

Bei Prozeduranpassungen für die Reports gelten folgende Regeln:

Grant

Damit alle User den Report resp. die Prozedur starten können, ist der sogenannte Grant-Befehl am Schluss der Prozedur anzufügen:

Beispiel:
end
go
grant exec on sage_hp_rptrechnung_i_domicil to sbsadmins with grant option
go
grant exec on sage_hp_rptrechnung_i_domicil to sbsusers
go
print 'Procedure: sage_hp_rptrechnung_i_domicil done ...'
go

Begründung:

Wird ein Servicepack eingespielt, wird somit die angepasste Prozedur nicht überschrieben, denn es werden nur Prozeduren mit Originalnamen überschrieben.

Werden die Prozeduren gesucht, so sind diese alle einfach auffindbar.

Im Crystal Report sind die Prozeduren beim Verlinken mit dem Report einfach auffindbar.

Weitere Punkte:

• Prozeduren für Belege nicht via sp_helptext prozedurname aus der Datenbank extrahieren. Es gehen sämtliche Kommentare verloren.

• Die Prozeduren sind auf der Installations-DVD in folgendem Verzeichnis auffindbar:  DVD-Laufwerk:\Listproc

• Pro Applikation ist ein Unterverzeichnis vorhanden (leider mit Ausnahme von E-Health)

• Für das Finden der Prozedur pro Report ist auf der DVD ein Verzeichnis DVD-Laufwerk:\\Dokumentation\Technische Informationen\Dokumentation Html

• Über main_index.html kann man die entsprechenden Reports finden. Darin sind die Aufrufparameter und der Prozedurname ersichtlich.

Begründung:

• Der Header und der Footer der Prozedur muss zusätzlich eingefügt werden

• Der Lifecycle der Prozedur ist nicht ersichtlich

• Bei einem Update sind die Prozeduren nicht vergleichbar z.B. via WinMerge oder ähnliche Programme

• Muss etwas angepasst werden, ist der Suchaufwand unverhältnismässig grösser als bei angepassten Originalprozeduren

Individuelle Stored Procedures für die Applikation (vor allem Auftrag)

1. Wie die Reports so passieren auch in den Funktionen der Applikationen alle Zugriffe auf die DB über diese STPs.

2. Im Auftrag und zum Teil auch im Heim gibt es Anforderungen von Kunden, welche vom Standard des Auftrags abweichen (z.B. die Preisfindung). Diese Anpassungen sind komplex und können (sollten) NUR von R&D gemacht werden. Hierzu werden die Standard-STPs dann für die Kunden angepasst. Zum Teil wird das auch von Partner gemacht. Die Änderungen dieser Procs müssen bei jedem Update immer wieder auf den neuesten Stand gebracht werden.

Problematik

1. Diese Anpassungen MUSS man auf ein absolutes Minimum beschränken – am besten ganz darauf verzichten!

2. Diese Änderungen verursachen, dass solche Kunden kaum noch migrierbar sind und wenn dann nur mit enormem Aufwand.

3. Der Grund für diese Änderungen sind kaum dokumentiert und werden deshalb bei Updates immer wieder vergessen und kaum getestet. Für den Kunden entsteht damit der Eindruck die Version laufe nicht, obwohl dies mit dem Standard überhaupt nichts zu tun hat (Beispiel Banholzer).

4. Leider sind die Bemühungen nicht von Erfolg gekrönt, denn häufig kommt das Argument «der Kunde kaufe sonst nicht».

5. Diese Anpassungen werden immer von R&D gemacht (ausser Partner) und werden IMMER in Rechnung gestellt. Früher ergab sich (nur) aus diesen Aufgaben das Budget für R&D Medium Business.

6. Die Freude für den Umsatz für diese Anpassungen ist nur von kurzer Dauer. Die Kunden sind bei Update über die Kosten erstaunt und für R&D kommen dann diese Anpassungsaufwendungen in Zukunft immer zum falschen Zeitpunkt (sind kaum planbar).

Individuell angepasste Dialoge

Über den Layout-Editor können Dialoge angepasst werden. Ab der Version 2015 werden diese automatisch auf die nächste Version migriert (ausser das XAML wurde manuell angepasst und importiert).

Alle angepassten Dialoge müssen dokumentiert und mit PrintScreens auf der Kundenablage gespeichert werden. Dies dient als Backup wenn bei der Migration Probleme aufgetreten sind.

Vor jeder Migration ist zu prüfen ob es individuell angepasste Dialoge auf dem System hat.

Überwachung von individuellen Anpassungen in Admin

In Admin, im Register „DATENBANK“ gibt es zwei Funktionen in der Gruppe „Individuelle Anpassungen“ welche die angepassten Prozeduren und Dialog anzeigen.

Schnittstellen

1. Daten aus Drittsystemen oder von Ausserhalb müssen in Sage 200 eingelesen werden.

2. Daten für andere Systeme werden aufbereitet und werden ausgelesen.

Connect bietet dazu, wie beispielsweise Finanz eine Vielzahl von Möglichkeiten an, wie man diese Daten ein/auslesen kann. Es ist wie Finanz eine Applikation welche für die Bedürfnisse der Kunden eingerichtet werden kann. Diese Einrichtungen sind auf der Datenbank gespeichert und haben noch nichts mit einer individuellen Anpassung zu tun.

1. In einigen Fällen kann es sein, dass die Anforderung der Kunden die Standard Möglichkeit von Connect überschreiten. Wenn z.B. Daten speziell aufbereitet werden müssen und es dazu keine API-Methode gibt.

2. In diesem Fall hat man die Möglichkeit selber eine STP zu programmieren und diese in Connect aufzurufen. Diese Art von Schnittstellen ist aber eher selten der Fall.

3. Das Hauptproblem bei den Schnittstellen liegt in der schlechten Dokumentation der Kundenschnittstellen. Man weiss in den wenigsten Fällen was die Schnittstellen genau importieren/exportieren und so geraten diese bei den Tests von Updates gerne vergessen.

4. Grundsätzlich sind Schnittstellen problemlos migrierbar