4 Implementierung openTRANS Implementierung im PPS, Formatierte Anzeige, Stylesheets, PDF-Ausgabe, Fibu-Import, Externer Import
Durchführung geplant für Dezember 2006
Start 30.11.2006
Ende 31.01.2007
 |
abgeschlossen |
 |
erfolgreicher Verlauf |
openTRANS Einführung abgeschlossen
Die Implementation und Integration der Erzeugung der verschiedenen openTRANS-Dokumente im PPS erfolgt unterschiedlich.
Folgende Berichte aus dem Projektverlauf liegen vor:
Es wurde festgelegt, welche Kann-Elemente für Systec sinnvoll sind und unterstützt werden sollen, wobei klar ist, dass alle Muss-Elemente berücksichtigt werden.
Es wurden die Verbindungen zwischen Quelle (PPS.Datei.Feld) und Ziel (openTRANS-Element ) festgelegt. Quelle/Ziel sind vertauschbar, o.g. gilt für den Export der Daten.) Die Zuordnung ist nicht immer 1:1 möglich! Da keine User-Erweiterungen vorgesehen sind, ergab sich auch kein Handlungsbedarf.
Besondere Probleme gab es nicht. Umfang und Struktur von openTrans sind deutlich kleiner und weniger komplex als bei BMEcat.
Dezember 2006
Die Basisarbeiten, auf denen die Erzeugung aller Dokumente aufbauen, sind abgeschlossen, allerdings können sich natürlich noch Änderungen und Erweiterungen durch die zukünftigen Arbeiten ergeben. Die grundsätzliche Integration der Dokumenterzeugung innerhalb des PPS wurde diskutiert und definiert.
Die Erstellung des Dokumenttyps Lieferavis / DISPATCHNOTIFICATION wurde implementiert. Dazu wurde eine neue Eingabemaske innerhalb des PPS erstellt. Die direkte Integration in die bestehende Organisation wurde für nicht so sinnvoll angesehen.
Die Maske ermöglicht die Erfassung zusätzlicher Angaben, insbesondere auch den Transporteur und die Sendungs-Id.
Bei der bisherigen Ablauforganisation im Versand wird als erstes der Lieferschein gedruckt, dieser bildet dann die Grundlage für die Kommissionierung, Verpackung usw. Zum Zeitpunkt der Lieferscheinerstellung fehlen also diverse Informationen über den eigentlichen Versand. Diese werden jetzt nach Abschluss aller Versandvorbereitungen erfasst.
openTRANS sieht keine Felder für Gewicht und Größe einer Sendung vor. Dies scheint aber durchaus eine wichtige Information zu sein, daher wurde definiert diese Daten optional zu erfassen und dann als Zusatz im Feld PACKAGE_TYPE mit auszugeben.
Ansonsten ergibt sich auch die Notwendigkeit, die Information über die Art des Versands von openTrans-Dokumenten zu speichern. Hierzu gibt es eine neue Tabelle, die eine Zuordnung der Informationen zu Adressen macht (Standard-Werte), welche aber im Detail mit der weiteren Zuordnung zu einem Auftrag und zu einer Auftragsposition
übersteuert werden kann.
Gespeichert wird hier u.a. die Art und Weise des Versendens von openTrans-Dokumenten (keine, an Email [Adresse] als XML, XML mit XSL, PDF, PDF als FAX) Diese Zuordnung kann global, aber auch differenziert für die einzelnen Dokumentarten festgelegt werden.
Januar 2007
Die Implementation und Integration der Erzeugung der verschiedenen openTRANS-Dokumente im PPS erfolgt unterschiedlich.
Angebot (QUOTATION): Es wurde lediglich die Erzeugung der entsprechenden Daten ohne besondere Oberfläche gemacht, dies eigentlich nur der Vollständigkeit halber, sieht Systec im Moment keinen Partner, der ein Angebot im Format openTRANS erwartet. Aber Systec könnte es im Bedarfsfall kurzfristig realisieren und werden es auf jedem Fall anbieten.
Angebotsanforderung (RFQ): Dieser Bereich war im PPS bisher praktisch nicht vorhanden. Es wurde eine eigene Maske erstellt, die es erlaubt, sowohl Lieferanten als auch Teile auszuwählen, um daraus Anfragen zu generieren.
Auftrag (ORDER): Hier wurde die Erzeugung von openTRANS-Dokumenten in den bestehenden Prozess integriert. Schon in der Vergangenheit konnte man wählen, ob die Bestellung als Fax, Brief oder PDF für Email erzeugt werden sollte. Hier ist nun als neue Option openTRANS-ORDER hinzugekommen.
Auftragsänderung (ORDERCHANGE): Analog zu Auftrag (ORDER).
Auftragsbestätigung (ORDERRESPONSE): Hier wurde die Erzeugung von openTRANS-Dokumenten in den bestehenden Prozess integriert. In der Vergangenheit konnte man das Druckformat wählen, Druck auf Kopfbogen, inklusive Logo für Normaldruck oder Druck als PDF. Hier ist nun als neue Option openTRANS- ORDERRESPONSE hinzugekommen.
Lieferavis (DISPATCHNOTIFICATION): Dieser Bereich war im PPS bisher nicht vorhanden. Es wurde eine eigene Maske erstellt, da hier noch weitere Daten zu erfassen sind, die dem PPS bisher nicht zur Verfügung stehen (Transporteur, Versanddetails inklusive Pachstück-Id).
Wareneingangsbestätigung (RECEIPTACKNOWLEDGEMENT): Dieser Bereich war im PPS bisher nicht vorhanden. Eine Wareneingangsbestätigung wurde auch im Normalfall nie verschickt, außer an externe Fertiger, da Systec auch von erwartet, ihnen eine solche zu schicken, wenn diese Material erhalten. Die Maske zur Erfassung eingehender Lieferungen wurde um einen Button erweitert, der nach Zugangsbuchung ein openTRANS-Dokument RECEIPTACKNOWLEDGEMENT erzeugt.
Rechnung (INVOICE): Hier wurde die Erzeugung von openTRANS-Dokumenten in den bestehenden Prozess integriert. Ein Bedieneingriff ist nicht möglich, die Erzeugung erfolgt automatisch im Hintergrund. Im Moment wird dies Dokument intern für den Export der Fibu-Daten verwendet. Zukünftig will Systec seinen Kunden anbieten, dass sie zusätzlich zur Originalrechnung auch ein openTRANS-Dokument INVOICE erhalten können. Im Geschäftsverkehr mit Systec ATS wird dies zur Regel werden.
Die Integration in das PPS dauerte doch erheblich länger, als zuvor geplant. Ursprünglich hatte Systec gedacht, dass einfache Einbindungen mit relativ kleinen Erweiterungen ausreichend wären. Es erwies sich aber als notwendig, auch diverse neue Masken zu schaffen, inklusive der damit verbundenen Änderungen der Menüstruktur usw.
Nachdem im Dezember zunächst ein erster Prototyp DISPATCHNOTIFICATION erstellt wurde, wurden jetzt die Stylesheeterstellung im Berichtszeitraum abgeschlossen.
Es wurden Stylesheets erstellt für die openTRANS-Dokumente
• Angebot (QUOTATION)
• Angebotsanforderung (RFQ)
• Auftrag (ORDER)
• Auftragsänderung (ORDERCHANGE)
• Auftragsbestätigung (ORDERRESPONSE)
• Lieferavis (DISPATCHNOTIFICATION)
• Wareneingangsbestätigung (RECEIPTACKNOWLEDGEMENT)
• Rechnung (INVOICE)
Die Stylesheets wurden zunächst in ähnlicher, mehr Tabellenartigen Form erstellt.
Daneben wurde beispielhaft das Stylesheet INVOICE wie die derzeitigen Papierrechnungen gestaltet. Eine endgültige Entscheidung über die Darstellung steht noch aus.
Eine Besonderheit bietet das Stylesheet RFQ: hier wurden vorausgefüllte Formularfelder eingebaut, die es dem Anbieter erlauben, eine Anfrage mit wenigen Mausklicks und Eingaben direkt in ein Angebot zu verwandeln und dies zurückzuschicken. Im Moment erfolgt die Rücksendung des Formulars per eMail, geplant ist aber die Sendung an ein Server-Skript, das dann eine (fast) automatische Datenübernahme in das PPS ermöglicht.
Ein Problem ist das Fehlen einer Kennzeichnung der verwendeten Sprache. Dies betrifft alle openTRANS –Definitionen. Aufgabe der Stylesheets soll sein, dem Nutzer eine direkte, formatierte Aufbereitung der Daten zu bieten. Nutzer sind hier zum einen Systec selbst, zum anderen aber auch deren Geschäftspartner.
Neben dem eigentlichen Inhalt enthält eine solche Darstellung weitere Bestandteile, insbesondere Überschriften und Feldbezeichnungen. Und hier wäre es sehr hilfreich, dies jeweils in der Sprache des Nutzers darzustellen. Und zunächst fehlt eben innerhalb von openTRANS die Möglichkeit zur Angabe der Sprache. (Dies hätte z.B. mit einem optionalen Attribut lang=“..“ im Wurzelelement erfolgen können, oder im jeweiligen Header als optionales Element LANGUAGE analog dem Element PRICE-CURRENCY. )
Allerdings ist das Attribut lang=“..“ laut XML-Spezifikation grundsätzlich bei jedem Element optional möglich, die Verwendung in openTRANS führt jedoch zu Validierungsfehlern gegen die jeweiligen Schemata. Hier muss unbedingt der Namespace xml mit angegeben werden: xml:lang=“..“, dann sollte es gehen, führt aber z.B. bei XMLSpy immer noch zu einem Validierungsfehler.
Außerdem gibt es Probleme mit der Darstellung in verschiedenen Browsern. Getestet wurden die Stylesheets mit InternetExplorer 6 und Firefox. Zum einen ist die Darstellung unterschiedlich, was aber offensichtlich auf die unterschiedliche Darstellung von HTML zurückzuführen ist. Es kommt aber auch zu Fehlermeldungen des XSLT-Parsers, so dass das Dokument überhaupt nicht dargestellt wird. Hier sind noch nicht alle Details gelöst, zunächst wurde sich auf den IE konzentriert, hier laufen jetzt alle Stylesheets.
Es wurden XSLT-Skripte erstellt für die Erzeugung von PDF-Dokumenten zu den openTRANS-Dokumenten
• Angebot (QUOTATION)
• Angebotsanforderung (RFQ)
• Auftrag (ORDER)
• Auftragsänderung (ORDERCHANGE)
• Auftragsbestätigung (ORDERRESPONSE)
• Lieferavis (DISPATCHNOTIFICATION)
• Wareneingangsbestätigung (RECEIPTACKNOWLEDGEMENT)
• Rechnung (INVOICE)
Die XSLT-Skripte transformieren die openTRANS-XML-Daten in das Format XSL-FO, daraus wird dann das PDF-Dokument erzeugt. Verwendet wird hier FOP von Apache, der Aufruf kann von der Kommandozeile, durch eine Batchdatei oder auch durch Aufruf aus anderen Programmen (PPS) erfolgen.
Es gibt natürlich die gleichen Probleme wie bei der Stylesheeterstellung (Sprache). Parallel zur externen Erstellung der XSL(T)-Dateien und in der Diskussion mit unserem Partner konnte Systec selbst Knowhow erwerben, um eigene Stylesheets und Transformationen erstellen zu können oder zumindest die hier entstandenen anzupassen, zu ändern und zu erweitern.
Die Erzeugung der Import-Daten für die Fibu aus den openTRANS-Daten des Dokuments INVOICE ist implementiert und getestet.
Die Daten werden durch ein XSLT-Skript in die erforderliche Form transformiert und als Textdatei gespeichert. Diese wiederum kann von der Fibu importiert werden.
Bei Ausgangsrechnung erfolgt die Erzeugung durch das PPS automatisch im Hintergrund. Bei fremden Eingangsrechnungen müssen die Daten zuvor verifiziert und freigegeben werden.
Die Schnittstelle des Fibu-Imports ist sehr schmal, es werden nur wenige Daten-Felder benötigt.
Ein Nachteil ist, dass zu jedem INVOICE-Dokument nur genau eine separate Datei erstellt werden kann, für den Fibu-Import ist es aber sinnvoll, nur eine Datei für alle Rechungen zu haben.
Ein echtes Problem ist, dass die Fibu bei mehrfachem Import gleicher Daten keine Fehlermeldung ausgibt. Es ist also anderweitig sicher zustellen, dass Daten nur einmal importiert werden können. Genauso muss sichergestellt werden, dass Daten versehentlich gar nicht importiert werden.
Es muss also der gesamte Prozess genau definiert und möglichst auch automatisiert werden. Dies wird aber nicht mehr Bestandteil dieses Projekts sein, hier wurde nur ein mögliches Verfahren entwickelt.
Da die Import-Schnittstelle sehr schmal war, ging die Erzeugung der notwendigen Daten recht zügig. Hinzu kam aber die Notwendigkeit der Definition des gesamten Prozesses Fibu-Import. Dennoch konnte dieses Arbeitspaket fast noch im Soll-Rahmen fertig gestellt werden.
Genutzt werden in diesem Zusammenhang:
• Anfrage (RFQ)
• Lieferavis (DISPATCHNOTIFICATION)
• Wareneingangsbestätigung (RECEIPTACKNOWLEDGEMENT)
Die Dokumente werden per Email versendet.
Wie erwartet, erhält Systec von seinen Partnerfirmen keinerlei Dokumente im openTRANS-Format. Systec steht allerdings hier auch noch am Anfang, bisher haben nur erste Informationen stattgefunden.
Vielleicht können die Firmen auf Dauer von den Vorteilen auch für sie überzeugt werden. Dazu wird Systec auch Hilfestellungen und Unterstützung geben. So werden den Partnern XSLT-Skripte zur Verfügung gestellt, die die Daten in eine „flache“ Form bringen, von der sie leicht in andere Programme importierbar sind, im einfachsten Falle können sie einfach mit Excel geöffnet werden. In anderen Programmen gibt es Befehle wie XMLTOCURSOR, die solche Daten mit einem Einzeilenbefehl in ein entsprechendes Datenformat einlesen.
Diese Skripte können und sollen als Vorlage dienen, sie können leicht bearbeitet werden, es können alle nicht relevanten Elemente unterdrückt werden, Feldnamen können den eigenen angepasst werden, Felder können kombiniert werden zu neuen Feldern usw. Dies alles ist auch ohne detaillierte XML- und XSL-Kenntnisse möglich, auch wird keine Software benötigt bis auf einen XSLT-Parser. Die aber gibt es kostenfrei, z.B. SAXON. Am einfachsten jedoch kann die Transformation z.B. mit dem Programm MSXSL.EXE (kostenlos bei Microsoft im Download).
Unter der realistischen Einschätzung, dass von Außen wenig openTRANS-Dokumente kommen werden, ist es durchaus sinnvoll, sich auf die folgenden Dokumente zu beschränken:
• Lieferavis (DISPATCHNOTIFICATION) und
• Rechnung (INVOICE)
Angebot (QUOTATION), Angebotsanforderung (RFQ), Auftrag (ORDER), Auftragsänderung (ORDERCHANGE), Wareneingangsbestätigung (RECEIPTACKNOWLEDGEMENT) oder Auftragsbestätigung (ORDERRESPONSE) bleiben zunächst unberücksichtigt.
Der Import von Rechnungen betrifft nur die Fibu und ist bereits erledigt. Allerdings muss hier eine Verifizierung durch einen Mitarbeiter stattfinden. Auch fehlen auf fremden Rechnungen eigene Kontierungen, sie müssen mit eingefügt werden. Eine vollständige Automatisierung ist hier auch auf Dauer ausgeschlossen.
Auch Lieferavis von fremden Partnern können nicht ohne Verifizierung auch zusammen mit Änderungen (bei abweichenden Mengen / Preisen) übernommen werden. Möglich und beispielhaft realisiert ist aber der Import bei der Schwesterfirma Systec ATS, aber auch hier nur unter Bedienereingriff. So muss z.B. das Lieferdatum angepasst werden, für den Lieferant ist es ja der Warenausgang, hier wird aber der Wareneinganstermin benötigt.
Ein weiteres Problem liegt in der Preisdarstellung. Bestellungen beinhalten jeweils den Einzelpreis, die Preiseinheit und den Rabatt. Für letzteren gibt es in openTRANS keine Entsprechung.
