Validation-Content herunterladen
Der Validation-Content kann von der Webseite https://www.next-level-help.org aus dem Bereich “Direct Support” heruntergeladen werden. Die detaillierte Beschreibung findet sich unter Download von Content-ABOs.
Nomenklatur der Version
Release-Notes
Die Änderungen in den Releases werden in Release-Notes festgehalten. Die Release-Notes sind auch im Direct Support zu finden, unter “Content ABO GPKE/GELI”, oder über diesen Direktlink: Content ABO GPKE/GELI
Einstellungsmöglichkeiten
Die hier aufgelisteten Einstellungen sind für den Validation-Content relevant. Sie werden für die ValidatorAction und für den EdiEditor benötigt.
Die Einstellungen sind mit Context überschreiben
einzustellen.
Verstellen der Werte kann zu einer „zu lockeren“ Validierung führen.
Default-Werte sind fett dargestellt.
ActionProperty / Eigenschaften & Wert | Beschreibung | |
---|---|---|
VALIDATION_APERAK_AFTER_POSITIVE_CONTRL | ||
true, false | Diese Eigenschaft läuft in Verbindung zur FORCE_POSITIVE_CONTRL und aktiviert die APERAK Prüfung nach der erzwungenen pos. CONTRL. Default = true. | |
VALIDATION_APERAK_AHB_CONDITIONS | ||
true, false | Schaltet die Bedingungen für die AHBs ein oder aus. Standardmäßig ist die Eigenschaft aktiviert. | |
VALIDATION_APERAK_STRICT | ||
true, false | Einschränkungen der Werte durchs AHB werden/werden nicht geprüft. Standartmäßig ist die Einstellung deaktiviert. | |
VALIDATION_CHECK_APPLY_MIG_REGISTRICTIONS_FOR_NUMERICAL_FIELDS | ||
true, false | Standardmäßig ist diese Einstellung aktiviert. | |
VALIDATION_CHECK_ARTICLE_NUMBERS | ||
deprecated | ||
VALIDATION_CHECK_ARTICLE_NUMBERS_APERAK | ||
deprecated | diese Eigenscfat hat auf Validierung der Artikelnummern ab INVOIC 2.7a, Codeliste der Artikelnummern des BDEW 5.0 bzw. dem 1.10.2021 keine Auswirkungen mehr, da der Hinweis nur erlaubte Nummern zu verwenden durch die Bedingung 40 ersetzet wurde. Siehe auch EDI-449 | |
NONSTRICT | Artikelnummern werden auf Existenz geprüft und ob der vorliegende Prüfi für diese Artikelnummer zugelassen ist sowie ob alle zugehörigen Begleitwerte vorliegen. Sind zu einer Artikelnummer keine Prüfis erlaubt, wird dies als implizite Erlaubnis für alle Prüfis interpretiert (altes Verhalten) | |
NONE | keine Prüfung auf APERAK Ebene (also kein Test “Artikelnummer für Prüfi erlaubt” und kein “benötigte sekundäre Werte(QTY+) gegeben”) | |
STRICT | Artikelnummern werden auf Existenz geprüft und ob der vorliegende Prüfi für diese Artikelnummer zugelassen ist sowie ob alle zugehörigen Begleitwerte vorliegen. Ist bei einer Artikelnummer kein Prüfi erlaubt, werden diese Artikelnummer abgelehnt. | |
Verwendung der Sonderentwicklung REJECT_EXPIRING_ARTNR_FOR_NOT_MEMI |
Diese dient dazu für nicht Memi Nachrichten die auslaufende Artikelnummer abzulehnen. Standardmäßig wird diese Eigenschaft nicht verwendet (Default: false) und führt zu keiner Veränderung der oben beschriebenen Funktionalität. Wird sie aber eingeschaltet (Wert: true) verändert sich die Verhaltensweise bei NONSTRICT. Während bei NONE noch immer keine Prüfung durchgeführt wird und bei STRICT alles, was nicht genau so beschrieben ist, abgelehnt wird, Kommt es bei NONSTRICT zu einer Verhaltensänderung. Bei NONSTRICT dürfte die auslaufende Artikelnummer für jeden Prüfi verwendet werden, da hier keine angegeben sind-> erlaubt für alle. Stattdessen ist die auslaufende Nummer nr für die Memi Prüfis (31005. 31006, 31007, 31008) erlaubt. Bei allen anderen kommt es zu einer Ablehnung. | |
VALIDATION_CHECK_ARTICLE_NUMBERS_CONTRL | ||
true, false | Aktiviert den Check für die BDEW-Artikelnummerliste. Ist die Eigenschaft auf false gesetzt, werden Artikelnummen auf CONTRL Ebene nicht geprüft (keine Prüfung auf Existenz). Bei true, werden Artikelnummern auf CONTRL Ebene auf Existenz geprüft vorausgesetzt sie stehen im ArtikelNummern Dokument. Ist die “alte” Eigenschaft VALIDTION_CHECK_ARTICLE_NUMBERS und diese gesetzt, wird die die Eigenschaft VALIDATION_CHECK_ARTICLE_NUMBERS_CONTRL verwendet. | |
VALIDATION_CHECK_TIMEZONE | ||
wird ab dem 1.4.2022 nicht mehr unterstützt und wirkungslos, Zeitzonenprüfungen werden auf APERAK Ebene ausgelagert z.B. in UB1 bis UB3 | siehe auch Allgemeine Festlegungen | |
verfügbar ab dem VC Mai Release in einer B2B vom Mai | siehe auch Allgemeinen Festlegungen 4.6a 1.20 | |
|
keine zusätzliche Prüfung von DTMs | |
Europe/Berlin | Für DTMs, die explizit eine Zeitzone definieren, wird auf CONTRL Ebene gefordert, dass diese der deutschen Zeitzone entsprichen. Ein DTM+???:datum?+03:303’ wird als immer per CONTRL abgelehnt (in der deutschen Zeitzone gibt es kein Datum mit einer Abweichung von 3 Stunden zu UTC). Ein DTM+163:202108011100?+02:303’ wird angenommen, weil am 1.8.2021 in Deutschland MESZ gilt (mit einer Differnz von 2 Stunden zu UTC). | |
<andere Zeitzone> | Für DTMs, die explizit eine Zeitzone definieren, wird auf CONTRL Ebene gefordert, dass diese der angegebenen Zeitzone entsprichen. Ein DTM+???:datum?+03:303’ wird als immer per CONTRL abgelehnt (in der deutschen Zeitzone gibt es kein Datum mit einer Abweichung von 3 Stunden zu UTC). Ein DTM+163:202108011100?+02:303’ wird angenommen, weil am 1.8.2021 in Deutschland MESZ gilt (mit einer Differnz von 2 Stunden zu UTC). | |
VALIDATION_CHECK_DUE_DATE_DEPENDANT_ON_MOA | ||
positive, negative, all, none | Einstellung für Fristenprüfung Sg8Dtm265FConditionCheck (Fristenprüfung INVOIC) Dabei wird einen APAREK im Fall ‘positive’ für nur Rechnungen (Positiven Betrag), ‘negative’ für nur Gutschriften (negativen Betrag), all => für beides, none => für kein erzeugt | |
VALIDATION_CHECK_HOUSE_NUMBER | ||
false, true | wenn auf true gestellt werden Adressen in NAD Segmenten gegen “2.17 Darstellung von Adressen” der Allgemeinen Festlegungen geprüft. Verletzungen der Richtlinien werden als CONTRL fehler betrachtet. |
|
VALIDATION_CHECK_MARKETPARTNERS_CONTRL | ||
true, false | Prüft bei true ob die MPID valide ist, ob die selbe MPID im UNB und NAD Segment vorhanden ist und ob die MPID zu der angegebenenen codepflegenden Stelle passt. | |
VALIDATION_MPID_CHECK_IGNORED_LIST | ||
999999999000;998888888888 | Als Wert kann eine Komma getrennte Liste von MPIDs angegeben werden, welche vom Marktpartnercheck ausgeschlossen werden. | |
VALIDATION_CHECK_MARKETPARTNERS_APERAK_Z31 | ||
strict | Überprüft, ob spezielle MP Rollen für spezielle Ereignisse miteinender kommunizieren dürfen. Bei dem Wert strict wird eine APERAK erzeugt, wenn die MP-ID nicht in der Liste vorhanden ist. Bei nonstrict wird keine Aperak erzeugt, wenn die MPID nicht in der Liste enthalten ist. | |
nonstrict | Unbekannte MP haben beliebige Rollen | |
none | Test wird nicht ausgeführt | |
VALIDATION_CHECK_MARKETPARTNERS_APERAK_Z31_MANUAL_ALLOWED | ||
(PrüfID(;Rolle/MPID;Rolle/MPID)+\r\n)? | In dieser Eigenschaft können weitere Marktrollen- oder Marktpartnerpaare für bestimmte Vorgänge für den APERAK Z31 Check freigeschaltet werden. Wenn nur für einen einzigen Vorgang mehr freigeschaltet werden soll, kann das direkt an der Action geschrieben werden, sonst sollte eine eigene Extension gepflegt werden und der Wert der ActionProperty auf ${loadextension(ExtensionName)} gesetzt werden. Die Eigenschaft beeinflusst nur die Prüfung auf einen APERAK Z31 Fehler. | |
11001;NB;NB | Erlaubt für den Vorgang 11001, dass Netzbetreiber (NB) mit Netzbetreibern kommunizieren dürfen | |
11001;NB;NB;999999999999;998888888888 | Erlaubt für den Vorgang 11001, dass Netzbetreiber (NB) mit Netzbetreibern kommunizieren dürfen und das der Marktpartner 999999999999 mit dem Marktpartner 998888888888 kommunizieren darf | |
VALIDATION_CHECK_MARKETPARTNERS_USE_APERAK_Z37 | ||
Diese Konfiguartion greift nur, wenn die Kommunikationsrichtungsprüfung eingeschaltet ist (VALIDATION_CHECK_MARKETPARTNERS_APERAK_Z31 strict/nonstrict) | ||
false | ist das Prächen aus sendender und empfangender Rolle für den Vorgang nicht erlaubt, wird ohne weitere Prüfung mit einer APERAK Z31 abgelehnt. | |
true | Gibt es kein Prächen, in dem die empfangende Rolle der tatsächlichen Empfängerrolle entspricht, wird ohne weitere Prüfung mit einer Aperak Z31 abgelehnt. Ist das Prächen aus sendender und empfangender Rolle für den Vorgang nicht erlaubt, wird mit einer APERAK Z37 abgelehnt. Dies funktioniert erst ab dem B2B Release März 2021 | |
VALIDATION_CHECK_OBIS_CODE | (Beispielwert: Strom,Gas,Others) | |
NONE | Kein Obis Check. Wenn die Property nicht gesetzt wird, wird als default Wert NONE verwendet. Ist ein anderer Wert gesetzt, wird sowohl CONTRL (syntaktische Prüfung für alle Arten von Obis-Codes) als auch APERAK Prüfung ausgeführt. | |
STROM | wenn diese Property aktiv ist, wird der Obis Check für Strom ausgeführt. Sonst keine Prüfung für Strom. | |
GAS | wenn diese Property aktiv ist, wird der Obis Check für Gas ausgeführt. Sonst keine Prüfung für Gas. | |
OTHERS | Others (alle anderen OBIS Codes außer Gas und Strom) werden per CONTRL abgelehnt, wenn diese Eigenschaft nicht gesetzt ist. Wenn sie gesetzt ist, werden diese nach korrekter Syntax geprüft und akzeptiert. | |
VALIDATION_CHECK_MEDIUM | true/false | |
false | Medium Codes werden nicht geprüft. Wenn die Property nicht gesetzt wird, wird als default Wert false verrwendet. | |
true | wenn diese Property aktiv ist, werden Medien Codes geprüft. | |
VALIDATION_CHECK_METERING_POINT | ||
true, false | Prüft bei true ob der Zählpunkt einen validen Namen besitzt | |
VALIDATION_CONTRL_21 | — | |
false, true | Schaltet die Prüfung für den Fehler 21 (Ungültiges Zeichen) ein oder aus. Standartmäßig ist die Prüfung deaktiviert. Diese Eigenschaft sollte für gesplittete Nachrichten immer auf false stehen. | |
VALIDATION_CONTRL_25_TESTFLAG | ||
true | Sucht nach “testflag” in der Nachricht und wirft eine contrl uci 21. | |
VALIDATION_ERROR_SEGMENT_CONTENT | ||
<Freitext> | Optional in Verbidung mit VALIDATION_ERROR_TYPE und ERRORS_TO_VALIDATE. Siehe ValidatorAction | |
VALIDATION_ERROR_SEGMENT_DESCRIPTION | ||
<Freitext> | Optional in Verbidung mit VALIDATION_ERROR_TYPE und ERRORS_TO_VALIDATE | |
VALIDATION_ERROR_ADDITIONAL_DESCRIPTION | ||
<Freitext> | Optional in Verbidung mit VALIDATION_ERROR_TYPE und ERRORS_TO_VALIDATE | |
VALIDATION_SIMPLE_MANDATORY_CHECK | ||
false, true | Wenn diese auf false gesetzt wird, wird ein Check verwendet der genauer aber auch ressourcenlastiger arbeitet. | |
REJECT_EXPIRING_ARTNR_FOR_NOT_MEMI | ||
false, true | Diese Property bewirkt, dass INVOIC Nachrichten mit den Prüfis 31001-31004 per APERAK abgelehnt werden können, wenn die Artikelnummer 9990001000574 vorkommt. | |
SIMULATE_STATE_AFTER_FORMAT_CHANGE | ||
true, false | Führt bei true die Validierung wie nach dem Formatwechsel aus, sofern eine umstellungsrelevante Prüfung enthalten ist. Dies umfasst neue EBD Codes und die Wirkungslosigkeit der Eigenschaft VALIDATION_CHECK_TIMEZONE | |
VALIDATION_RESULT_FORMATTER_SHOW_ONLY_INCORRECT_INCIDENTS | ||
false, true | wenn diese Property auf true gesetzt ist, zeigt das Validierungsresultat ausschließlich inkorrekte Incidents an, ansonsten werden alle Incidents ausgegeben | |
VALIDATION_RESULT_FORMATTER_SHOW_ONLY_INCORRECT_MESSAGES | ||
false, true | Wenn eine Nachricht per negativer CONTRL abgelehnt wird, stehen im formatierten Default-Validierungsergebnis alle Nachrichten (UNH-UNT Blöcke). Dies kann, zum Beispiel bei MSCONS Dateien, zu einem langen und unübersichtlichen Ergebnis führen. Die Aussgabe kann so gesteuert werden (Propertie = true), dass ausschließlich die Nachrichten angezeigt werden die für die Ablehnung ausschlaggebend sind. | |
VALIDATION_USE_EXTENSION_FOR_MPID_CHECK | ||
false, true | Schalter in der Validierung ob Extension genutzt werden soll(true) oder csv, welche innerhalb der Validierung liegt(false). Vor erste Benutzung Tomcat neu starten. Arbeitet nur mit VALIDATION_CHECK_MARKETPARTNERS_TYP=CSV_VALIDATOR (In alle ValidatorAction). VALIDATION_USE_EXTENSION_NAME_FOR_MPID_CHECK gehört zusammen | |
VALIDATION_USE_EXTENSION_NAME_FOR_MPID_CHECK | ||
${loadextension(MARKETPARTNER_CHECK)}, ${loadextension(<Freitext>)} | Lädt Extension für die Prüfung von Marktpartnern während der Validierung. Defautname der Extension ist MARKETPARTNER_CHECK. Extensioninhalt soll in der Form marketpartners.csv sein. VALIDATION_USE_EXTENSION_FOR_MPID_CHECK soll man auf true setzen | |
VALIDATION_MSCONS_MELO_MALO_CHECK | ||
true, false | Schalter in der Validierung ob Melo-Malo Check für Mscons ausgeführt werden soll. Der Check bezieht sich auf Kapitel 6 des Mscons AHB. | |
VALIDATION_CHECK_UNB_REFERENCE_FORMAT | ||
true, false | Schalter in der Validierung ob UNB DE0020 Check nach EDI@Energy Allgemeine Festlegungen (Zur Gewährleistung der Eineindeutigkeit sind nur Großbuchstaben zu nutzen) ausgeführt werden soll. | |
PERSIST_NOT_REJECTED_APERAK_Z29_ERRORS | ||
false, true | Nur relevant für Übertragungsnetzbetreiber: Wird diese Eigenschaft auf true gesetzt, werden die fehlenden Daten aus UTILMD Stammdatensynchronisationsnachrichten (BGM+Z38) als zusätzliches Datum unter dem key NOT_REJECTED_APERAK_Z29_ERRORS persistiert. Setzt einen VC der die FU Oktober 2021 (2021.10.1+) unterstützt voraus. |
Rollenkürzel
Verschiedene Konfigurationen erwarten, dass eine Marktrolle angegeben wird.
Rolle | Kürzel |
---|---|
Betreiber einer technische Ressource | BTR |
Bilanzkreiskoordinator | BIKO |
Bilanzkreisverantwortlicher | BKV |
Einsatzverantwortlicher | EV |
Energieserviceanbieter des Anschlussnutzers | ESA |
Erzeuger | EZ |
Kapazitätsnutzer | KN |
Lieferant | LF |
Marktgebietsverantwortlicher | MGV |
Messstellenbetreiber | MSB |
Netzbetreiber | NB |
Netznutzer | NN |
Übertragungsnetzbetreiber | UNB |
Umweltbundesamt/Herkunftsnachweisregister | UBA |
Verwendung eigener und echter ILN Nummern
Es ist möglich, auch offizielle und eigene ILNs zu verwenden. Hierzu ist folgende Konfiguration vonnöten (an allen Validator Actions). Auch hier ist es wichtig, dass “Kontext überschreiben” ausgewählt wird.
VALIDATION_CHECK_MARKETPARTNERS_TYPE=MULTISOURCE_VALIDATOR
VALIDATION_USE_EXTENSION_FOR_MPID_CHECK=true
VALIDATION_USE_EXTENSION_NAME_FOR_MPID_CHECK=${loadextension(MARKETPARTNER_CHECK)}
wobei die Extension, entsprechend wie in VALIDATION_USE_EXTENSION_NAME_FOR_MPID_CHECK benannt sein und folgendes Format erfüllen muss:
"MSB";"E";"9912121212978";"interne Test-MPID des Messstellenbetreiberes"
"LIEF";"E";"9912121212978";"intern vergebene Lieferanten ID des alten Backends"
"NB";"E";"3123344334456";"intern vergebene Netzbetreiber ID des Abrechnungsbackend"
"MSB";"G";"98122456744";"intern vergebene Messstellenbetreiber Nummer des Zählers am Gastank"
...
Standardmäßig sind dabei folgende Rollen in der B2B hinterlegt und können entsprechend in der Extension genutzt werden:
Alle Rollen: "ANY"/"AF"/"AG",
Bilanzkreiskoordinator: "BKO"/"BIKO",
Bilanzkreisverantwortlicher: "BKV",
Dienstleister: "DL",
Einsatzverantwortlicher: "EV",
Erzeuger: "ERZ",
Fernleitungsnetzbetreiber: "FLNB",
Kapazitätsnutzer: "KN",
Letztverbraucher: "LV",
Lieferant:"LIEF"/"LF",
Marktgebietsverantwortlicher: "MGV",
Messdienstleister: "MDE"/"MDL",
Messstellenbetreiber: "MSB",
Netzanschlussnehmer: "NAN",
Netzbetreiber: "NB"/"VNB",
Umweltbundesamt: "UBA",
Übertragungsnetzbetreiber: "UNB",
Netznutzer: "NN",
Betreiber technischer Resource: "BTR"
Durch diese Konfiguration wird die eigene Liste an MPIDs zusätzlich zu der ausgelieferten verwendet.
Bei der Auswahl der internen Nummern ist zu beachten, dass falls diese aussehen, als wären sie vom BDEW bzw. DVGW ausgestellt (also mit 99 bzw. mit 98 beginnen) in den Feldern für Verantwortliche Stelle für die Codepflege, Code
auch der Code für BDEW/DVGW in den Nachrichten verwendet werden muss. Gleiches gilt für die Angabe der Sparte, also E
(Electricity/Strom) für quasi BDEW-Nummern, G
(Gas) für quasi DVGW-Nummern bzw. das im konkreten Fall passende bei GS1-Nummern.
Um das Beispiel von oben aufzugreifen: NAD+MR+9912121212978:293'
oder NAD+MS+3123344334456:9'
. Dies gilt auch umgekehrt für Nummern, die nicht wie BDEW/DVGW Nummern aussehen.
Da es sich hierbei um gecachte Daten handelt, greift eine Änderung in diesem Bereich erst nach einem Neustart der B2B.
Prüfung der Marktrolle und Sparte
Es ist möglich Daten aus der B2B zur Prüfung der Marktrolle und des Marktsektors heranzuziehen und danach zu validieren. Hierzu müssen die Informationen der Rolle und des Sektors für jeden Marktpartner und für die eigenen ID’s in der B2B hinterlegt werden. Der Hinterlegungsort dieser Informationen kann je System unterschiedlich sein.
Die Information für die eigenen ID’s sollten in der Extension SENDER_EMAIL
hinterlegt werden. Diese Informationen können wie folgt aussehen:
ROLE_9999999999999=LF
SECTOR_9999999999999=E
Wichtig hierbei ist, dass die Validierung nur mit bestimmten Kürzeln zurecht kommt. Für die Rolle können LF, NB, MSB, MDL, UBA, BKV, BIKO, ERZ, BTR hinterlegt werden, für die Sparte E und G.
Die Informationen zur Rolle der Marktpartner werden im MPID-Editor in der Spalte SA-ID hinterlegt. Hier können die Standardabkürzungen wie oben genannt eingetragen werden. Ist das nicht der Fall und es werden individuelle Abkürzungen verwendet, so müssen diese auf die entsprechende Abkürzung gemappt werden. Das passiert über die Extension MPID_ROLE_MAPPING. Hier werden Key/Value Paare angegeben, wobei der Key auch ein Regex sein kann. Steht im MPID-Editor beispielsweise in der SA-ID Spalte LIEF, so wird in die Extension
LIEF=LF
eingetragen. Falls spezielle Rollen erlaubt sein sollen, die keinem offiziellen Kürzel zuzuordnen sind, so kann dies über
BLA=ANY
passieren. Falls alles erlaubt ist, kann dies über den Regex
.+=ANY
(Achtung: Damit werden potentiell nicht gepflegte Rollen und damit ein Fehler verschleiert.)
definiert werden. Sind die offiziellen Kürzel in der Spalte SA-ID hinterlegt wird in der MPID_ROLE_MAPPING Extension LF=LF bzw NB=NB usw. eingetragen
Falls die Marktpartner mit denen kommuniziert wird zu unterschiedlichen Sektoren gehören, muss das ebenfalls im MPID-Editor gepflegt werden. Angenommen es wird mit Marktpartnern aus dem Sektor Strom und Gas kommuniziert, dann kann diese Information auch in der SA-ID Spalte hinterlegt werden zum Beispiel über ENB, GNB, ELF, GLF usw. In diesem Fall muss dann natürlich die MPID_ROLE_MAPPING angepasst werden zu
ELF=LF
GLF=LF
ENB=NB
GNB=NB
usw.
Außerdem müssen an jeder (!) ValidatorAction müssen dann folgende drei Eigenschaften hinterlegt werden:
VALIDATION_CHECK_MARKETPARTNERS_TYPE=MPID_SYNC_VALIDATOR
VALIDATION_MARKETPARTNERS_ROLES=dynamischer Ausdruck zur Rolle der eigenen ID;dynamischer Ausdruck zur Rolle der Partner ID
VALIDATION_MARKETPARTNERS_SECTORS=dynamischer Ausdruck zum eigenen Sektor;dynamischer Ausdruck zum Sektor des Marktpartners
Als Beispiel nehmen wir an, die eigene Rolle ist wie oben beschrieben in der SENDER_EMAIL
hinterlegt und die Marktpartnerrolle in der SA-ID Spalte des MPID Editors und wird über die Extension gemapped. Dann kann folgender dynamischer Ausdruck für die Eigenschaft VALIDATION_MARKETPARTNERS_ROLES verwendet werden:
${template(&(this.FORMAT.senderCode))}
=
${loadExtensionProperty(SENDER_EMAIL,${template(ROLE_&(this.FORMAT.senderCode))},true)};
${template(&(this.FORMAT.partnerCode))}
=
${elpwithregex(MPID_ROLE_MAPPING,${getmpidsid(${template(&(this.FORMAT.senderCode))},${template(&(this.FORMAT.partnerCode))})})}
(einzeiliger Ausdruck)
Wird die Sparte für den Marktpartner als erster Buchstabe an die Rolle in die SA-ID gehängt dann lautet der zweite dynamische Ausdruck wie folgt
${template(&(this.FORMAT.senderCode))}
=
${loadExtensionProperty(SENDER_EMAIL,${template(SECTOR_&(this.FORMAT.senderCode))},true)};
${template(&(this.FORMAT.partnerCode))}
=
${substring(${getmpidsid(,${template(&(this.FORMAT.partnerCode))})},0,1)}
(einzeiliger Ausdruck)
Natürlich kann die Information für die Marktpartnersparte auch in der Spalte Name des MpidEditors hinterlegt werden, dann muss der dynamische Ausdruck die Funktion getmpidname benutzen. Gibt es nur eine Sparte von der und mit der kommuniziert wird, dann kann die Eigenschaft so aussehen:
VALIDATION_MARKETPARTNERS_SECTORS=
${template(&(this.FORMAT.senderCode))}=E;${template(&(this.FORMAT.partnerCode))}=E