Layout mit BI Publisher ein Kinderspiel?

Transkript

1 Schlüsselworte: Layout mit BI Publisher ein Kinderspiel? BI Publisher, xml, Layout Einleitung Annegret Schlenker Fox Mobile Group Berlin Der BI Publisher ist mittlerweile etabliert als das Werkzeug der Wahl zur Erstellung von Reports in der Oracle E-Business Suite. Seine Anwendungsmöglichkeiten reichen von der einfachen Abfrage bis hin zum komplexen Report mit ansprechendem Layout in verschiedensten Formaten. Technisch unterscheidet man in die in der Oracle E-Business Suite standardmäßig integrierte Version sowie die Standalone Version, die auch zusätzliche technologische Möglichkeiten bietet, wie zum Beispiel die Anbindung an verschiedene Datenquellen oder integrierte Lösungen zum Versand der generierten Dokumente bzw. Inhalte per . Anders als bei herkömmlichen Oracle Reports findet bei der Anwendung des BI Publisher eine Trennung statt zwischen der eigentlichen Datenabfrage und dem Report Layout, welches dann wiederum verschiedene Lokalisierungen oder Übersetzungen bekommen kann. Das ermöglicht eine sinnvolle Arbeitsteilung zwischen dem für die Datenabfrage verantwortlichen Entwickler und dem für das Layout Design zuständigen Vertreter der Fachabteilung. Aber wie sieht das in der Praxis aus? Ist es wirklich ohne Weiteres möglich, den Aufbau der Layout-Vorlagen der Fachabteilung zu übergeben? Wie viel Zeit benötigt man für den Aufbau solcher Layout-Vorlagen? Welche Information kann sinnvollerweise in der Vorlage gehalten werden, welche Information hält man besser in der Applikation selbst vor und füllt sie mit Hilfe der Datenabfrage? Und was noch sollte man bei der Arbeit an der Layout-Vorlage wissen und bedenken? Antworten auf diese Fragen sind nicht leicht zu finden dieser Artikel soll eine Orientierungshilfe dabei sein, basierend auf den Erfahrungen bei der Einführung des BI Publisher in der Fox Mobile Distribution GmbH. Die Fox Mobile Distribution GmbH als Teil der News Corporation setzt seit mehreren Jahren die Oracle E-Business Suite (Version ) für die Abbildung der finanziellen Geschäftsprozesse (Hauptbuch, Debitoren, Kreditoren, Anlagen und Einkauf inklusive der Online Bedarfsanforderung). Traditionell wurden Dokumente aus der Oracle E-Business Suite (Lieferantenbestellung, Ausgangsrechnung) mit Oracle Reports erzeugt und am Ende in eine Drittanbieter-Software eingespeist, die das Layout erzeugte. Dafür mussten spezielle Server vorgehalten werden, der Zugriff auf die Software war dem technischen Personal vorbehalten und Änderungen am Layout bedurften regelmäßig des Einsatzes eines Entwicklers. Und Änderungen gab es aufgrund einer sich rasch ändernden Firmenstruktur nicht wenige. Nun sollte BI Publisher hier Abhilfe schaffen und, im ersten Schritt für die Lieferantenbestellung,

