Die teuersten Verkaufsaufträge in jeder JDE-Installation sind die, die gar nicht erst in F4211 hätten landen dürfen. Ein Auftrag über 1.200 Einheiten für einen Artikel mit einer maximalen Bestellmenge von 200. Eine Lieferung an einen Kunden, dessen Kreditlimit bereits vor drei Aufträgen überschritten wurde. Eine Auftragsposition mit einem zugesagten Datum, das vor dem heutigen Tag liegt. Das sind keine exotischen Sonderfälle — sie passieren jede Woche auf jedem System, das keine saubere Custom-Order-Entry-Validierung in JD Edwards EnterpriseOne mit BSFN-Logik hat, und sie enden als Gutschriften, Expressfrachtkosten oder Kommissionierfehler im Lager, die niemand bis zur ursprünglichen Erfassung zurückverfolgt.

Die Standardanwendung P4210 fängt einige dieser Fälle über Form Event Rules und Data-Dictionary-Prüfungen ab, aber sobald der Auftrag über eine Orchestration, einen AIS-Service oder einen Z-File-Import eingeht, werden diese clientseitigen Regeln vollständig umgangen. Die Validierung muss dort leben, wo am Ende jeder Erfassungspfad ankommt: in einer kompilierten Business Function, die serverseitig läuft, bevor irgendeine Zeile F4211 berührt.

Warum clientseitige Validierung allein irgendwann immer scheitert

Form Event Rules innerhalb von P4210Sales Order Entry — die Standard-JDE-Anwendung zum Erstellen und Ändern von Verkaufsaufträgen. Die Grid-Form und die Detail-Form enthalten den Auftragskopf beziehungsweise die Auftragspositionen. sind der naheliegende erste Ort für eine Validierungsregel. Sie sind visuell, schnell zu schreiben und werden genau im richtigen Moment ausgelöst, wenn ein Benutzer einen Auftrag über die Standardmaske erfasst. Das Problem ist nicht, was sie tun; das Problem ist alles, was sie nicht sehen.

Ein Auftrag, der über einen Orchestrator-Flow platziert wird, ruft den zugrunde liegenden AIS-Endpunkt auf, der direkt über die Datenebene in die Tabelle F4211 schreibt. Form ER wird nicht ausgeführt. Ein Auftrag, der durch einen EDI-Inbound-Prozess erstellt wird, läuft über die Z-File-Tabelle F47011 und über R47011 in F4211 — auch hier wird Form ER nie ausgeführt. Eine B2B-Integration, die Aufträge über die REST API sendet, trifft dieselbe Datenebene, und dieselben clientseitigen Regeln werden umgangen.

In einer typischen mittelgroßen Installation liegt der Anteil der Verkaufsaufträge, die über diese Nicht-Form-Kanäle eingehen, irgendwo zwischen 30% und 60%, und er wächst jedes Jahr mit zunehmender Nutzung von Orchestrator und AIS. Eine Validierung, die nur im Green-Screen-Pfad greift, schützt eine schrumpfende Minderheit der Aufträge.

Das Muster, das dieses Problem löst, ist einfach zu beschreiben und wird in der Praxis dennoch regelmäßig falsch umgesetzt: Die Validierungslogik lebt in einer Business Function, und jeder Erfassungspfad — einschließlich der Standardmaske — ruft sie auf. Form ER wird zu einem dünnen Wrapper, der die BSFN aufruft und auf den zurückgegebenen Fehlercode reagiert. Das Data Dictionary bleibt für syntaktische Einzelfeldregeln zuständig, also Länge, Wertebereich und Pflichtfelder. Alles, was feldübergreifend, tabellenübergreifend oder bedingungsabhängig ist, wandert in die BSFN.

Die Anatomie einer Custom-Validierungs-BSFN

Eine Validierungs-BSFN hat drei Aufgaben: die Eingaben aus der Data Structure lesen, die Regeln ausführen und Ausgaben zurück in dieselbe Struktur schreiben, damit der Aufrufer sie lesen kann. Die Signatur ist der Vertrag, auf den sich jeder Erfassungspfad verlassen wird, und sie am Anfang richtig zu definieren spart später enorm viel Refactoring. Das Muster, das gut altert, ist eine BSFN pro Validierungsdomäne — Kredit, Lagerverfügbarkeit, Preisberechtigung — statt einer Mega-Funktion, die alles zu erledigen versucht.

