Aktionen in individuellen Apps

Individuelle React-Apps können Plattformdaten über das Ennea-SDK lesen und ändern, ohne Standardkomponenten für Geschäftsabläufe einzubetten. Konnie kann Bildschirmfolge, bedingte Prüfungen, Fotoanforderungen, Statusanzeigen und Berechnungen in der App umsetzen und sinnvolle Parameter als Einstellungen anbieten. Die Plattform schützt gespeicherte Daten, aktuelle Berechtigungen, Mengen und gleichzeitige Änderungen.

Bitte Konnie, vor der Erstellung die Referenzen app-programs, production-station und app-evidence zu laden. Verwende tatsächliche IDs für Arbeitsplätze, Aufträge, Positionen und Träger. Eine Bearbeitung speichert einen Entwurf mit Verlauf; die Veröffentlichung erfolgt gesondert.

Im Code-Arbeitsbereich entwickeln

Mit Schnell öffnen (⌘/Strg P) findest du Dateien in den Quellprogrammen der App. Ergänze den Programmnamen, um gleiche Pfade zu unterscheiden, oder hänge :Zeile:Spalte an, um direkt an eine Stelle zu springen. Befehle (⌘/Strg Umschalt P) öffnet Suche, Änderungsprüfung, Datenanbindungen, Formatierung und Ansichtssteuerung. Die Tastenkürzel gelten, solange der Fokus im Code-Arbeitsbereich liegt.

In Dateien suchen (⌘/Strg Umschalt F) sucht nach wörtlichem Text, optional mit Groß-/Kleinschreibung oder nur ganzen Wörtern. Jeder Treffer führt zur genauen Stelle. Bei vielen Ergebnissen werden die ersten 100 Treffer angezeigt und du erhältst einen Hinweis zum Eingrenzen. Änderungen hebt Ergänzungen und Entfernungen gegenüber dem gespeicherten Ausgangsstand hervor. Unveränderte Bereiche lassen sich aufklappen und einzelne Dateien zurücksetzen.

Wähle in der Vorschau oder geteilten Ansicht Einpassen, Mobil, Tablet oder Desktop, um unterschiedliche Breiten zu prüfen. Größen- und Ansichtswechsel erhalten den Zustand der laufenden Vorschau. Die Steuerung ändert die Ansichtsbreite; sie emuliert keine Touch-Funktionen oder Gerätebrowser.

Öffne nach der Codeprüfung die Build-Analyse für Dateigrößen, Größe der kompilierten Ausgabe und lokale Importabhängigkeiten. Ein Klick auf eine Abhängigkeit öffnet deren Quelle. Die Analyse gehört zum geprüften Quellstand und verschwindet bei Änderungen. Die Byteangaben enthalten keine bereitgestellten Bibliotheken, Netzwerkübertragung oder Browserarbeit. Nicht referenzierte Module sind ein Hinweis; Stylesheets können weiterhin global wirken. Eine erfolgreiche Prüfung belegt die Kompilierung. Prüfe deshalb vor der Veröffentlichung auch Vorschau und vorgesehenen Ablauf.

Gleiche gleichzeitige Leseaufrufe für native Daten, Datensätze und Tabellen innerhalb einer laufenden App teilen sich jetzt eine ausstehende Abfrage. Jeder Aufrufer erhält ein unabhängiges Ergebnis. Abgeschlossene Ergebnisse werden nicht zwischengespeichert; Schreibvorgänge und Änderungsereignisse erzwingen für spätere Leseaufrufe eine neue Anfrage. Verwende weiterhin SWR-Schlüssel mit passendem Geltungsbereich und lade nach einer Wiederverbindung verlässliche Daten neu.

Mit Konnie in einer laufenden App arbeiten

Eine App kann ihre ausgewählte Aufgabe und benannte Aktionen mit useAppInteraction bereitstellen. Eine Materialanforderung kann beispielsweise ihre aktuellen Antworten sowie patchDraft und submitRequest anbieten. Konnie kann die Arbeitsdaten ausfüllen, erläutern oder denselben Sendeablauf wie die Schaltfläche der App verwenden. Felder, Gestaltung, Validierung und Ablauf gehören zur App. Ein separates Formular oder ein eingebetteter Chat ist dafür unnötig.

Wähle im regulären Konnie-Chat oder im Seitenfenster die laufende App neben dem Nachrichteneingabefeld aus. Dadurch bezieht sich die Nachricht auf deren aktuelle Aufgabe. Andere erlaubte Werkzeuge des normalen Kontos bleiben verfügbar. Wird die App geschlossen, die Aufgabe gewechselt, die Berechtigung entzogen oder das Konto gewechselt, kann eine alte Antwort die neue Aufgabe nicht verändern.

Für eine eigene Oberfläche bietet useKonnie Nachrichten, Senden und Stoppen, ein Konnie-Fenster, aufgenommenes Diktat und die Auswahl von Anhängen. Die App kann eigene Bedienelemente gestalten oder das Konnie-Fenster verwenden. Von einer App gestartete Gespräche verwenden immer die veröffentlichte Werkzeugrichtlinie der App, auch bei normalen Konten. Shopfloor-Konten benötigen zusätzlich die zugewiesene App, eine aktuelle Gerätesitzung und passende Objektberechtigungen. Ein geteiltes Konto identifiziert keine einzelne Person.

Bitte Konnie, beim Erstellen den Skill app-interaction-authoring und beim Bedienen app-interaction-operations zu verwenden. Das Builder-Thema app-interaction enthält die aktuelle API. Die Vorlage Dateneingabe mit Konnie besteht aus bearbeitbarem Quellcode und bietet einen optionalen App-eigenen Chat. Wenn du die vorhandene Tabellenübermittlung der Vorlage nutzt, verbinde vor dem Senden deine Tabelle.

Zeige den Speicherstatus und schütze manuelle Änderungen. Umkehrbare Unterstützung kann direkt angewendet werden und eine passende Rückgängig-Aktion anbieten. Ein eingereihter oder zugestellter Befehl bestätigt noch keine Speicherung oder Übermittlung. Verwende bei wirksamen Aktionen den tatsächlichen Plattformbeleg. Gleiche unterbrochene Anfragen ab oder wiederhole die exakt gespeicherte Absicht mit derselben Aufruf-ID. Wiederhole eine unbestätigte Aktion nicht stillschweigend. Entwürfe benötigen zum Speichern und Übermitteln eine Verbindung.

Datensätze zwischen Apps teilen

Verwende für einen neuen Datensatztyp ein gemeinsames Modell. Modelle können Regeln für Statusänderungen durchsetzen, einen Datensatzverlauf führen und Ereignisse für Automationen auslösen. Mehrere Apps können beispielsweise dasselbe Modell für eine Schichtübergabe verwenden, die an einer Station beginnt und an einer anderen fortgesetzt wird. Jede App hat eigene Ansichten, Einstellungen und erlaubte Aktionen. Die Datensätze bleiben unabhängig von Layout und Veröffentlichungshistorie der App gespeichert.

Bedarf	Lösung
Neuer gemeinsam genutzter Datensatztyp	Modell. Verwende writes: "actions", wenn für Statusänderungen Regeln gelten.
Zusätzliches Merkmal oder zusätzliche Verknüpfung an einem bestehenden Ennea-Datensatz	Benutzerdefiniertes Feld oder Beziehungserweiterung
Beobachtung, Foto oder Messwert zu einem Fertigungsvorgang	App-Nachweis
Bestehende benutzerdefinierte Tabelle und ihre Apps	Benutzerdefinierte Tabelle beibehalten