2 eine flexible Funktionalität zur Verteilung der Dokumente per sowie für ein ebenso zeitgemäßes wie leicht anpassbares bzw. erweiterbares Layout bereitstellen. Das Projekt So war das Projekt ins Leben gerufen. Ziel: Einführung von BI Publisher als integrierte Oracle E-Business Suite Komponente am Beispiel der Lieferantenbestellung inklusive einer Funktion zum Versand der Bestelldokumente per . Die Funktion und das Layout sollten einfach übertragbar sein auf andere Dokumentenarten wie die Ausgangsrechnung, denn letzten Endes sollte der BI Publisher die Dritt-Anbietersoftware komplett ersetzen. Aus rein technischer Sicht (ohne hier die üblichen Phasen des Projekt Managements von Anforderungsanalyse, Entwicklung, Test etc. zu betrachten, die natürlich auch in diesem Projekt in der üblichen Abfolge eine Rolle spielten) haben wir das Projekt in 3 Schwerpunkte unterteilt: 1. Die technische Implementierung der BI Publisher Funktion hier planten wir die Aktivierung der notwendigen Funktionen und Zuständigkeiten, erforderliches Patching und Testen der grundsätzlichen Funktionalität. 2. Das Programm zur Verteilung der erzeugten Dokumente hier waren Anforderungen zu erfüllen wie - Versand des Bestelldokuments an interne wie externe Beteiligte (Lieferant, Einkaufsabteilung, Fachabteilung) - Versand von weiteren Dokumenten, die der Bestellung in Oracle angehängt sind - Versand des Bestelldokuments in verschiedenen Ausprägungen der enthaltenen Information (Version mit Wert und ohne Wert) 3. Entwicklung des Layouts in zeitgemäß ansprechendem Design und konform mit den rechtlichen Anforderungen an die enthaltenen Informationen hier muss auch der Anforderung nach verschiedenen Versionen (mit und ohne Wert) Rechnung getragen werden, ebenso der Tatsache dass sich unter dem Dach der Fox Mobile Group verschiedene eigenständige Firmen mit eigenem Firmenlogo und eigener handelsrechtlicher Information vereinen. Die Erstellung des Reports, der als Datenquelle dienen sollte, wird hier aus gutem Grund nicht erwähnt. Wir gingen davon aus, dass der bestehende Report, der bereits eine Eigenentwicklung von Fox Mobile war und zusätzlich zum Standard Print PO Report spezielle, firmenspezifische Informationen enthält, als Datenquelle dienen soll und kann. Es gab keine Anforderungen, zusätzliche Informationen auf dem Bestelldokument auszuweisen. Zudem waren die Ressourcen an Programmierkapazität beschränkt auf die Person eines Entwicklers für, der neben dem Projekt auch für tägliche Support- Aufgaben zur Verfügung stehen musste. Ganz ohne externe Hilfe sollte das Vorhaben jedoch nicht stattfinden, so starteten wir das Projekt mit einem 4tägigen Workshop mit dem Anbieter APCONEX. In diesem Workshop erhielten die Projektmitwirkenden eine Einführung in die technischen und funktionalen Möglichkeiten mit BI Publisher. Um nicht bei der Theorie zu verweilen, begann man bereits im Workshop die Arbeit am neuen Layout für das Bestelldokument, so dass am Ende der vier Tage zumindest das Grundgerüst zu erkennen war. An dieser Stelle ein Dankeschön an den Referenten, Herrn Uwe Klos, für seine sehr gute Einführung in die technischen und funktionalen Anwendungsbereiche für BI Publisher.

3 Phase 1 In der ursprünglichen Planung waren wir von einem etwa ausgeglichenen Arbeitsaufwand in den drei Projektphasen ausgegangen. Dieses Bild sollte während der Arbeit an dem Projekt gründlich revidiert werden. Als überaus einfach erwies sich Teil 1 die Installation der notwendigen Komponenten und das erfolgreiche Testen der BI Publisher Funktionen. Das erforderliche Patch-Level war schnell festgestellt, ein paar Datenbankeinstellungen rasch erledigt. Schnell war auch die Client Version des BI Publisher in Form eines Word Add Ons auf den Rechnern der Mitarbeiter installiert, die mit dem Werkzeug arbeiten sollten. Dabei gibt es nicht viel zu beachten. Wichtig ist für die spätere Arbeit an den Layouts, dass die Version des installierten Clients mit der in der Applikation installierten übereinstimmt, sonst kann es dann schon mal passieren, dass eine Layout Vorlage auf dem eigenen Rechner ganz prima Resultate auswirft, hat man die Vorlage dann aber in der Applikation registriert passt die Formatierung nicht mehr. Und dann war es auch schon Zeit für erste Anwendungsbeispiele, die auch recht schnell zum Erfolg führten: einen einfachen Standard-Report als Beispiel auswählen in der Hintergrundprozessdefinition das Ausgabeformat des Programms auf xml umstellen den Report starten und das Resultat als xml Datei speichern die xml Datei in ein Word-Dokument importieren und das Vorlagendokument als rtf Datei speichern mit Hilfe des Tabellenassistenten schnell die Daten einfügen, sortieren und gruppieren, auch ein nettes grafisches Element ist leicht eingefügt per Vorschau-Funktion die Ausgabe überprüfen mit der xml Publisher Administrator Zuständigkeit eine Datendefinition generieren dazu muss man zwei Dinge kennen und korrekt hinterlegen: die Applikation in welcher der Hintergrundprozess registriert ist und den Prozess- Kurznamen, denn über diese Daten wird die Verbindung von Datenabfrage und Layout hergestellt ebenfalls als xml Publisher Administrator eine Vorlage registrieren und mit der Datendefinition verlinken, als Methode rtf wählen, das gewünschte bevorzugte Reportformat (z.b. pdf) hinterlegen, und die zuvor erstellte rtf Datei anhängen. Dann kann das Ergebnis auch schon vorgezeigt werden. Wird der entsprechende Report jetzt als Hintergrundprozess gestartet, so wird zunächst eine Datei im xml Format erstellt und in der Datenbank abgelegt. Der Post Output Prozessor des BI Publisher greift diese dann auf und generiert das Dokument im gewünschten Format, welches dann über die Hintergrundprozess- Ausgabe aus der Applikation heraus abgerufen werden kann. Übrigens, auch das zugrunde liegende xml File lässt sich auf diesem Wege wieder sichtbar machen, der Weg zu diesem führt über Diagnostics xml Ansicht. So einfach war dieser Teil, und so schnell und unkompliziert kann man mit ein paar Handgriffen einen einfach strukturierten Report mit einem schicken Layout versehen. Zeitaufwand Phase 1: 4 Tage

