Ausgangslage

Neben der Möglichkeit innerhalb eines Feldes über F1 und technische Informationen aus den einzelnen Felddaten Tabellennamen und Feldname zu ermitteln (oder alternativ im Coding nachzuschauen) oder über die Transaktion SE12 in den einzelnen Tabellen des SAP Systems zu suchen besteht auch die Möglichkeit über eine SAP Query die Tabellen D010TAB (Tabelle für Report<->Tabellen-Verwendung) und TSTC (SAP-Transaktions-Codes) innerhalb eines Joins zu verknüpfen und über den hinter der Transaktion liegenden ABAP Programm eine Auswertung die genutzten Tabellen zu ermitteln.

Diese Methode ist im Buch Praxishandbuch SAP Query Reporting von Stephan Kaleske beschrieben und ist hier um die Tabellenart (aus der Tabelle DD02L) sowie der Tabellenbezeichnung (aus der Tabelle DD02T) ergänzt worden.

Als Ergänzung oder mit einen anderen Schwerpunkt kann ich ferner noch das Buch von  Martin Peto und Katrin Klewinghaus " Reporting im SAP-Finanzwesen: Standardberichte, SAP QuickViewer und SAP Query" und natürlich meine Einführung in das Thema SAP Query, welche weiter unten im Artikel verlinkt ist.

SAP Query zur Auswertung von Tabellen und Programm hinter SAP Transaktionscode

1. Infoset definieren
Zur Darstellung der gewünschten Daten müssen folgende Tabellen miteinander verknüpft werden:

• D010TAB - Tabelle für Report<->Tabellen-Verwendung
• TSTC - SAP-Transaktions-Codes
• DD02L - SAP-Tabellen
• DD02T - R/3-DD: Texte zu SAP-Tabellen

Folgende Felder werden hierbei miteinander verknüpft.

Verknüpfungen
Hierbei steht <--> für einen normalen Join und >LO< für einen left outer join.

D010TAB-MASTER <--> TSCT-PGMNA
D010TAB-TABNAME <--> DD02L-TABNAME
DD02L-TABNAME <--> DD02T

Schematisch ist hierbei folgendes Infoset geplant.



Die Felder der Tabellen D010TAB und TSTC werden komplett innerhalb der Feldgruppen übernommen. Aus der Tabelle DD02L wird nur das Feld Tabellenart (DD02L-TABCLASS) und aus der Tabelle DD02T die Felder Sprachenschlüssel (DD02T-DDLANGUAGE) und die Tabellenbezeichnung (DD2T-DDTEXT) übernommen. Hierbei werden die Feldgruppen analog der Tabellenbezeichnung angelegt

Der Sprachenschlüssel ist dabei erforderlich, da die Bezeichnungen von Tabellen mehrfach vorkommen je nachdem inwieweit unterschiedliche Sprachversionen gepflegt sind.

2.) Query definieren
Innerhalb der Query werden nun auf folgende Felder der einzelnen Tabellen Zugriff genommen bzw. in der Grundliste zugewiesen. Hierbei ist L als Listenfeld und S als Selektionsfeld zu verstehen.

Die Felder werden hier in der Reihenfolge angeben, wie diese dann auch in der Query ausgegeben werden sollen:

Tabelle für Report<->Tabellen-Verwendung
TCODE (L,S) TSTC-TCODE

Zusatzfelder (werden in der Grundliste zur Verfügung gestellt)
Text:Transaktionscode (L) TEXT_TSTC_TCODE

Tabelle für Report<->Tabellen-Verwendung
ABAP-Hauptprogramm (L,S) D010TAB-MASTER
Tabellenname (L,S) D010TAB-TABNAME


Zusatzfelder (werden in der Grundliste zur Verfügung gestellt)
Text:Tabellenart (L) TEXT_DD02L_TABCLASS

R/3-DD: Texte zu SAP-Tabellen
Kurzbeschreibung von Repository-Objekten (L) DD02T-DDTEXT
Sprachenschlüssel (S) DD02T-DDLANGUAGE

3. Query ausführen
Beim Ausführen der Query kann nun über den Transaktionscode, ein ABAP-Programm oder über den Tabellenname eine Liste mit allen Transaktionen oder Tabellen die mit der jeweiligen Selektion in Verbindung stehen ausgewertet werden.

