Parameterbeschreibung

Anwendungsbeispiele

In einem EDIFACT- oder IDoc-Dokument können Angaben mit gleicher Bedeutung wahlweise auf Kopfebene oder auf Positionsebene stehen. Eventuell gilt auch ein Defaultwert, wenn weder im Kopf noch in Positionen ein Wert existiert. Dabei gelten die folgenden Regeln.

• Wenn der Wert auf Positionsebene gegeben ist, gilt der in dieser Position. Ein eventuell auf Kopfebene gegebener Wert mit gleicher semantischer Bedeutung wird dann nicht verwendet.

• Wenn der Wert auf Positionsebene fehlt, gilt der semantisch gleichbedeutende Wert auf Kopfebene.

• Wenn auch auf Kopfebene kein Wert gegeben ist, gilt der Defaultwert.

Diese Funktion vermeidet in diesem Fall die Auswertung von Bedingungen oder verzweigte Funktions-Ketten mit goto-Funktionen, indem jeder Dokumenten-Ebene, auf der ein Wert gegeben sein kann, ein bestimmter Level der Map zugeordnet wird. Höherwertige Level verdecken alle niederwertigen Level. Bei Abfrage des Wertes mit der Funktion get value from map(key a, name of map b, delimiter c, item d, [default e], [escape string f]) wird derjenige Wert ohne gesetztes Empty Flag zurückgegeben, der sich im höchsten Level befindet. Wenn alle Level entweder leer sind oder nur Werte mit Empty Flag enthalten, dann ist der zurückgegebene Wert ein String der Länge 0 ("") mit gesetztem Empty Flag.

Die Level sind nicht fest bestimmten Bedeutungen zugeordnet, sondern: Level 2 'schlägt' Level 1, Level 3 'schlägt' Level 2. Einfacher: Das höchste Level gewinnt. Das schwächste ist Level 1, das stärkste ist Level 20.

Level, denen kein Wert (oder das Empty Flag) zugewiesen ist, gelten als nicht vorhanden, bzw. "transparent". Ein niedrigeres Level kann von einem höheren Level verdeckt werden, aber später, wenn das höhere Level ein Empty Flag zugewiesen bekommt, wird der Wert des niedrigeren Levels "sichtbar", einfach weil es keinen gültigen Wert in einem höheren Level gibt. Details werden in der Beschreibung des Vererbungswertes erklärt.

Beispiel 1

Eine Rechnung muss einen Zahlungstermin enthalten. Als Termin der Rechnungsstellung dient der Zeitpunkt, zu dem der Job verarbeitet wird und die Rechnung versendet wird. Die Lieferung enthielt mehrere Teil-Lieferungen. Für die Festlegung des Zahlungstermins wird ein Defaultwert angenommen, das Zahlungsziel kann aber auch für ausgewählte Kunden auf Kopfebene anders festgelegt werden. Zusätzlich können einzelne Teil-Lieferungen einen anderen Zahlungstermin haben.

1) Im Init-Knoten des Profils wird mit der System-Variable VAR_TIMESTAMP durch Addition von 14 Tagen der Defaultwert des Zahlungszieles berechnet und mit der Funktion add to inheritance-map(...) in eine Map unter dem Key a = ZAHLG in Level 1 eingetragen.

2) Aus einer Datenbank-Abfrage wird im Profil bei Bearbeitung des Rechnungskopfes aus der Kundennummer ermittelt, ob für den Kunden ein anderes Zahlungsziel anzuwenden ist. Das berechnete Zieldatum wird mit demselben Key in Level 2 der Map geschrieben, bzw. das Empty Flag gesetzt, falls kein alternatives Datum vorhanden ist.

3) Bei der Berechnung der Summe jeder einzelnen Teil-Lieferung wird ermittelt, ob für diese Teillieferung ein abweichendes Zahlungsziel existiert. Das berechnete Zieldatum wird für jede Teillieferung unter dem selben Key in Level 4 geschrieben, bzw. das Empty Flag gesetzt.

Zu jeder (Teil-)Lieferungs-Summe wird nun der Zahlungstermin aus der Map mit dem Key a = ZAHLG gelesen. Wenn auf Positionsebene (Teillieferung) das Empty Flag gesetzt wurde, ist dieser 'durchsichtig'. Es wird also der allgemeine Termin für den jeweiligen Kunden geliefert, oder, wenn der ebenfalls leer war, der Defaultwert.

Vorteil: Auf Kopfebene muss man nur die Regeln für die Kopfebene implementieren, auf Positionsebene nur die Regeln für die Position implementieren und im Initialisierungsknoten nur den Defaultwert angeben. Das macht die Implementierung verständlicher und einfacher.

Beispiel 2

Ein ORDERS-IDoc definiert auf Kopfebene eine Lieferadresse (Warenempfänger WE) und enthält 12 Positionen. Zwei Positionen haben auf Positionsebene jeweils eine abweichende Lieferadresse (Warenempfänger WE).

1) Beim Verarbeiten der Kopfdaten wird in die Map mit Key WE die auf Kopfebene definierte Adresse in Level 1 geschrieben.

2) Beim Verarbeiten der Positionsdaten wird die auf Positionsebene definierte Lieferadresse ermittelt. Wenn keine auf Positionsebene definiert ist, wird das Empty Flag gesetzt. Der Wert (ob gültige Adresse oder leer) wird mit dem gleichen Key WE in Level 2 geschrieben.

3) Die anschließende Abfrage des Wertes mit Key WE liefert entweder die auf Positionsebene in Level 2 geschriebene Adresse, oder - falls auf Positionsebene keine existiert und deshalb das Empty Flag in Level 2 gesetzt ist - die gültige Adresse aus Level 1.

Da die Map für jeden Key, also für jeden Adressqualifier, einen Vererbungswert mit mehreren Levels speichern kann, kann man diese Logik für alle Adresstypen in der gleichen Map anwenden. Analog dazu kann man eine Datums-Map aufbauen.

Siehe auch

• add to map(key a, value b, name of map c, [skip empty d])

• clear map(name of map a)

• count keys in map(name of map)

• csv-into-map(file a, [mapname b], [keycol(s) c], [csv delim d], [csv encoding e], [clear first f], [ignore caching h], [delim for map i], [startRow j], [endRow k])

• dump map (a,b)

• fill-map-from-fields( map a, prefix b, index c, hidden d )

• get key(s) from map([a,b,c])

• get value from map(key a, name of map b, delimiter c, item d, [default e], [escape string f])

• increase map value(key a, value b, map name c)

• key in map(key a, name of map b)

• remove from map(key a, name of map b)

• select into map(a,b,[param &1 = c], d,e, f,g,h,i,j], delimiter k, map l,m,n,o,p)

• value in map(value a, name of map b)