4 Phase 2 Nach den ersten Erfolgen bei der Layout-Gestaltung haben wir natürlich gleich mit der Arbeit an der Vorlage für das Bestelldokument angefangen. Parallel dazu konnte jedoch unser Programmierer bereits an den Funktionen für den Dokumentenversand arbeiten. Hier war die Erwartung, dass BI Publisher über derartige Funktionen verfügt und diese von uns genutzt werden können. Leider trifft diese Annahme nur für die Standalone-Version zu. Die integrierte Variante des BI Publisher bietet lediglich verschiedene Schnittstellen an, um eigene Programme daran anzubinden. So kam dann hier zunächst die Aufgabe auf unser technisches Team zu, diverse Lösungsoptionen zu analysieren und sich für die am besten für unsere Bedürfnisse passend Schnittstelle zu entscheiden. Die letztendliche Entscheidung fiel dafür, das UTL_SMTP Programm zu verwenden. Ein aus der Purchase Order Maske über eine Forms Personalisierung aufgerufenes Hintergrundprogramm startet den eigentlichen Report, der die Datenabfrage durchführt und die Ausgabe als xml in der Datenbank ablegt, ebenso wie das fertige Dokument in pdf Format. Sind diese Dokumente erstellt sorgt das UTL_SMTP Package für den Versand der . Aus funktionaler Sicht stellt sich das Ergebnis so dar: Der Lieferantenbetreuer aktiviert die Funktion mit Hilfe einer Personalisierung in der Purchase Order Maske über einen Menüeintrag oder über ein Symbol und öffnet damit eine eigens dafür erstellte Maske. Hier werden ihm zur Kontrolle die Bestellungsnummer, die Absender- für die jeweilige bestellende Firma und die -Adresse des Lieferantenkontakts angezeigt. In einem Eingabefeld kann er weitere -Empfänger eintragen. Da diese zusätzlichen Empfänger in der Regel Mitarbeiter von Fox Mobile sind wurde inzwischen auch die Möglichkeit hinzugefügt, Mitarbeiter aus einer Werteliste hinzuzufügen. Als letzte Eingabe wählt er das zu verwendende Layout aus den Optionen mit bzw. ohne Wert aus, wobei zur Sicherheit die Option ohne Wert vorbelegt ist. Beim Starten der Funktion wird der zuvor beschriebene Hintergrundprozess mit den übergebenen Parametern ausgelöst, in einem ersten Teilprozess das Bestelldokument in pdf Format generiert und im zweiten Schritt eine erstellt und versandt. Der -Text ist in Messages hinterlegt, der ist das Bestelldokument angehängt, ebenso wie alle weiteren der Purchase Order als Anhang (Attachment/ Büroklammerfunktion) angehängten Dokumente vom Typ Datei und Kategorie An den Lieferanten. In diesen Dokumenten werden bei Fox Mobile spezielle Informationen an den Lieferanten übermittelt, zum Beispiel bei der Bestellung von Werbeinhalten bei Fernsehsendern wird genau definiert, welcher Werbespot mit welcher Häufigkeit, zu welchen Zeiten etc. ausgestrahlt werden soll Informationen die so nicht im Standard-Bestellformular hinterlegt werden können und sollen. Diese Zusatzfunktion zum Versand angehängter Dokumente war ein wichtiges Ziel und Erfolgskriterium für das Projekt. Nach Festlegung des geeigneten Lösungsdesigns gestaltete sich der Codierungsprozess recht unkompliziert. Das Programm lief von Anfang an ohne Fehler, es wurden lediglich nach Vorstellung des ersten Entwurfs zusätzliche Anforderungen nach Warnmeldungen identifiziert und diese nachträglich eingebaut (zum Beispiel für den Fall, dass in den Lieferantenstammdaten keine hinterlegt ist). Zeitaufwand Phase 2: Design, Coding und Test der versand-Funktionalität: ca. 14 Tage