Sofern eine Auswertung anhand von ABAP-Programmen ohne Transaktionszuordnung erfolgen soll besteht die Möglichkeit die Verknüpfung
D010TAB-MASTER mit TSTC-PGMNA als "left outer join" zu definieren. Entsprechend länger würde hier aber eine Auswertung dauern.

Als beispielhafte Anwendung der Query kann zum Beispiel die Transaktion KS03 (Kostenstelle anzeigen) mit dem Sprachenschlüssel "DE" ausgewertet werden und innerhalb der Query erkannt werden, dass in der "Transparente Tabelle" "CSKS - Kostenstellenstammsatz" die Kostenstellenstammdaten zu finden sind und hinter der Transaktion das ABAP Programm SAPLKMA1 liegt.

Diese Methode kann besonders dann sinnvoll sein, wenn umfangreiche Transaktionen oder ABAP Programme eine Vielzahl von Tabellen verwenden und ein schneller Überblick geschaffen werden soll.

Alternative: Trace über Datenbanknutzung (Transaktion ST05)

Sollte diese Vorgehensweise nicht weiter helfen besteht immer noch die Möglichkeit per Trace eine Auswertung der im Zugriff befindlichen Datenbanktabellen zu starten. Dieser Trace kann über die Transaktion ST05 gestartet werden. Im Artikel "SAP-Tabellen finden – eine minimalistische Anleitung" auf thinkdoforward.com ist dieses ebenso wie im Artikel "Transaktion ST05 (Performance Trace)"  auf berater-wiki.de beschrieben. Dennoch nutze ich die beschriebene Query immer wieder gerne, da sie für eine Vielzahl von Transaktionen tatsächlich eine erste Antwort liefert und nicht ganz so umfangreich in der Handhabung wie ein Trace ist. Eine andere Frage ist hier tatsächlich der Einsatz von Trace im Berechtigungswesen. Wie im Artikel "SAP Basis Basic oder dank SU53 oder ST01 Trace fehlende Berechtigungen finden" beschrieben, möchte ich hier auf die Alternative genauer solche Fragen nachzugehen nicht verzichten. :-)

Berichtswesen und SAP Query

SAP Query, Rechercheberichte, Report Painter sind noch immer Tools, die gerne von mir im Berichtswesen im SAP Controlling eingesetzt werden. Gerade für SAP Query ist die obige Auswertung hilfreich um zu einer Transaktion die dahinter liegenden Tabellen als ersten Ansatz für eigene Auswertungen nutzen zu können. Aber auch unabhängig davon stellen SAP Query, gerade im Controlling und der Finanzbuchhaltung eine praktische Möglichkeit dar um individelle Berichte erstellen zu können.



Im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlich auf dies Thema eingegangen.
  Vielleicht finden sich hier ja auch noch weitere Anregungen für den Aufbau eines Berichtswesen mit SAP nicht nur für CO im Buch.
 
 

---

Hinweis:

Eine kurze Einführung in das Thema SAP Query habe ich im Artikel
"Grundlagen Kurzeinführung und Handbuch SAP Query" beschrieben und hoffe Ihnen hier eine Einführung ins Thema bieten zu können.

---

Ausgangslage:

Für einen PSM Recherchebericht wurde aus der PFCG eine kundeneigene Transaktion angelegt. Nach Aufruf dieser Transaktion erscheinen im Selektionsbild die zusätzlichen Felder "Aktualität der Daten (Lesemodus) sowie Druckeinstellungen und Vorverdichtung. Dieses ist bei anderen Transaktionen von Rechercheberichten oder beim Start über die Transaktion FMEQ (Recherchebericht ausführen) nicht der Fall. Auch wenn diese Felder dann über eine entsprechende Selektionsvariante ausgeblendet werden kann, ist dieses doch iritierend.

Lösung:
Ursache hierfür ist, dass aus der PFCG eine Reporttransaktion statt Parametertransaktion angelegt worden ist. Hier kann jedoch über die Transaktion SE93 der Transaktionstyp von Reporttransaktion auf Parametertransaktion geändert werden.

Dieses ist über

• Bearbeiten
• Transaktionsart ändern

möglich umzustellen.

Der Vorteil einer Parametertransaktion ist, dass einzelne Dynprofelder des Reports vorab belegt werden können. Hier scheinen dann auch die oben geschilderten und auch in der FMEQ nicht auftauchenden Felder ebenfalls automatisch belegt zu sein, so dass hier diese automatisch beim Transaktionsaufruf gefült und ausgeblendet sind. Ein weiterer Vorteil der Paramatertransaktion ist es auch, dass gegebenfalls auch Selektionsvarianten mit ausgegeben werden können.