Bitte Konnie, das Builder-Thema workspace-models zu laden, die Modellfelder zu definieren und die Apps anzubinden. Definiere die Eingaben in der App. Wenn das Modell Aktionen voraussetzt, binde seine Erstellungsaktion über ihren Schlüssel in actions und rufe sie beim Absenden auf. Bestehende benutzerdefinierte Tabellen und die Apps, die sie verwenden, werden weiterhin unterstützt.

Zum Beispiel: „Erstelle ein Modell für Schichtübergaben mit Referenz, Status, Notizen und Prüfungen. Verbinde eine Erfassungs-App und eine Prüf-App mit denselben Datensätzen. Prüfer sollen vorhandene Übergaben fortsetzen können.“ Wähle für jede Verbindung persönliche Datensätze oder gemeinsamen Zugriff im Arbeitsbereich. Gemeinsamer Zugriff benötigt eine berechtigte Verbindung; die Kenntnis einer Datensatzreferenz gewährt keinen Zugriff.

Die App-Verbindung legt das Modell, seine Strukturversion und die erlaubten Vorgänge fest. React-Apps lesen über ennea.models.describe, query und get. Verwende für direkte Schreibvorgänge create und update, wenn das Modell sie erlaubt. Verwende für gebundene Aktionen act. Felder unterstützen Text, Zahlen, Wahrheitswerte, Kalendertage, Zeitpunkte, Auswahlwerte, verschachtelte Gruppen, Listen und Verweise auf unterstützte Ennea-Datensätze oder andere Modelle. Konnie kann optionale Felder in einer neuen Version ergänzen; bestehende App-Verbindungen behalten bis zur bewussten Aktualisierung ihre ausgewählte Version.

Verwende choice für eine feste Auswahl. Definiere options: [{key, label: {en, de}}] mit 1–100 unterschiedlichen Schlüsseln und beiden Beschriftungen. Schlüssel beginnen mit einem ASCII-Buchstaben, enthalten nur ASCII-Buchstaben, Ziffern oder Unterstriche und sind höchstens 64 Zeichen lang; __proto__, constructor und prototype sind reserviert. Speichere den Schlüssel, etwa open, statt der angezeigten Beschriftung. Eine Liste mit items vom Typ choice speichert eine Mehrfachauswahl als Array von Schlüsseln. Spätere Versionen dürfen Optionen ergänzen oder Beschriftungen ändern, bestehende Schlüssel aber weder entfernen noch umbenennen.

{
  "key": "state",
  "label": { "en": "State", "de": "Status" },
  "type": "choice",
  "options": [
    { "key": "open", "label": { "en": "Open", "de": "Offen" } },
    { "key": "done", "label": { "en": "Done", "de": "Erledigt" } }
  ]
}

Verwende date für einen Kalendertag (2026-11-08) und datetime für einen Zeitpunkt (2026-11-08T15:04:05.123Z). Zeitpunkte benötigen einen vollständigen ISO-8601-UTC-Zeitstempel mit Sekunden und Z oder +00:00; optionale Sekundenbruchteile werden auf Millisekunden mit Z vereinheitlicht. Wandle lokale Datums- und Zeitangaben vor dem Speichern in UTC um. Das Studio zeigt Auswahlbeschriftungen in der aktuellen Sprache und Zeitpunkte in der Zeitzone deines Browsers. choice- und datetime-Felder auf oberster Ebene können als displayField des Modells dienen und unterstützen skalare Filter.

Frage verknüpfte Datensätze auf dem Server ab. Ein einzelnes where: {field, value} bleibt möglich und bedeutet Gleichheit. Verwende ausdrücklich op: 'eq' oder op: 'in' mit values aus 1–50 skalaren Werten oder Auswahlschlüsseln. Kombiniere 1–4 Bedingungen mit {all: [...]}. Filter beziehen sich auf Felder der obersten Ebene; Referenzen unterstützen Gleichheit mit ihrem exakten Wert {objectType, entityId} oder {modelId, recordId}. Referenzen in Gruppen oder Listen sind nicht filterbar.

const page = await ennea.models.query("requests", {
  where: {
    all: [
      {
        field: "machine",
        value: { objectType: "work_center", entityId: selectedMachineId },
      },
      { field: "state", op: "in", values: ["open", "pending"] },
    ],
  },
  order: { field: "dueAt", direction: "asc" },
  limit: 20,
});

order akzeptiert newest (Standard), oldest oder ein datetime-Feld der obersten Ebene mit direction: 'asc' oder 'desc'. Lade weitere Ergebnisse mit nextCursor und behalte Filter und Sortierung zwischen den Seiten bei. Für jede Seite gelten die aktuellen Berechtigungen für Arbeitsbereich und persönliche Datensätze sowie Datenschutzbeschränkungen.

Öffne Betriebsstudio → Modelle, um zugängliche Modelle zu durchsuchen. Wähle ein Modell, um seine Datensätze zu sehen oder seinen Aufbau zu prüfen. Öffne einen Datensatz, um gespeicherte Werte anzusehen; operative Änderungen erfolgen in einer verbundenen App. Listen laden seitenweise, Mehr laden zeigt ältere Datensätze. Hat eine andere Person zuerst gespeichert, lade den aktuellen Datensatz neu und prüfe ihn vor dem Speichern deiner Änderungen. Das schützt gemeinsame Arbeit; gleichzeitige Textbearbeitung ist damit nicht verbunden.

Der Bereich Verknüpfte Datensätze in der Datensatzansicht zeigt zugängliche Datensätze, deren Referenz auf oberster Ebene auf diesen Datensatz verweist, nach Modell gruppiert. Öffne einen Eintrag zur Prüfung und verwende Mehr laden für weitere Verknüpfungen. Konnie kann außerdem workspaceModels mit action: 'linkedRecords' und target: {modelId, recordId} oder {objectType, entityId} verwenden; die Ergebnisse bleiben auf lesbare Modelle und Datensätze beschränkt. Ein lesbarer Datensatz bleibt auch sichtbar, wenn eine seiner Verknüpfungen auf etwas zeigt, das du nicht öffnen darfst; diese Verknüpfung zeigt Verknüpfter Datensatz für dich nicht verfügbar und verrät sonst nichts.

Öffne in einem Datensatz Verlauf anzeigen, um seine gespeicherten Änderungen zu sehen, die neueste zuerst: die Version, welche Felder sich geändert haben, ob eine Person, ein gemeinsames Shopfloor-Konto, Konnie oder eine Automatisierung die Änderung vorgenommen hat und ob sie aus einer App oder aus Studio kam. Der Verlauf beginnt mit der ersten Änderung, die nach Verfügbarkeit dieser Funktion gespeichert wurde; frühere Änderungen wurden nicht erfasst. Verwies eine frühere Version auf einen Datensatz, den du nicht mehr öffnen kannst, bleibt der Eintrag ohne seine Werte sichtbar. In einer React-App liefert ennea.models.history(alias, recordId, {limit, cursor}) dieselben Einträge über die Lese-Verbindung der App.

Bereite als Administrator vor Beziehungsabfragen für eine bestehende Datenbank die Indizes mit dem ausdrücklichen Indexwerkzeug vor. MONGODB_URI muss die genaue Zieldatenbank benennen. Bereite zuerst die Indexgruppe workspace vor und prüfe, übernehme und verifiziere anschließend den abgeleiteten Referenzindex unabhängig:

pnpm --filter @ennea/backend exec node scripts/appRuntimeReleaseIndexes.js --group workspaceReferences --dry-run
pnpm --filter @ennea/backend exec node scripts/appRuntimeReleaseIndexes.js --group workspaceReferences --apply
pnpm --filter @ennea/backend exec node scripts/appRuntimeReleaseIndexes.js --group workspaceReferences --verify

Die vollständige Freigabesequenz pnpm --filter @ennea/backend apps:indexes --dry-run / --apply / --verify enthält beide Gruppen in dieser Reihenfolge. Die Nachpflege baut nur abgeleitete Referenzeinträge neu auf; Werte, Versionen, Zeitstempel und Verlauf der Datensätze bleiben unverändert. Fehlende Modelldefinitionen im genauen Geltungsbereich und gleichzeitige Änderungen der Quelldaten verhindern den Abschluss und müssen vor einem erneuten Versuch geprüft werden. Führe sie aus, sobald alle Server diese Version ausführen. Bis die Verifizierung erfolgreich ist, melden Referenzfilter und Verknüpfte Datensätze, dass Beziehungsabfragen aktiviert werden müssen; andere Modellabfragen funktionieren weiter.

Nexus zeigt Modelldefinitionen, ihre Verweisbeziehungen und verbundene Apps in der Konfigurationskarte. Öffne dort ein Modell, um es im Betriebsstudio anzusehen. Einzelne Modelldatensätze prüfst du derzeit im Betriebsstudio oder in ihrer verbundenen App.

Aktionen und Regeln definieren

Definiere Fachvorgänge am Modell, damit in jeder verbundenen App, Konnie und Automation dieselben Regeln gelten. Mit writes: "actions" müssen Datensätze über Aktionen erstellt und geändert werden. Allgemeine Aufrufe von create und update lehnen den Schreibvorgang dann ab. Bestehende Modelle behalten ihr Verhalten, bis dieser Modus bewusst aktiviert wird.

Verwende für Mehrweggestelle ein Modell rack mit den Statuswerten available, out und damaged sowie ein Modell rackCirculation mit einer Referenz rack, den Statuswerten out, overdue und returned, returnedAt (Datum und Uhrzeit) und returnedBy (Akteur). Definiere checkOut so, dass es nur bei einem verfügbaren verknüpften Gestell einen Umlauf erstellt und anschließend dessen Aktion dispatch aufruft. Definiere registerReturn am Umlauf wie folgt:

{
  "key": "registerReturn",
  "label": { "en": "Register return", "de": "Rückgabe erfassen" },
  "kind": "update",
  "parameters": [
    {
      "key": "condition",
      "label": { "en": "Condition", "de": "Zustand" },
      "type": "choice",
      "required": true,
      "options": [
        {
          "key": "available",
          "label": { "en": "Ready to use", "de": "Einsatzbereit" }
        },
        { "key": "damaged", "label": { "en": "Damaged", "de": "Beschädigt" } }
      ]
    }
  ],
  "rules": [
    {
      "id": "isOut",
      "when": { "field": "status", "in": ["out", "overdue"] },
      "message": {
        "en": "Only racks that are out can be returned.",
        "de": "Nur ausgegebene Gestelle können zurückgegeben werden."
      }
    }
  ],
  "effects": [
    { "set": "status", "to": { "const": "returned" } },
    { "set": "returnedAt", "to": { "now": true } },
    { "set": "returnedBy", "to": { "actor": true } },
    {
      "invoke": {
        "via": "rack",
        "action": "receive",
        "parameters": { "condition": { "param": "condition" } }
      }
    }
  ],
  "allow": { "shopFloor": true, "automations": false },
  "konnie": "approval_required"
}

Die Gestellaktion receive nimmt dieselbe Auswahl condition an und setzt daraus den Status. Beide Änderungen werden gemeinsam gespeichert. Eine fehlgeschlagene Regel schreibt nichts. Regeln, die Parameter benötigen, bleiben in der Vorschau offen, bis die Parameter vorliegen. Verknüpfte Datensätze werden mit aktuellen Berechtigungen und Datenschutzsperren geprüft; ein nicht verfügbarer Verweis gibt niemals dessen Werte preis.

Verbinde die Wareneingangs-App mit operations: ["read"] und actions: ["registerReturn"] sowie der genauen Modellkennung und Revision. Jede Bindung darf höchstens 32 Aktionsschlüssel enthalten; die Veröffentlichung lehnt unbekannte oder stillgelegte Schlüssel ab. Der Aufruf von rack.receive wird durch die Aktionsdefinition delegiert und benötigt keine eigene App-Bindung. Aktuelle Gruppenmitgliedschaften und allow.shopFloor gelten weiterhin. Ein Akteurwert für ein gemeinsames Shopfloor-Konto bezeichnet dieses Konto, keine einzelne bedienende Person.

Bei einer Verbindung mit own bleiben verknüpfte Lesezugriffe in dasselbe Modell auf Datensätze des aktuellen Kontos beschränkt. Verweise auf andere verbundene Modelle nutzen deren festgelegten Lesezugriff. Ein nicht verbundenes Modell darf durch die Aktion geprüft werden; dadurch erhält die App keinen allgemeinen Lesezugriff auf seine Datensätze.

const preview = await ennea.models.availableActions("circulations", record.id);
// Zeige preview.data.actions und deren übersetzte failure.explanation an.
const result = await ennea.models.act("circulations", {
  recordId: record.id,
  action: "registerReturn",
  parameters: { condition: "available" },
  expectedVersion: record.version,
  invocationId: savedInvocationId,
});
if (!result.data.ok) {
  showReasons(result.data.failures.map((failure) => failure.explanation));
}

Sichere vor dem Senden die genaue ausstehende Eingabe und die Vorgangskennung; wiederhole einen unklaren Ausgang mit derselben Kennung und unveränderter Eingabe. Lasse bei einer erstellenden Aktion recordId und expectedVersion weg. Die Vorschau erklärt die aktuelle Verfügbarkeit; die Ausführung prüft Berechtigungen, Regeln und Versionen erneut. Regeln verwenden die aktuelle Modellrevision, auch wenn eine App an eine ältere Revision gebunden ist.

In Studio zeigt Struktur Aktionen, Parameter, Regeln und Berechtigungen. Ein Datensatz zeigt Verfügbare Aktionen samt Gründen, ohne sie auszuführen. Frage Konnie, warum eine Aktion nicht verfügbar ist; es nutzt dieselbe Vorschau und erklärt die zurückgegebene Regelmeldung in deiner Sprache. Bei der Ausführung gilt die strengere Vorgabe aus Konnie-Richtlinie der Aktion und Control Center. Prüfe vor der Freigabe einer folgenreichen Modellrevision die betroffenen veröffentlichten App-Bindungen. Definiere Aktionen über Konnie oder die API; Schaltflächen für Fachvorgänge gehören in Apps.

Archivierte Datensätze und Modell-Datenquellen

Die Archivierung erhält Identität, Werte und Verlauf eines Datensatzes. Normale Abfragen schließen archivierte Datensätze aus; zum ausdrücklichen Einbeziehen ist dieselbe Leseberechtigung erforderlich. Archivierte Datensätze können bis zur Wiederherstellung weder geändert noch neu referenziert werden. Bestehende Verweise behalten ihre ursprüngliche Identität und kennzeichnen ein archiviertes Ziel. Ein Modell kann nicht archiviert werden, solange gespeicherte App-Entwürfe, aufbewahrte veröffentlichte App-Versionen, Referenzfelder anderer Modelle, verweisende Datensätze oder Datenquellen davon abhängen. Der Sperrbericht nennt jede Abhängigkeit eindeutig.