5 Phase 3: Das Layout Die Schätzung des Aufwandes für das Layout des Bestelldokuments war der schwierigste Posten bei der Erarbeitung des Projektplans, da wir auf diesem Gebiet auf keinerlei Erfahrung zurückgreifen konnten. Unsere Schätzung beruhte also letzten Endes auf der Annahme, dass nach dem kurzen Workshops zur Einführung das Gros der Arbeit getan sein würde und nur noch ein Finetuning, vorzugsweise sogar durch die Fachabteilung, stattfinden müsste. Schließlich ist die Aussage von Oracle zum Thema Layout, dass hier fortan eine Trennung stattfindet würde zwischen IT Abteilung, die für die Bereitstellung der Datenquelle, also der eigentlichen Datenabfrage zuständig zeichnet, und der Fachabteilung, die eigenständig die Gestaltung des Layouts übernehmen kann. Nur, kann man das von der Fachabteilung tatsächlich so erwarten? Versteht ein Mitarbeiter aus dem Einkauf so ohne Weiteres die zur Verfügung gestellte xml Datei? Kann er mit dem neuen Werkzeug, dem BI Publisher, umgehen? Wie viel Anleitung und Unterstützung benötigt er, und woher bekommt er die? Bereits während des einführenden Workshops zeigte sich: den erforderlichen Aufwand für die Erstellung der Layout-Vorlage hatten wir bei Weitem unterschätzt. Erschwert wurde das Ergebnis außerdem durch fehlerhafte Annahmen was z.b. die Brauchbarkeit der vorhandenen Datenabfrage als Grundlage für den Report angeht, bzw. auch Unsicherheit darüber, welche Informationen sinnvollerweise im Layout und welche in der Applikation hinterlegt werden sollen. Einige wesentliche Erkenntnisse wurden bei Fox Mobile inzwischen in einem Folgeprojekt (Erzeugen und Versenden der Ausgangsrechnung mit BI Publisher) erfolgreich umgesetzt und sollen im Folgenden als eine Art Leitfaden für ähnliche Projekte aufgeführt werden. Zeitaufwand Phase 3: 4 Wochen Das Layout 1. Die Vorlage planen Wichtig bei komplexen Reports ist es, die Vorlage vorab genau zu planen. Dabei gilt es unter anderem folgende Überlegungen anzustellen: Soll mit dem Report jeweils eine Transaktion (Bestelldokument, Rechnung) verarbeitet werden, oder sollen mehrere Transaktionen zu einem Dokument verarbeitet werden? Wird es mehrseitige Dokumente geben? Wenn ja, soll jede Seite die gleiche Information enthalten, oder sollen bestimmte Informationen nur auf der ersten bzw. letzten Seite angezeigt werden? Werden Vorlagen in verschiedenen Sprachen (Übersetzungen) benötigt? Werden Vorlagen in verschiedenen lokalen Ausprägungen (Lokalisierungen) benötigt? Werden Vorlagen in verschiedenen inhaltlichen Ausprägungen (vollständige versus reduzierte Version) benötigt? Welche Inhalte sind statisch, welche dynamisch und von welchen Variablen gesteuert?

6 Aufgrund welcher Steuerelemente sollen dynamische, variable Inhalte ausgewählt werden (zum Beispiel: soll der Endanwender beim Starten des Reports auswählen, welches Firmenlogo eingeblendet wird, oder soll ein entsprechendes Element im Report die Auswahl des Logos automatisch steuern?) Aber Vorsicht ist geboten, um keine unerfüllbaren Erwartungen in der Fachabteilung zu wecken. BI Publisher ist kein Wundermittel oder Alleskönner. Hier nur zwei Beispiele: Es ist nicht vorgesehen, mehrere Dokumente gleichzeitig zu generieren, also zum Beispiel den Purchase Order Report für eine Reihe von Bestellungen laufen lassen aber für jede Bestellung ein separates pdf File zu erstellen. Die Funktionen, verschiedene Information in Kopf- und Fußzeile sowie im Inhalt abhängig von der jeweiligen Seite auszugeben ist, hat ihre Grenzen. So lässt sich z.b. die Last Page Funktion des BI Publisher nur bedingt mit der standardmäßigen Funktion von Word zur Darstellung verschiedener Inhalte auf der Frontseite kombinieren. 2. Die XML Datei verstehen Ausgangspunkt für die Gestaltung des Layout Templates ist die vom Report gelieferte xml Datei. Diese zeichnet sich durch folgende Merkmale aus: jeder Datensatz innerhalb der Datei ist mit einem Anfangs-und einem End-Tag versehen. Die Datensätze sind in (beliebig vielen) Gruppen angeordnet, die die (beliebig verschachtelte) Hierarchie der Daten abbilden. Zum Beispiel für die Lieferantenbestellung wäre das typischerweise: Gruppe PO Kopfdaten, Untergruppe PO Zeilendaten, Untergruppe PO Zeilen Anhänge etc. Die Datenhierarchie zu verstehen ist wesentliche Voraussetzung um die Daten im Report korrekt darzustellen. Das setzt zunächst ein grundlegendes Verständnis für die Datenabfrage als solches voraus, gelingt dann aber mit ein wenig Übung und einem guten xml Editor Programm recht schnell. Nur, darauf wird hier im nächsten Absatz eingegangen, enthalten vorhandene Reports, die ja nicht nur der Datenlieferung dienten sondern ebenso das Layout steuerten, im Allgemeinen zahlreiche überflüssige Elemente und sind somit schwerer zu verstehen und zu verarbeiten. 3. Die Daten der vorhandenen Abfrage analysieren An dieser Stelle nun muss man sich die Frage stellen, ob die vorhandene Datenabfrage geeignet ist, den Input für den gewünschten Report zu liefern. Natürlich lässt sich (fast) jeder vorhandene Report ohne Mühe in eine xml Output Datei verwandeln und als Grundlage für das Layout Template verwenden. Allerdings sind die vorhandenen Reports nicht dahingehend optimiert, die Daten für ein BI Publisher Layout Template zu liefern, sondern enthalten die Daten meist schon vorformatiert, gruppiert, sortiert und zu einem Layout aufbereitet. Mit BI Publisher heißt es hier Umdenken. Je einfacher die Daten strukturiert sind, umso leichter lässt sich daraus die Vorlage zusammenbauen. Und umso besser lässt sich die Datenabfrage für verschiedene Ausgabeformate (Vorlagen) verwenden. Zum Beispiel: Ein Datensatz, der in Großschreibung (Upper Case) vorformatiert ausgegeben wird, kann schwerlich wieder sinnvoll in gemischte Schreibweise (Mixed Case)