Im Artikel Transaktion anlegen (Report, Parameter) bspw. für SAP Query ist die Vorgehensweise anhand einer SAP Query erläutert. Gerade beim Einführen von neuen Berichten (so auch Rechercheberichte aus PSM) sollte auch die Vorgehensweise beim Erstellen von Transaktionen beachtet werden.

Innerhalb einer 3-Systemlandschaft (Entwicklung, Test, Produktiv) kann es daher sinnvoll sein erst in einen Testnamensraum (bspw. Y*) entsprechende Transaktionen zu testen und produktiv in einen anderen Namensraum (bspw. Z*) die tatsächlich zu verwendenden Transaktionen anzulegen.

Im Rahmen des Transportwesen ist dabei zu beachten, dass es sich beim Anlegen von Transaktionscodes um Workbench-Aufträge und nicht Customizing-Aufträge handelt, so dass hier (gerade beim Einsatz in einer Mehrmandantenumgebung) auch aus Seiten der Berechtigungen eine Einschränkung beim Transport geben kann. Diese Unterscheidung ist relevant, da Einstellungen eines Customizing-Auftrages mandantenabhängig und eines Workbench-Auftrages mandantenunabhängig sind. Wobei hierbei die Pflege der Transaktionen zwar als Workbench-Auftrag definiert ist, da hierzu entsprechende Tabellen gepflegt werden. Eine Übersicht über vorhandene Transaktionen kann auch in der Tabelle TSTC bzw. TSCT wie unter Verwendungsnachweis von Tabellen in Transaktionen beschrieben erstellt werden.

Ausgangslage
Bei der Erstellung eines Berechtigungskonzeptes kann ein Thema auch die Frage sein, wie die Benutzer mit der Anwendung umgehen sollen. Hierbei ist es sicher die einfachste Möglichkeit einfach das SAP Menü im Standard zu benutzen. Jedoch kann es immer wieder erforderlich sein auch darüber hinausgehende Funktionen schnell zugängig zu machen.

Hier gibt es verschiedene Möglichkeiten die nach Aufwand kurz erläutert sind.

a) Favoriten

Für jeden User besteht die Möglichkeit sich Favoriten über das Menü Favoriten anzulegen. Hier gibt es die Möglichkeit Ordner anzulegen, Funktionen aus den SAP Menü als Favoriten abzulegen (meistens wird dann auch der Pfad in die Beschreibung mit übernommen) oder auch Transaktion einfügen.

Zur zentralen Verwaltung der Favoriten besteht die Möglichkeit diese über einen Referenzuser oder per Upload innerhalb der User zu verteilen. Ein Referenzuser dient hierbei bei der Anlage eines neuen User als Vorlage (Kopie des bestehenden Users) und kann sowohl Parameter als auch Favoriten enthalten.Die direkte Übertragung von Favoriten ist der "Download auf PC" bzw. "Upload auf PC" innerhalb des Favoriten-Menüs.

Innerhalb der Tabelle SMEN_BUFFC ("Tabelle für die Ablage der Favoriten") werden die Einträge der einzelnen User gespeichert, so dass hier anhand eines Benutzernamen auch eine Auswertung über vorhandene Einträge möglich ist bzw. auch hier eine Pflegemöglichkeit gegeben wäre.

Meistens sind in den Favoriten durch die einzelnen Benutzer auch die häufigst genutzten Transaktionen und kann auch als Basis für die Neukonzeptionierung von Berechtigungen dienen.


Favoriten haben jedoch den Nachteil nur Transaktionen beziehungsweise Einträge aus den SAP Menü zu übernehmen. Hier besteht natürlich der Nachteil, dass SAP Query, Rechercheberichte oder ReportWriter Berichte nicht direkt eingebunden werden können.

Zwar gibt es die Möglichkeit über kundeneigene Transaktionen (wie im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query Unterschied Parameter- oder Reporttransaktion" oder unter Parametertransaktionen bzw. ausführlicher im Artikel "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" beschrieben) anzulegen aber hier ist dann auch ein entsprechend hoher Aufwand zu betreiben. Außerdem müssen diese Transaktionscodes auch in Erinnerung behalten werden.
 

b) Benutzermenüs