Innerhalb der Funktion werden die Regeln in Fail-Fast-Reihenfolge ausgeführt: die billigste Prüfung zuerst, die teuerste zuletzt. Eine Null-Prüfung für Branch/Plant kostet nichts und schließt eine ganze Fehlerklasse aus, bevor überhaupt ein Datenbankzugriff erfolgt. Eine Prüfung gegen den Customer Master F0301, um den Kreditstatus zu lesen, kostet einen Tabellenabruf. Eine Prüfung, die offene Auftragsbeträge aus F4211 aggregiert, um das Exposure zu berechnen, kostet einen Range Read mit einem Index auf AN8 und OPSTS. Ordnet man die Regeln nach Kosten, bleibt die durchschnittliche Ausführungszeit schnell, selbst wenn die meisten Aufrufe sauber zurückkommen.

Das Ausgabemuster, das sauber mit Form ER und AIS-Aufrufern integriert, ist ein strukturiertes Fehlerergebnis: ein einstelliger Fehler-Schweregrad (E für Error, W für Warning), ein Fehlercode, der auf eine Zeile in F7900Error Message File — die JDE-Tabelle, die Fehlermeldungstexte anhand des Fehlercodes hält. Custom-Codes hier zu ergänzen ermöglicht jedem Aufrufer, konsistente mehrsprachige Meldungen anzuzeigen, ohne Text hart zu codieren. verweist, und ein optionaler Fehlerparameter-String. Form ER liest den Schweregrad und markiert entweder die Zeile oder blockiert das Speichern. Ein AIS-Aufrufer liest dieselben Felder und gibt sie in der JSON-Antwort zurück. Dieselbe BSFN, dieselbe Fehlersemantik, zwei völlig unterschiedliche Benutzererfahrungen.

Zwischen C und NER für die Implementierung wählen

JDE gibt Ihnen zwei Möglichkeiten, eine Custom Business Function zu schreiben: kompiliertes C über den Business Function Design Aid oder NERNamed Event Rules — die visuelle Skriptsprache zum Schreiben von Business Functions, ohne C-Code zu schreiben. Wird durch das Tools Release im Hintergrund nach C kompiliert, aber als Event Rules geschrieben und gepflegt. über den visuellen Designer. Die Wahl ist keine Glaubensfrage, und die richtige Antwort hängt davon ab, was die Funktion tatsächlich tut.

NER ist die richtige Wahl für Validierungen, die hauptsächlich aus Tabellenlesungen, bedingten Verzweigungen und Fehlercode-Zuweisungen bestehen. Es kompiliert in dasselbe Objektformat wie C-BSFNs, läuft mit vergleichbarer Geschwindigkeit und ist dramatisch einfacher von der nächsten Person zu warten, die daran arbeiten muss. Ein Senior Consultant kann ein NER in fünfzehn Minuten lesen und verstehen; derselbe Code in C braucht fünfundvierzig Minuten und setzt voraus, dass der Leser die JDE-C-Makros für jdeStrcpy, jdeERRORInsert und die Zugriffsmuster auf Data Structures kennt.

C ist die richtige Wahl, wenn die Funktion String-Parsing, komplexe Datumsarithmetik, die sich mit den Event-Rule-Operatoren von NER nicht sauber abbilden lässt, oder Aufrufe von Drittanbieterbibliotheken benötigt, die in die JDE-Runtime gelinkt sind. Für Order-Entry-Validierung tritt diese Situation fast nie ein. Von den letzten fünfzehn Validierungs-BSFNs, die ich geschrieben oder geprüft habe, waren vierzehn NER und eine C, und diese eine C-Funktion war nur deshalb C, weil sie eine Header-Datei mit einem bestehenden Legacy-Modul teilte.

Eine Disziplin ändert sich zwischen C und NER nicht: Die Funktion muss re-entrant sein. JDE wird sie unter Last parallel aus mehreren Threads aufrufen, und jeder modulweite Zustand erzeugt intermittierende Fehler, deren Diagnose Wochen dauern kann. Zustand lebt in der übergebenen Data Structure, niemals in statischen Variablen.

Die BSFN in jeden Erfassungspfad einbinden

Sobald die Funktion existiert, ist die Integration der Teil, der sie tatsächlich nützlich macht. In P4210 wird der Aufruf in die Row-Save-Form-ER eingefügt, unmittelbar bevor die Position festgeschrieben wird. Der zurückgegebene Fehlercode wird geprüft, und wenn der Schweregrad E ist, wird das Speichern blockiert und die betroffene Zeile hervorgehoben; bei W erhält der Benutzer einen Bestätigungsdialog. Das sind zwanzig Zeilen Form ER, und es bewahrt die Benutzererfahrung der Standardmaske, während jedes Speichern durch das zentrale Regelwerk geleitet wird.