7 zurückverwandelt werden, dagegen die Umwandlung in Großschreibung (Upper Case) kann ohne Probleme im BI Publisher Template vorgenommen werden. Eine Tabelle kann mit Hilfe von BI Publisher mit Sortierung, Gruppierung und Verschachtelung versehen werden, aber eine bereits verschachtelte und gruppierte Reportausgabe zu entwirren ist eine ungleich schwerere wenn nicht unmögliche (und auch unsinnige) Aufgabe. Fazit: Das Verwenden vorhandener Reports als Datenquelle ist nur bedingt möglich, in vielen Fällen ist es sinnvoller, die Datenabfrage neu zu programmieren bzw. anzupassen und dabei so einfach wie möglich zu strukturieren und gleichzeitig möglichst viele Datenfelder auszugeben. Dabei sollte man auch an solche Datenfelder denken, die später nicht 1:1 im Ausgabedokument angezeigt werden, sondern als Steuerelemente für variable Inhalte dienen werden. Was unser Beispiel-Projekt angeht, so wuchs diese Erkenntnis leider erst während der Arbeit an den Vorlagen und es gab keine Möglichkeit den eingeschlagenen Kurs kurzfristig zu korrigieren. So enthält unsere Vorlage für die Bestellung etliche Kompromisse, die wir demnächst in einem Folgeprojekt aber bereinigen wollen, indem die Datenabfrage den Bedürfnissen der Layout-Vorlage angepasst wird. Aber wie geht man diese Aufgabe sinnvollerweise an? Was wird zuerst definiert die Datenabfrage oder das Layout? Am besten wenn beide Aufgaben Hand in Hand gehen und die Anforderungen für die Datenabfrage von demjenigen formuliert werden, der dann auch die Layout Vorlage erstellt. So haben wir bei Fox Mobile für unseren zweiten großen BI Publisher Report die Ausgangsrechnung den von Oracle vordefinierten Standardreport Print Selected Invoices analysiert und als Anforderung zusätzliche Datenfelder und deren Stellung in der xml Hierarchie vorgegeben. Auf dieser Grundlage ist uns die Gestaltung der Layout Vorlage schon viel besser von der Hand gegangen. 4. xml Elemente und Gruppen in die Vorlage einfügen Das Einfügen der Daten und Datengruppen in die Layout Vorlage (rtf Datei) erfolgt über die BI Publisher Toolbar in MS Word. Je nach Anforderung, kann man die Datenfelder und Datengruppen einzeln oder mit Hilfe des Tabellenassistenten einfügen, gruppieren, sortieren und Tabellenüberschriften bearbeiten. Dabei ist es wichtig zu wissen ob es sich um einzelne oder sich wiederholende Felder bzw. Gruppen handelt. Im Beispiel unseres Bestelldokumentes wären das Einzelfelder wie Bestellnummer, Lieferanschrift, Bestelldatum, Währung, Gesamtpreis usw. Informationen, die für jedes Dokument einmalig sind (jedoch beliebig häufig an verschiedenen Stellen in das Dokument einfügt werden können). Die Datengruppe der Bestellpositionen ist jedoch als Wiederholung einzufügen, denn hier handelt es sich um eine 1:n Beziehung Bestellung: Bestellposition, und die auf Positionsebene darzustellenden Felder müssen entsprechend mit der for Each Funktion eingefügt werden, um eine n-fache Wiederholung der Felder zu gewährleisten. Mit dem einfachen Einfügen von Kopf- und Fußzeileninformation über die Standardfunktion von MS Word und den Tabellenassistenten lassen sich einfache Reports für den internen Gebrauch schnell und problemlos formatieren. Was aber wenn die Anforderungen komplexer