Eine andere Alternative ist die Nutzung der Benutzermenüs welche innerhalb der Berechtigungspflege innerhalb des Profilgenerators (Transaktion PFCG) eingepflegt werden können. Ein Nachteil dieser Methode kann jedoch sein, dass eine Transaktion nur einmalig im Menü auftaucht. Sofern bspw. die Transaktion FK03 (Kreditor anzeigen) innerhalb eines Benutzermenübaumes hinterlegt ist wird diese nur einmalig ausgegeben und nicht an mehreren Positionen des Benutzermenüs. Dieses scheint jedoch bei aktuelleren Releases nicht mehr der Fall zu sein.

Hinweis
Um eine entsprechende Funktion innerhalb des Benutzermenüs dann aus Anwendersicht zu finden ist es hilfreich die Transaktion "search_user_menu" als Gegenstück zur Suche im SAP Menü uber die Transaktion "search_sap_menu" zu verwenden. Alternativ kann auch mit der Suchenfunktion (STRG F) das jeweilige aktive Menü durchsucht werden.

c) Erweiterung SAP Menü / Bereichsmenü

Eine entsprechende komplexere Möglichkeit besteht darin das vorhandene SAP Menü um eigene Berichte zu erweitern. Einzelne Menübäume sind hierbei als Bereichsmenüzweige pflegbar. Das gesamte SAP Menü liegt zum Beispiel innerhalb des Bereichsmenü S000 und kann wie unter "SAP Menü exportieren" beschrieben als Liste exportiert werden.

Eine andere Möglichkeit ist es ein entsprechendes Untermenü zu bearbeiten. Details zum Bereichsmenü kann auf einen Menüknoten unter Zusätze->Technische Detailinformationen eingesehen werden.

So kann unter

• Rechnungswesen->
• Controlling
• Profit-Center-Rechnung
• Infosystem