Konnie nutzt workspaceModels mit archiveRecord oder restoreRecord sowie der genauen Modellkennung, Strukturversion, Datensatzkennung, aktuellen Datensatzversion als expectedVersion und stabiler invocationId. Nutze für archiveModel und restoreModel die lifecycleVersion des Modells als expectedVersion; sie ist von der unveränderlichen Strukturversion getrennt. Beide Statusänderungen benötigen aktuelle Rechte und standardmäßig eine Freigabe. Mit includeArchived: true bei den entsprechenden Lesevorgängen findest du ein Wiederherstellungsziel; eine verweigerte Archivierung liefert genaue blockingReferences-Kennungen. Eine verbundene App benötigt die Operation archive in ihrer Modellverbindung für ennea.models.archive oder restore. Wiederhole einen unklaren Ausgang mit derselben Vorgangskennung und unveränderter Eingabe.

In der Dashboard- und App-Datenkonfiguration lassen sich ein Modell und seine Strukturversion auswählen. Die Datenquelle benötigt zusätzlich eine passende Modell-Leseverbindung und verwendet standardmäßig Meine Datensätze. Gemeinsamer Zugriff im Arbeitsbereich setzt eine berechtigte Arbeitsbereichsverbindung voraus. Feld- und Auswahlbeschriftungen stammen aus den englischen/deutschen Modellbeschriftungen. Datenabfragen fassen ausschließlich den aktuellen Zustand zusammen, ohne archivierte oder datenschutzrechtlich eingeschränkte Datensätze; sie rekonstruieren keinen Verlauf. Zählen und Gruppieren unterstützen skalare Felder, Auswahl- und Referenzfelder auf oberster Ebene; Summe, Mittelwert, Minimum und Maximum verwenden Zahlenfelder. Größen- oder Zeitgrenzen ergeben einen ausdrücklichen Fehler, niemals einen unvollständigen Endwert. App-Änderungshinweise lösen eine erneut berechtigte Abfrage aus.

Die Freigabevorbereitung benötigt außerdem die Gruppe workspaceArchives nach workspace und workspaceReferences:

pnpm --filter @ennea/backend apps:indexes --group workspaceArchives --dry-run
pnpm --filter @ennea/backend apps:indexes --group workspaceArchives --apply
pnpm --filter @ennea/backend apps:indexes --group workspaceArchives --verify

Diese ausdrückliche Nachpflege ergänzt Archivstandardwerte ohne Änderungen an gespeicherten Werten, Versionen, Zeitstempeln oder Verlauf und bereitet anschließend die archivbewussten v2-Indizes vor. Behalte v1-Indizes für das ausdrückliche Einbeziehen. Halte alte schreibende Prozesse während Vorbereitung und Umstellung an; normale Lese- und Schreibzugriffe bleiben gesperrt, bis die benötigten Archivindizes vorbereitet sind.

Modellaktionen automatisieren

Wähle in Betriebsstudio → Automationen Modelldatensatz erstellt, Modelldatensatz aktualisiert oder Modellaktion angewendet und anschließend das genaue Modell. Beim Aktionsereignis kannst du zusätzlich eine bestimmte Aktion auswählen. Bedingungen dürfen nur Auswahl- und Wahrheitswerte des Zustands, geänderte Felder, die Quelle und die App-ID verwenden. Auswahlwerte zeigen ihre übersetzten Beschriftungen. Warten → Ereignis verwendet dieselben Modell-, Aktions- und Bedingungsregeln sowie die Datensatzzuordnung und eine Frist.

Füge Modellaktion ausführen hinzu, wähle ein Modell und eine für Automationen erlaubte Aktion und ordne Datensatz, erwartete Datensatzversion und Aktionsparameter aus dem Auslöser, festen Werten oder früheren Schritten zu. Wähle, ob eine Regelablehnung den Durchlauf beendet oder dem Zweig Abgelehnt folgt. Verbinde Angewendet mit dem erfolgreichen Pfad. Eine Ablehnung liefert die übersetzte Regelbegründung. Der Modellkern prüft aktuelle Regeln und Berechtigungen bei jedem Versuch. Eine Aktion, die bei Ablehnung stoppt, darf der letzte Schritt sein.

Definiere beispielsweise markOverdue am Modell rackCirculation als ändernde Aktion mit diesen Regeln und dieser Wirkung:

{
  "key": "markOverdue",
  "label": { "en": "Mark overdue", "de": "Als überfällig markieren" },
  "kind": "update",
  "parameters": [],
  "rules": [
    {
      "id": "isOut",
      "when": { "field": "status", "eq": "out" },
      "message": {
        "en": "Only circulations that are out can become overdue.",
        "de": "Nur ausgegebene Umläufe können überfällig werden."
      }
    },
    {
      "id": "pastDue",
      "when": { "field": "dueAt", "lt": { "now": true } },
      "message": {
        "en": "The due date has not passed.",
        "de": "Der Fälligkeitstermin ist noch nicht überschritten."
      }
    }
  ],
  "effects": [{ "set": "status", "to": { "const": "overdue" } }],
  "allow": { "automations": true, "shopFloor": false },
  "konnie": "unavailable"
}

Verwende einen täglichen Zeitplan und Modellaktion für passende Datensätze ausführen. Wähle das Umlaufmodell und markOverdue, ergänze Status ist gleich Ausgegeben, wähle Fällig am: früheste zuerst und begrenze den Durchlauf auf höchstens 50 Datensätze. Die Verarbeitung erfolgt in stabiler Reihenfolge; jeder Datensatz hat eine eigene Wiederholungskennung. Der Durchlauf meldet verarbeitete, abgelehnte und fehlgeschlagene Datensätze sowie weitere vorhandene Treffer. Noch nicht fällige Umläufe lehnt die Regel ab. Wird ein Datensatz nach der Auswahl bearbeitet, zählt er für diesen Durchlauf als fehlgeschlagen. Die übrigen Datensätze werden weiterverarbeitet; der nächste Zeitplan kann die aktuelle Version auswählen. Ein späterer Durchlauf wählt geänderte Datensätze mit dem nun überfälligen Status nicht mehr aus. Die Wiederholung desselben Durchlaufs verwendet seine gespeicherten Ergebnisse und wendet die Aktion nicht zweimal an.

Die Veröffentlichung bindet die Modellrevision und prüft Aktion und Dienstidentität im genauen Geltungsbereich. Prüfe und veröffentliche erneut, wenn sich Ausführungsregeln, Auswirkungen, Berechtigungen oder der Parametervertrag ändern. Änderungen an Beschriftungen oder Regelerklärungen allein erfordern keine erneute Veröffentlichung. Jede Ausführung verwendet die Dienstidentität der Automation; der Verlauf enthält diesen Softwareakteur und die Durchlaufkennung. Entziehst du ihr die Schreibberechtigung für Modelle, scheitern spätere Ausführungen. Modell-Auslöser und Warteereignisse erfordern, dass sowohl die erstellende Person als auch die Dienstidentität das Leserecht für das Modell behalten. Fehlt es, erscheint jeder spätere Auslöser ohne Ereignisdaten als wegen fehlender Berechtigung blockierter Durchlauf im Verlauf, und wartende Durchläufe werden blockiert. Datensatz und Version eines Auslösers können nur eine Aktion desselben Modells ansteuern. Modell-Auslöser ignorieren Änderungen durch Automationen standardmäßig. Auch nach bewusster Aktivierung bleibt die Verursachungskette begrenzt.

Modellereignisse enthalten keine Texte, Zeitangaben, Verweise oder Akteurwerte. Aktionsergebnisse enthalten Kennungen und Änderungsübersichten ohne Datensatzwerte. Diese Details werden KI-Anbieterschritten vorenthalten; Datensatzwerte benötigen einen gesonderten verwalteten Lesezugriff. Bitte Konnie, vor dem Aufbau desselben Ablaufs die Referenzen automations und gemeinsame Modelle zu laden. Veröffentlichung, Aktivierung und Ausführung bleiben getrennte Schritte.

Nachweise zum Arbeitskontext speichern

Ein Nachweis kann strukturierte JSON-Daten, Text und hochgeladene Medien enthalten. Verknüpfe ihn mit Kundenauftrag, Kundenauftragsposition, Fertigungsauftrag, Arbeitsgang, Ausführungsteil oder Materialträger. So kann die App Antworten und Fragetexte einer Prüfung, Verpackungsfotos oder berechnete Verpackungsmaße speichern. Die App entscheidet, welche Angaben gelten und was vor ihrer Fertigmeldung gespeichert sein muss.

Das SDK bietet ennea.evidence.list, get, create, update und delete. Jeder Aufruf enthält ein ausdrückliches Bezugsobjekt {type,id}. IDs bezeichnen gespeicherte Datensätze; Auftragsnummern oder erfundene Paket-IDs sind keine Bezugsobjekt-IDs. Eine eigene Paketkennung kann in den Nachweisdaten des Auftrags oder der Position stehen.

const result = await ennea.evidence.create({
  subject: { type: "customerOrderLine", id: selectedPositionId },
  kind: "inspection",
  data: { checks: [{ id: "visual", checked: true }], packageReference: "A" },
  invocationId: savedInvocationId,
});

Gib beim Ändern oder Löschen die gespeicherte Revision als expectedRevision an. Löschen entfernt den Nachweis und seine Verknüpfungen; gemeinsam verwendete hochgeladene Medien werden nicht automatisch gelöscht. Auch beim Lesen in einer anderen berechtigten App oder an einer anderen Station gelten die aktuellen Berechtigungen des Bezugsobjekts und der Datei.

Für Nachweise, die ein nativer Fertigungsarbeitsgang verlangt, verwende das tatsächliche Bezugsobjekt productionOrder und speichere dessen genaue data.operationId und data.splitId. Eine Beobachtung zu einem anderen Arbeitsgang erfüllt diese Anforderung nicht. Ein Messwert benötigt einen endlichen numerischen data.value und eine nicht leere Einheit; erhalte seine tatsächliche Bezeichnung und Einheit. Berechtigte Apps und die üblichen Auftragsdetails öffnen dieselben kanonischen Nachweise und Dateien erneut.

Medien hochladen und anzeigen

Sichere vor einem fortsetzbaren Upload dessen stabile invocationId. Rufe ennea.files.uploadStatus({invocationId}) auf: data.state ist ready, pending oder missing. Ein fertiges Ergebnis enthält data.file; verwende diese kanonische Datei ohne erneute Auswahl. Bei ausstehendem oder fehlendem Upload wählt die bedienende Person die tatsächliche Datei mit ennea.files.select aus oder erneut aus. Rufe anschließend ennea.files.upload(handle, {fileType: 'image', invocationId}) mit derselben Kennung auf. Der Handle stammt aus der vertrauenswürdigen Dateiauswahl; Konnie kann keine lokale Datei für die Person erfinden oder auswählen.

Wiederhole mit denselben Dateidaten, demselben Dateityp und demselben unveränderlichen App-Kontext. Abweichende Daten oder ein anderer Kontext werden abgelehnt, statt den ursprünglichen Upload zu ersetzen. Sichere die zurückgegebene data.file.id im Wiederherstellungsentwurf, bevor du {runtimeFileId} in Nachweis-media verknüpfst. Behalte auch für diesen Nachweisaufruf Kennung und Eingabe bei unklarem Ausgang bei. Sichere vor dem Senden der Dateidaten die Upload-Phase: selection bei sicher ungesendeter Auswahl, uploading vor files.upload und ready zusammen mit der Datei-ID. Ein Abbruch entfernt nur eine sicher ungesendete Auswahl mit aktuellem Status missing. Nach möglichem Senden, bei Status pending oder bei einer älteren Absicht ohne Phase bleibt dieselbe Wiederherstellungskennung erhalten und das Ergebnis unbekannt. Prüfe nach der Statusabfrage und nach der Auswahl vor dem Upload, ob die Interaktion noch aktuell ist. Das bisherige files.create bleibt für vorhandene besondere Integrationen verfügbar. Die Fotoauswahl und der Upload sind vom Speichern der Nachweisverknüpfung getrennt.

Lies verknüpfte Medien mit ennea.files.read({evidenceId,evidenceSubject:subject,runtimeFileId}). Der Aufruf liefert berechtigte Dateidaten und Metadaten für die Vorschau. Er prüft den aktuellen Nachweis, das Bezugsobjekt und die Datei, statt eine wiederverwendbare Speicher-URL auszugeben. Entfernte oder gesperrte Nachweise sowie entzogene Berechtigungen können über diese Verknüpfung keinen weiteren Zugriff gewähren.

Ein eigener neuer Upload kann erstmals verknüpft werden; bei erneuter Nutzung am selben Bezugsobjekt gelten weiterhin dessen aktuelle Objekt- und Dateiberechtigungen. Um eine bereits operativ verwendete Datei mit einem anderen Bezugsobjekt zu verknüpfen, übergib deren aktuell berechtigte sourceEvidenceId und sourceEvidenceSubject im Medienverweis. Eine Datei-ID, ein Dateiname oder die Upload-Herkunft allein gewährt keinen Zugriff. Das Lesen operativ verknüpfter Dateien benötigt den Nachweis-/Objektkontext oder eine geprüfte native Auftrags-/Stationsauswahl.

Die App kann ein oder mehrere Fotos vor oder nach einer Checkliste auf Positions- oder Auftragsebene erfassen. Diese Entscheidungen gehören zur App. Upload-Grenzen sind technische Grenzen und keine Fertigungsanforderungen.

Medienbetrachter in einer React-App wiederverwenden

Verwende components.MediaViewer für ein Bild, Video, eine hochgeladene Audiodatei, ein PDF oder ein GLB/glTF-Modell und components.MediaGallery für eine geordnete gemischte Sammlung. Diese gemeinsamen Betrachter erhalten gewöhnliche React-Props. Gestaltung, Auswahl und Bedingungen gehören zur App; eine eingebettete Geschäftskomponenten-Konfiguration ist dafür nicht erforderlich.

import React from "react";
import { components, useAppSettings, type AppMediaItem } from "ennea";

const { MediaGallery } = components;

export default function App() {
  const settings = useAppSettings();
  const items = Array.isArray(settings.instructions)
    ? (settings.instructions as unknown as AppMediaItem[])
    : [];
  return <MediaGallery items={items} />;
}

