<\/p>\n
Sie erweitern die Artikelverwaltung um Funktionen zur Eingabe von Bestellungen und zum Drucken von Bestellscheinen.<\/p>\n
Access, Abfragen, 1:1-Beziehungen, Formulare, Unterformulare, Berichte, VBA<\/p>\n
Access 2000 oder höher<\/p>\n
André Minhorst, Duisburg<\/b><\/p>\n
In den vorherigen beiden Ausgaben haben Sie die Artikelverwaltung kennen gelernt, mit der Sie Artikel und Inventurdaten verwalten können. Damit haben Sie bereits die Voraussetzungen für die Musterlösung dieses Beitrags geschaffen – für die Bestellverwaltung. Damit können Sie Bestellungen eingeben und Bestellscheine drucken.<\/b><\/p>\n
Die Bestellverwaltung schlägt die Brücke zwischen der Artikelverwaltung und den im Beitrag Kunden und Kontakte verwalten (Ausgabe 4\/2005, Shortlink 293) vorgestellten Funktionen. Die Bestellverwaltung bietet folgende Erweiterungen:<\/p>\n
Das Formular bietet die Möglichkeit, Bestellungen einzugeben und zu bearbeiten. Dazu ist das Auswählen eines Kunden und dessen Liefer- und Rechnungsanschrift sowie die Eingabe beliebig vieler Positionen möglich.<\/p>\n
Zu jeder Position lässt sich ein individueller, vom ursprünglichen Preis abweichender Preis festlegen.<\/p>\n
Der Bericht gibt einen Bestellschein mit Bestell- und Lieferdatum, den Anschriften für Rechnung und Lieferung sowie die einzelnen Positionen aus.<\/p>\n
Alle Tabellen der Bestellverwaltung sind bereits in der Artikelverwaltung enthalten – wenn Sie die Bestellverwaltung „nachbasteln“ möchten, brauchen Sie zumindest keine neuen Tabellen hinzuzufügen.<\/p>\n
Bild 1 zeigt den Ausschnitt des Datenmodells, der für die Bestellverwaltung interessant ist.<\/p>\n
Betrachten Sie das abgebildete Datenmodell im Uhrzeigersinn: Die Tabelle tblArtikel enthält Informationen über die Artikel, wobei im Folgenden vor allem die Felder Bezeichnung, EinheitID, Mehrwertsteuersatz und Verkaufspreis eine Rolle spielen werden. Hinter dem Feld EinheitID verbirgt sich noch eine Lookup-Tabelle, die aber hier aus Platzgründen nicht abgebildet ist.<\/p>\n
Dann folgen zwei Tabellen namens tblBestandsaenderungen und tblPositionen. Die beiden Tabellen sind per 1:1-Beziehung miteinander verknüpft und enthalten die Informationen, die in der Nordwind-Datenbank durch die Tabelle Bestelldetails abgebildet werden. Hier sind die Informationen auf zwei Tabellen verteilt, weil ein Bestelldetail auch immer eine Bestandsänderung verursacht und diese in der Datenbank in einer eigenen Tabelle gespeichert wird – etwa um leicht Inventuren durchführen zu können.<\/p>\n
![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic001.png\")
<\/p>\n
<\/b><\/p>\n
Bild 1: Datenmodell der Bestellverwaltung<\/span><\/b><\/p>\n Prinzipiell können Sie diese beiden Tabellen aber wie eine einzige behandeln – was in der Anwendung durch den Einsatz einer entsprechenden Abfrage auch geschieht.<\/p>\n Am anderen Ende dieser beiden Tabellen hängt die Tabelle tblBestellungen – sie enthält die Informationen der Bestellung selbst, also den Kunden, das Bestell- und Lieferdatum und die Liefer- und Rechnungsadresse des Kunden.<\/p>\n Wenn man den Zusammenhang zwischen diesen vier Tabellen (oder drei, wenn man die mittleren beiden als eine betrachtet) verstanden hat, steht der Programmierung einer Bestellverwaltung nichts mehr im Wege: Die mittleren beiden Tabellen sind nicht mehr und nicht weniger als die Verknüpfungstabellen einer m:n-Beziehung zwischen den Tabellen tblArtikel und tblBestellungen. Damit kann man jeder Bestellung jeden Artikel zuweisen und legt dabei in den Tabellen tblBestandsaenderungen und tblPositionen fest, welche Anzahl des Artikels die Bestellung enthält und wie der Preis und die Mehrwertsteuer für diese Bestellung lauten.<\/p>\n Warum nun soll der Preis in den Bestelldetails nochmals auftauchen, obwohl dieser doch schon in den Artikeldaten enthalten ist Ganz einfach: Weil das der einzige Weg ist, um einen Artikel auch einmal zu einem anderen Preis zu verkaufen, und vor allem, um sicherzustellen, dass bei einer Preisänderung eines Artikels die Werte aller bereits aufgenommenen Bestellungen automatisch geändert werden.<\/p>\n Das Gleiche gilt für die Mehrwertsteuer: Wenn sich diese einmal ändert, soll sich das natürlich nicht rückwirkend auf alle bereits vorhandenen Bestellungen auswirken. Deshalb werden diese Daten separat in den Bestelldetails gesichert.<\/p>\n Jede Bestellung ist genau einem Kunden zugeordnet. Jeder Kunde kann aber eine oder mehrerer Liefer- und Rechnungsadressen besitzen.<\/p>\n Daher werden in der Tabelle tblBestellungen nicht nur die KundenID, sondern auch noch die ID der Bestelladresse und der Lieferadresse für diese Bestellung eingetragen.<\/p>\n Auf diese Weise lässt sich später genau nachvollziehen, wohin Bestellung und Rechnung gegangen sind.<\/p>\n Und wenn der Kunde einmal umzieht, legt man einfach je einen neuen Datensatz in den Tabellen tblLieferadresse und tblRechnungsadresse an – dann bleiben trotz weiterer Bestellungen die bestehenden Bestellungen unberührt.<\/p>\n Warum die Tabellen mit den Adressdaten in der Art aufgeteilt sind, wie es das Datenmodell darstellt, erfahren Sie im Beitrag Kunden und Kontakte verwalten (Shortlink 293).<\/p>\n Für den gesamten unteren Zweig des Datenmodells aus Bild 1 ist die Erweiterung der Artikelverwaltung aus dem oben genannten Beitrag verantwortlich.<\/p>\n Die Pflege der Artikel wurde bereits in den beiden Beiträgen Artikelverwaltung mit Inventurfunktion, Teil 1 (Heft 2\/2005, Shortlink 273) und Teil 2 (Heft 3\/2005, Shortlink 281) beschrieben.<\/p>\n Bleiben noch die Tabellen tblBestellungen, tblPositionen und tblBestandsaenderungen. <\/p>\n Die Pflege dieser Daten ist identisch mit dem Anlegen von Bestellungen und kann in einem einzigen Formular samt Unterformular abgewickelt werden.<\/p>\n Hauptformular<\/b><\/p>\n Das Hauptformular hat als Datenherkunft die Tabelle tblBestellungen. Damit der obere Teil des Formulars so wie in Bild 2 aussieht, ziehen Sie einfach die fünf dargestellten Felder aus der Feldliste in die Entwurfsansicht des Formulars.<\/p>\n <\/b><\/p>\n Bild 2: Das Bestellformular mit Unterformular in der Entwurfsansicht<\/span><\/b><\/p>\n Die drei Kombinationsfelder erfordern noch ein wenig Nacharbeit. Das erste dient der Auswahl des Kunden und soll den Kunden wie in Bild 3 anzeigen. Dazu stellen Sie die Datensatzherkunft des Kombinationsfeldes wie folgt ein:<\/p>\n Mit diesem Ausdruck sorgen Sie dafür, dass das Komma zwischen Nach- und Vorname nur angezeigt wird, wenn auch beide Felder gefüllt sind.<\/p>\n <\/b><\/p>\n Bild 3: Auswahl von Kunden<\/span><\/b><\/p>\n Die übrigen beiden Kombinationsfelder zur Anzeige von Lieferadressen und Rechnungsadressen sollen bei der Auswahl möglichst viele Daten anzeigen, damit man die richtige Adresse auswählen kann.<\/p>\n Das aufgeklappte Kombinationsfeld soll daher wie in Bild 4 aussehen. Nachname, Vorname und Firma sind dabei platzsparend zusammengefasst und werden auch in eingeklapptem Zustand angezeigt; die übrigen Daten sind in weiteren Feldern enthalten.<\/p>\n <\/p>\n <\/b><\/p>\n Bild 4: Auswahl einer Rechnungsadresse<\/span><\/b><\/p>\n Die Datensatzherkunft des Kombinationsfeldes basiert in diesem Fall auf einer Abfrage, die beim öffnen und Aktualisieren des Formulars zugewiesen wird. Die Abfrage fasst die beiden per 1:1-Beziehung verknüpften Tabellen tblAdressen und tblRechnungsadressen zusammen und erzeugt außerdem den in Bild 4 erkennbaren Ausdruck <Nachname>, <Vorname> (<Firma>). Die dazu notwendige Funktion ist in Bild 5 nicht zu erkennen und daher nachfolgend separat aufgeführt:<\/p>\n <\/b><\/p>\n Bild 5: Datensatzherkunft des Kombinationsfeldes cboRechnungsadressen<\/span><\/b><\/p>\n Das Kombinationsfeld zur Auswahl der Lieferadressen ist genauso aufgebaut wie das zur Auswahl der Rechnungsadressen und soll daher nicht gesondert erläutert werden.<\/p>\n Die beiden Kombinationsfelder zur Anzeige von Liefer- und Rechnungsadresse sind von der Auswahl des Kunden im oberen Kombinationsfeld des Formulars abhängig. <\/p>\n Sie sollen jeweils alle Liefer- und Rechnungsadressen zu dem oben ausgewählten Kunden zur Auswahl anbieten.<\/p>\n Das bedeutet, dass mit jeder neuen Auswahl im Kombinationsfeld KundeID auch die Datensatzherkunft der beiden Kombinationsfelder LieferadresseID und RechnungsadresseID aktualisiert werden muss.<\/p>\n Um dies zu realisieren, gibt es zwei Möglichkeiten:<\/p>\n Die zweite Variante hat den Vorteil, dass sie eine Abhängigkeit weniger beinhaltet: Das Formular ist von der Datensatzherkunft abhängig, aber nicht umgekehrt. Die erste Abhängigkeit enthält eine zusätzliche Abhängigkeit zwischen der Abfrage und dem Formular – nämlich das Kriterium der Abfrage.<\/p>\n Um mit der zweiten Lösung zum Ziel zu kommen, benötigen Sie ein wenig VBA-Code (s. Quellcode 1).<\/p>\n Die Ereignisprozedur Nach Aktualisierung des Kombinationsfeldes KundeID ruft die Prozedur AdressenAktualisieren auf.<\/p>\n Diese Prozedur weist den Datensatzherkünften der Kombinationsfelder LieferadresseID und RechnungsadresseID die jeweils mit der aktuellen Kunden-ID als Kriterium versehene Abfrage zu und aktualisiert die Kombinationsfelder.<\/p>\n Diese paar Zeilen Code befinden sich in einer eigenen Prozedur, weil die Funktion noch von einer anderen Stelle aus aufgerufen werden soll.<\/p>\n Der zweite Anlass zum Aktualisieren der Datensatzherkunft dieser beiden Kombinationsfelder ist die Anzeige einer neuen Bestellung, die unter Umständen für einen anderen Kunden bestimmt sein kann.<\/p>\n Quellcode 1: Aktualisierung der Kombinationsfelder zur Auswahl von Liefer- und Rechnungsadressen<\/b><\/p>\n Beim Wechseln des Datensatzes wird immer das Ereignis Beim Anzeigen ausgelöst. Quellcode 2 zeigt, was dort passiert: Zunächst wertet die Prozedur Form_Current das öffnungsargument des Formulars aus. Beim Anlegen einer neuen Bestellung kann man direkt den Kunden übergeben, um dem Benutzer unnötige Arbeit zu ersparen.<\/p>\n Der folgende Aufruf würde das Formular direkt mit dem Kunden Nummer 10 öffnen und einen neuen, leeren Datensatz anzeigen:<\/p>\n Damit die beiden Kombinationsfelder direkt die richtigen Rechnungs- und Lieferadressen zur Auswahl anbieten, ruft auch diese Routine die Prozedur AdressenAktualisieren auf.<\/p>\n Schließlich kontrolliert eine If…Then-Verzweigung, ob das Formular einen neuen und noch nicht geänderten Datensatz enthält. Falls der Datensatz neu ist, wird das Unterformular gesperrt.<\/p>\n Es wird erst freigegeben, wenn im Hauptformular ein neuer Datensatz angelegt wurde – ansonsten könnte man im Unterformular Datensätze anlegen, ohne dass es einen entsprechenden Datensatz im Hauptformular gibt – was dafür sorgen würde, dass dieser Datensatz zwar in den Tabellen tblBestandsaenderungen und tblPositionen auftaucht, aber mangels korrespondierendem Datensatz in der Tabelle tblBestellungen nie wieder im Formular frmBestellungen sichtbar würde.<\/p>\n Wenn ein neuer Datensatz schließlich „beschmutzt“ wird, also die Eigenschaft Dirty den Wert True bekommt, löst dies auch das Ereignis Bei änderung aus. Quellcode 3 enthält die dadurch gestartete Prozedur, die für die Freigabe des Unterformulars sorgt.<\/p>\n Quellcode 2: Anzeigen eines Datensatzes<\/b><\/p>\n Quellcode 3: Aktivieren des Unterformulars bei geändertem Datensatz<\/b><\/p>\n Neben den Bestelldaten gehören zu einer Bestellung natürlich auch noch die Bestellpositionen. Diese werden in einem Unterformular verwaltet. Als Datenherkunft für das Unterformular dient die Abfrage qryWarenausgang. Die Abfrage fasst die beiden per 1:1-Beziehung verknüpften Tabellen tblBestandsaenderungen und tblPositionen zusammen.<\/p>\n <\/b><\/p>\n Bild 6: Datenherkunft des Unterformulars frmPositionen<\/span><\/b><\/p>\n Quellcode 4: Vorbelegen der Mehrwertsteuer und des Einkaufspreises einer Bestellposition<\/b><\/p>\n Das Formular enthält die folgenden Felder der Abfrage: ArtikelID, Anzahl, Mehrwert, Verkaufspreis, BestellungID und Vorzeichen. Die letzten beiden sind dabei nicht sichtbar, sie dienen lediglich dem Herstellen der Verknüpfung zum Hauptformular beziehungsweise zum Einstellen des Feldes Vorzeichen.<\/p>\n Der Grund dafür ist, dass die Tabelle tblBestandsaenderungen sowohl Wareneingänge als auch Warenausgänge (also bestellte Artikel) enthält und die beiden betragsmäßig irgendwie voneinander getrennt werden müssen.<\/p>\n <\/b><\/p>\n Bild 7: Das Unterformular und dessen Eigenschaften<\/span><\/b><\/p>\n Und damit nicht in jeder Bestellposition eine auf den ersten Blick nicht nachvollziehbare negative Anzahl an Artikeln erscheint, speichert man das Vorzeichen in einem separaten Feld und holt es nur für die Ermittlung des Lagerbestandes hervor.<\/p>\n Die Anordnung der sichtbaren Steuerelemente geht aus Bild 7 hervor; die nicht sichtbaren Steuerelemente sind hinter den übrigen Steuerelementen verborgen.<\/p>\n Wie bereits weiter oben erwähnt, besitzt jede Position ein eigenes Feld für Mehrwertsteuer und Verkaufspreis. Diese Felder werden durch die Prozedur aus Quellcode 4 vorbelegt.<\/p>\n Die Daten für die jeweiligen Artikel ermittelt die Prozedur per DLookup-Funktion aus der Artikel-Tabelle.<\/p>\n Zu guter Letzt müssen Sie nur noch das Formular frmPositionen in das Formular frmBestellungen einbauen und dafür Sorge tragen, dass die beiden Formulare ordnungsgemäß miteinander verknüpft sind.<\/p>\n Wenn die Eigenschaften des Unterformularsteuerelements wie in Bild 8 aussehen, haben Sie alles richtig gemacht und Sie können Bestellungen wie eingangs beschrieben anlegen.<\/p>\n Die Bestellungen wollen natürlich auch zusammengestellt und versendet werden – ganz abgesehen von der Rechnungsstellung. Letzteres ist freilich ein anderes Thema und wird in einem zukünftigen Beitrag behandelt.<\/p>\n <\/b><\/p>\n Bild 8: Verknüpfung zwischen Haupt- und Unterformular<\/span><\/b><\/p>\n Die Lösung dieses Beitrags soll zunächst einmal einen Bestellschein als Bericht ausgeben, mit dem die Bestellung zusammengestellt werden kann.<\/p>\n <\/b><\/p>\n Bild 9: Datenmodell des Berichts rptBestellscheine<\/span><\/b><\/p>\n Der Bericht soll Daten aus einer ganzen Reihe von Tabellen enthalten. Dementsprechend sieht das Datenmodell aus Bild 9 auch relativ wüst aus.<\/p>\n Da die benötigten Felder bei weitem nicht auf eine Bildschirmseite passen, finden Sie die entscheidenden Felder der beteiligten Tabellen in der Abbildung rot eingerahmt vor. Beachtung ist der Definition der Abfrage bezüglich der Liefer- und Rechnungsadressen zu schenken: Beide beziehen die zu druckenden Daten aus der Tabelle tblAdressen, aber welcher Datensatz daraus verwendet wird, entscheiden die Felder LieferdresseID und RechnungsadresseID der Tabelle tblBestellungen. Eine kleine Faustregel in Access heißt: Wenn die Werte derselben Tabelle in mehreren Zusammenhängen in der gleichen Abfrage verwendet werden, dann fügen Sie für jeden Fall eine neue Kopie der Tabelle in den Entwurf ein.<\/p>\n Dementsprechend gibt es in der Abfrage zweimal die Tabelle tblAdressen – einmal mit dem Originalnamen und einmal als tblAdressen_1. Weitere Tabellen würden übrigens fortlaufend durchnummeriert. Desgleichen hängt an diesen beiden Tabellen auch je eine eigene Kopie der Tabelle tblAnreden.<\/p>\n Der Bericht rptBestellschein verwendet die oben beschriebene Abfrage als Datenherkunft. Im Gegensatz zum Formular frmBestellungen ist hier kein Unterbericht notwendig, um die Positionen zu einer Bestellung aufzulisten. Berichte bringen die segensreiche Erfindung der Gruppierung mit sich. Dadurch kann man – ohne sich Gedanken um redundant angezeigte Daten zu machen – einfach alle Daten in eine Abfrage werfen. Das Abfrageergebnis erhält dann zwar für eine Bestellung mit zehn Position zehnmal die gleichen Daten für Felder wie BestellungID, Bestelldatum, Lieferdatum und auch für die Rechnungs- und die Lieferanschrift, aber durch geschickte Gruppierung zeigt man die redundanten Daten einfach nur einmal im jeweiligen Gruppierungskopf oder -fuß an. Genau so gehen Sie bei der Erstellung des Berichts auch vor.<\/p>\n Nachdem Sie die Datenherkunft eingestellt haben, fügen Sie dem Bericht zunächst einmal die gewünschte Gruppierung hinzu. Diese soll die Datensätze nach dem Wert des Feldes BestellungID gruppieren.<\/p>\n Aktivieren Sie einfach den Dialog Sortieren und Gruppieren und fügen Sie als Gruppierung das Feld BestellungID hinzu. Damit die Gruppierung im Bericht einen Bereich erhält, der die allgemeinen Informationen wie die Bestelldaten und die Anschriften aufnehmen kann, stellen Sie die Eigenschaft Gruppenkopf der Gruppierung auf den Wert Ja ein (siehe Bild 10).<\/p>\n Nun müssen Sie nur noch die Steuerelemente in die richtigen Bereiche des Berichts einfügen und diese verschönern. Anschließend sieht die Entwurfsansicht des Berichts beispielsweise so wie in Bild 11 aus. Die Felder Anrede, Vorname und Nachname werden für die Bestell- und die Lieferanschrift jeweils zusammengefasst. Der Ausdruck des Textfeldes txtNameLieferanschrift lautet folgendermaßen:<\/p>\n <\/b><\/p>\nDer doppelte Preis<\/h3>\n
Bestellungen und Kunden<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic002.png\")
<\/p>\nSELECT tblKunden.KundeID, [Nachname] & IIf(Not IsNull([Nachname]) And Not IsNull([Vorname]),\", \",\"\")
\r\n& [Vorname] AS Kunde FROM tblKunden;<\/pre>\n![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic003.png\")
<\/p>\nLiefer- und Rechnungsadressen anzeigen<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic004.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic005.png\")
<\/p>\nLieferadresse: [Nachname] & Wenn(Nicht IstNull([Nachname]) Und Nicht IstNull([Vorname]);\", \";\"\")
\r\n& [Vorname] & Wenn(Nicht IstNull([Firma]);\" (\";\"\") & [Firma] & Wenn(Nicht IstNull([Firma]);\")\";\"\")<\/pre>\nLieferadressen<\/h3>\n
Abhängigkeit der Kombinationsfelder<\/h3>\n
Private Sub KundeID_AfterUpdate()\r\n AdressenAktualisieren\r\nEnd Sub\r\nPrivate Sub AdressenAktualisieren()\r\n Me.LieferadresseID.RowSource = \"SELECT * FROM qryLieferadressen WHERE KundeID = \" & Me.KundeID\r\n Me.LieferadresseID.Requery\r\n Me.RechnungsadresseID.RowSource = \"SELECT * FROM qryRechnungsadressen WHERE KundeID = \" _ & Me.KundeID\r\n Me.RechnungsadresseID.Requery\r\nEnd Sub<\/pre>\n
DoCmd.OpenForm \"frmBestellungen\", _ DataMode:=acFormAdd, OpenArgs:=2860<\/pre>\n
Private Sub Form_Current()\r\n If Not Nz(Me.OpenArgs, \"\") = \"\" Then\r\n Me.KundeID = Me.OpenArgs\r\n End If\r\n AdressenAktualisieren\r\n If Me.NewRecord And Not Me.Dirty Then\r\n Me.frmPositionen.Enabled = False\r\n Me.frmPositionen.Locked = True\r\n Else\r\n Me.frmPositionen.Enabled = True\r\n Me.frmPositionen.Locked = False\r\n End If\r\nEnd Sub\r\n<\/pre>\n
Private Sub Form_Dirty(Cancel As Integer)\r\n If Me.NewRecord Then\r\n Me.frmPositionen.Enabled = True\r\n Me.frmPositionen.Locked = False\r\n End If\r\nEnd Sub\r\n<\/pre>\n
![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic006.png\")
<\/p>\nPrivate Sub ArtikelID_AfterUpdate()\r\n Me.Mehrwertsteuer = DLookup(\"Mehrwertsteuersatz\", _ \"tblArtikel\", \"ArtikelID = \" & Me.ArtikelID)\r\n Me.Verkaufspreis = DLookup(\"Verkaufspreis\", _ \"tblArtikel\", \"ArtikelID = \" & Me.ArtikelID)\r\n Me!Datum = Me.Parent.Lieferdatum\r\nEnd Sub<\/pre>\n
![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic007.png\")
<\/p>\nMehrwertsteuer und Verkaufspreis einstellen<\/h3>\n
Bestellungen und Positionen zusammenführen<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic008.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic009.png\")
<\/p>\nErstellen des Berichts<\/h3>\n
=Wenn([tblAnreden.Anrede]=\"Herr\";\"Herrn \";\"Frau \") & [tblAdressen.Vorname] & \" \" & [tblAdressen.Nachname]<\/pre>\n
![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic010.png\")
<\/p>\n
![](\"..\/fileadmin\/_temp_\/{60437684-04EE-4736-BB32-D1C5BC4C28B2}\/pic011.png\")
<\/p>\n