unter der Anzeige technischer Details als Bereichsmenü KE50 angezeigt werden. Ein Bereichsmenü kann nun auch direkt aufgerufen werden (bspw. durch /nKE50 für einen neuen Modus oder aber auch im Benutzerstamm unter Festwerte (entweder in der Benutzerpflege oder wie unter SAP Parameter auf Benutzerebene beschrieben über die Transaktionen SU3 im Reiter Festwerte als Startmenü hinterlegt werden.

Durch das Hinterlegen des Bereichsmenü KE50 wird nun statt des SAP Menüs das Menü der Profit-Center-Rechnung aufgerufen.

Neben der Erweiterung bestehender Menüs ist es aber auch möglich kundeneigene Z-Menüs anzulegen. So könnten bspw. PSM Rechercheberichte unter einen Bereichsmenü mit der Bezeichnung ZFMR oder auch ZFMEQ hinterlegt werden.

Die Pflege eines Bereichsmenü erfolgt unter

• Werkzeuge
• ABAP Workbench
• Entwicklung
• Weitere Werkzeuge
• Bereichsmenü Transaktion SE43

Hier kann dann entweder ein neues Bereichsmenü (bspw. ZFMEQ) angelegt werden oder ein bestehendes Bereichsmenü bearbeitet werden. Sofern ein vorhandenes Bereichsmenü bearbeitet werden soll, ist es sinnvoll dieses über Erweitern statt Ändern zu bearbeiten, da anderenfalls nach einen Upgrade das Menü wiederum überschrieben wird.

Innerhalb des Bereichsmenü können nun einzelne Ordner angelegt werden. Die entsprechenden Unterordner können über den Punkt "Eintrag auf gleicher Ebene hinzufügen" innerhalb der Symbolleiste eingefügt werden.

Um einen Bericht innerhalb des Bereichsmenü einzufügen kann die Funktion "Eintrag eine Ebene tiefer hinzufügen" ausgewählt werden. Hier kann dan ein Bericht über die Schaltfläche Bericht hinzugefügt werden. Hier besteht nun die Möglichkeit einen ABAP Report, SAP Query, Transaktion mit Variante, ReportWriter (als Berichtsgruppe) oder auch Recherchebericht einzufügen. Dabei wird automatisch neben einen Menüeintrag auch ein entsprechender Transaktionscode angelegt (Y* Transaktion).

Hinweis: Früher[TM] Anwendungsbaum (Transaktion SERP)

Vorgängerin der Bereichsmenü waren die sogenannten Anwendungsbäume. Diese konnten mit der Transaktion SERP gepflegt werden und sind heute durch die Bereichsmenü abgelöst worden. Sollten Sie noch Anwendungsbäume im Einsatz haben, dann können Sie über die Transaktion RTTREE_MIGRATION diese entsprechend umwandeln lassen. Die Anwendungsbäume waren bis R/3 4.6a aktuell, daher ist das schon ein ziemlicher Schritt in die Vergangenheit ;-).

 

Fazit

Gerade wenn mehrere Varianten eines Berichts (als Varianten innerhalb einer Parametertransaktion) oder unterschiedliche Rechercheberichte bzw. selbst entwickelte Berichte zur Verfügung gestellt werden sollen ist dem Aufruf der direkte Aufruf von Rechercheberichte (in PSM zum Beispiel über die Transaktion FMEQ) oder von ReportWriter Berichten (über die Transaktion GR55 (Berichtsgruppe ausführen) oder gar GRR3 (Bibliothek anzeigen)) eine wie oben beschriebene Vorgehensweise sicherlich zu bevorziehen.

Hierbei sollte jedoch daran gedacht werden, dass gegebenenfalls veraltetete Berichte sowohl seitens der Berechtigungen als auch seitens des Bereichsmenü wieder entfernt werden.

Insgesamt stellt aber gerade die Möglichkeit eines Bereichsmenüs oder Benutzermenüs die Möglichkeit zur Verfügung hier ein "internes" Haushaltsinformationssystem zur Verfügung zu stellen. Ggf. können hier auch externe Quellen (Dokumentationen oder Verlinkungen auf Internetseiten) hinterleght werden.

Vor der eigentlichen Anlage solcher benutzereigener Menüs sollte aber auch ein Konzept wie das SAP Berichtswesen auf Basis der Infouser aussehen soll mit den beteiligten Fachabteilungen erarbeitet werden, insbesondere da meistens Infouser auch bei den "produktiven" Usern anrufen um zu erfahren, wo denn ein entsprechender Bericht zu finden ist.

Dieses sollte bei Benutzermnüs innerhalb des SAP Berechtigungskonzeptes so abgefangen werden können, dass die Menübäume relativ vergleichbar sind.

Denkbar ist hier ein Menübaum für Infouser in der Form

• Budgetinformationssystem
• Berichte
  • Einzelposten
  • Summenberichte

welches bei Usern mit Buchungsberechtigung um entsprechenden funktionalen Berechtigungen erweitert wird. Hier könnte das Menü dann wie folgt aussehen:

• Budgetinformationssystem
• Berichte
  • Einzelposten
  • Summenberichte
• Budgetbuchungen
  • CO Budget buchen
  • PSM Jahresbudget buchen
  • PSM Gesamtbudget buchen
  • Budget umbuchen

.
Der Knoten Budgetbuchungen ist dann nur in der Rolle der Budgetbuchungsberechtigten enthalten und ergänzt das Benutzermenü der Anzeigeberechtigten von Budgets. Auf diese Weise können auch die User innerhalb der Budgetbuchhaltung Auskunft darüber geben an welcher Stelle die einzelnen kundeneigene Berichte in SAP zu finden sind sofern nicht über eine zentrale Transaktion ZLANDESBUDGET, ZDRITTMITTEL, ... und so weiter die Berichte aufgerufen werden.

Hinweis - Berichtswesen im SAP Controlling

Nicht nur für das Berichtswesen im SAP Controlling, auch für andere Finanzberichte habe ich einige Hinweise in meinen neuen Buch zusammengefasst:

Im Buch "Berichtswesen im SAP®-Controlling" bin ich auf einige Möglichkeit zum Aufbau eines Berichtswesen eingegangen.
  (01. Juni 2017)
Paperback ISBN: 9783960127406

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *


Daher möchte ich in diesen Artikel ebenfalls darauf verweisen. Gerade der Aufbau eines Berichtswesen ist definitiv als eine modulübergreifende Sache zu betrachten und dürfte hier nicht nur durch den Artikel "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)" eines der für mich spannendsten Themen rund um SAP sein, dass sich auch beruflich für die Bereiche Hochschulberichtswesen und Hochschulcontrolling anwenden lässt.

Sofern, meistens aus Sicherheitsgründen, die Ausgabe von Fehlermeldungen bei PHP deaktiviert ist, gibt es neben der Einstellungen innerhalb der Serverkonfiguration (PHP.INI) auch weitere Möglichkeiten diese zu aktivieren, sofern dieses unterstützt wird.

a) php.ini
Hier wäre die Einstellung auf

