GDI-Business-Line (ERP + CRM) · funktional relevant sind (also beispielsweise eine...

Technische Informationen zur GDI Business-Line 30.06.2016 ERP + CRM 3.6.1.x Seite 1/51

GDI-Business-Line (ERP + CRM)

Technische

Informationen

Version 3.6.1.1510

Stand: 30. Juni 2016

Technische Informationen zur GDI Business-Line (ERP + CRM) ..................................................... 3 Einführung ........................................................................................................................................... 3 Installation ............................................................................................................................................ 3 Lizenz ................................................................................................................................................... 3 Nicht oder eingeschränkt verfügbar: Offline, Fremdsprache ............................................................... 3 Start des Programmes über BL_Start.exe ............................................................................................ 3 Dateistruktur auf Platte ........................................................................................................................ 4 Mandantenauswahl/Mandant.txt .......................................................................................................... 5 Die Datei Bline_Design.txt .................................................................................................................. 5 Die gegenüber dem ERP erweiterte Datenstruktur .............................................................................. 7 Reorganisation ................................................................................................................................... 11 Update auf GDI-Business-Line 3.x: ERP mit CRM-Funktionen ...................................................... 14 Firebird-ODS und ODSKonver.exe ................................................................................................... 15 Daten-Konvertierung GDILine à Bline ........................................................................................... 17 Bediener- und Rechner-Einstellungen im CRM ................................................................................ 22 Menüdesigner/Rechteverwaltung ....................................................................................................... 23 Grid-Designer..................................................................................................................................... 24

Vertikaler Grid (VGrid) ................................................................................................................. 24 Horizontaler Grid (HGrid) ............................................................................................................. 24

Drop-Down-Menüs zum Speichern von Gridbuttons (GBN) und Masken (MSK2) im CRM-Bereich der GDI-Business-Line ...................................................................................................................... 24

MSK2-Masken-Speichern .............................................................................................................. 24 GBN-Gridbutton-Speichern ........................................................................................................... 25

Anpassung des neuen Grid (Masken-Griddesign (VGrid, HGrid) und F4-Griddesign) .................... 26 Masken-Griddesign ............................................................................................................................ 26 Grid: Designen des Grids ................................................................................................................... 26 Felder: Aktivieren eines (neuen) Datenfeldes .................................................................................... 27 Zeilen (bei VGrid) bzw. Spalten (bei HGrid): Designen eines Datenfeldes im Grid ........................ 27 à ImageComboBox (ImageComboBox) .......................................................................................... 31 à F4-Auswahlgrid (psPopUp) .......................................................................................................... 32 à Datumsfelder im CRM (DateEdit) ................................................................................................ 35 à Button für Script ("Basic-Button") ................................................................................................ 37 Weitere Buttons im Designer ............................................................................................................. 38 Layout-Designer................................................................................................................................. 38 Eigene Buttons und eigene Karteireiter im Adress-Stamm ............................................................... 39 Maskendesigner für Masken des Factur-Bereiches, neue Objekte, Look & Feel .............................. 39 Maskenaufrufe in Bline (Factur-Bereich, MSK bzw. TXT): ............................................................. 39 Konvertieren angepasster Masken aus der GDILine ......................................................................... 42 Zusatzfelder innerhalb der neuen Dokumenterstellung/Serienbriefe ................................................. 43 Mails mit mehreren Adressen/Serienmails ........................................................................................ 44 Email Senden und Anhänge ............................................................................................................... 44 Vorlagen und Textbausteine, Signaturen in Dokumenten ................................................................. 45 Serienbrief mit erweiterter Datenbasis ............................................................................................... 46 Ansteuerung Briefeditor per GDI-Basic ............................................................................................ 47 GDI-Basic-Funktion CrmAdressenInsert: Adress-Korb füllen ......................................................... 48 Reportmanager (TReporter2) ............................................................................................................. 51


Technische Informationen zur GDI Business-Line (ERP + CRM) Stand: 30.06.2016 Version 3.6.1.1510 Einführung Mit der Entwicklung der neuen Produktlinie "GDI Business-Line" ergeben sich durch Einsatz neuer Tools neue Möglichkeiten hinsichtlich der Anpassbarkeit des Systems. So wurde beispielsweise als zentrales Maskenelement ein neuer Erfassungs- und Anzeigegrid und ein neues Menüsystem implementiert. Ebenso wurden zur Implementierung der CRM-Funktionalitäten Änderungen/ Erweiterungen an der Datenstruktur der Datenbank und an der Dateistruktur auf Platte erforderlich. Als Ergänzung zur allgemeinen Anwenderdokumentation, die im wesentlichen über die Online-Hilfe verfügbar ist, soll diese Dokumentation Informationen geben über:

• Installation und Lizenz • die Dateistruktur auf Platte • die gegenüber dem ERP erweiterte Datenstruktur • Reorganisation • gemeinsamer Einsatz von CRM und ERP • Konvertierung • Rechner- und Bediener-Einstellungen im CRM • Menüdesigner/Rechteverwaltung • Grid-Designer • Handling von Masken des CRM- und des Factur-Bereiches

Begriffe: Die GDI Business-Line wird in dieser Dokumentation kurz als Bline bezeichnet, die bisherige GDI-Auftrag & Warenwirtschaft als GDILine. Installation Die Installation der GDI-Business-Line (Bline) wird in ein separates Verzeichnis vorgenommen. Auch für den Fall, dass mit dem Programm auf vorhandene Warenwirtschaftsdaten zugegriffen werden soll (Ablösung einer GDILine durch die Bline), ist für die Installation ein separates Verzeichnis zu wählen. Lizenz Lizenztechnisch wird die Bline-Lizenz an die WAWI-Lizenz gekoppelt. Das bedeutet, dass für den Einsatz des Programms ein aktueller Namenseintrag WR36 gegeben sein muss. Die Freischaltung der CRM-Funktionalitäten wurde in den Warenwirtschaftslizenzcode eingearbeitet. Hinweis: "Letzter" Stand der GDILine-Auftrag & Warenwirtschaft ist die 2.7.0.290. Hierfür wird WR27 benötigt. Nicht oder eingeschränkt verfügbar: Fremdsprache Hinsichtlich der fremdsprachigen Benutzeroberfläche gibt es die Einschränkung, dass die Sprachumschaltung nur für die Masken des WAWI-Bereiches möglich ist. Start des Programmes über BL_Start.exe Durch die Größe der Bline.exe bedingt dauert der Start des Programmes länger als bei den anderen (bisherigen) GDI-Programmen. Um die Ladezeit zu "überbrücken" wird die BL_Start.exe verwendet. Diese EXE befindet sich ebenfalls im Programmverzeichnis, meldet sich mit einem kleinen Begrüßungsbildschirm und startet die Bline.exe. Bei Bedarf kann die hinterlegte Grafik ausgetauscht werden, indem man in den Ordner "Design" eine eigene Grafik als BL_Start.bmp, BL_Start.jpg oder BL_Start.gif ablegt (638 x 310 Pixel).


Dateistruktur auf Platte Nach der Installation findet man die nachfolgend aufgezeichnete Verzeichnis-Struktur auf der Festplatte vor. Im Hauptunterschied zu einer GDILine-Warenwirtschafts-Installation ist das Unterverzeichnis "Factur" zum Programmordner entfallen (bei den anderen GDI-Programmen wäre das "Fibu" oder "Lohn" ...), neu hinzugekommen ist das Unterverzeichnis "Mandanten". Hierin befinden sich in separaten Ordnern die eigentlichen Mandanten, wobei an dieser Stelle nicht zwingend die jeweilige Datenbank liegen muss. Stattdessen steht hier immer die Textdatei "Mandant.txt", in welcher festgehalten wird, wo sich die Datenbank physikalisch befindet. Programmordner +---BDE +---Bediener +---Design +---Export +---Grids +---Hilfe +---Import +---Lexikon +---Mandanten | \---DemoFact | +---Anlagen | +---Design | +---Dokument | +---Export | +---Filter | +---Grids | +---Import | +---Masken | +---Metadaten | +---PDF | +---Reports_FR4 | | \---Belege | | +---Einkauf | | \---Verkauf | +---Reports_frf | +---Reports_rpd | +---Script | +---SQL | \---Vorlagen +---Masken +---MetaDaten +---Reports_FR4 | +---Adressen | | +---Adresse | | +---Interess | | +---Kunden | | +---Liefer | | +---Personal | | \---Vertreter | +---Allgemein | +---Artikel | | +---Artikel | | +---Chargen | | +---HSL | | +---PSL | | \---Serien | +---Basisdaten | +---Belege | | +---Einkauf | | +---Verkauf | | \---Warenkorb

Ausführbare Programme, DLLs

Bediener-/Rechnereinstellungen

Gridbutton-Definitionen (GBN und GDF)

Mandantenordner mit Mandant.txt und i.d.R. GDB/FDB Enthält wie bisher die mandantenspezifischen Unterordner

Wie bisher Masken des ERP –Bereiches als MSK oder TXT plus gespeicherte Maskenlayouts des CRM- Bereiches (Panel, Grids einer Form) als MSK2

Vorgabe-Dateien für die Reorganisation

Ausschließlich FR4-Reports. Bis zur 3.2.0.201 lautete der Verzeichnisname "Reports"

Vorgabe-Dateien für die Reorganisation auch bei Mandant möglich


| +---Cockpit | +---Lager | +---Offline | +---Projekte | +---Sonstige | +---System | \---Zeiterfassung | +---Mitarbeiter | +---Stammdaten | \---Zeitarten +---Reports_FRF +---Reports_RPD +---Script +---Service +---Sprachen +---SQL +---Textbausteine +---Vorlagen \---Vorlagen_DOC \---Word95 Mandantenauswahl/Mandant.txt Bei Start der Mandantenauswahl werden alle "Unterordner" des Verzeichnisses "Mandanten", welche eine Mandant.txt beinhalten, als mögliche Mandanten angeboten. Beispiele für die Mandant.txt: - Mandant angelegt mit Option "relativer Pfad für USB-Modus": Mandname=1_Demo-Daten DatabaseName=GDI.FDB DBUserName=XRXOIJ DBPassword=fjx ny`nr DBUNCPFAD=D:\GDIBusinessLine\Mandanten\1_Demo\GDI.FDB Diese Option kann angewendet werden, wenn sich die Datenbank sich im Mandantenordner bei der Mandant.txt befindet und im wesentlichen rein lokal gearbeitet wird. Programm und Mandant könnte beispielsweise auf einem USB-Stick liegen. Durch Kopieren des kompletten Mandanten-Ordners kann der Mandant auf einen anderen Rechner portiert werden, ohne dass bei der Anmeldung spezielle Pfadkorrekturen erforderlich werden. (Der DBUNCPfad wird bei jedem Login neu ermittelt.) - Mandant angelegt ohne Option "relativer Pfad für USB-Modus" Mandname=2_Testfirma DatabaseName=LOGE3/23053:D:\GDIBusinessLine\Mandanten\2_Test\GDI.FDB DBUserName=XRXOIJ DBPassword=fjx ny`nr DBUNCPFAD=D:\GDIBusinessLine\Mandanten\2_Test\GDI.FDB Die Datei Bline_Design.txt Diese Datei liegt im Ordner "Design" und enthält Informationen für das Programm, die im wesentlichen für den Startvorgang und das Login in die Datenbank benötigt werden:

Vorlagen u. Textbausteine für Dokumentenverwaltung

"alte Reports"

Script à GDI-Basic (PRG) und Pascal-Script (PAS)


AnmeldeLogo=BLINE_Anmeldelogo.bmp DESKTOPLOGO=BLINE_Desktoplogo.bmp SkinKind=Standard SkinName=Office2007Blue NativeStyle=0 FirebirdPort=23053 SQLdialect=1 Mandantenanzeige=1 ZOOM_PC3=100 Wichtig ist insbesondere die Angabe des Schlüssels "FirebirdPort": • ist wichtig für die Mandantenneuanlage und bestimmt, mit welchem FireBird-Server die Anlage

der neuen Datenbank vorgeschlagen wird • ist bei USB-Modus von Belang: In diesem Falle enthält die Angabe "DatabaseName" in der

Mandant.txt keinen vollständigen Connect-String (s.o.), daher wird über den Schlüssel FirebirdPort der Server für den Zugriff bestimmt. Bei einer Mandantenneuanlage wird die Funktion USB-Modus nur unterstützt, wenn der gewählte Firebird-Server dem FirebirdPort der Bline_Design.txt entspricht.

Die mandantenspezifische Angabe des Logos ist auch möglich (Rechteverwaltung, Karteikarte "Allgemein"). Hierdurch wird auf Mandantenebene ein Ordner Design mit einer Bline_Design.txt mit einem Eintrag DESKTOPLOGO=.... angelegt. (Das Bild/Logo (bmp oder jpg) in dieses Verzeichnis abzulegen). Andere Einträge in einer BLine_design.txt auf Mandantenebene haben keine Auswirkung.


Die gegenüber dem ERP erweiterte Datenstruktur Der Kern des CRM beruht auf der Verwaltung sämtlicher Adressdaten in einer gemeinsamen Datentabelle (Tabelle CM_ADRESSEN). Hier werden alle im System vorkommende Adressen "gesammelt". Erst über weitere Definitionen wird festgelegt, ob es sich hierbei funktional um einen Kunden, Lieferanten, Mitarbeiter, Ansprechpartner, Vertreter oder sonstige Adresse handelt. Dabei ist es möglich, dass eine Adresse mehrere Funktionen haben kann, also beispielsweise gleichzeitig Kunde und Lieferant darstellt. Die bisherigen Stammdatentabellen bleiben unverändert im System bestehen. Namentlich beginnen alle über das CRM neu hinzugekommenen Datentabellen mit dem Präfix "CM_". Hier der Aufbau der wichtigsten Tabellen: [CM_ADRESSEN.FELDER] ADRESSID=GDI_CHAR20 ADRESSNR=GDI_LONG LFDNR=GDI_SHORT DEAKTIV=GDI_CHAR1 ADRESSGRPKD=GDI_CHAR6 ADRESSGRPLI=GDI_CHAR6 ADRESSTYP=GDI_LONG BRANCHE=GDI_SHORT SUCHNAME=GDI_CHAR40 ANZEIGENAME=GDI_CHAR80 DISPLAYNAME=GDI_CHAR80 ANREDE=GDI_CHAR10 DOCTITEL=GDI_CHAR40 VORNAME=GDI_CHAR40 NAME=GDI_CHAR40 NAME1=GDI_CHAR40 NAME2=GDI_CHAR40 NAME3=GDI_CHAR40 STRASSE=GDI_CHAR40 ANSCHRIFTZUSATZ=GDI_CHAR40 PROVINZ=GDI_CHAR2 ISOA2LAND=GDI_CHAR2 LAND=GDI_CHAR3 PLZ=GDI_CHAR10 ORT=GDI_CHAR30 POSTFACH=GDI_CHAR10 PLZPFACH=GDI_CHAR10 TELEFON=GDI_CHAR20 TELPRIVAT=GDI_CHAR20 HANDY=GDI_CHAR20 TELEFAX=GDI_CHAR20 EMAIL=GDI_CHAR50 BRIEFANREDE=GDI_CHAR40 HOMEPAGE=GDI_CHAR50 FUNKTION=GDI_CHAR30 ABTEILUNG=GDI_CHAR30 INFO=GDI_MEMO KATEGORIE=GDI_MEMO REFERENZADR=GDI_MEMO USTIDNR=GDI_CHAR16 STEUERNR=GDI_CHAR16 GEBDATUM=GDI_DATE GEBERINN=GDI_CHAR1 UPDFLAG=GDI_CHAR1 ANSPRECHPARTNER=GDI_SHORT NEWSLETTER=GDI_SHORT CREATEBED=GDI_CHAR5 CREATEDATUM=GDI_DATE

Die Tabelle CM_ADRESSEN enthält die maßgeblichen Adressinformationen. Informationen, welche für die Adresse funktional relevant sind (also beispielsweise eine Zahlungsbedingung) werden wie bisher in den mit dieser Funktion zusammenhängenden Datentabellen (z.B. Kunden) geführt. Die LfdNr unterscheidet "Stammadresse" (LfdNr = 0) und "Ansprechpartner" (LfdNr > 0). Eine Besonderheit stellt das Feld Anzeigename dar: Der Anzeigename wird dynamisch aus Name, Vorname und Firma1 (Name1) gebildet wird. Durch manuelle Einträge in dieses Feld wird die Dynamik ausser Kraft gesetzt. Man kann also auch individuelle Anzeigenamen erfassen.

In den meisten Tabellen mit Adressbezug gibt es neu das Feld AdressID=GDI_CHAR20 Dieses enthält dann jeweils die "CM-Adresse", bei Ansprechpartnern zusammengesetzt aus Adressnr und Lfdnr (durch Punkt getrennt), bei der Stammadresse ohne die Lfdnr.

"Adressgruppe" in CM_Adressen: Hier gibt es eine Aufteilung in die beiden Felder AdressgrpKD und AdressgrpLI, es erfolgt ein Triggern des Feldinhaltes aus Kunde/Lieferant nach CM_Adressen. Alle Ansprechpartner haben in diesen Feldern dieselben Inhalte wie der Stammsatz, die Erfassung der Adressgruppe erfolgt nur auf den Karteireitern Kunde und Lieferant.


AENDBED=GDI_CHAR5 AENDDATUM=GDI_DATE OFFLINEDAT=GDI_DATE OFFFILIALE=GDI_LONG -- [CM_ADRESSEN.INDIZES] CM_ADADR=*,+,ADRESSNR,LFDNR CM_ADDESC=,-,ADRESSNR,LFDNR CM_ADADRESSID=,+,ADRESSID -- [CM_ADRESSLINK.FELDER] ADRESSNR=GDI_LONG ADRESSTYP=GDI_CHAR1 NUMMER=GDI_LONG -- [CM_ADRESSLINK.INDIZES] CM_ALIDNR=*,+,ADRESSTYP,NUMMER CM_ALADRNR=,+,ADRESSNR,ADRESSTYP CM_ALNR=,+,NUMMER -- [CM_ADRESSCOM.FELDER] ADRESSNR=GDI_LONG LFDNR=GDI_SHORT COMMART=GDI_CHAR10 COMM=GDI_CHAR100 -- [CM_ADRESSCOM.INDIZES] CM_ACCOMMNR=,+,COMM CM_ACIDNR=*,+,ADRESSNR,LFDNR,COMMART -- [CM_DOKU.FELDER] DOKUID=GDI_CHAR40 DOKUTYP=GDI_SHORT DOKUSUBTYP=GDI_SHORT PARENT=GDI_CHAR40 PERSONALNR=GDI_LONG BELEGID=GDI_CHAR20 PROJECTID=GDI_CHAR20 ADRESSID=GDI_CHAR20 VON=GDI_CHAR100 BETREFF=GDI_CHAR100 NOTIZ=GDI_MEMO KONTAKT=GDI_MEMO EMAIL=GDI_MEMO KATEGORIE=GDI_MEMO MSGID=GDI_CHAR40 BLOBFELD=GDI_BINARY BLOBTYP=GDI_CHAR5 PRIORITAET=GDI_CHAR1 KZANHANG=GDI_CHAR1 KZRUECKMELDUNG=GDI_CHAR1 GEDRUCKT=GDI_DATE GEDRUCKTBED=GDI_CHAR5 GESENDET=GDI_DATE GESENDETBED=GDI_CHAR5 ERSTELLT=GDI_DATE ERSTELLTBED=GDI_CHAR5 FAELLIG=GDI_DATE KZERINNERN=GDI_SHORT ERINNERNMINUTEN=GDI_LONG ERINNERNDATUM=GDI_DATE

Die Tabelle CM_ADRESSLINK verknüpft die Daten der Tabelle CM_Adressen mit den bekannten Stammdatentabellen. Im Feld Adressnr wird die CRM-Adresse festgehalten, das Feld Adresstyp gibt Auskunft über deren Funktion (z.B. "K" = Kunde, "L" = Lieferant) und das Feld Nummer enthält die Schlüssel-Nummer des zugeordneten Stammdatensatzes (z.B. die KundenNr oder die LieferNr).

In der Tabelle CM_ADRESSCOM werden Informationen über die Kommunikationswege zu den CRM-Adressen gesammelt. Jede im System erfasste Telefonnummer oder eMail-Adresse wird in dieser Tabelle festgehalten, so dass beispielsweise in der Vorgangsverwaltung anhand dieser Daten eine Adresse gefunden werden kann (Anruferkennung bei eingehenden Telefonaten, Automatische Zuordnung eingehender Mails).

In der Tabelle CM_DOKU werden sämtliche Dokumente und Vorgänge gespeichert. DOKUTYP in CM_Doku (Nummer=Vorgang [Symbol]): 1=Entwurf (Dokument) [25] 2=Postausgang [129] 3=Posteingang [130] 4=Telefon [38] 5=Aufgabe [5] 6= ----------- nicht mehr verwendet (Terminper) 7= ----------- nicht mehr verwendet (Terminres) 8=Notiz [1] 9=Termin [138] 10=vorgesehen für Belege 11=vorgesehen für Projecte 12=vorgesehen für Verträge 13=vorgesehen für BelegArchiv


BEGINNT=GDI_DATE TERMINPERS=GDI_LONG RICHTUNG=GDI_SHORT RUFNR=GDI_CHAR40 ZEITVON=GDI_DATE ZEITBIS=GDI_DATE DAUER=GDI_LONG STATUS=GDI_SHORT STATUSPROZ=GDI_SHORT ORDNERID=GDI_CHAR20 PRIVAT=GDI_SHORT NOTIZID=GDI_CHAR40 UPDFLAG=GDI_CHAR1 AENDBED=GDI_CHAR5 AENDDATUM=GDI_DATE -- [CM_DOKU.INDIZES] CM_DKBRIEFID=*,+,DOKUID CM_DKPERSONALNR_DESC=,-,PERSONALNR,ERSTELLT CM_DKBRORDNER_DESC=,-,ORDNERID,ERSTELLT CM_DKMSGID=,+,MSGID CM_DKPERSONTYP_DESC=,-,PERSONALNR,DOKUTYP,ERSTELLT CM_DKDATUMPERS_DESC=,-,ERSTELLT,PERSONALNR -- [CM_DOKULINK.FELDER] IDENT=GDI_CHAR40 TYP=GDI_SHORT DOKUID=GDI_CHAR40 LFDNR=GDI_SHORT DATUM=GDI_DATE PERSONALNR=GDI_LONG BELEGID=GDI_CHAR20 -- [CM_DOKULINK.INDIZES] CM_DLIDNR=*,+,IDENT,DOKUID,LFDNR CM_DLDATUM_DESC=,-,DATUM CM_DLIDENTTYP=,+,IDENT,TYP CM_DLPERSONALNR=,+,PERSONALNR CM_DLDOKUID=,+,DOKUID CM_DLBELEGID=,+,BELEGID -- AdressTyp in CM_Adressen Die Tabelle CM_Adressen enthält die Grunddaten zu allen in der Bline angelegten Adressen. Funktions-bestimmende "Daten" wie Preislistenzuordnung, Zahlungsbedingungen, Mahngruppen etc. sind (wie früher bei der GDILine) in den zugehörigen Tabellen Kunden, Liefer, Vertret etc. abgelegt. Um leicht erkennen zu können, welche "Funktion" eine Adresse besitzt wurde das Datenfeld AdressTyp implementiert. Es handelt sich um ein numerisches Feld, jeder Zahlenwert steht für genau eine Funktion, binäre Kombinationen sind möglich: 1 = Kunde 2 = Lieferant 4 = Interessent 8 = Vertreter 16 = Personal

In der Tabelle CM_DOKULINK werden Verknüpfungen zwischen Dokumenten/Vorgängen und den Adressen gespeichert. Ein Dokument/Vorgang kann mehreren Adressen zugeordnet sein.


3 = 1+2 = Kunde + Lieferant 9 = 1+8 = Kunde + Vertreter Der Anwender muss in der Regel diese Nummern nicht kennen, in der Programmoberfläche z.B. in der Adresstabelle finden sich "sprechende" Anzeigen. Für den Fachhandel ist die Kenntnis z.B. für SQL-Auswertungen wichtig. Um die möglichen Kombinationen abgreifen zu können, wurden die UDF-Funktion "bin_and" entwickelt: select * from CM_Adressen where Adresstyp = 8; à selektiert Adressen, die ausschließlich als Vertreter deklariert sind, Adressen mit weiterer Funktion z.B. als Kunde oder Lieferant erscheinen nicht im Ergebnis select * from CM_Adressen where bin_and(Adresstyp,8) = 8; à selektiert Adressen, die als Vertreter deklariert sind, diese können aber gleichzeitig auch noch als Kunde, Lieferant im System sein Adresstyp in CM_AdressLink Im Gegensatz zur CM_Adressen-tabelle ist in der Tabelle CM_AdressLink das Datenfeld AdressTyp als alphanumerisches Feld definiert. Das Kürzel zeigt unmittelbar die Funktion des Adresse an ("K" = Kunde, "L" = Lieferant …). Es gibt hier keine "Mehrfachbelegung". Datenfeld Suchname Bei den CM_Adressen das Feld Suchname in der Art gefüllt, dass alle Ansprechpartner (AP) zu einer Adresse den Suchnamen ihrer Hauptadresse besitzen. Änderungen am Suchnamen eines APs werden beim Speichern verworfen. Eine "Initialisierung" in bestehenden Daten ist über folgende SQLs möglich (!!ACHTUNG: Kann lange laufen!!): update CM_Adressen set Suchname = "X" || Suchname where StrLen(Suchname) < 40 and LfdNr = 0; update CM_Adressen set Suchname = Cast(Copy(Suchname,2,39) as VarChar(40)) where StrLen(Suchname) <= 40 and LfdNr = 0; Notizen aus der GDILine: Die Notizen aus dem Factur-Bereich werden nicht in die neue Dokumentenstruktur der Bline "verschoben", sondern bleiben praktisch unverändert erhalten. In der Bline wurde die Möglichkeit geschaffen, dass diese zusammen mit den neuen Dokumenten in der Vorgangsverwaltung angezeigt werden können. In den Masken des Factur-Bereiches kann die Erfassung von Notizen bei Bedarf weiterhin erfolgen (aktuell erfolgt dies durch den Email-Versand beim Belegdruck). Terminverwaltung aus GDILine: Die bei den alten Notizen der GDILine verfügbare Terminverwaltung ist im Bline-"Standard" nicht als Menüpunkt vorhanden. Bei Bedarf ist hierfür ein Menüpunkt mit der Verknüpfung zum Programmaufruf "TFTermine" zu ergänzen. Eigene Felder in Ansprechtabelle aus GDILine Die Tabelle Ansprech bleibt in der Datenbank erhalten, wird aber in der Bline nicht mehr verwendet! Es gibt das GDI-Basic-Programm "Ansprech_CM_Adressen.prg" mit welchem bei Bedarf nicht durch die Konvertierung erfasste (Zusatz-) Datenfelder von der Tabelle Ansprech nach CM_Adressen übertragen werden können.


Reorganisation Durch eine Reorganisation können Änderungen an der Datenstruktur und an den datenbank-internen Verarbeitungsroutinen vorgenommen werden, ebenso können sogenannte Vorgabedaten in die Datenbank eingebracht werden. Eine Reorganisation ist in der Regel bei einem Programmupdate notwendig, um die Datenbank an die Programmversion anzupassen. Sie stellt außerdem ein wichtiges Werkzeug für den Fachhandel dar, wenn individuelle Erweiterungen vorgenommen werden sollen. Aufbau der Reorganisationsmaske:

• Links: Auswahlmöglichkeit für Metadaten, XML-Importdaten und Button zum Einfügen der

Vorgabedaten in die Datenbank. Unter "Metadaten" sind alle Informationen über die (Soll-) Struktur der Datenbank zu verstehen. Sie umfassen demnach die zu verwendenden Datentypen, die sog. User Defined Funktions (UDF), die Tabellen mitsamt ihren Indizes und die Trigger und Proceduren. Gespeichert werden die Metadaten in Textdateien mit der Dateiendung ".meta" im gleichnamigen Ordner unterhalb des Programmverzeichnisses. Öffnet man eine solche Datei mit einem Editor kann man erkennen, dass es sich um eine Zusammenfassung der aus der alten Reorganisation der Gdiline bekannten Dateien Domain.sql, GDILine.dbs und Procedur.sql handelt. Als Besonderheit ist zu nennen, dass man mehrere Metadaten-Dateien gleichzeitig verwenden kann (wie in der obigen Abbildung dargestellt). Somit kann ein Fachhändler seine individuellen Strukturanpassungen in einer eigenen Metadaten-Datei zusammenstellen und additiv zu den Strukturvorgaben von GDI in die Datenbank reorganisieren. à was ist hinsichtlich der Namenskonvention zu beachten? Das Präfix von Meta-Dateien und darin enthaltener Trigger und Proceduren ist von zentraler Bedeutung. Es bestimmt, welche Trigger und Proceduren im Verlauf der Reorganisation gelöscht werden. So werden nach Ablauf der eigentlichen Reorganisation alle Trigger und Proceduren aus der Datenbank gelöscht, für welche eine Metadatei mit gleichem Präfix existiert, welche aber selbst nicht in dieser Metadatei enthalten sind. (Vgl. alter Reorg: Es werden alle "GDI_" –Trigger und -Proceduren zu Beginn des Reorgs gelöscht).


Sofern GDI-Trigger oder -Prozeduren "übersteuert" werden sollen, ist darauf zu achten, dass die eigene Metadatei gemäß alphabetischer Sortierreihenfolge nach den GDI-Metadateien liegt. Sofern die Metadatei unterhalb des Mandanten abgelegt ist entfällt diese Einschränkung, namensgleiche SP/Trigger aus Meta-Dateien im Mandanten haben Vorrang vor denen aus der Programmebene. Im Übrigen werden in der Bline die in den Nummernkreisen definierten Zusatzfelder (TI-Datensätze der Tabelle GDIDEF) als "dynamische" Metadaten bei der Reorganisation berücksichtigt. Unter "XML-Importdaten" sind Daten zu verstehen, welche in eine bestehende Datenbank importiert werden sollen. In der Regel wird diese Funktion bei Neuanlage eines Mandanten benötigt, um die zunächst angelegten, leeren Tabellen mit Vorgabedaten zu füllen. Beispiele können die Nummernkreisdefinitionen, Steuerschlüssel, die Datensätze der Tabelle "Staat" oder ähnliches sein. Bei den Dateien handelt es sich um Dateien im XML-Format. Wie bei den Metadaten besteht die Möglichkeit, mehrere Dateien parallel zu verwenden. In den Datensätzen der Vorgabedaten regelt das Feld "GDIModus" in welchen Fällen ein Datensatz aus einer XML in die Datenbank eingelesen wird. Die Funktion des GDIModus in den XML-Vorgabedaten wurde wie folgt festgelegt:

GDIModus Bedeutung I = Immer Satz wird immer in die Datenbank eingelesen N = Neu (oder Nicht vorhanden) Satz wird eingelesen, wenn er neu / nicht vorhanden ist M = Mandantenneuanlage Satz wird eingelesen, wenn man sich innerhalb der Mandanten-

Neuanlage befindet A = Aktualisieren Satz wird nur eingelesen, wenn er bereits vorhanden war L = Löschen Satz bewirkt Löschen des Satzes in der Datenbank

• Rechts: Protokollfenster Je nach durchgeführter Aktion handelt es sich um ein reines "Prüf-" oder ein "Durchführungs-" Protokoll. Es kann über den Button "Drucken" ausgedruckt werden.

• Unten: Buttons zur Durchführung der Reorganisation Bei einer Reorganisation wird die vorhandene Struktur der Datenbank mit den Vorgaben in den Metadaten-Dateien verglichen. Der Button "Korrektur" wird nur dann aktiviert, wenn das Programm im Modus "Prüfen" eine Differenz zwischen den Vorgaben und der Datenbank festgestellt hat.

Wichtige Hinweise: • Es wird empfohlen, vor einer Reorganisation eine Datensicherung durchzuführen. • Im Falle eines Updates von GDILine à BLine: Liegen Anpassungen in der Datenbank in

Form von Tabellenerweiterungen, Triggern oder Prozeduren vor, so sind diese aus den Reorganisationsdateien der Warenwirtschaft in die der Business Line zu überführen, damit diese Änderungen durch den Reorg. in der Bline nicht verloren gehen. Das bedeutet, dass für die (neue) Reorganisation eine oder mehrere ".meta"-Dateien erzeugt werden müssen, die diesen Bereich abdecken. Sofern z.B. zu Testzwecken noch mit einer GDILine auf die Daten zugegriffen wird, sollte dort der "alte" Reorganisationslauf mit Procedur.sql, Domain.sql und GDILine.dbs im Menü gesperrt werden, damit nicht versehentlich die CRM-Funktionen "eliminiert" werden. Über die GDILine.exe (Warenwirtschaft) darf also nicht reorganisiert werden!


• Sofern Tabellen erweitert oder gar eigene Tabellen definiert werden sollen: Hier sind für die Datentypen die GDI-Domainen zu verwenden (GDI_Char10, GDI_Short etc.)

• Sofern eigene Trigger/Prozeduren geschrieben werden: Für Übergabe- , Rückgabe- und interne Variablen sind Standard-Datentypen zu verwenden (also keine GDI-Domainen).

Versionsreorganisation: Seit Anfang März 2010 gibt es im Programm in der "normalen" Reorganisation eine Checkbox "Versionsreorganisation durchführen". Hierbei handelt es um eine Folge von Schritten, um vorhandene Daten auf den aktuellen Programmstand zu bringen und - bei erfolgreicher Umsetzung - die Versionsnummer des Programmstandes in die Daten einzutragen. Wird bei einem Update eine Änderung der Versionsnummer festgestellt (Programmversion > Datenversion), so springt beim Login automatisch die Reorganisation bestehend aus - "normaler" Reorganisation und - "Versionsreorganisation" an. Die normale Reorganisation dient der Anpassung der Datenstruktur. Läuft sie erfolgreich durch wird die Versionsreorganisation durchgeführt. Wird beim Login (bei vorliegendem Versionsunterschied) die Frage nach der Reorganisation verneint, so kann diese auch über den Menüpunkt Reorganisation "nachgeholt" werden. Die Checkbox ist dann aktiviert.

Abb.: Manuelles Anstossen des Versionsreorg über Kontextmenü, wenn keine Strukturunterschiede vorliegen (der Korrekturbutton ist nur aktiv, wenn der "normale" Reorg. Strukturunterschiede gefunden hat).


Update auf GDI-Business-Line 3.x: ERP mit CRM-Funktionen Die neue GDI-Business-Line (Bline) vereint die bekannten ERP-Funktionen der GDILine mit neuen CRM-Funktionalitäten und kann auf einer Datenbank der Warenwirtschaft "aufsetzen". Neben dem Einsatz als Neuinstallation ist das Programm als Ablösung für eine GDILine-Warenwirtschaft konzipiert. Hierzu sollte die vorhandene Warenwirtschaft (GDILine) zunächst auf einen aktuellen Programmstand gebracht werden (2.3.2.150 oder höher). Bei einem Update ist es zwingend erforderlich, dass die Daten auf den Stand der Bline konvertiert werden (siehe hierzu den Abschnitt Konvertierung), weitere Maßnahmen betreffen in erster Linie individuelle Erweiterungen. Die notwendigen Schritte bei einem Update:

1. Vorbereitung: Prüfen der Datenstruktur der "alten" GDILine, insbesondere auf Erweiterungen im Bereich Trigger und Proceduren. Ggfs. Erzeugen eigener ".meta"-Reorganisationsdateien.

2. Installation der GDI Business-Line in ein neues Verzeichnis (Achtung: Das Setup schlägt u.U. das Verzeichnis der letzten GDILine-Installation vor!)

3. Anlage eines neuen Daten-Verzeichnisses im Ordner "Mandanten" 4. Kopieren der GDI.GDB in dieses Verzeichnis 5. Durchführen einer Mandantenanlage mit der Option "Bestehende Datenbank auswählen". * 6. Durchführen der CRM-Konvertierung, so dass die neuen Tabellen aufgrund der im System

vorhandenen Daten gefüllt werden (Versionsstand der Daten ist nun "3.0.0.0"). 7. Einloggen in den Mandanten. Der Versionsreorg. startet und führt ggfs. Schritte durch, um

die Daten auf den zur Version der Bline.exe passenden Stand zu bringen (z.B. "3.1.0.192"). 8. Umkopieren der relevanten Dateien aus der GDILine-Mandantenordner in die neue

Ordnerstruktur (Reports, PDFs, SQLs, Masken, Basic-Programme, ARCHIV, Vorlagen, ...). Wichtig: Die Archivdaten unbedingt vor dem Einsatz der Bline umkopieren.

9. Die Maskenumsetzung erfolgt bei Aufruf der jeweiligen Maske in der Bline. Daher sind Masken aus der GDILine-Umgebung in die Bline-Umgebung zu kopieren und dort ins Menü einzubinden. Aktionen des Maskenkonvertierung: • Ersatz TpsTable durch BDE-freie TsTable • Aktualisierung WP-Richtext-Komponente • Austausch von Buttons und TpsNotes durch TsButton und TsPageControl wegen Skin.

10. Angepasste/gespeicherte Menüs können aus der GDILine nicht in die Bline übernommen/konvertiert werden. Diese sind neu einzustellen.

11. Alter Reportdesigner: Listen/Belege, welche das Objekt TrpWpRichText enthalten, können mit der Bline nicht direkt gedruckt werden. Die Ausliefer-Reports enthielten diesen Typ bei den Belegen und bei den Serienbriefen. Gegebenenfalls ist ein Ausdruck möglich, wenn ein Ersatz durch den Objekttyp TrpRichtext im Formular vorgenommen wird. Bei Belegen wurde die Möglichkeit implementiert, über die Systemdateneinstellung "Belegdruck.Extern=JA" (im Textmodus einzugeben) den Druck über die psReporter1.exe auszuführen. Diese unterstützt den alten WP-Komponentenstand.

*Sollte während des Reorg. bei der Neuanlage die Indexanlage CREATE UNIQUE INDEX AC_UUID ON ARCHIV (SATZUUID) misslingen, so ist die SQL update archiv set SatzUUID = "X" notwendig. Anschl. Programm neu starten und Reorg. wiederholen.


Firebird-ODS und ODSKonver.exe ODS steht für On Disk Structure - das ist das Format, in welchem Firebird (FB) Datensätze, Indizes und Metadaten in der Datenbank speichert. Hier gibt es von FB-Version zu FB-Version einige (in der Praxis meist unproblematische) Änderungen. Neuere FB-Versionen können i.d.R. die Datenbanken mit ODS älterer FB-Versionen verarbeiten bzw. öffnen, im Sinne eines sicheren Einsatzes sollte die tatsächliche ODS der Datenbank der jeweiligen Firebird-Version entsprechen. Folgende Tabelle gibt einen Überblick:

Firebird-Version Architektur ODS-Version 1.0 32-bit 10 1.5 32-bit 10.1 2.0 32-bit und 64-bit** 11.0 2.1 32-bit und 64-bit** 11.1 2.5 32-bit und 64-bit** 11.2 3.0* 32-bit und 64-bit* 12.0*

* Firebird 3 befindet sich noch in der Entwicklung (Stand 02.2011) ** Unabhängig von der Architektur sind bei gleicher Firebird-Version die Datenbanken identisch ODS prüfen: In der Mandantenverwaltung kann über das Kontextmenü (rechte Maustaste) auf einem Mandanteneintrag geprüft werden, welche ODS bei der Datenbank vorliegt.

Voraussetzung ist, dass ein Firebird-Server auf der Maschine verfügbar ist, welcher die Datenbank öffnen / auslesen kann (siehe Stichwort "32/64-Bit Inkompatibilität" im nächsten Abschnitt).


Um die Datenbankstruktur an den eingesetzten Firebird-Server anpassen zu können, gibt es das Programm ODSKonver.exe. Dieses befindet sich im Programmverzeichnis der Bline. Es kann direkt gestartet oder aus der Bline heraus an folgenden Stellen aufgerufen werden: • Bei einem Login in eine Datenbank (insbesondere bei Neuanlage eines Mandanten mit Zugriff

auf eine bestehende Datenbank) wird die ODS geprüft und bei Bedarf die ODS-Konvertierung gestartet. Wird diese nicht durchgeführt lässt das Programm Strukturänderungen an der Datenbank durch eine Reorganisation nicht zu und gibt eine entsprechende Meldung aus.

• Im Programmpunkt "Reorganisation" findet man ab 3.1.0.192 den Button "Datenbank Upgrade". Dahinter verbirgt sich die ODS-Konvertierung.

• In der Mandantenverwaltung/Anmeldefenster über das Kontextmenü (rechte Maustaste). Zum Aufbau der ODSKonver-Maske: Oben findet man die Angabe des Datenbankpfades gefolgt von Informationen über die Datenbank. Wichtig ist vor allem die Angabe über den Ist-Zustand der Datenbank-ODS. Den unteren Teil der Maske bestimmt die Anzeige und ggfs. Auswahlmöglichkeit des/der installierten Firebird-Servers. Die Anzahl und Funktion der Buttons variiert je nach Ort und Stelle, von welchem aus ODSKonver.exe aufgerufen wurde.

"Eckpunkte" der ODS-Konvertierung: • Bei einer "Aufwärtskonvertierung" reicht es in der Regel aus, wenn der Firebird-Server (FB) in

der höheren (Ziel-) Version auf der Maschine vorhanden ist. Eine Ausnahme ergibt sich durch eine "32/64-Bit Inkompatibilität" beim Upgrade auf die 64-Bit-Versionen. Diese können die Datenbanken von FB1.0/FB1.5 nicht öffnen. So erfordert eine Konvertierung von FB 1.5 (32-bit) nach FB 2.1 (64-bit) oder FB 2.5 (64-bit) einen 1.5er FB auf der Maschine, eine Konvertierung von FB 1.5 (32-bit) nach FB 2.1 (32-bit) oder FB 2.5 (32-bit) dagegen nicht.

• Eine "Abwärtskonvertierung" erfordert immer das Vorhandensein beider Firebird-Server Varianten (Ziel und Quelle) auf dem Rechner.


"Support-Modus": Für Support-Mitarbeiter besteht ab und zu die Notwendigkeit, Prüfungen an bestehenden Datenbanken vorzunehmen ohne dass diese reorganisiert oder bzgl. ihrer ODS-Struktur verändert werden sollen. Aus diesem Grunde wurde zur Version 3.1.0.192 ein "Support-Modus" integriert: Wird im Mandantenwechsel einer der Buttons "Anmeldung" bzw. "Neuanlage" bei gedrückter Tastenkombination Strg+Alt+Shift gewählt, so werden Warnmeldungen während des Logins unterdrückt und ein Anmelden auch ohne Reorganisation/ODS-Konvertierung zugelassen. Bitte beachten: Unter Umständen ist im Support-Modus kein erfolgreicher Login möglich (die üblichen Prüfungen sind ja abgeschaltet). Sofern der Login möglich wurde, ist die Reorganisation im Programm nicht möglich, wenn die ODS "nicht passt". Der Supportmodus ist bei Neuanlage einer neuen Datenbank ohne Wirkung, ebenso bei Zugriff mit einem 64-Bit-FB auf eine Datenbank mit FB 1.0/FB1.5-Struktur. Hier muss zwangsläufig die ODS umgestellt werden. Daten-Konvertierung GDILine à Bline Bevor die neue BLine als Ersatz für eine vorhandene GDILine-Warenwirtschaft eingesetzt werden kann, müssen die Daten konvertiert werden. Bei dieser Konvertierung werden die bestehenden Adresstabellen (Kunden, Lieferanten, Interessenten und Vertreter) in der neuen (gemeinsamen) Adresstabelle (CM_Adressen, s.o.) zusammengefasst. Nach der Konvertierung können Kunden-, Lieferanten-, Interessenten- und Vertreterdaten (inkl. Ansprechpartner) innerhalb der Bline im neuen Adressbereich und in den bekannten Stammdatenmasken geändert werden, nicht aber die Personaldaten. Die Personaldaten der Warenwirtschaft werden in eine weitere Tabelle überführt und mit einer numerischen Personalnummer geschlüsselt. Hierzu sind folgende Maßnahmen/Schritte notwendig: Schritt 1: Mandantenanlage Nach Anlage eines neuen Daten-Verzeichnisses im Ordner "Mandanten", Kopieren der Datenbank der WAWI in dieses Verzeichnis führt man eine Mandantenanlage mit Zugriff auf diese bestehende Datenbank durch. Im Zuge dieser Mandantenanlage erfolgt: • eine Anpassung der Firebird-ODS-Version - falls der Firebird-Server gewechselt wird. • eine Datenreorganisation (neuer Reorg. mit ".meta"-Datei) zur Erweiterung der Datenbank-

Struktur.

Schritt 2: CRM-Konvertierung Dieser Schritt wird über den Menüpunkt "Konvertierung CRM" im Systemmenü durchgeführt und umfasst die Teilschritte: • Umsetzen der Bediener. Jedem Anmeldebediener wird in der Bline eine (numerische)

Personalnummer zugeordnet. Mehrere Anmeldebediener können auf dieselbe Personalnummer verweisen.

• Die eigentliche Konvertierung der Adressdaten. Versionsstand ist danach 3.0.0.0 Schritt 3: Versionsreorganisation Den abschließenden Schritt stellt die Durchführung der Versionsreorganisation dar, entweder bei erneutem Login oder manuell angestossen im Menüpunkt "Reorganisation". Durch die Versionsreorganisation wird beispielsweise die Eintragung neuer Adressverweise in den Belegen und Belegpositionen vorgenommen. Nach fehlerfreier Versionsreorganisation entspricht der Daten-Versionstand dem aktuellen Versionsstand der Bline.exe, z.B. 3.1.0.196.


Nachfolgende Abbildung zeigt den Start des Schritt 1 (Mandantenanlage "Bestehende Datenbank auswählen"):

Nachdem der Pfad zur gewünschten Datenbank eingestellt ist wird mit Klick auf "Weiter" die eigentliche Mandantenanlage mit Prüfung der Firebird-ODS eingeleitet. Tipp: Sofern der "alte" zur Datenbank passende FB-Server noch auf der Maschine vorhanden ist, kann er zum besseren Überblick zunächst beibehalten werden. Die Umstellung auf einen anderen Firebird kann später separat erfolgen. Bitte beachten Sie bei den folgenden Bildschirmen angezeigte Hinweise und Meldungen genau. Am Ende einer Reihe von Teilschritten "landet" man wieder in der Maske "Mandantenwechsel" und kann sich in den neuen Mandanten einloggen. Als einziger Bediener ist zu diesem Zeitpunkt der "admin" verfügbar. Es erfolgt der Hinweis auf die noch anstehende CRM-Konvertierung.


Für den zweiten Schritt ist nun der Menüpunkt "Konvertierung CRM" anzuwählen. Nach einem "Begrüßungsbildschirm" mit Hinweisen zur Konvertierung gelangt man zur Bedienerumsetzung:

Bei der Zuordnung der alten Bediener in die neue Bedienertabelle besteht die Möglichkeit, doppelt geführte Bediener zusammen zu fassen. Damit entsteht eine genaue Zuordnung aller alten Vorgänge zu den zukünftigen Bedienern. In der linken Bildschirmhälfte sehen Sie zunächst alle im der Warenwirtschaft angelegten Bediener.

• Mit "Bediener à" erstellen Sie im neuen GDI CRM plus einen Bediener, der zukünftig aktiv mit dem Programm arbeiten soll. Der ausgewählte Bediener wird in die rechte Bildschirmhälfte überstellt.

• Mit "ß Bediener" können Sie einen Bediener von rechts nach links zurück stellen ("Rückgängig"-Funktion).

• Mit "Zuordnen" können Sie den in der linken Seite markierten Bediener wie über den Button "Bediener à" auf die rechte Seite überstellen, er wird allerdings dem aktuell in der rechten Seite markierten Bediener zugeordnet. Ein solcher Bediener bleibt als eigenständiger Anmeldebediener bestehen, er kann beispielsweise einer anderen Bedienergruppe zugeordnet sein. Er wird im System allerdings unter der selben Personalnummer wie der übergeordnete Bediener geführt. Das ist sinnvoll, wenn es sich tatsächlich um ein und dieselbe Person handelt.

• Sollte bei Ihnen jeder Bediener im alten System einmal angelegt worden sein, können Sie mit der Funktion "Alle übernehmen" die Einzel-Zuordnung übergehen. Alle Bediener werden 1:1 von links nach rechts übernommen.

Alle Bediener, welche nicht von links nach rechts überführt werden, werden nicht als Anmeldebediener für das CRM übernommen (z.B. ausgeschiedene Mitarbeiter). Systemintern werden den Bedienern eindeutige vierstellige Personalnummern zugeordnet.


Aus technischen Gründen können die Anmeldebediener im CRM nur in Kleinschreibung verwendet werden. In der Warenwirtschaft war dagegen eine gemischte Schreibweise zulässig. Bei der Konvertierung erfolgt eine automatische Umsetzung in Kleinbuchstaben. Werden Doppelungen erkannt (z.B. wenn in der WAWI die Bediener "Test" und "TEST" verwendet wurden), wird eine entsprechende Hinweismeldung ausgegeben. In solchen Konstellationen kann nur einer als Anmeldebediener übernommen werden (im Beispiel "test") und es wird empfohlen, die Funktion der Bediener-Zuordnung (s.o.) zu verwenden. Somit werden bisherige Notizen der wegfallenden Bediener bei den übergeordneten Bedienern im CRM sichtbar sein. Notizen der Warenwirtschaft werden nicht in die neue Dokumentenstruktur der Bline "verschoben", sondern bleiben praktisch unverändert erhalten. In der Bline wurde die Möglichkeit geschaffen, dass diese zusammen mit den neuen Dokumenten angezeigt werden können. Hardcopies einer Bedienerumsetzung (ohne aktivierten Skin):

Alle übernehmen -->


"zurück" und Bedienerübernahme geändert, Möglichkeit der Zuordnung genutzt:

Ist die Bedienerzuordnung abgeschlossen, wechselt man mit "Weiter" zur Adressdaten-Umsetzung, bei fehlerfreier Umsetzung wird die CRM-Konvertierung mit einer "Erfolgsmeldung" beendet:

Durch einen erneuten Login in die Datenbank (Mandantenwechsel) wird die Versionsreorganisation angestoßen und somit der dritte und letzte Schritt der Umsetzung durchgeführt:


Bediener- und Rechner-Einstellungen im CRM à Siehe Menüpunkt "Systemmenü | Einstellungen". Hier werden die Einstellungen für den jeweiligen Bediener und Arbeitsplatz vorgenommen. • Bedienereinstellungen:

Die Bedienereinstellungen werden hinter dem Anmeldekürzel gespeichert und gelten für jeden Arbeitsplatz im Netzwerk, auf dem das Programm aufgerufen wird. Z.B. können die Skins und Einstellungen für den Brief-Editor festgelegt werden.

• PC-Einstellungen: Rechnerbezogen sind dagegen Einstellungen wie die Tapi-Schnittstelle oder die Verknüpfung zum am Rechner vorliegenden Mail-System. Die PC-Einstellungen gelten für den Arbeitsplatz, an dem der Mitarbeiter normalerweise sitzt. Information zur Tapi: Die Bline unterstützt die Tapi -Version 2.1. Die Tapi 2.1 -"Definition" ist abwärtskompatibel --> d.h. Telefonanlagen mit Tapi 2.1 sollten auch die Befehle der Tapi 1.3 unterstützen, ein Telefonieren aus/mit der Bline sollte funktionieren. Bei der Tapi 1.3 handelt es sich um die sog. First-Party-Architektur, bei der das Telefonendgerät i.d.R. über die serielle oder USB-Schnittstelle direkt mit dem lokalen PC gekoppelt wird.

Bei den Mail-Einstellungen gibt es eine bedienerabhängige Steuerung (allerdings nicht mandantenabhängig): Es gibt im Verzeichnis BEDIENER folgende Arten von Dateien: a) Bline_Bedname.txt b) Bline_PCname.PC c) [email protected] Die PC-Datei gibt an, welche Art der Mail-Anbindung betrieben wird. Dabei gilt die Datei ohne "@" bei normalen Netzwerkzugang, die Datei mit "@" ist es nur bei Zugang über Terminal(server) vorhanden. Die TXT-Datei ist bei Mails relevant, wenn es um POP3/SMTP geht. Ist MAIL über MAPI eingestellt, so gilt dies für den Rechner (PC-Datei) Ist MAIL über POP3/SMTP eingestellt, so gilt das an sich auch für den Rechner, aber die TXT-Datei wird mit einbezogen. Dort stehen bedienerabhängig die Zugangsdaten drinnen. Das in den CRM-Masken eingestellte Layout/Design wird beim Speichern in Voreinstellung bedienerbezogen gespeichert. Näheres siehe unten im entsprechenden Abschnitt.