8 sind und Aufgaben beinhalten wie: die Kopf- und Fußinformation soll abhängig sein von der Seitenzahl, Inhalte sollen abhängig von bestimmten Parametern angezeigt oder ausgeblendet werden oder variieren. Logos, Adressen, Tabellen, Unterschriften sollen dargestellt werden. 5. Seitenspezifische Inhalte Für das Darstellen von seitenspezifischen Inhalten lassen sich zwei Wege beschreiten. Zum einen ist es möglich, die Standardfunktion von MS Word einzusetzen, die es ermöglicht Inhalte bzw. Kopf- und Fußzeilen für die erste bzw. für gerade/ungerade Seiten unterschiedlich zu hinterlegen. Leider jedoch gibt es diese Funktion aus Word heraus nicht mit einer speziellen Funktion für Inhalte auf der letzten Seite. Hier hilft die Body Funktion der rtf Vorlage, die im Grunde den umgekehrten Ansatz verfolgt: mit dem Befehl <start:body?> wird das Ende der Kopfinformation deklariert, der :last <?end body?> im Anschluss an einen Section Break hingegen deklariert den Beginn von spezifischem Seiteninhalt für die letzte Seite. Für unsere ursprüngliche Anforderung: Darstellen einer Kopfzeile mit detaillierten Informationen auf der ersten Seite, Darstellen einer reduzierten Kopfzeile auf den Folgeseiten, Einfügen spezifischer zusammenfassender Informationen nur auf der letzten Seite haben wir nun versucht, beide Formatierungsarten zu kombinieren, sind dabei jedoch an die Grenzen des Zusammenspiels von BI Publisher und Word gestoßen. Bietet Word keine Funktion zur Definition von Inhalt nur für die letzte Seite, so sorgt die Verwendung der BI Publisher Last Page Funktion dafür dass zuvor definierte Kopfinformation auf der letzten Seite nicht angezeigt wird also keine Option die beiden Funktionen zu kombinieren. Letzten Endes entschlossen wir uns bei Fox Mobile für eine einfachere Lösung: auf verschiedene Inhalte der Kopf- und Fußzeile wurde verzichtet, die Kopfzeile zeigt nun auf allen Seiten die volle Information mit Logo, Firmenadresse und Bestellungs- bzw. Rechnungskopfdaten, die Fußzeile enthält nur das Impressum mit den handelsrechtlichen Informationen und ist ebenfalls auf allen Seiten mit gleichem Inhalt präsent. Die restlichen seitenspezifischen Inhalte wie Bestell- bzw. Rechnungsanschrift auf der ersten Seite, Summe, Unterschriften etc. auf der letzten Seite wird durch die BI Publisher Funktionen abgebildet. 6. Bedingte Formatierung und bedingte Inhalte Gerade bei der Erstellung von Dokumenten für externe Zwecke ist es wichtig, bestimmte Inhalte oder Formatierungen abhängig von im Report hinterlegten Steuerelementen darzustellen, oder aber Felder komplett aus- oder einzublenden, wenn bestimmte Informationen enthalten bzw. auch nicht enthalten sind. Im Beispiel der Bestell- und Rechnungsdokumente der Fox Mobile Group spielt dies eine besondere Rolle insofern, da der Organisations-Setup in der E-Business Suite in den Operating Units jeweils mehrere Firmen mit eigenem Firmennamen, Logo, Adresse und handelsrechtlichen Informationen abbildet. Die Auswahl lässt sich erreichen über verschiedene BI Publisher Funktionen:

9 Die IF Funktion, um abhängig vom Ausgangswert oder vom Vorhandensein eines bestimmten Werts Informationen einzublenden. Im Beispiel hier wird ein bestimmter (als ATTXT hinterlegter) Text auf dem Bestelldokument aufgedruckt wenn der Bestellung ein Anhang vom Typ Datei zugehört. Da dieser Anhang mit Hilfe des anfangs beschriebenen Programms neben dem Bestelldokument selbst an den Lieferanten verschickt wird, sollte ein Hinweis auf die Abhängigkeit der beiden (oder mehreren) Dokumenten auf der Bestellung enthalten sein. ATTXT?><?end if?> Die IF Funktion um ein definiertes Datenfeld komplett auszublenden, wenn in der Reportausgabe für dieses kein Wert auftaucht. <?if:iban!=?>iban: IBAN <?end if?> Die Choose Funktion, um abhängig von einem Ausgangswert verschiedene Informationen abzurufen, wie hier im Beispiel abhängig von der die Bestellung auslösenden Firma (in der Reportausgabe CF_PO_BUSINESS_NAME) die Unterschrift auf dem Bestelldokument. Die Otherwise Funktion ermöglicht es, nicht für jeden möglichen Ausgangswert ein entsprechendes Ausgabeformat zu definieren, sondern nur Abweichungen vom Normalverhalten zu hinterlegen. <?choose:?> <?when:cf_po_business_name="fox MOBILE DISTRIBUTION, LLC"?><?call: signature_nwillits?><?end when?> <?when:cf_po_business_name="fox MOBILE DISTRIBUTION, INC."?><?call: signature_nwillits?><?end when?> <?when:cf_po_business_name= FOX MOBILE ENTERTAINMENT, INC."?><?call: signature_nwillits?><?end when?> <?otherwise:?> <?call: signature_hp?> <?end otherwise?><?end choose?> Konditionales Formatieren erlaubt es, die Darstellung in Abhängigkeit von bestimmten Werten oder Inhalten verschieden darzustellen, z.b. um mit Upper Case eine einheitliche Schreibung der Firmennamen zu erreichen oder bestimmte Informationen andersfarbig hervorzuheben. Auf unserem Bestellformular haben wir die Funktion zum Beispiel eingesetzt, um stornierte Mengen anzeigen zu können