Deklariere die Liste instructions im Einstellungsschema der App. Jeder gespeicherte Eintrag enthält eine stabile id, mediaType (image, video, audio, pdf oder model3d) und fileId sowie optional Beschriftung und Sichtbarkeitsregeln. Die Veröffentlichung prüft und erhält diese strukturierten Dateiverweise. Eine Datei-ID nur im React-Quellcode deklariert kein veröffentlichtes Medium. Verwende den verwalteten Dateispeicher statt Dateidaten oder Speicher-URLs im Quellcode.

Für eine einzelne Datei verwende <MediaViewer mediaType="pdf" file={reference} label="Montageanleitung" />. Verweise können auch den vollständigen vorhandenen Nachweis-, Auftragsanhang- oder Instandhaltungskontext enthalten. Bei jedem Laden gelten aktuelle App-Zuweisung, Veröffentlichung sowie Datei- und Objektberechtigungen. Entzogener Zugriff, gelöschte oder gesperrte Dateien verhindern weitere Lesezugriffe.

ennea.files.open(reference, {signal}) lädt bis zu 250 MiB in begrenzten, an dieselbe Dateiversion gebundenen Abschnitten und liefert data.blob, name, mimeType und size. Ein Videoverweis mit delivery: 'playback' wählt die kompatible Wiedergabekopie. Die gemeinsamen Betrachter verwenden diesen Weg automatisch, zeigen Verarbeitung und Wiederholung an und geben temporäre Blob-URLs beim Dateiwechsel frei. Die Wiedergabe beginnt nach dem Laden; dies ist kein fortlaufendes Streaming. files.read bleibt für begrenzte Dateidaten einschließlich der vorhandenen Nachweis-API verfügbar.

PDFs bieten Seitenauswahl, Zoom, auswählbaren Text und Textsuche, sofern die Quelle Text enthält. Es wird jeweils eine Seite dargestellt. Browser-Codecs bestimmen die Audio- und Videowiedergabe. Verwende eigenständige GLB-Modelle für portable 3D-Anleitungen; externe Textur-/Modell-URLs können nicht geladen werden. CAD-Formate wie STEP oder STL benötigen vor der Vorschau eine Konvertierung. Prüfe tatsächliche Dateien in der veröffentlichten App mit dem vorgesehenen Shopfloor-Konto und Gerät, in beiden Sprachen und bei schmaler Ansicht.

Dateien und Fotos auf Modelldatensätzen

Ein Model-Feld vom Typ file speichert {runtimeFileId}. Jede Model-Datei ist auf 64 MiB begrenzt. Nutze accept: ["image"] für ein Foto oder {type: "list", items: {type: "file", accept: ["image"]}} für eine Fotoserie. Erlaubte Arten sind image, pdf, video, audio und model3d; ohne accept sind alle Arten möglich. Spätere Revisionen dürfen die Menge erweitern. Dateien dienen weder als Abfragefilter noch als Anzeigefeld, Gruppierung oder Ereigniszustand.

Für eine Gestellrückgabe erhält das Model das Feld returnConditionPhoto und registerReturn den Parameter returnPhoto, jeweils mit {type: "file", accept: ["image"]}. Der Effekt lautet {set: "returnConditionPhoto", to: {param: "returnPhoto"}}. Wähle das tatsächliche Foto über die vertrauenswürdige Dateiauswahl aus, lade es hoch und sichere Upload-Aufruf und Datei-ID. Rufe die Aktion mit parameters: {returnPhoto: {runtimeFileId: fileId}} auf. Behalte bei ungewissem Ergebnis dieselbe Eingabe und Aufruf-ID. Konnie kann keine Datei auswählen oder hochladen; es kann einen Wert behalten oder leeren oder eine Datei verwenden, auf die der Benutzer bereits zugreifen darf.

Ein gespeichertes Foto öffnest du mit ennea.files.open({runtimeFileId, recordContext: {modelId, recordId, field: "returnConditionPhoto"}}) oder derselben Referenz in MediaViewer bzw. einem MediaGallery-Eintrag. files.read akzeptiert denselben Kontext. Für einen historischen Stand ergänze recordVersion. Jeder Abruf prüft aktuellen Geltungsbereich, eigenen/Arbeitsbereichszugriff, Datenschutzsperren und Dateiberechtigung. Gesperrte oder gelöschte Datensätze gewähren keinen Zugriff mehr. Eine gelöschte Datei lässt den Datensatz gültig und wird als nicht verfügbar angezeigt. Studio bietet Vorschauen im Datensatz und seinen verfügbaren Verlaufseinträgen.

Ein neuer Upload muss demselben Akteur im exakten Geltungsbereich gehören. Für vorhandene Dateien ist eine aktuell berechtigte Quelle nötig, getrennt von den Werten als fileContexts: [{runtimeFileId, recordContext: {modelId, recordId, field}}] oder als {runtimeFileId, sourceEvidenceId, sourceEvidenceSubject} bei Belegen. Dies gilt für create/update, Aktionsparameter/-effekte und aufgerufene Aktionen. Eine ID allein erteilt keine Berechtigung. Konnies workspaceModels readFile liest ausschließlich kontrollierte Metadaten.

Einen Produktionsnachweis erzeugen und aufbewahren

Binde eine veröffentlichte Dokumentvorlage über globalConfig.reportTemplates oder ein eingebettetes strukturiertes Layout über globalConfig.reportDefinitions. Verwende getrennte lokalisierte EN-/DE-Aliase und Definitionen, wenn sich Deckblatt und Layoutbeschriftungen unterscheiden, und wähle den Alias anhand der aktuellen App-Sprache. Zusammenarbeitende Apps verwenden bewusst dieselbe Definitionskennung und Version; ein unabhängiger Ablauf benötigt eine eigene Kennung.

Rufe ennea.reports.describe(alias) auf und sichere die tatsächliche Bindung vor reports.create: für eine eingebettete Definition expectedDefinitionId, expectedDefinitionVersion und expectedDefinitionDigest, für eine veröffentlichte Vorlage expectedTemplateId und expectedTemplateVersion. Sichere den genauen Titel, orderId, verfassten workingContent und die Vorgangskennung mit diesen Bindungen. Erfinde keine Vorlagenkennung und übernimm bei der Wiederherstellung keine geänderte Bindung stillschweigend.

Wenn du gespeicherte Beobachtungen in einen Fertigungsauftragsbericht übernimmst, setze requireSourceEvidence: true an dessen eingebetteter Definitionsbindung und übergib sourceEvidence: [{id, revision}] an reports.create. Erfasse jeden übernommenen kanonischen Fertigungsauftragsnachweis mit seiner aktuellen Revision, höchstens 100 eindeutige Verweise. Übergib ausdrücklich eine leere Liste, wenn kein generischer Nachweis übernommen wurde. Erstellung und identische Erstellungswiederholungen prüfen aktuelle Quellrevisionen, Berechtigungen und Datenschutzsperren. Frei verfasster Inhalt bleibt möglich; eigenständige Berichte ohne Auftrag können keine Auftragsnachweise verknüpfen. Kennungen in beliebigem Text oder JSON begründen diese Beziehung nicht.

Prüfe den Bericht und rufe anschließend ausdrücklich reports.finalize({template, reportId, version}) mit seiner aktuellen Version auf. Sichere die tatsächliche endgültige Version vor reports.savePdf({template, reportId, version, invocationId}). Das speichert das unveränderliche endgültige PDF als kanonische Laufzeitdatei. Sichere data.file.id und verknüpfe es anschließend über Nachweis-media. Setze nach einem unbekannten Ausgang jede Phase mit ursprünglicher genauer Eingabe und Vorgangskennung fort. Ein gespeichertes PDF schließt die Produktionsarbeit nicht ab.