mailto:[email protected]


Menüdesigner/Rechteverwaltung Im Grundsatz wird mit einer Rechtestruktur gearbeitet, wie man sie bislang in der Warenwirtschaft verwendet (Lizenzrecht, Menürecht, Aliasrecht/Programmrecht). Neu hinzugekommen sind bedienerbezogene Rechtevergaben auf bestimmte Datenbereiche (Umsätze, Belege...), auf Personal und Ressourcen. Der Menüdesigner zum "sichtbaren" Menü umfasst jetzt drei Bereiche:

• Systemmenü (vertikal) • Menü (horizontal) • Toolbar (Schnellstart-Leiste)

Desweiteren gibt es jetzt eine Anzeige für alle aktuell geöffneten Fenster, welche einen schnellen Wechsel zwischen den offenen Masken ermöglicht. Derzeit werden mehrere Menü-Dateien mitgeliefert:

• BLINE_Menue_Factur.txt: Komplettes Menü mit CRM, WAWI und Zeiterfassung • BLINE_Menue_CRM.txt: Nur CRM-Menüpunkte • BLINE_Menue_Zeit.txt: Nur Zeiterfassung-Menüpunkte • BLine_Menue_Softterminal.txt: Reduziertes Menü bei Einsatz des Softterminals • BLINE_Menue.txt: In der Auslieferung mit BLINE_Menue_Factur.txt identisch. à Sofern