10 Die oben angeführten Beispiele (Auswahl von Logo und Unterschrift über Feld CF_PO_Business_Name) zeigen allerdings auch deutlich die Unzulänglichkeiten des verwendeten, bestehenden Reports als Datengrundlage für das Layout. Das Feld CF_PO_BUSINESS_NAME wird mit der dem Report zugrunde liegenden Logik aus dem Company Segment des Charge Account abgeleitet. Einfacher für die Layout-Gestaltung wäre es hier, hätte man den dreistelligen numerischen Wert direkt in den Reportdaten und könnte die Auswahl darüber steuern. 7. Subtemplates Überall wo man in der Vorlage Inhalte aufruft, die an anderer Stelle definiert sind, verwendet man im Grunde Subtemplates und ruft diese über die Call Funktion auf. So wird es ermöglicht, dass die Vorlage im Format des Enddokuments gestaltet werden kann, im Anhang variable Informationen (wie in unserem Beispiel die erforderlichen Unterschriften als Bilddatei) enthält die bei Bedarf aufgerufen werden. BI Publisher bietet außerdem die Möglichkeit, Inhalte die reportübergreifend verwendet werden in getrennten Subtemplates zu verwalten. Wir haben bei der Gestaltung des Bestelldokuments für Fox Mobile auch diesen Ansatz verfolgt und darüber nachgedacht, Firmenlogo, Unterschriften und handelsrechtliche Informationen in einem solchen Subtemplate zu verwalten. Um so ein externes Subtemplate aus der Layoutvorlage aufzurufen, muss das Subtemplate am Beginn der Vorlage in diese importiert werden: <?import:file:///d:\aschlenker\myxml\logo_subcc.rtf?> Dabei können auch Parameter übergeben werden: <?template:logos?> Im Laufe unserer Testversionen mit dem Subtemplate wurde jedoch klar, dass die Verwendung von externen Subtemplates einhergehen muss mit strengen Gestaltungsrichtlinien und Übereinstimmungen in den verwendeten Dokumenten. Es geht nicht einfach nur darum, ein Logo in einer bestimmten Datei abzuspeichern, sondern das Logo muss auch in der Vorlage des Subtemplates in der Größe und an der Stelle definiert werden, die es später in der Reportformatierung einnehmen soll. Schnell passen da Layoutvorlage und Subtemplate nicht mehr zusammen. Da auch die Anforderungen aus den Fachabteilungen (z.b. Debitoren und Kreditoren) an die Gestaltung der Ausgangsdokumente voneinander abwichen, sind wir letzten Endes den weniger komplexen Weg gegangen und halten die notwendigen Firmenlogos in beiden Dokumentenvorlagen vor.

11 Auch der Ansatz die handelsrechtlichen Informationen in einem Subtemplate zu verwalten wurde letzten Endes verworfen. Hintergrund hier ist die Tatsache, dass diese Informationen in unserer Firmenstruktur einer relativ häufigen Änderung unterliegen, und die Erkenntnis dass jegliche Änderung im Layout die Gefahr beinhaltet, dass die mühselig erarbeitete Formatierung zerstört wird. Unsere Lösung für diese Art von Information: zurück zum bewährten Flexfeld, in dem der Endanwender die Daten direkt in der Applikation einpflegt und wo man bei entsprechender Definition der Datenfelder auch das notwendige Format eingehalten wird. Sinnvoll ist die Verwendung von Subtemplates sicher dann, wenn es darum geht, eine einheitliche Gestaltungsvorlage für das interne Reporting vorzugeben, an dieser Stelle werden wir sicher auch bei Fox Mobile noch einmal die Einsatzmöglichkeiten einer zentralen Vorlage mit Logo und Firmeninformationen prüfen. 8. Lokalisierungen und Übersetzungen Ist die Vorlage mit allen Gestaltungselementen und Datenfeldern erst einmal erstellt, dann kann mit Hilfe der Übersetzungsfunktion leicht eine anderssprachige Version der Vorlage generiert werden. Übersetzen kann man mit dieser Funktion jedoch nur die Feldernamen (z.b. Item Description Artikelbeschreibung), nicht den Inhalt der Datenfelder (also hier die Artikelbeschreibung selbst). Eine Funktion, mit der man z.b. interne Reports in Tabellenform leicht mehrsprachig darstellen kann. Bei der Erstellung von externen Dokumenten wie Bestellung oder Rechnung geht es jedoch eher darum, in Abhängigkeit von der versendenden Organisationseinheit oder anderer Faktoren Inhalte und Layout nicht nur anderssprachig, sondern auch in inhaltlichen Varianten darzustellen. Hierzu eignet sich die Möglichkeit, die Vorlage zu lokalisieren und dann als lokalisierte Abart unter der xml Publisher Zuständigkeit im Template zu registrieren. 9. Formatieren in Word Kommen wir an dieser Stelle noch einmal auf die Rolle der Fachabteilung zu sprechen. Sicher ist es nicht ohne weiteres möglich, die Erstellung der Vorlage vollständig der Fachabteilung zu überlassen. Wenn es jedoch gelingt, Mitarbeiter der Fachabteilung rechtzeitig in die Erarbeitung der Vorlagen einzubeziehen, kann man davon nur profitieren. Oft findet sich dort ein Kollege, der mit den MS Office Tools Word und Excel bestens vertraut ist, der so manchen Trick beim Formatieren kennt und Spaß daran hat, die Vorlage zu perfektionieren und in die gewünschte Form zu bringen. Wenn man anfangs ein wenig Mühe in Anleitung und Unterstützung für die Fachabteilung investiert, ist die Lernkurve gewaltig und bald schon kann die Abteilung sich um die Gestaltung der Layout-Vorlagen tatsächlich selbst kümmern. Ständiger Dialog mit der Fachabteilung und eine gemeinsame Überprüfung der Ergebnisse helfen dann zu verhindern, dass in die Vorlage Logik und Informationsbausteine eingearbeitet werden, die besser in variablen Feldern in der Applikation oder in der Datenabfrage abzubilden sind. BI Publisher sollte nicht die Trennlinie zwischen der IT und der Fachabteilung darstellen, sondern zu einer engeren Verbindung beitragen.

