Content zur Validierung von Nachrichten

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

siehe hier

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.

Achtung! 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 Aktiviert den Check für die BDEW-Artikelnummerliste. Der Defaultwert bei dieser Einstellung ist auf flase. Die Eigenschaft wird weiterhin nur im Contrl Check ArticleNumberCheck verwendet, eine Aperak mit ArticlenumerberConditionCheckTemplateTest ist für diese Option nicht konfiguriert.  
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
View Me   Edit Me