in der Datenbank kein Menü gespeichert ist, greift das Programm automatisch auf diese Datei zu (Vorgabemenü).

Hinweise zum Einbinden eigener Masken ins Menü siehe unten im entsprechenden Abschnitt. Einige Anmerkungen:

• Angepasste/gespeicherte Menüs können aus der GDILine nicht in die Bline übernommen/konvertiert werden.

• Wird in einer Maske aus dem CRM-Bereich eine Aktion durchgeführt, welche Bereiche aus dem WAWI-Bereich betrifft, so wird hierbei das zugehörige Programmrecht verwendet. Beispiel 1: Adressen | Adress-Stamm > Kunden. Für die Berechtigung einer Kundenanlage /-bearbeitung wird das auf TFAKunden liegende Programmrecht ausgewertet. Hat man also auf TFAKunden nur Leseberechtigung, so kann kein Kunde aus der CRM-Maske heraus angelegt werden, auch wenn für den Adress-Stamm volle Zugriffsrechte bestehen. Beispiel 2: Adressen | Adress-Stamm > Interessenten. Hier wird das Recht für TFInteressenten ausgewertet. Stellt man hier "rot" = "kein Rechte" ein, so wird der Karteireiter Interessenten im AdrStamm ausgeblendet.

• Berechtigung für Kategorie: Ob eine Bedienergruppe eine Kategorie anlegen darf, wird über die Klasse "TKategorie" auf der Karteikarte "Rechte" gesteuert (Rechte > Programme > TKategorie).