Bericht und PDF behalten typisierte Beziehungen zu ihren Quellen. Gewöhnliche spätere Nachweisänderungen schreiben einen historischen Bericht nicht um. Einschränkung, Anonymisierung oder Löschung der Quelle sowie entzogene Quellberechtigungen können weitere Lesezugriffe verhindern. Öffne die Daten über die aktuell berechtigten Berichts-, Nachweis- und Datei-APIs; kopiere Dateien oder Datensätze nicht in einen eigenen App-Speicher.

Der vertrauenswürdige Download-Dialog gibt den Tastaturfokus an das auslösende Bedienelement zurück, solange dessen App aktiv und das Bedienelement weiterhin verfügbar ist. Wird die App ausgeblendet, ersetzt oder geschlossen, verschiebt ein verspätetes Download-Ergebnis den Fokus nicht in die alte Laufzeit.

Mit Materialträgern arbeiten

ennea.materialFlow.overview liest Träger, Materialobjekte und Zuordnungen. execute unterstützt das Erstellen eines Ausgabeobjekts, Platzieren, Zuordnen verfügbarer Mengen, Entnehmen/Freigeben von Zuordnungen, Umbuchen von Mengen, Korrigieren einer Zuordnung und Leeren einer ausdrücklichen Auswahl. Eine Position kann mehrere Wagen belegen; ein Wagen kann Mengen mehrerer Positionen enthalten, wenn seine Konfiguration gemischte Inhalte erlaubt.

Jede Bewegung nutzt eine ausdrückliche Auswahl, eine Vorgangskennung und bei Bedarf die aktuellen Revisionen. Zeige Quelle, Ziel und Menge vor der Bestätigung. Bewegung oder Entnahme meldet keinen Produktionsfortschritt. Korrekturen und Leeren benötigen eigene deklarierte Fähigkeiten. Konnie kann Auswahl, Scannen oder eine andere passende Bedienung umsetzen, ohne eine neue Plattformkomponente einzuführen.

Speichere die absolute produzierte Menge, bevor du physische Ausgabemengen zuordnest. Aktive Zuordnungen dürfen den gemeldeten Ausstoß nicht überschreiten; der gemeldete Fortschritt darf nicht unter aktive Zuordnungen sinken. Buche oder entnimm nur die angeforderte Teilmenge der genauen Zuordnung und Revision; erhalte fremde gemischte Inhalte. Die Entnahme erhält die ursprüngliche Ausgabeidentität und macht deren Einheiten erneut zuordenbar. Verwende die tatsächlichen Trägerpositionen und passende Einheiten; eine Auftragsreferenz allein bezeichnet keine physische Ausgabemenge.

In der Produktionsfortschritts-App warten die Bedienelemente für Materialbewegungen, während Nachweise und Materialträger aktualisiert werden. Das eingegebene Ziel, die Position und die Menge bleiben nach der Aktualisierung verfügbar.

Fortschritt und Stationsabschluss melden

Verwende ennea.productionStation.write('reportProgress', ...) für absoluten Fortschritt eines Ausführungsteils: übergib die gewünschte quantityProduced mit beobachteter expectedQuantity und expectedQuantityProduced. Nutze completePosition für den atomaren Abschluss der genau angezeigten Arbeitsgänge und finishOrder für die ausdrückliche abschließende Bestätigung der Station. Übermittle den beobachteten Plan und die Revisionen. Der Server lehnt geänderte Ausgangswerte ab, statt gleichzeitige Arbeit zu überschreiben. Bisherige Differenzzähler und direkte Fortschritts-/Statusänderungen an Auftrag, Arbeitsgang oder Ausführungsteil umgehen den geschützten nativen Weg nicht. Die vollständig gemeldete Menge ist vom ausdrücklichen Abschluss getrennt.

Lies Auftragsliste, Auftrag und Verlauf über productionStation.read. Die App bestimmt, welche anderen Schritte angezeigt werden, wie deren Abschluss dargestellt wird und welche Aktionen folgen. Die Verpackungsvorbereitung kann eine Berechnung speichern und ihre Arbeit fertigmelden. Abholung kann optionale Medien speichern und Fortschritt oder Abschluss bestätigen; die Entnahme aus einem Materialträger ist eine eigene Trägeraktion.

Veröffentlichte Stationsanforderungen durchsetzen

Veröffentliche enforceChecklistCompletion: true auf oberster Einstellungsebene, um eine nicht leere Auswahl aus erforderlichen checklistItems, requirePhoto, requiredEvidenceKinds oder requireHolder am gebundenen Arbeitsplatz durchzusetzen. Alle aktiven veröffentlichten Regeln dieser Station gelten gemeinsam innerhalb des genauen Mandanten, Standorts und Systems. Sie gelten auch in unabhängigen Apps und nativen Abschlussaktionen. Eine Entwurfsänderung aktiviert keine Regel; Aktivieren, Ersetzen oder Entfernen geltender Anforderungen benötigt zusätzlich die Berechtigung work_center.manage.

Lies die aktuellen operation.completionRequirements. Speichere ausdrückliche Prüfergebnisse mit setChecklist, beobachteter Revision und bei einer anderen geltenden Regel deren genau zurückgegebenem completionPolicy: {appId, appVersion, settingsHash}. Unterstelle keine bestandene Prüfung. Erforderliche Nachweise müssen zu genauem Auftrag, Arbeitsgang und Ausführungsteil passen. Eine erforderliche Trägerbelegung muss in passender Einheit genau max(geplant, produziert) auf berechtigten vorhandenen Trägern abdecken; fremde gemischte Inhalte zählen nicht mit. Speichere vor endgültiger Zuordnung und Abschluss den vollständigen Produktionsfortschritt. Bereits abgeschlossene Historie wird nicht automatisch migriert; Wiederholungen klären bestehende Belege, statt neue Arbeit zu erzeugen.

Für eine wachsende Arbeitsplatzwarteschlange verwende ennea.productionStationPages.read('queueV2', {workCenterId, status, limit:20, cursor, boundedRead:true}) und lade nur den ausgewählten Ausführungsteil mit read('operationV1', {workCenterId, splitId, includeContext:true}). data.context enthält die bisherigen Arbeitsgangdetails, gespeicherte Prüfnachweise und aktuelle Abschlussbedingungen. Ohne includeContext bleibt die ursprüngliche Antwort von operationV1 erhalten. Bereits veröffentlichte Apps behalten ihren gespeicherten Quellcode und ihre Leseverträge.

Die App für Produktionsfortschritt lädt gemeinsame Auftragsnachweise ausdrücklich in Seiten von 20 über evidence.list({subject:{type:"productionOrder",id}, operation:{operationId,splitId}, limit:20, cursor}). Der optionale genaue Arbeitsgangbezug begrenzt die Berechtigungsprüfung auf die ausgewählten zugehörigen Datensätze und erhält gemeinsame Auftragsnachweise; er filtert Nachweise nicht auf diesen Ausführungsteil. Ein Artfilter ist dabei nicht zulässig. Nicht verfügbare oder gesperrte ausgewählte Datensätze führen zum Abbruch. Bestehende Abfragen ohne diesen Bezug behalten ihren ursprünglichen Vertrag. Für Materialträger verwendet sie materialFlow.overview({readMode:'operationV1', productionOrderId, operationId, executionSplitId, holderAfter, selectedHolderId}): Die Antwort enthält Ausbringung und Zuordnungen genau dieses Ausführungsteils, aufbewahrte unzugeordnete Materialidentitäten, belegte Träger und eine Seite möglicher Zielträger. Der optionale selectedHolderId lädt den aktuell ausgewählten Zielträger auch außerhalb der Seite erneut mit aktuellen Berechtigungs- und Sperrprüfungen, damit Auswahl, Position und Menge beim Aktualisieren erhalten bleiben. Folge nextHolderCursor mit Weitere Materialträger; ein nicht angezeigter Träger ist nicht automatisch leer. quantitiesComplete gilt nur für den ausgewählten Arbeitsgang; occupancyComplete:false trifft keine Aussage zu fremden Inhalten. Die Materialabfrage erlaubt bis zu 50 Ausbringungsobjekte und 100 aktive Zuordnungen sowie 20 mögliche Zielträger pro Seite zuzüglich belegter und des ausgewählten Zielträgers. Größere Auswahlen führen zum Abbruch, statt unvollständige Mengen anzuzeigen. Vor der Aktivierung müssen die benannten Abfrageindizes über die bestehenden Indexverfahren geprüft oder angelegt werden; fehlen sie, bricht die Abfrage ab. Schreibvorgänge prüfen weiterhin aktuelle Berechtigungen, Revisionen, Mengen und Abschlussbedingungen.

Die ausdrücklich gewählten begrenzten Lesemodi begrenzen auch die Verarbeitung von Datenschutz-Einschränkungen über die gesamte Anfrage einschließlich der Berechtigungsprüfung. Ein unvollständiger Einschränkungsstand erteilt niemals Zugriff; bei überschrittenen Grenzen oder fehlenden erforderlichen Indizes schlägt das Lesen fehl. Bestehende Aufrufe ohne diese Optionen behalten ihr bisheriges Verhalten. Ein ausdrücklich aus einem anderen Auftrag geteilter PDF-Nachweis behält die eigenständigen Berechtigungs- und Datenschutzprüfungen seines Quellauftrags; die Sichtbarkeit am gewählten Auftrag gewährt keinen Zugriff auf die Quelle.

Ohne doppelte Buchung wiederherstellen

Speichere vor dem Senden die genaue ausstehende Eingabe und stabile Vorgangs-/Idempotenzkennung im kontoprivaten App-Speicher. Wiederhole einen unklaren Schreibvorgang mit derselben Kennung und unveränderter Eingabe. Eine Zeitüberschreitung beweist keinen Fehlschlag. Nachweise liefern eine gespeicherte Quittung/Revision; eine abweichende Revision erfordert Neuladen und eine neue bewusste Speicherung.

Bei useAppDraft startet das Setzen eines Werts eine zeitversetzte Speicherung. Nimm vor einem verbindlichen Schreibvorgang die genaue Eingabe, Vorgangskennung sowie Ziel- und Versionskennungen in den Entwurf auf. Warte dann auf draft.save() und fahre nur beim Ergebnis true fort. Scheitert diese Sicherung, darf kein Schreibvorgang gesendet werden. Behalte für einen erneuten Versuch dieselben Daten und Kennungen bei und prüfe nach dem Warten erneut, ob Konto und aktive Aufgabe noch aktuell sind.

Hat ein anderes Fenster einen abweichenden Entwurf gespeichert, behalte beide Stände für eine ausdrückliche Prüfung durch die bedienende Person. Verwende draft.reconcile((local, saved, attempted) => mergedJson) mit einer reinen Zusammenführung, die vollständige ausstehende Eingaben, Ziel- und Versionsbindungen sowie jede Variante unklarer Vorgangskennungen erhält, einschließlich eines älteren versuchten Sicherungsstands. Der Callback erhält isolierte JSON-Werte und darf keine Fachvorgänge senden. Während der Wiederherstellung sind Entwurfsschreibvorgänge gesperrt; der zusammengeführte Wert wird bedingt mit der aktuellen Speicherrevision gesichert. Fahre nur beim Ergebnis true fort. Ein Fehler der Zusammenführung, eine volle Wiederherstellungswarteschlange oder ein weiterer Speicherkonflikt muss die Wiederherstellungsdaten erhalten und das Senden blockieren. Verwirf einen unklaren Vorgang niemals durch blindes Neuladen. Prüfe für ältere Laufzeitstände typeof draft.reconcile === "function". Fehlt die Methode, beende die Prüfung und lass die ursprüngliche App und Version geöffnet. Empfiehl bei einem unbestätigten privaten Sicherungsstand weder Neuladen noch Aktualisieren oder einen Versionswechsel.

Nur ein erfolgreich bestätigtes save oder reconcile sichert die Daten im kanonischen kontoprivaten Speicher. Unbestätigte oder widersprüchliche lokale Eingaben bleiben flüchtig im selben geöffneten Host und derselben Laufzeitidentität, einschließlich App-Version und Ausführungskontext. Ein vollständiges Browser-/Host-Neuladen, Absturz, Abmelden, Sitzungsablauf oder Versionswechsel erhält diesen privaten Speicher nicht. Die native Warnung vor dem Verlassen ist keine dauerhafte Sicherung.

Das Beispiel für Produktionsfortschritt erhält je Wiederherstellungsgruppe bis zu acht unterschiedliche Varianten von Vorgängen, Mengen/Auswahl und Nachweisentwürfen, einschließlich der aktiven Variante. Bei Überschreitung wird nichts verworfen. Die Person lädt den gespeicherten Arbeitsbereich ausdrücklich, prüft den ursprünglichen Auftrag/Ausführungsteil und wiederholt dann dieselbe Kennung über denselben geschützten Handler. Konnie übergibt die Auswahl widersprüchlicher Entwürfe an diese menschliche Prüfung. Danach kann Konnie den vorhandenen benannten Wiederholungsaufruf verwenden und muss bis dahin die ausstehende Prüfung statt eines Abschlusses melden. Der Assistenten-Snapshot enthält nur begrenzte Prüfhinweise und Anzahlen aufbewahrter Varianten, keine archivierten Eingaben.

Abonniere Änderungs- und Wiederverbindungsereignisse und lade Daten mit aktueller Berechtigung neu. Erhalte dabei ausgewählten Auftrag, offene Position und ungesendete Antworten. Prüfe Desktop und schmale Ansichten auf Deutsch und Englisch sowie gespeicherte Nachweise, Medien, Wagenbewegungen und Fortschritt mit fiktiven Datensätzen im vorgesehenen System. Ein kompilierter Entwurf oder eine Bürovorschau allein belegt keinen Bedienerzugriff.

Eine veröffentlichte Stationsrichtlinie kann zusätzlich requireFinalPhoto: true verlangen. Dies ist ein eigener Nachweis für die Übergabe des Kundenauftrags, kein Arbeitsgangfoto. Lies handoverRequirements aus dem aktuellen Auftrag, speichere den Nachweis mit dem zurückgegebenen evidenceKind, dem Bezug {type:"customerOrder",id:order._id} und data:{executionHash:order.executionHash} und aktualisiere vor finishOrder. Das Backend prüft die aktuellen Richtlinien, Bildfreigabe, Quell- und Datenschutzberechtigungen sowie die Nachweisrevision innerhalb der Transaktion. Das Wiederöffnen oder Ändern einer Ausführung macht ihren früheren Abschlussnachweis auch bei unveränderten Abschlusszeitstempeln ungültig. Die Übergabe bewahrt den angenommenen Nachweisstand, erhöht keine Fertigungsmenge und schließt den Kundenauftrag nicht global ab.