error_reporting = E_ALL
display_errors = On

zu ändern.

b) .httaccess
Hier kann über PHP Flags die Ausgabe von Fehlern wiederum aktiviert werden.

php_value display_errors 1
php_value error_reporting 6143

Zur Erklärung:
display_errors 1 schaltet die Fehlerausgabe auf an und error_reporting 6143 steht für alle Fehler.

Sofern der Server diese Konfiguration nicht unterstützt kann es zu einen unerwarteten Serverfehler kommen (HTTP-Statuscode 500)

c) innerhalb des PHP Skripts

Durch folgenden PHP Code innerhalb einer PHP Anweisung kann ebenfalls die Ausgabe von Fehlern aktiviert werden:

error_reporting(E_ALL);
ini_set('display_errors', 1);

Auch hier werden wiederum alle Fehler berichtet und per ini_set dann auch ausgegeben.

Eine Übersicht über die möglichen Werte sind auf php.net untererrorfunc.constants.php beschrieben.

Die sicherste Variante dürfte daher c) und die Angabe innerhalb eines PHP Skriptes sein. Aus Sicherheitsgründen sollte dieser Codeblock nach erfolgreichen Test aber wieder entfernt werden, da ansonsten anhand der Fehlermeldung auch Informationen zum Aufbau der Seite ausgelesen werden können.

Ausgangslage
Neben den schon vorhandenen Diagrammbögen (bspw. UML, ER, Datenbank, ...) bietet Dia auch die Möglichkeit weitere Objekte bzw. Diagrammbögen herunterzuladen und so das Programm um weitere Objekte zu erweitern. Beispiele können hier Baustellenzeichnungen, elektrische Schaltpläne oder auch weitere Modellierungsobjekte sein.

Innerhalb der Anwendung Dia ist es möglich überDatei->Objektbögen und Objekte ... (F9) aus den vorhandenen Objekten einen eigenen Objektbogen zu erstellen. Sofern hier aber bestimmte Objekte noch nicht vorhanden sind, kann es hilfreich sein hier "neue" Objektbögen als "Plugin" zu installieren.

Hier soll als Beispiel eine ereignisgesteuerte Prozesskette dargestellt werden.

Exkurs Definition Ereignisgesteuerte Prozesskette
Bei Ereignisgesteuerte Prozessketten (englisch: Event-driven Process Chain (EPC)) handelt es sich um eine Methode der Geschäftsprozessdarstellung.
Hierbei werden Prozesse nicht nur mit den zu Grunde liegenden Ereignissen sondern auch mit den zuständigen Organisationseinheiten verknüpft.

Diese könnte als Beispiel wie folgt aussehen.


Lösung
Auf der Seite dia-installer.de sind im Bereich "Fundgrube für Dia-Objekte" sind einige Objekte zu finden.

Diese können entweder über das Programm Diashapes pauschal installiert werden oder einzeln als ZIP heruntergeladen und der Anwendung hinzugefügt werden.

Zur manuellen Installation müssen die einzelnen Dateien aus der .ZIP Datei in das Programmverzeichnis von DIA extrahiert werden. Hierbei ist darauf zu achten, dass bei DIA Portable dieses der Ordner "DiaPortableAppDia" ist.

Anhand der "Objekte zum Zeichnen von ereignisgesteuerten Prozessketten" möchte ich kurz die Einbindung und Nutzung dieser Diagrammbögen erläutern.

Nachdem die ZIP Datei (edpc.zip Objekte und Objektbogen, gezippt) im Programmordner entpackt worden ist kann DIA erneut gestartet werden.

Innerhalb der ZIP Datei befinden sich zwei Ordner:

• shapesedpc
  Hier liegen die Grafikdefinitionen der Objekte
• sheets
  Hier liegt die Datei edpc.sheet in der als XML die Sprachdatei (Übersetzung) der Diagrammbögen liegen

Sofern diese Ordner in Dia integriert sind kann DIA gestartet werden und es steht der Diagrammbogen zur Verfügung.

In diesen Fall sind die Objekte einer "Ereignisgesteuerte Prozesskette / Event-driven process chain" als Auswahl vorhanden, so dass ein entsprechendes Diagramm erstellt werden kann.



In den gelben Kästen sind entsprechende Beispiele für die Objektausprägungen aufgeführt.