Für Orchestrator- und AIS-Aufrufer wird dieselbe BSFN über den Form Service Request oder über einen dedizierten Orchestration-Schritt aufgerufen, der die Funktion direkt anspricht. Die Output-Data-Structure fließt zurück in die Orchestration-Antwort, und das aufrufende System — ob das ERP eines B2B-Partners, ein Kundenportal oder eine mobile App — erhält eine strukturierte Fehler-Payload, die es den eigenen Benutzern anzeigen kann. Dieses Muster macht die Validierung wirklich universell statt formulargebunden.

Für Z-File-Importe über R47011 wird die BSFN innerhalb der Verarbeitungsschleife der UBE aufgerufen, nachdem die Inbound-Zeile gelesen wurde und bevor die Standardlogik zum Einfügen in F4211 läuft. Zeilen, die die Validierung nicht bestehen, werden im Z-File mit einem Fehlercode markiert und vom Insert ausgeschlossen, wodurch ein klarer Audit Trail entsteht, was abgelehnt wurde und warum. Die Standardverarbeitung von R47011 unterstützt dieses Muster bereits über ihren Error-Handling-Abschnitt — die Custom-BSFN wird einfach eingesteckt.

Die Disziplin, die das Ganze zusammenhält, besteht darin, genau einen Einstiegspunkt in der Codebasis zu haben, der definiert, was eine "gültige Verkaufsauftragsposition" bedeutet. Wenn das Business die Regel für die Mindestbestellmenge bei Gefahrgutartikeln ändert, erfolgt die Änderung in einer BSFN, wird einmal getestet, durch die Standardumgebungen promoviert und greift gleichzeitig in jedem Kanal. Die Alternative — drei Stellen zum Aktualisieren, drei separate Testzyklen, drei Gelegenheiten, eine davon zu vergessen — produziert genau die Supporttickets, die niemand haben will.

Eine Custom-Validierungs-BSFN sicher testen und promovieren

Eine Validierungs-BSFN sitzt auf einem kritischen Schreibpfad, was bedeutet, dass jede Regression direkte Auswirkungen auf den Umsatz hat. Die Testdisziplin, die mich mehr als einmal gerettet hat, ist unit-artige Isolation: eine kleine Custom-UBE, die die Input-Data-Structure programmatisch aufbaut, die BSFN aufruft und den erwarteten Fehlercode und Schweregrad für jeden Fall prüft. Zwanzig bis dreißig Testfälle pro BSFN decken Kreditlimits, MOQ-Regeln, gesperrte SKUs, Datumsvalidierung und die tabellenübergreifenden Bedingungen ab, die manuell schwer zu testen sind. Die Test-UBE lebt im selben Package wie die BSFN selbst und wird mit ihr promoviert.

Die Promotion durch DV-, PY- und PD-Umgebungen folgt dem Standard-OMW-Pfad, aber mit einer Ergänzung speziell für Validierungsfunktionen: Die promovierte BSFN sollte am Tag der Promotion in PD nicht aktiv werden. Kapseln Sie die neue Regellogik in einem Feature Flag, das aus einer UDC-Tabelle gelesen wird, deployen Sie mit inaktiv gesetztem Flag, prüfen Sie in PD, dass die Funktion aufrufbar ist und das alte Verhalten unverändert bleibt, und aktivieren Sie das Flag dann in einem ruhigen Zeitfenster. Eine fehlerhafte Validierungsregel, die sofort bei der Promotion auslöst, kann die Auftragserfassung im gesamten Unternehmen blockieren, solange das Backout dauert — Feature-Flagging sind zwanzig zusätzliche Zeilen ER und ein paar Stunden Prozessdisziplin, und es verwandelt einen möglichen Ausfall in ein Non-Event.

Mehr zu dieser Seite der JDE-Entwicklung finden Sie in den verwandten Artikeln zum Retrofitting von Kopien des Standards, zu Entscheidungsmustern zwischen NER und C und zu BSFN-Test-Harnesses, die die hier angesprochenen Teile vertiefen. Das technische Projektportfolio auf dieser Website dokumentiert zwei produktive Validierungssuiten, aus denen die oben beschriebenen Muster entstanden sind.