• Sonderstatus des Bedieners "admin": Er darf als einziger Bediener Mandanten anlegen und ist immer der Bedienergruppe "ADMIN" zugeordnet.

• Sonderstatus der Gruppe "ADMIN": Diese hat immer Zutritt zur Rechteverwaltung. • Neu gegenüber der GDILine: Steuerung, ob eine Maske modal geöffnet wird oder nicht

(Modal bedeutet, dass andere Menüpunkte/Masken erst bearbeitet werden können, wenn zuvor die aufgerufene Maske geschlossen wurde). Desweiteren kann eine Maske freistehend geöffnet werden. Die Maske lässt sich dann aus dem GDI-Hauptfenster herausschieben, z.B. wenn man zwei Bildschirme hat.


Grid-Designer Das Gridobjekt ist grundsätzlich neu, es gibt die Unterscheidung zwischen: Vertikaler Grid (VGrid) Horizontaler Grid (HGrid) Die Funktionen dieser beiden Grids sind sehr umfangreich. Hier wurde/wird nach Sichtung/Prüfung eine Beschreibung der wichtigsten (praxisrelevanten) Funktionen erforderlich. Einige Punkte finden Sie auf den folgenden Seiten. Drop-Down-Menüs zum Speichern von Gridbuttons (GBN) und Masken (MSK2) im CRM-Bereich der GDI-Business-Line In der GDI-Business-Line wurden Drop-Down-Menüs zum Speichern und Löschen von Masken und Griddefinitionen implementiert. Deren Funktion wird im Folgendem beschrieben: MSK2-Masken-Speichern In den Masken des CRM-Bereiches gibt es ein Drop-Down-Menü über das "Zahnrad"-Symbol, um den Designer aufrufen zu können. Über den Designer zudem angezeigt, welche MSK2-Definitionsdatei zugrunde liegt und woher sie geladen wurde.

Dieses Fenster zeigt im oberen Bereich die designbaren Objekte an. Per Doppelclick auf einen Eintrag oder über den Designen-Button kann der eigentliche Designer gestartet werden. Über den unteren Bereich wird eine Maske gespeichert. Es wird angezeigt, ob und woher eine gespeicherte Maske geladen wurde.

Geladen/gesucht wird in folgender Hierarchie: • MSK2-Definition aus

Mandanten, bedienerbezogen

• MSK2-Definition aus Mandanten, allgemein

• MSK2-Definition aus Programm (mandantenübergreifend), allgemein


Hinweise: • Das Laden einer bedienerbezogenen Maske aus der Programmebene ist nicht vorgesehen • Nur der Bediener admin besitzt die Berechtigung, eine MSK2-Maske in der Programmebene

(mandantenübergreifend) zu speichern oder aus der Programmebene zu löschen • Die Masken aus dem CRM-Bereich besitzen als Dateiendung/Suffix "MSK2" zur Abgrenzung von Masken aus

dem Factur-Bereich ("MSK"). Die Masken aus dem Factur-Bereich der Bline besitzen wie früher als Dateiendung ".MSK" oder ".TXT und werden im selben Ordner wie die MSK2-Masken abgelegt.

GBN-Gridbutton-Speichern Wurde ein Gridbutton gedrückt und die Auswahltabelle ist sichtbar, so kann dort das Drop-Down-Menü über das "Zahnrad"-Symbol geöffnet werden, um die erforderlichen Einstellungen vorzunehmen und die GBN-Datei zu speichern. Gleichzeitig wird dort angezeigt, welche Griddefinitionsdatei zugrunde liegt und woher sie geladen wurde.

Geladen/gesucht wird eine GBN-Definition in folgender Hierarchie: - Griddefinition aus Mandanten, bedienerbezogen - Griddefinition aus Mandanten, allgemein - Griddefinition aus Programm, allgemein Hinweis: Das Laden einer bedienerbezogenen Griddefinition aus Programmebene ist nicht vorgesehen.

• Bedienerbezogen speichern in Verzeichnis Grids unterhalb des Mandanten z.B. "ADRESSEN_admin.GBN"

• Allgemein speichern z.B. als ADRESSEN.GBN über Speichern-Dialog mit Vorschlag Verzeichnis Grids unterhalb des Mandanten

• Aufruf Griddesigner

• Aufruf SQL-Bearbeitung

• Löschen der aktuell geladenen Definition (GBN-Datei). Nicht verfügbar, wenn Grid aus Programmebene gezogen wurde.

• Anzeige der aktuell geladenen Definition über GBN-Dateiname plus Herkunftsangabe in Klammern. (P) = Programmebene, (M) = Mandantenebene


Anpassung des neuen Grid (Masken-Griddesign (VGrid, HGrid) und F4-Griddesign) Masken-Griddesign In der NavBar befindet sich das "Zahnrad" zum Aufruf des Designers. Hier den Eintrag "Designer" wählen. Es startet das Fenster mit der Auswahl der designbaren Objekte und stellt sich - falls in der Maske mehrere Grids designt werden können - immer auf den aktuell in der Maske markierten Grid ein. Ein Doppelclick oder der Designen-Button startet den eigentlichen Designer. Über eine Radiobox mit den möglichen Werten "Grid", "Felder" und "Zeilen" bzw. "Spalten" lassen sich die drei Grundbereiche des Griddesigns auswählen: Grid: Designen des Grids Nach Aufruf des Designers ist rechts oben in der Radio-Box der Eintrag "Grid" eingestellt. Das bedeutet, dass im linken Designer-Bereich grundsätzliche, für den gesamten Grid geltende Einstellungen getroffen werden können. Hierzu Beispiele: Vertikaler Grid (VGrid) Property "Layoutstyle": Legt fest ob der Grid Daten einspaltig oder mehrspaltig darstellen soll. • IsBandView: Ein Datensatz wird dargestellt und gegebenenfalls automatisch auf mehrere

Spalten umgebrochen, wenn der Platz nicht ausreicht. Beispiel einer so eingestellten Standardmaske: Grid Bearbeiten im Adress-Stamm.

• IsSingleRecordView: Es wird nur ein Datensatz dargestellt, aber ohne automatischen Umbruch. Zur vollständigen Anzeige des Datensatzes wird die Aktivierung der Scrollbars notwendig (OptionsView > Scrollbars). Beispiel einer so eingestellten Standardmaske: Grid im Firmenstamm.

• IsMultiRecordView: Darstellung mehrerer Datensätze nebeneinander. Beispiel einer so eingestellten Standardmaske: Grid für den Bereich Kunden im Adress-Stamm.

Hinweis: Im Adress-Stamm ist diese Umschaltung auch über das rechte Maustasten-Kontextmenü möglich Property "OptionsBehavior > CellHints": Steuert, ob beim Überfahren einer Gridzelle mit der Maus, sofern der Zellinhalt nicht komplett angezeigt werden kann, die sog. Hint-Anzeige erscheint. Defaultwert ist true. Property "OptionsBehavior > RowSizing": Legt fest, ob man im Grid grundsätzlich die Zeilenhöhe per Ziehen mit der Maus ändern kann (auch ohne aktiven Designer). Sollen einzelne Zeilen unveränderlich bleiben / davon ausgenommen sein, so ist bei diesen die Eigenschaft "Options > CanResized" auf false zu stellen. Horizontaler Grid (HGrid) Property "FilterRow" Blendet als oberste Gridzeile eine sogenannte Filterzeile ein. Ermöglicht eine gezielte, auf die jeweiligen Spalten bezogene Filterung. Hinweis: In der Adress-Tabelle ist die Aktivierung der Filterzeile per rechter Maustaste möglich Property "OptionsView > Navigator" und Property "NavigatorButtons"


Erstere blendet unterhalb des Grids den Navigator ein, dessen Buttons über die zweitgenannte im Detail festgelegt werden (ein-/ausblenden). Im Standard ist dieser kleine Navigator z.B. in der Adress-Tabelle zu finden, wo er in erster Linie zum Einblenden der sog. Filterbox dient.

Property "FilterBox": Alternativ lässt sich die FilterBox auch fest über die gleichnamige Einstellung aktivieren, indem man dort visible auf "fvAlways" einstellt. Hinweis: Die FilterBox am unteren Gridrand wird immer angezeigt, sofern mindestens ein gespeicherter Filter vorliegt (sofern mit der Maske ein Filter gespeichert wurde ist dieser sofort sichtbar, ansonsten steht dort <Filter ist leer>). Gespeicherte Filter können dann über das Pulldown ausgewählt werden.

Property "OptionsView.ColumnAutoWidth": Defaultwert = true. Diese Funktion steuert, dass immer alle visible-eingestellten Spalten ohne horizontale Scrollbar angezeigt werden. Wird beispielsweise durch Vergößern/Verkleinern der Maske die Gridbreite geändert, so werden alle Spalten in der Breite dynamisch angepasst. Stellt man diese Eigenschaft auf false, so wird stattdessen ein Scrollbalken - sofern erforderlich - eingeblendet. Property "OptionsCustomize > ColumnsQuickCustomization": Soll der Spaltenaufbau des Grids nicht durch den Bediener veränderbar sein (Spalten zu- oder abschalten verhindern), so ist diese Einstellung auf false zu stellen. Felder: Aktivieren eines (neuen) Datenfeldes Zum Einfügen eines Feldes zunächst rechts oben in der Radio-Box von „Grid“ auf „Felder“ wechseln. Hier weder alle in der jeweiligen Datentabelle zur Verfügung stehenden Felder angeboten. Beim gewünschten Feld das Häkchen zur Aktivierung setzen, das Feld ist nun zum Design im Grid „verfügbar“. Zeilen (bei VGrid) bzw. Spalten (bei HGrid): Designen eines Datenfeldes im Grid Zur weiteren Einstellung rechts oben in der Radio-Box von "Felder" auf "Zeilen" bzw. "Spalten" wechseln. Nun werden alle zuvor unter "Felder" aktivierten Datenfelder zum Design innerhalb des Grids angeboten. Bei beiden Arten von Grids (horizontaler Grid /vertikaler Grid) steuert die Eigenschaft "visible", ob ein Datenfeld im Grid aktuell angezeigt wird. Zusätzlich kann bestimmt werden, ob ein Datenfeld außerhalb des Designers zu-/abgeschaltet werden kann:


Horizontaler Grid: Property "VisibleForCustomization": Bestimmt, ob ein Datenfeld in der über die linke Ecke des Grids zu öffnende Feldliste erscheint und somit durch den Benutzer zu-/abgeschaltet werden kann. Vertikaler Grid: Property "Options > ShowInCustomizationForm": Bestimmt, ob ein Datenfeld im Layout-Designer sichtbar ist. Nur Felder bei denen diese Eigenschaft auf true steht, können durch den Bediener beliebig aus dem Grid genommen oder wieder eingefügt werden, sofern der Griddesigner selbst über das Rechtesystem abgeschaltet ist und somit dem Bediener nicht zur Verfügung steht.


Zweizeiliger HGrid – Einzeiliger HGrid In der Dokumentenverwaltung kommt eine besondere Form des horizontalen Grids zum Einsatz, welches mehrzeilige Datensatzanzeigen ermöglicht. D.h. zur Ausgabe eines einzigen Datensatzes stehen mehrere Zeilen des Grids zur Verfügung. Somit hat man auf einen Blick - ohne im Grid nach rechts/links scrollen zu müssen - mehr Information. Die Besonderheiten dieses Grid gegenüber dem "Standard"-Grid sind folgende:

Die oberste angezeigte Zeile des Grids stellt eine Bandzeile (rein textuelle Überschriftszeile) dar. Diese Bandzeile kann mehrere Einträge (im Designer unter der Eigenschaft "Bands" beim Grid einstellbar) umfassen, um die Überschriftszeile in einzelne Blöcke aufzuteilen. In der Standardmaske sind dies folgende Überschriften:

Typ, Information, Adressdaten, Termin, Telefon und Statusinfo. Da es sich um reine Texte handelt, können die Überschriften nicht für Sortierungen oder Gruppierungen verwendet werden. Das bei den Datenfeldern gewohnte Kontextmenü ist hier nicht verfügbar. Schaltet man eine Überschrift in der Ansicht ab (ganz links über das "*"-Symbol in der Bandzeile), so werden alle unter ihr angeordneten Datenfelder ausgeblendet. Unterhalb der Bandzeile folgen wie beim Standardgrid die auszugebenden Datenfelder. Als Besonderheit können Datenfelder nicht nur horizontal, sondern auch vertikal verschoben werden. Somit wird die mehrzeilige Darstellung ermöglicht. Die Standardmaske umfasst eine zweizeilige Darstellung, beispielsweise werden die Felder "Betreff" und "Von/An" untereinander ausgegeben. Wünscht man eine einzeilige Darstellung der Datensätze, so müssen alle Datenfelder vertikal auf gleicher Höhe stehen. Für folgende Abbildung wurden alle Datenfelder der zweiten Zeile in die obere verschoben, der Grid wurde einzeilig:

Wichtig beim Einfügen weiterer Felder (Spalten) in den mehrzeiligen HGrid: Die Einordnung eines Feldes erfolgt über die Angabe seiner Position. Im Designer kann dies bei der ausgewählten Spalte unter der Eigenschaft "Position" über BandIndex, CollIndex und RowIndex eingestellt werden. Außerhalb des Designers ist ein Verschieben im Grids per Drag & Drop möglich. Da ein neues Feld in Voreinstellung mit BandIndex=0 eingefügt wird, findet man dieses unter der ersten Überschrift - in der Dokuverwaltung also unter "Typ". Da diese Spalte sehr schmal ist, empfiehlt es sich den BandIndex gleich nach dem Einfügen auf 1 zu setzen. Das Feld befindet sich dann in der breiteren "Adressdaten"-Spalte und kann leichter per Maus an die gewünschte Stelle im Grid verschoben werden.

Bandzeile

Datenfeld-Zeilen


Folgende Tabelle zeigt Gestaltungsmöglichkeit von Feldern beim Vertikalen Grid. Ein "X" in der dritten Spalte (B) zeigt an, dass weiter unten im Text eine ausführliche Beschreibung folgt:

Funktion Einstellung/Beschreibung B Normales Feld Bei einem "normalen" Datenfeld sind keine weiteren

Einstellungen notwendig. Über den Grid selbst ist das Datenfeld bereits mit der Datenbank verbunden.

Checkbox EditProperties: CheckBox, meist ist es sinnvoll anschließend EditProperties > ValueChecked auf "1", EditProperties > ValueUnchecked auf "0" einzustellen. EditProperties > NullStyle ist auf "nssUnchecked" zu stellen.

ComboBox veränderlich EditProperties: ComboBox, danach unter Items die gewünschten Einträge erfassen. Angezeigter und bei einer Auswahl in der Datenbank gespeicherter Wert sind bei einer ComboBox identisch.

ComboBox unveränderlich

wie oben, jedoch zusätzlich die Eigenschaft EditProperties > DropDownListStyle von IsEditList auf IsFixedList stellen. Somit wird die Eingabe von "freiem" Text unterbunden.

ImageComboBox EditProperties: ImageComboBox Hier handelt es sich um eine Combobox, bei der pro Listeneintrag zwischen in der Auswahl angezeigtem und in die Datenbank übernommenen Wert unterschieden wird. Zusätzlich lassen sich Grafiksymbole anzeigen.

X

Mehrzeiliges Feld Editproperties: psMemo Normalerweise springt der Cursor bei Bestätigen mit Enter in die nächste Gridzelle und ein Umbruch im Text kann per Strg + Enter erzeugt werden. Möchte man dies nicht, so ist EditProperties > WantReturns auf true zu stellen

Bild im Grid EditProperties: Image. Unter GraphicClassName angeben, ob Bilder im BMP- (à Eintrag TBitmap) oder JPG- (à Eintrag TJPEGImage) Format verwendet werden. Es können nur Bilder angezeigt werden, die in der Datenbank in einem Binärfeld abgespeichert sind.

F4-Auswahlgrid EditProperties: psPopUp X Datumsfeld EditProperties: DateEdit X Button für Script ("Basic-Button")

EditProperties: psEdit X

Wichtig: Sobald bei der Eigenschaft EditProperties die gewünschte Funktion eingestellt ist, werden bei dieser passende Untereigenschaften aktiviert. Wie in der folgenden Abbildung gezeigt wird das "+" –Zeichen zum Öffnen der Unterpunkte sichtbar.


à ImageComboBox (ImageComboBox) Bei der ImageComboBox können für jede Zeile der sich öffnenden DropDown-Liste drei Werte hinterlegt werden: Anzeigewert, Datenbankwert und optional eine Grafik. • EditProperties > DropDownRows: Max. Anzahl sichtbarer Zeilen bei geöffneter ComboBox • EditProperties > ImageAlign: Anzeige der Grafik links oder rechts • EditProperties > Images: Falls Grafik-Symbole in der Box angezeigt werden sollen, wird hier

die gewünschte Imageliste eingestellt, aus der diese geladen werden. "Gängige" Imagelisten sind ".FSMenu.sTool.IL_Image" (diese Liste enthält derzeit 160 verschiedene Grafiken, welche meist in Navigationsleisten der Masken des CRM-Bereiches verwendet werden) und ".FSMenu.IL_SmallHaupt" (Liste mit den Grafiksymbolen des Menüs). Desweiteren kann auf die individuellen Imagelisten zugegriffen werden.

• EditProperties > Items: Hier wird "(TcxImageComboBoxItems)" angezeigt. Per Mausklick auf diesen Eintrag öffnet sich ein Hilfsfenster, in welchem sich die Zeilen für die DropDown-Liste definieren lassen. Über Symbole können Zeilen eingefügt, gelöscht oder auch in ihrer Reihenfolge verschoben werden. Markiert man eine Zeile in diesem Fenster, zeigt der Grid des Designers die Detaileinstellungen an.

o Description: Text für die Anzeige (was der Bediener bei einer Auswahl in der Box sieht) o ImageIndex: Nummer einer Grafik aus einer ImageListe. Der Eintrag "-1" bedeutet

"keine Grafik". o Tag: nicht von Bedeutung o Value: Wert, der in der Datenbank gespeichert werden soll. Zusätzlich wird eingestellt,

um welchen Datentyp es sich handelt Die nachfolgende Abbildung zeigt Einstellungen der ImageComboBox für das Feld "Newsletter" im Adress-Stamm.


à F4-Auswahlgrid (psPopUp) Für das F4-Auswahlgrid sind mehrere Schritte notwendig: Zum einen die Definition des Feldverhaltens als "Gridbutton" - dies erfolgt im Designer der Maske, zum anderen muss der sich öffnende Auswahlgrid designt werden. Das erfolgt bei geöffnetem Auswahlgrid über den dort zur Verfügung stehenden Griddesigner. Grid in der Maske: EditProperties: psPopUp Die weiteren Schritte spezifizieren die Einstellungen, zur Verdeutlichung am Beispiel einer Adressgruppenauswahl im CM_Adress-Stamm • EditProperties > AssignedValues > GDIAnzeigeSQL: Entspricht der aus der GDILine

gewohnten SQL zur Anzeige von Daten in einem ClientDBText-Objekt

select F1 ausgabe from gdidef where satzart = "AG" and IND1=:Feldname • EditProperties > AssignedValues > GDIGridname: Entspricht der LoadDefs-Angabe aus der

GDILine. Unter diesem Namen wird der Grid gespeichert/geladen.

ADRESSGRUPPEN • EditProperties > AssignedValues > GDIReturnwert: Feldinhalt, welcher bei der Auswahl

übernommen werden soll in der Syntax Empfängerfeldname=Senderfeldname (vgl. GDILine Property Dialog.Return beim EditFeld mit Buttonstyle ebsGridbutton)

ADRESSGRP=IND1

• EditProperties > AssignedValues > GDIStartWert: Feldinhalt, welcher an den Auswahlgrid

beim Start übergeben werden soll, ebenfalls in der Syntax Empfängerfeldname=Senderfeldname (vgl. GDILine Property Dialog.Start beim EditFeld mit Buttonstyle ebsGridbutton)

IND1=ADRESSGRP

Nach diesen Definitionen kann der Griddesigner der Maske geschlossen werden. Bei Click oder F4 öffnet sich jetzt bereits der Auswahldialog, allerdings sogleich in der "Designeransicht" zur Hinterlegung der SQL:


Zur Information werden Gridname, Rückgabewert (Returnwert) und Startwert angezeigt. Es wird eine entsprechende select- SQL, welche die zur Auswahl anzubietenden Daten liefert hinterlegt: (Hinweis: Eingabefeld mit <Tab> anspringen) select * from GDIDEF where satzart ="AG" order by Ind1

Damit ist die Grunddefintion zum "Ziehen" der Daten aus der Datenbank gelegt, es fehlt noch die Definition des Grids an sich, d.h. welche Spalten die Auswahltabelle anzeigen soll. Man wechselt hierzu über das Zahnrad zum Griddesigner:


Nach Einstellen der gewünschten, anzuzeigenden Spalten und Speichern der Griddefinition über Zahnrad > Speichern bzw. Speichern unter ist das Designen der F4-Auswahltabelle fertiggestellt.


à Datumsfelder im CRM (DateEdit) Für die Anzeige vom Datumswerten ohne Uhrzeit sind folgende Eigenschaften wichtig:

• EditProperties > AssignedValues > DisplayFormat: True • EditProperties > DisplayFormat: dd.mm.yyyy

Bei den Datumsfeldern des CRM besteht die Möglichkeit einer Schnelleingabe. Man muss nicht zwingend das Datum mit Ziffern eingeben oder per Mausklick/F4 den Kalender öffnen, sondern kann gezielt durch Eingabe weniger Zeichen ein Datum bilden. Aufgrund einer Mindesteingabe erfolgt eine automatische Wort-Vervollständigung. Beim Verlassen des Eingabefeldes wird aus dem textuellen Begriff ein korrektes Datum erzeugt. Voraussetzung: Die Eigenschaft EditProperties des Eingabefeldes steht auf DateEdit, die Eigenschaft InputKind auf ikRegExpr. Beispiel: Eingabe von "h" ergibt "heute" und somit das Tagesdatum.

Auch "rechnende" Eingaben sind möglich. So ergibt die Eingabe von "h - 7" das Datum des genau eine Woche zurückliegenden Tages.


Übersichtstabelle (groß- und fettgedruckte Buchstaben = Mindesteingabe):

Eingabe Ergebnis BOM erster Tag des Monats EOM letzter Tag des Monats ERster erster Tag der aktuellen Woche (beginnend bei Montag) Zweiter zweiter Tag der aktuellen Woche DRitter dritter Tag der aktuellen Woche Vierter vierter Tag der aktuellen Woche FÜnfter fünfter Tag der aktuellen Woche SEchster sechster Tag der aktuellen Woche SIebenter siebenter Tag der aktuellen Woche Heute aktueller Tag MORgen nächster Tag Gestern vorheriger Tag Jetzt aktueller Tag und Zeit (nur bei Kind = ckDateTime) MONtag Datum des nächsten Montags DIenstag Datum des nächsten Dienstags MIttwoch Datum des nächsten Mittwoch DOnnerstag Datum des nächsten Donnerstags FReitag Datum des nächsten Freitags SAmstag Datum des nächsten Samstags SOnntag Datum des nächsten Sonntags


à Button für Script ("Basic-Button") Voraussetzung: Lizenz für Maskenaufruf oder Lizenz Autom. Belegerstellung Eine Gridzelle des vertikalen Grids kann als Button definiert und zur Ausführung von GDI-Basic verwendet werden. Die Haupteinstellung wird durch Festlegung der EditProperties auf psEdit festgelegt, dadurch werden die entscheidenden Einstellungen zugänglich. • Caption: wie üblich die Beschriftung links im "festen" Teil des Grids • Properties > EditProperties: psEdit • Properties > EditProperties > Buttons: Es kann ein Zusatzdialog zum Definieren des Buttons

geöffnet werden. Dort sind folgende Einstellungen von Belang: • Caption: Beschriftung des Button • Glyph: Auswahl einer Bitmap • Kind: Soll die Caption angezeigt werden, ist hier bkText zu setzen. Soll eine Bitmap gesetzt werden, so ist bkGlyph zu setzen.

• Properties > EditProperties > ViewStyle: Regelt die Breite des Buttons. vsButtonsAutoWidth

• Properties > Options > ShowEditButtons: Diese Einstellung sorgt dafür, dass der Button angezeigt wird.

eisbAlways

• Properties > EditProperties > GDIMaskenAufruf: Hier wird hinterlegt, welches Script aufgerufen werden soll. Nach dem Schlüsselwort "GDIScript=" wird der Name einer gespeicherten Scriptdatei angegeben. Bei dieser Datei kann es sich um ein GDI-Basic oder um ein Pascalscript handeln. Sie wird im Ordner Script (beim Programm oder Mandanten) abgelegt.

GDIScript=Test.prg

Ein (lesender) Zugriff auf die aktuellen Daten z.B. um aus dem Basic-Programm heraus Übergabeparameter zu bilden und andere Masken aufzurufen ist bereits möglich. Beispielsweise gibt es folgende Datenobjekte in der Maske Adress-Stamm:

• TA_Ansprech für CM_Adressen-Zugriff Ansprechpartner-Satz • TA_Adressen für CM_Adressen-Zugriff Hauptdaten-Satz • TA_Kunden für Kundenzugriff • TA_Liefer für Lieferantenzugriff

Beispiel-Programm für den Aufruf der Beleg-Adress-Artikel-Maske: Kundennr := IntToStr(TA_Kunden.Kundennr); if Kundennr = "0" then exit; endif; Name1 := TA_Kunden.Name1; Ort := TA_Kunden.Ort; CR := CHR(13,10); Start := "Adressnr=" + Kundennr + CR + "Name1=" + Name1 + CR + "Ort=" + Ort; show(Start); Startdialog("TFAdrArtBeleg",true,Start); exit;


Weitere Buttons im Designer Im Designer gibt es auf der rechten Seite fünf Buttons, diese sind nur auf bei Einstellung der Radiobox auf "Zeilen" aktiv: v Editor hinzufügen à Über diesen Button lässt sich eine einzelne Gridzeile einfügen. Die

Funktion entspricht der oben beschriebenen Vorgehensweise, dass man zunächst auf der Einstellungsseite "Felder" das gewünschte Datenfeld aktiviert und dann nach Wechsel auf die Einstellungsseite "Zeilen" weitere Eigenschaften vornimmt.

v Kategorie hinzufügen à Über diesen Button kann eine sog. Kategorie-Zeile (Überschrift) eingefügt werden. Diese Funktion ist auch über den Layoutdesigner (s.u.) verfügbar.

v Multieditor hinzufügen à Über diesen Button kann man eine Gridzeile zur Darstellung mehrerer Datenfelder "vorbereiten": Nach Anwahl des Buttons ist über die Eigenschaft Properties > Editors ein Hilfsfenster zu öffnen. Man kann dort die Felder eintragen, die nebeneinander im Grid dargestellt werden können. Nach Markieren eines Feldes im Hilfsfenster lassen sich im Griddesigner die gewohnten Definitionen zur Gestaltung als "normales" Eingabefeld, Checkbox, F4-Auswahlgrid etc. vornehmen (EditProperties etc... siehe obige Tabelle). Wichtig: Standard-Multieditoren können per Design nicht verändert werden. Bei Bedarf sind diese zu in der Anzeige zu deaktivieren und durch eigene zu ersetzen.

v Löschen à Löscht eine Zeile aus dem Grid v Alles Löschen à Löscht den kompletten Grid

Layout-Designer Diesen Designer gibt es nur bei einem vertikalen Grid. Der Layout-Designer muss aktiviert werden, wenn die Position eines Feldes innerhalb des Grids verschoben werden soll. Er dient weiterhin zum Gliedern von Datenfeldern innerhalb des Grids durch sogenannte Kategorien (=Überschriften).


Eigene Buttons und eigene Karteireiter im Adress-Stamm In der Maske TAdrStamm (Adress-Stamm) gibt es ab Version 3.1.0.192 erweiterte Design-Möglichkeiten: Sofern die Maskendesigner/Maskenaufruf-Lizenz gegeben ist, lassen sich eigene Buttons und Karteireiter realisieren. Hierzu sind bereits Objekte im Standard vorbereitet, die jedoch visible=false definiert sind. Die Objekte lassen sich freischalten und designen. àsiehe separate Dokumentation im Forum (http://www.gdi-software.com/forums/showthread.php?t=17171) Maskendesigner für Masken des Factur-Bereiches, neue Objekte, Look & Feel Im Bereich der Factur-Masken der GDI-Business-Line findet man den aus der GDILine bekannten Bildschirmdesigner. Hier wurden neue Objekte eingebunden, die eine wesentlich bessere Darstellung bei aktiviertem Skin ermöglichen als bisher. So gibt es neu:

• TsButton als Ersatz für die verschiedenen bisherigen Buttons wie TpsBasicButton, TpsBasicSpeedButton, TpsExeButton etc...

• TsPageControl als Ersatz für TpsNotes In den Standard-Masken des Factur-Bereiches wurden die alten Objekte durch die neuen ersetzt, im Maskendesigner stehen die beiden neuen Objekte ebenfalls zur Verfügung. Die alten Objekttypen sind im Designer weggefallen, ihr Einsatz in (alten) Masken ist aber nach wie vor möglich. Bei der Konvertierung von Masken aus der GDILine durch den Maskenkonverter werden u.a. die alten durch die neuen Objekttypen ausgetauscht. Zur Vermeidung von Problemen hinsichtlich der Skins ist ein Maskendesign jetzt nur noch möglich, wenn unter Systemmenü > Einstellungen der NativeStyle aktiviert und als Skinart "Standard" gesetzt ist. Wird eine Maske in der BLine designt und gespeichert, so wird sofern möglich - wie es in der GDILine üblich war - automatisch eine Verknüpfung zwischen dem Programmaufruf und der Maske hergestellt. Das funktioniert nicht bei Aufruf komplett eigener Masken oder wenn für den Aufruf einer Maske mehrere Menüpunkte vorgesehen sind. Dann muss diese Verknüpfung separat über das Menüsystem getroffen werden. Maskenaufrufe in Bline (Factur-Bereich, MSK bzw. TXT): Im Maskenaufruf ergaben sich Änderungen (und neue Möglichkeiten) aufgrund der Tatsache, dass das neue Menüsystem keine explizite Aliasliste führt, wie es in der GDILine der Fall ist. Es gibt also keine direkte Verknüpfung zwischen einem Alias und einer Maske, welche systemweit gültig ist, sondern bei einem Menüpunkt kann jeweils eine Maske angegeben werden. Ein Aufruf des Kundenstammes über zwei Menüpunkte mit unterschiedlichen gestalteten Masken ist somit möglich. Bei Aufruf von Masken von anderen Stellen wird das Menüsystem in der Reihenfolge Menü, Toolbar und Systemmenü nach einem passenden Menüpunkt durchsucht, um hieraus verknüpfte Masken und Berechtigungen zu ermitteln. Beispiel: Aufruf des Kundenstammes aus Belegmaske --> Ermitteln, ob mit TFAKunden im Menü eine Maske verknüpft ist. Aufrufe über das Menü: Maskenaufrufe über das Menüsystem erfolgen ab der zweiten designbaren Hierarchieebene (z.B. Menü > Adressen > Kunden). Ein direkter Aufruf einer Maske über einen auf der ersten Ebene liegenden Menüpunkt ist nicht möglich (z.B. Menü > Kunden).

http://www.gdi-software.com/forums/showthread.php?t=17171)


Im Menüsystem wird ein Menüpunkt über die Eigenschaft "Programmaufruf" zunächst mit dem zu startenden Programm-Modul verknüpft (z.B. TFAKunden oder TFABelegVK). Sofern dabei auf eine Maskendatei (MSK oder TXT) zugegriffen werden soll, wird diese als "Parameter 1" eingetragen. Über einen Auswahldialog wird die Zuordnung erleichtert. Parameter 2 und 3 sind für Belegaufrufe vorgesehen (Parameter 2 enthält das Belegart-Kürzel z.B. "AN" und Parameter 3 den Bezeichner der Belegart z.B. "Angebot"). Eigene per Maskendesigner erstellte Masken werden über den Programmaufruf "ExterneMaske" plus Angabe der Maskendatei (TXT oder MSK) als Parameter 1 eingebunden. Hinweis: Im CRM-Bereich erfolgt über das Menü lediglich die Zuweisung des entsprechenden Programm-Modules einschl. seiner Rechteeinstellung zu einem Menüpunkt. Die Verwaltung der MSK2-Masken des CRM-Bereiches erfolgt nicht über das Menü. Verbergen von Menüpunkten Aufgrund der fehlenden Aliasliste zur direkten Verknüpfung zwischen einem Alias und einer Maske müssen Menüpunkte auch für Masken generiert werden, die an sich nicht über das Menü aufgerufen werden - sofern man diese designen möchte. Beispiele hierfür sind Masken wie die Positionsinfo in der Belegerfassung, der Assistent zur Auswahl von Chargen, die Belegübernahme etc. Über nachfolgenden Trick kann man die Verknüpfung anlegen, aber den Menüpunkt "ausblenden". Wichtig ist, dass man beide Ebenen "füllt", aber jeweils als Bezeichnung ein "-" (Minuszeichen) angibt!


Für eigene Aufrufe per GDI-BASIC-Funktion Startdialog ergeben sich nachfolgende Funktionen. Die im Menüsystem optional bei einem Aufruf angebbaren Parameter 1 - 4 werden bei der Startdialog-Funktion in deren erstem Parameter "Dialog" übergeben, und zwar durch Pipe ("|") getrennt. Die weiteren Parameter der Startdialog-Funktion (Modal, Start, Return, ...) gelten unverändert wie in der GDILine: Systemmasken, z.B. Kundenaufruf Startdialog("TFAKunden"); --> Kundenstamm wird aufgerufen. Das Menü wird nach einem mit TFAKunden verknüpften Menüpunkt (Kartei "Menü" in Menü-/Rechteverwaltung) durchsucht. Ist dort eine Maske hinterlegt, wird diese auch beim Startdialog-Aufruf verwendet. Ebenfalls wird das dort eingestellte Recht verwendet (dies entspricht dem o.g. Aufruf des Kundenstammes aus einem Beleg). Gibt es keinen Menüpunkt, somit auch keine hinterlegte Maske, so erfolgt der Aufruf der Standardmaske mit dem auf TFAKunden liegenden Recht (Kartei "Rechte" in Menü-/Rechteverwaltung). Startdialog("TFAKunden|Kunden.txt"); --> Kundenstamm wird aufgerufen. Das Menü wird nach einem mit TFAKunden und der angegebenen Maske verknüpften Menüpunkt (Kartei "Menü" in Menü-/Rechteverwaltung) durchsucht. Ist er vorhanden, wird das dort eingestellte Recht verwendet. Ansonsten erfolgt der Aufruf der angegebenen Maske mit dem auf TFAKunden liegenden Recht (Kartei "Rechte" in Menü-/Rechteverwaltung). Startdialog("TFAKunden|*"); --> Kundenstamm wird mit Verwendung der Standard-Kunden-Maske aufgerufen. Das Menü wird nach einem mit TFAKunden verknüpften Menüpunkt durchsucht. Ist er vorhanden, wird das dort eingestellte Recht verwendet. Ansonsten erfolgt der Aufruf mit dem auf TFAKunden liegenden Recht (Kartei "Rechte" in Menü-/Rechteverwaltung). Sofern über das Menü nur ein Aufruf einer gespeicherten Kundenmaske definiert ist, kann über diese Syntax der Aufruf der Standardmaske erzwungen werden. Externe, eigene Masken Startdialog("ExterneMaske|Testmaske.txt") --> Syntax zum Aufruf einer eigenen, individuellen Maske. Existiert im Menü ein Menüpunkt mit identischer Masken-Verknüpfung, so wird dort die Rechteeinstellung ausgelesen und verwendet, ansonsten besteht Vollzugriff. Im Gegensatz zur GDILine ist also an sich keine Definition in der Menü-/Rechteverwaltung notwendig. Sofern man aber Rechteeinschränkungen benötigt, muss aber ein Menüpunkt mit identischer Verknüpfung angelegt werden. In Vorbereitung: Ein Flag/Schalter zum Ausblenden solcher Menüpunkte im Menü. Beleg-Masken Startdialog("TFABelegVK|VerkaufTest1.txt|AU|Caption der Maske"); --> Syntax zum Aufruf einer Belegmaske. Hier werden neben der Angabe, welcher Dialog (TFABelegEK oder TFABelegVK) aufzurufen ist, sind hier drei Teil-Parameter notwendig: Par1: Maskenname Par2: Belegart-Kürzel Par3: Überschrift der Maske (in der Regel ist das die ausgeschriebene Bezeichnung der Belegart) Als Berechtigungsstufe wird das beim entsprechenden Menüpunkt in der Menü-/Rechteverwaltung hinterlegte Recht verwendet.


Startdialog("TFABelegVK|*|AU|Caption der Maske", true,"BelegNr=101200008"); --> Syntax zum Aufruf einer Standard-Belegmaske. Will man die Standardbelegmaske "erzwingen", so ist auch hier das "*" zu setzen. Ohne "*" würde die beim entsprechenden Menüpunkt in der Menü-/Rechteverwaltung hinterlegte Maske verwendet. Hier mit Übergabe einer Belegnummer im "Start"-Parameter (dritter Parameter der Startdialogfunktion). Der Startdialog-Parameter "Modal" (zweiter Parameter der Startdialogfunktion): Gegenüber der GDILine wurde in der Bline die Funktionalität dieses Parameters erweitert (siehe auch "Anzeigemodus" bei einem Menüpunkt im Rechtesystem). 0 = nicht modal (Standard) 1 = modal (= alter default-Wert true 2 = nicht modal und freistehend. Die Maske lässt sich dann aus dem GDI-Hauptfenster herausschieben. Z.B. wenn man zwei Bildschirme hat.... 3 = nicht modal und einzeln 4 = nicht modal, freistehend und einzeln Alter Reportdesigner im Menü Für die Business-Line gibt es nun auch einen "alten" Reportdesigner, der bei Bedarf ins Menü eingebunden werden kann: Programmaufruf: ShellExecute Parameter1: Open Parameter2: RptDesgn.exe ab 3.2.0.208 à RptDesgn3.exe Parameter3: %DatabaseName %Bedname %Bedpass %DBUsername %DBPassword Wichtig: Für den Einsatz des alten Reporters muss die zum eingesetzten Firebird passende Version von gds32.dll und fbclient.dll im Programmpfad vorliegen (ansonsten erscheint der Login-Fehler RepDesgn_526) rpd-Listen/rpd-Belege werden automatisch BDE-frei umgesetzt, wenn Sie zum ersten Mal bei BDE-freiem Druck verwendet oder mit der BDE-freien RptDesign3.exe geladen werden. Der "BelegDruck.Extern" (alter Report-Druck über psReporter1.exe, der z.B. bei Verwendung von Belegformularen mit WPRichtext-Objekten erforderlich ist) bleibt auch in Zukunft BDE behaftet (er enthält die Druckengine der alten GDILine.exe). Solche Reports dürfen nicht mit der RptDesgn3.exe bearbeitet werden (es erscheint ein entsprechender Warnhinweis, wenn Reports mit BDE-Objekten geladen werden). Stattdessen ist die ältere RptDesgn.exe zu verwenden (--> Menüpunkt zum Start des Reportdesigners kontrollieren/umstellen!) Konvertieren angepasster Masken aus der GDILine Die Umsetzung von GDILine-Masken auf die Struktur der BLine3.x erfolgt automatisch beim ersten Aufruf auf den Stand der eingesetzten Bline.exe. Aktionen der Maskenkonvertierung, sowohl bei Standardmasken als auch bei komplett eigenen Masken sind:

• Ersatz TpsTable und TQuery durch BDE-freie TsTable • Aktualisierung WP-Richtext-Komponente • Austausch von Buttons und TpsNotes durch TsButton und TsPageControl wegen

verbesserter Skin-Eigenschaften Die Umsetzung legt dabei Sicherheitskopien (AltMaskenName.Versionsnummer.bak) plus Protokolldateien (AltMaskenName.Versionsnummer.log) an. Die Aktualisierungen auf den jeweils aktuellen Versionsstand erfolgen ebenfalls über die Bline.exe unter Zuhilfenahme der Steuerdatei MskAbg32.gdi. In der GDILine wurde hierzu ein eigenes Umsetzungsprogramm (Mskabg23/24/25.exe) benötigt, dies ist somit entfallen. Über die Steuerdatei kann man bei Bedarf die durchzuführenden Schritte "beeinflussen".


Zusatzfelder innerhalb der neuen Dokumenterstellung/Serienbriefe Als Datenquelle für die Dokumenterstellung dient die Tabelle CM_Adressen. Werden Informationen aus anderen Tabellen benötigt, so kann diese durch Definition individueller Zusatzfelder erfolgen. Die Definition der Zusatzfelder wird in der Datei "Zusatzfelder.sql" im Ordner "Vorlagen" unterhalb des Programmverzeichnisses gespeichert. Beispiel 1: Ausgabe von Bemerk1 aus dem Kundenstamm:

select K.Bemerk1 Ausgabe from kunden K, CM_Adresslink CM where K.Kundennr = CM.Nummer and CM.Adressnr = :Adressnr and CM.Adresstyp = "K"

Beispiel 2: Ausgabe des Ortes gemäß Postvorschrift in Großbuchstaben, wenn es sich um eine Auslandsadresse handelt:

select CASE WHEN (Land > "") and (Land <> "D") THEN uppercase(Ort) ELSE Ort END Ort from CM_Adressen where Adressnr = :Adressnr

Beispiel 3: Ausgabe des Datums "in 14 Tagen" ausgehend vom aktuellen Tagesdatum:

select Getdate("now") + 14 from rdb$database Die Tabelle rdb$database ist eine Systemtabelle, welche immer nur einen Datensatz besitzt und hier als "Dummy" angesprochen wird, damit die SQL syntaktisch funktioniert.


Mails mit mehreren Adressen/Serienmails An dieser Stelle noch ein Hinweis zum Thema Versenden eines Dokumentes an mehrere Adressen per Mail. Man kann entweder eine Mail erzeugen mit allen Adressen im "AN" (Variante 1 - also jeder Empfänger sieht, wer die Mail noch bekommen hat) oder für jede Adresse eine separate Mail (Variante 2). Hierbei ist natürlich auch zu beachten, dass die Variante 1 nicht die Möglichkeit eines personalisierten Anschreibens bietet.

Email Senden und Anhänge In den ersten Versionen wurde bei Emails mit Anhängen immer ein ZIP als Anhang generiert, dessen Dateiname dynamisch in Form einer UUID generiert wurde (Beispiel: F54A9306-024A-4815-BB74-F8EB487C1DCF.zip). Seit Mitte 2010 ist es möglich den Dateinamen zu bestimmen (z.B. Anhang.zip oder Attachment.zip) oder aber auch die Angangdateien in ihrer Ursprungsform (ungezipt) zu versenden. Auf Platte werden die Anhänge hinsichtlich der Bline-internen Verwaltung weiterhin als UUID.zip abgelegt.

Erzeugt eine Mail mit allen Adressen im "AN" Personalisierung nicht möglich

Erzeugt für jede Adresse eine Mail Personalisierung möglich


Vorlagen und Textbausteine, Signaturen in Dokumenten Der Editor für die Brieferstellung unterstützt zwei Arten von vorgefertigten Texten für die Texterstellung: Vorlagen und Textbausteine. Während Vorlagen (wie der Name bereits aussagt) als Grundlage eines neuen Dokumentes dienen (beim Laden einer Vorlage wird das bestehende Dokument ersetzt), haben die Textbausteine die Funktion, ein Dokument um vorgefertigten Text zu erweitern. Zudem werden Textbausteine bedienerspezifisch verwaltet. Aufbau des Dateinames für einen Textbaustein: Bedienerkürzel + "_#" + Textbausteinkürzel + "." + Dateisuffix Beispiel: Wenn es die Textbausteine

- ADMIN_#MFG.RTF - 1_#MFG.RTF - GS_#MFG.RTF

gibt (für die drei Bediener admin, 1 und gs) wird über die Eingabe von #mfg + <Strg><Enter> jeweils der bedienerspezifische Textbaustein/Signatur an der aktuellen Cursor-Position eingefügt. Ist das Textbausteinkürzel z.B. bei weniger geläufigen Testbausteinen nicht bekannt, genügt die Eingabe von <Strg><Enter> um die Auswahl für die Textbausteine zu öffnen. Für die leichtere Erfassung von Briefen/Mails wurden in den Einstellungen Eingabefelder zur die Hinterlegung von Vorlagen und Signatur geschaffen: • Standardvorlage • Signatur • Terminbestätigung

Standardvorlage und Signatur sind im Briefeditor auch über das Kontextmenü (rechte Maustaste) anwählbar. Falls gewünscht kann durch das "Häkchen" das automatische Laden/Einfügen bei einem neuen Dokument vorgewählt werden. Die Terminbestätigungs-Vorlage ist speziell für die Erstellung von Dokumenten aus dem Terminkalender heraus gedacht. Hierin kann die Variable #Termin zum Andrucken des Termindatums verwendet werden. In den Dialogen zur Auswahl von Vorlagen wurden die Dateitypen für Worddokumente (*.doc, *.docx) entfernt, da für diese Dokumente keine Vorschau angezeigt werden konnte. Im Briefeditor können Worddokumente nach wie vor über den (Standard-) Öffnen-Dialog geladen werden. Generell wird empfohlen, Vorlagen für den Briefeditor mit diesem zu erzeugen und als *.rtf-Dokumente abzuspeichern.


Serienbrief mit erweiterter Datenbasis Es wurde eine Möglichkeit implementiert, Serienbriefe nicht nur auf Basis von Adressdaten zu erstellen, sondern auf Basis individueller Daten. Funktionsweise: Man benötigt eine SQL, welche als Rückgabewerte (zwingend) die AdressID plus die gewünschten Zusatzinformationen/Felder umfasst. Die SQL wird an den Briefeditor übergeben, der daraus eine erweiterte Kontaktliste erstellt. Im Unterschied zur "normalen" Kontaktliste bei Erstellen eines Serienbriefes aus der Adresstabelle heraus umfasst die erweiterte Kontaktliste neben den eigentlichen Kontaktdaten auch die Zusatzdaten aus der SQL. Diese können über Variablen im Serienbrief ausgegeben werden. Die Syntax für eine Variable lautet "_" + Feldname der SQL. Beispiel: select K.Adressnr as AdressID, P.Projektnr as KFZNR, p.ausfab as HU from Kunden k, projekt P where K.kundennr = P.Kundennr and getMonth(p.ausfab)= 6 and getYear(p.ausfab)= 2010 In diesem Falle kann die KFZNR über "_KFZNR" und der HU-Termin über "_HU" ausgegeben werden.


Wichtig: • Es sollten nur Zusatzfelder in der SQL erzeugt werden, die im Brief tatsächlich benötigt werden.

Also kein "select K.Adressnr as AdressID, P.* from …". • Um mehrzeilige Zusatzfelder (Memos) verarbeiten zu können, müssen diese umgewandelt in

eine Zeichenkette übergeben werden. D.h. es ist in der SQL BlobToStr(Memofeldname) as Feldname zu verwenden!

• In einem Dokument mit erweiterten Kontaktlisten können zwar Adressen problemlos entfernt, aber nicht hinzugefügt werden. Bei nachträglich zugefügten Adressen würden die Zusatzdaten fehlen.

Die Funktion kann im SQL-System getestet werden. Hierfür wurde ein Button zum Aufruf des Briefeditors auf der Karteiseite "Ergebnistabelle" ergänzt:

Über den Button wird die hinterlegte SQL an den Briefeditor übergeben und ausgeführt. Hinweise: • Die Ausführung der SQL im SQL-System ist nicht erforderlich, wird allerdings empfohlen - wie in der Abbildung

gezeigt - um das Ergebnis vorab kontrollieren zu können. • Die SQL darf weder mehrschrittig sein noch Parameter enthalten. • Der Button ist in erster Linie zum Testen der Funktion vorgesehen. Für die eigentliche Anwendung ist die

Einbettung in GDI-Basic gedacht (siehe nächster Abschnitt), dort lassen sich weitere Steuerungen vornehmen, wie z.B. die Übergabe von Betreff und Briefvorlage.

Ansteuerung Briefeditor per GDI-Basic Die o.g. Funktion steht auch über GDI-Basic zur Verfügung, in dem der Briefeditor über die Startdialog-Funktion aufgerufen wird. Durch Übergabeparameter sind dabei weitere Möglichkeiten gegeben wie beispielsweise die Übergabe einer Vorlagendatei für den Text, den Betreff oder das automatische Anfügen von Anhängen: SQL := "select K.Adressnr as AdressID, ..."; Betreff := "Erinnerung an die KFZ-Hauptuntersuchung"; Vorlage := "HU_Erinnerung.rtf"; Anhang := "D:\temp\Angebot_des_Monats.pdf";


Start := "Betreff=" + Betreff + CHR(13,10) + "SQL=" + SQL + CHR(13,10) + "Vorlage=" + Vorlage + CHR(13,10) + "Anhang=" + FmtMemoStr(Anhang); show(Start); startdialog("TEditor",true,Start); GDI-Basic-Funktion CrmAdressenInsert: Adress-Korb füllen Beispiel: Kunden, für welche der Artikel "Camba" fakturiert wurde S := "select BP.AdressID " + "from Belegpos BP " + "where " + "BP.Belegtyp = :BelegTyp and " + "BP.Artikelnr = :Artikelnr"; %S.CreateSQL(""); %S.SetSQL(S); %S.ParamByName("BelegTyp","V"); %S.ParamByName("Artikelnr","Camba"); %S.Open; AID := ""; while %S.EOF = false do if AID = "" then AID := "AdressID=" + %S.FieldByName("AdressID"); else AID := AID + "," + %S.FieldByName("AdressID"); endif; %S.Next; endwhile; %S.Close; %S.FreeSQL; OID := "Ordner=Camba"; S := AID + CHR(13,10) + OID; show(S); StartDialog('CrmAdressenInsert',false,S); StartDialog('TAdrAdr',false,OID); exit;


Beispiel 2: Alle Kunden der Vertreter in einzelne Adress-Ordner packen //Alle Kunden der Vertreter in einzelne Adress-Ordner packen // GL 05.03.2010 // Alle "Vertreter"-Ordner löschen S := "select VertretNr from Vertret order by VertretNr"; %VT.CreateSQL(""); %VT.SetSQL(S); %VT.Open; while %VT.EOF = false do V := %VT.FieldByName("VERTRETNR"); OID := "Ordner=Vertreter" + V; S := "AdressID=" + CHR(13,10) + OID; show(S); StartDialog('CrmAdressenInsert',false,S); //AdressID= leer --> Ordner löschen %VT.Next; endwhile; %VT.Close; %VT.FreeSQL; // Sonderfall Ordner "Vertreter0" löschen OID := "Ordner=Vertreter" + "0"; S := "AdressID=" + CHR(13,10) + OID; show(S); StartDialog('CrmAdressenInsert',false,S); //AdressID= leer --> Ordner löschen //Für im Kundenstamm vorkommende Vertreter Ordner neu anlegen S := "select distinct VERTRNR from Kunden"; %KV.CreateSQL(""); %KV.SetSQL(S); %KV.Open; S := "select K.AdressNr " + "from Kunden K " + "where " + "K.VERTRNR = :Vertrnr"; %S.CreateSQL(""); %S.SetSQL(S); while %KV.EOF = false do V := %KV.FieldByName("VERTRNR"); %S.ParamByName("Vertrnr",V); %S.Open; AID := ""; while %S.EOF = false do if AID = "" then AID := "AdressID=" + %S.FieldByName("AdressNr"); else AID := AID + "," + %S.FieldByName("AdressNr"); endif; %S.Next; endwhile; OID := "Ordner=Vertreter" + V; S := AID + CHR(13,10) + OID; show(S); StartDialog('CrmAdressenInsert',false,S); //Ordner neu anlegen %KV.Next; endwhile; %S.Close; %S.FreeSQL; %KV.Close;

Falls die Ansprechpartner mitselektiert werden sollen ist folgende SQL zu verwenden: select K.AdressNr, CM.Adressnr, CM.AdressID from Kunden K right outer join CM_Adressen CM on K.Adressnr = CM.Adressnr where K.VERTRNR = :Vertrnr order by K.Adressnr, CM.AdressID; Auszuwerten ist dann CM.AdressID beim Füllen der Variable AID: … + %S.FieldByName("AdressID");


%KV.FreeSQL; StartDialog('TAdrAdr',false,OID); exit;


Reportmanager (TReporter2) Dreh- und Angelpunkt für die Fastreports 4.x in der Business-Line 3.x stellt der Reportmanager (als "Treporter" bis zur Version 3.2.0.201 mit Ablage der Reports im Verzeichnis Reports bzw. als "TReporter2" ab 3.2.2.222 mit Ablage der Reports im Verzeichnis Reports_FR4) dar. Die Standardlisten im Bereich Zeiterfassung werden ausschliesslich über den Reportmanager verwaltet und angesteuert. Im Warenwirtschaftsbereich besteht die Druckmöglichkeit für die Standard-Listen sowohl über den alten Reporter (rpd) als auch als über neue Listen auf Fr4-Basis über den TReporter. Insbesondere können so "Altanwender" noch die ihnen bekannten und gegebenenfalls angepassten RPD-Listen ausdrucken. Für die (Neu-) Erstellung von Listen wird der Reportmanager empfohlen. Gegenüber dem aus der GDILine bekannten FastReporter bietet er einige Vorteile: • Selektionsdialoge können im TReporter2 voreingestellt werden, Selektionen lassen sich

speichern. Anstelle von (schwer vorzubesetzenden) Dialogseiten im eigentlichen Report tritt also ein auf Basis des üblichen Griddesigners des CRM gestaltbarer Selektionsbereich.

• Es lässt sich voreinstellen, welches Unterverzeichnis (zum Verzeichnis Reports_FR4) beim Start des TReporter2 im TreeView (Baum) angezeigt wird, ob nur bestimmte Reports angezeigt werden sollen und ob ein bestimmter Report markiert/angewählt sein soll. Bei Aufruf des TReporter2 zeigt sich der TreeView mit geschlossenen Knoten, wenn insgesamt mehr als 30 anzuzeigende Einträge vorhanden sind.

• Es werden die Virtuellen Drucker (anzulegen unter Menüpunkt Basisdaten | Versandarten > Druckerdefinitionen) unterstützt. Sie stehen in der Drucker-ComboBox des Reportmanagers zur Auswahl. Der Drucker lässt sich über Parameter beim Aufruf des TReporters ebenfalls voreinstellen. Hierzu wird "Ausgabe=Printer¦" + Druckername als weiterer Parameter benötigt. ("¦" ist das ASCII-Zeichen 166, eingebbar über <Alt> + 0166). Bei einem virtuellen Drucker ist der Druckername in spitze Klammern zu setzen, z.B. <Flurdrucker>

• Um direkt einen Ausdruck zu starten gibt es folgende "Ausgabeparameter" - Sofortdruck - Sofortdruck|Druckername - SofortdruckDialog - SofortdruckDialog|Druckername - SofortPrewiew - SofortExport|DateiPfadName Damit startet der TReporter2, druckt und beendet sich wieder. Der Druckername kann optional angegeben werden, bei der "Dialog"-Variante bleibt man im Windows-Druckdialog "stehen", bei der "Export"-Variante wird der Dateiname inkl. Pfad als Angabe erwartet (z.B. \\PC1\Temp\Test.pdf).

• Darüberhinaus bestehen Ansteuerungsmöglichkeiten und spezielle Übergabeparameter beim Aufruf über GDI-Basic

Nähere Informationen hierzu siehe à separate Dokumentation zum TReporter2 im Forum.

GDI-Business-Line (ERP + CRM) · funktional relevant sind (also beispielsweise eine...

Documents

Transcript of GDI-Business-Line (ERP + CRM) · funktional relevant sind (also beispielsweise eine...