12 Zusammenfassung BI Publisher ist ein sinnvolles und hilfreiches Werkzeug beim Reporting aus der Oracle E- Business Suite, auch wenn vielleicht nicht alle Erwartungen so erfüllt werden, wie Oracle sie mit der Produktpräsentation weckt. Der Aufwand ein komplexes, kundenbezogenes Layout zu gestalten ist besonders am Anfang ein nicht zu unterschätzender Faktor, es sollte reichlich Zeit dafür eingeplant werden. Dann allerdings ist die Lernkurve beachtlich, und mit entsprechender Übung lassen sich Datenabfragen schnell mit einem ansprechenden Layout versehen. Es lohnt sich, hier die Fachabteilung rechtzeitig einzubeziehen, damit die Kollegen dort an der Gestaltung des Layouts mitarbeiten können und befähigt werden, spätere Änderungen selbst zu übernehmen. Dennoch macht es Sinn, so wenig wie möglich an solchen Informationen im Layout selbst unterzubringen, die potentiell Änderungen unterliegen. Hier ist es einfacher, auf die bekannten Flexfelder zurückzugreifen, in denen die Fachabteilung Werte pflegen kann ohne direkt auf die Layout-Vorlage zuzugreifen. Eine gute Demonstration des Lerneffekts im Umgang mit BI Publisher ist im besprochenen Beispiel die Gegenüberstellung des Bestellformulars und der Vorlage für die Ausgangsrechnung. Obwohl von Umfang und Komplexität ähnlich, sieht man deutliche Unterschiede, die aus besserer Formatierung aber auch einem sinnvolleren Zusammenspiel von Datenquelle und Layout resultieren: Abb. 1: Layoutvorlage für das Bestellformular

13 Abb. 2: Layoutvorlage für die Ausgangsrechnung Neue Möglichkeiten wecken auch neue Begehrlichkeiten - die Ansprüche der Fachabteilung wachsen und die Änderungswünsche nehmen zu. Um dem von vornherein entgegenzuwirken ist es eine gute Idee, am Anfang der Einführung von BI Publisher eine Gestaltungsrichtlinie für interne und externe Firmendokumente bzw. Reports zu erstellen, und am besten sogar in Form eines oder einiger weniger Subtemplates Gestaltungsvorlagen zur Verfügung zu stellen. Da bei BI Publisher Reports, anders als bei herkömmlichen Reports, Datenquelle und Layout in verschiedenen Tools erstellt werden, stellt das Reporting mit BI Publisher neue Ansprüche an die zugrunde liegenden Datenabfragen. Das erfordert übergreifendes Wissen um Datenabfrage und Layout sowohl beim Programmierer als auch beim Gestalter der Layoutvorlage. Trennung von Datenabfrage und Layout sollte nur in technischer Hinsicht der richtige Begriff sein. Zusätzlich steht mit den Data Templates eine neue und einfache Funktion zur Verfügung, Datenabfragen direkt mit BI Publisher zu integrieren. Kontaktadresse: Annegret Schlenker Telefon: +49(0) Fox Mobile Group Fax: +49(0) Karl-Liebknecht-Str. 5 annegret.schlenker@foxmobile.com D Berlin Internet: