Aufträge, Ausführung und Abnahme
Diese Seite beschreibt die Kette aus Auftrag, Ausführungsplan, Übergabe und Abnahme. Aktionen hängen von Rechten, Kunde, Rechtsträger und dem Zustand des Arbeitsablaufs ab.
Auftrag erstellen und bestätigen
Öffnen Sie /operations/orders/new oder starten Sie aus einer Kundenkarte. Fügen Sie eine oder mehrere Auftragszeilen hinzu, insgesamt 1 bis 40. Jede Zeile hat ein eigenes Katalogangebot, eine Menge, Einheit und eingefrorene Preisbedingungen; die letzte Zeile kann nicht gelöscht werden. Gemischte Währungen sind unzulässig und blockieren das Senden. Bei fehlendem Verzeichnis oder fehlenden Bedingungen keine Nullen einsetzen und nicht blind erstellen; ein Fehler bei den Bedingungen gehört zur betroffenen Zeile und bietet nur dort einen neuen Versuch an.
\nNach der Auswahl des Kunden und des ersten Angebots/Preises schlägt das Portal einen Namen nach dem Muster „Angebot — Kunde“ vor. Solange Sie ihn nicht ändern, wird der Vorschlag bei einer anderen Auswahl aktualisiert; nach einer manuellen Änderung bleibt Ihr Text erhalten. Ein Auftrag darf ohne Namen bleiben und erhält in der Liste einen neutralen Fallback — erfinden Sie keine Daten für das Formular.
Der Ablauf lautet draft → submitted → confirmed → provisioned. Entwurf speichern, mit Beleg oder Referenz senden und mit der aktuellen Version bestätigen. Die Bestätigung macht den Auftrag verbindlich; Provisioning erzeugt den Ausführungsplan. Wird eine Aktion nicht angenommen, prüfen Sie Rechte und Pflichtfelder, laden Sie den Auftrag neu und wiederholen Sie sie erst danach.
Bei einer Zeile für Managed Service (managed_service) ist Service verbinden der eigene Schritt, der das Service-Recht anlegt oder wiederverwendet. Die Bestätigung des Auftrags oder der Start des Plans erzeugt dieses Recht nicht automatisch. Ist die Aktion nicht verfügbar oder erscheint unter Services und SLA kein Recht, prüfen Sie Zeilenstatus und Zugriff, lesen Sie die Karte neu und wiederholen Sie den Schritt nur mit aktuellen Daten.
In /operations/orders sind draft, submitted, confirmation_pending, confirmed, on_hold und completed filterbar. Zeilen können auch provisioned, fulfilled, cancelled oder closed tragen; diese Zustände bleiben beim Öffnen des Auftrags sichtbar. Tabelle/Karten, Summen, Seitenladen, Wiederholen und Leerzustände sind vorhanden.
Wenn Sie eine Zeile öffnen dürfen, erreichen Sie den Auftrags-Pass unter /operations/orders/:orderId. Dort sehen Sie Positionen, Beteiligte, Status und den nächsten verfügbaren Schritt. Die URL ist direkt aufrufbar und kann mit Kollegen geteilt werden; der Zugriff richtet sich weiterhin nach den Rechten.
Bei einem bestätigten Auftrag zeigt der Pass außerdem den Fortschritt jeder Planposition: planned, in_progress, handed_over, accepted oder cancelled. Sobald die übergebene Menge die erforderliche Menge erreicht, wird die Position als vollständig übergeben markiert, auch wenn der Status des übergeordneten Plans noch nicht nachgezogen wurde. Öffnen Sie für die Aktion /operations/fulfillment und lesen Sie die aktuelle Position neu; leiten Sie die Übergabe nicht allein aus dem Auftragsstatus ab.
Das Register startet mit allen lesbaren Kunden, lädt bis zu 25 Zeilen und setzt mit Mehr anzeigen die Liste fort. Status- und Kundenfilter sowie Tabelle/Karten gelten nur für diese Seite; ein leerer, gefiltert leerer und fehlerhafter Zustand sind zu unterscheiden.
Wenn die verknüpften Lesevorgänge erfolgreich sind, zeigt der Auftragspass Was aus diesem Auftrag entstanden ist mit Links zur Verpflichtungs- und Abnahmekarte. Der Block kann bei leerem Ergebnis oder Lesefehler fehlen; sein Fehlen beweist nicht, dass kein Folgeobjekt existiert.
Ausführung vorbereiten
In /operations/fulfillment Plan und Positionen prüfen. planning oder blocked wird zu ready, ready oder partially_completed kann gestartet werden. Jeder Übergang braucht eine Bestätigung oder eine Referenz und die aktuelle Version. Ein bestätigter Auftrag allein bedeutet nicht, dass der Plan bereit ist; prüfen Sie Positionen, Menge, Einheit, Verantwortlichen und Rechtsträger. Ein fehlendes Arbeitspaket kann noch nicht erstellt oder bereits im Bereich Arbeitspakete verknüpft sein.
Plan starten und eine einzelne Position übergeben sind verschiedene Schritte. Der Start versetzt den Plan in die Bearbeitung, übergibt aber keine Position. Die Übergabe ist nur bei in_progress möglich, solange die ausgewählte Position noch eine offene Menge hat; prüfen Sie Status und Restmenge vor der Aktion.
Das Übergaberegister umfasst standardmäßig alle Kunden; der Kundenfilter gilt nur für diesen Bildschirm und wird nicht gespeichert. Der Block mit geplanten, noch nicht übergebenen Positionen wird erst nach Auswahl eines Kunden geladen; entfernen Sie den Filter, um zu allen Übergaben zurückzukehren. Ein leerer Planblock ohne ausgewählten Kunden beweist nicht, dass keine Daten vorhanden sind.
Jede Lieferung auf einer Kundenkarte führt jetzt hierher und übernimmt den Kundenfilter in der URL; die Zeile öffnet außerdem eine eigene Lieferungsdetailkarte unter /operations/fulfillment/deliveries/:deliveryId. Diese Karte zeigt Details und Status. Die Zeilenaktionen Abnahme öffnen, Rückgabe, Korrigieren, Problem melden und Stornieren werden weiterhin im Register gestartet. Die Zeile verwendet, sofern vorhanden, den menschlichen Anzeigenamen der Lieferung; nur bei älteren Datensätzen fällt sie auf die Lieferart zurück.
Beim Öffnen kann die Detailkarte zunächst einen Ladezustand anzeigen; warten Sie, statt daraus fehlende Daten abzuleiten. Bei einem vorübergehenden Fehler wird Erneut versuchen angeboten; der erneute Abruf liest die Karte neu ein und führt keine Aktion aus. Bei fehlender Berechtigung beantragen Sie Zugriff oder kehren Sie zum Register zurück — das bedeutet nicht, dass die Lieferung fehlt. Eine Karte ohne Positionen kann ein gültiger leerer Zustand sein: Sie bietet keine Aktionen und ist selbst kein Fehler.
Lieferungen verwenden das gemeinsame Register mit Tabelle/Karten und einem Aktionsmenü pro Zeile. Nicht verfügbare Aktionen bleiben mit Begründung sichtbar; nach einer Aktion das Register neu lesen, denn eine Erfolgsmeldung ersetzt nicht die Prüfung des Status.
Eine leere Zelle „Arbeitspaket“ kann ebenfalls normal sein: Wenn executionContainerPolicy=work_order nicht verwendet wird, wird die Arbeit an der Position geführt; das beweist jedoch nicht, dass eine Aufgabe erstellt, zugewiesen oder erledigt wurde. Wenn die Richtlinie ein Arbeitspaket verlangt, bedeutet „Noch nicht erstellt“ nur, dass das Paket noch nicht materialisiert ist, nicht dass ein Zugriffsfehler vorliegt. Im aktuellen Portal bieten Lebenszyklus und Paket eines Arbeitspakets keinen Weg, eine Aufgabenkomponente zu erstellen oder zu versenden, und sie beweisen nicht, dass eine ausführende Person die Arbeit erhalten oder abgeschlossen hat. Prüfen Sie vor Übergabe oder Abschlussprüfung das tatsächliche Ergebnis im vereinbarten Aufgaben- und Zuständigkeitskontext; fehlt es, halten Sie an und fragen Sie die Portalverantwortung, statt dies per direktem API-Aufruf zu umgehen.
Position übergeben
Die Übergabe ist nur bei in_progress und nur für noch nicht übergebene oder abgenommene Menge möglich. Nachweis und Methode angeben: physische Ware nutzt shipment, andere Typen den Serviceweg. Bei Teilergebnis erst Plan und Historie aktualisieren, nicht blind wiederholen. Bereits übergebene Position, veraltete Revision und Konflikt sind getrennte Ergebnisse. Eine Stornierung braucht einen nicht leeren Grund.
Das Zeilenmenü bietet Korrigieren und Rückgabe, sobald etwas übergeben wurde; beide
benötigen eine Beschreibung und gelten nur für eine Lieferung mit genau einer Position. Die
Rückgabe benötigt außerdem die aktuelle Lieferrevision und ist nach einer Abnahmeentscheidung
nicht mehr möglich; die Korrektur wird neben dem Original protokolliert. Bei keiner oder mehreren
Positionen erklärt das Menü die Einschränkung. Status wie ready_for_handoff, received,
accepted, returned und exception beschreiben den Registerzustand, nicht automatisch eine
Lagerbewegung.
Wenn nach der Übergabe eine Lieferung erscheint, aber die Bestätigung fehlt, lesen Sie das Register erneut, statt eine zweite Lieferung zu erstellen. Für die Stornierung sind Grund und eine aktualisierte Karte nötig; eine bereits übergebene Position kann nicht storniert werden.
Eine versehentlich erstellte Lieferung kann nur in planned, ready_for_handoff oder exception zurückgezogen werden, solange noch keine Übergabezeile geschrieben wurde. Nach der Übergabe wird die Aktion nicht angeboten. Das Zurückziehen benötigt einen Grund und die aktuelle Kartenversion; bei Erfolg erhält die Lieferung den Status cancelled. Das Datum im Register ist die Erstellzeit, nicht das Übergabedatum; ob übergeben wurde, ergibt sich aus dem Status.
Wenn die aktuelle Version Report a problem anbietet (in einer bereits lokalisierten Oberfläche kann die Aktion als Problem melden erscheinen), wird damit nur ein Vorfall erfasst, nicht die Ware verändert. Das kann bei planned, ready_for_handoff, partially_handed_over und handed_over verfügbar sein; beschreiben Sie, was passiert ist. Die Lieferung wird als problematisch markiert, aber weder Rückgabe noch Abnahme oder Lagerbewegung werden gestartet. Bei geändertem Zustand oder Kartenstand das Register neu laden und erneut prüfen.
Auf der Abnahmekarte ist der Titel des Ursprungsauftrags nun ein Link zu /operations/orders/:orderId, sofern der Auftrag geöffnet werden darf. Ist der Titel nicht verfügbar oder lädt noch, verwendet das Portal eine neutrale Bezeichnung und zeigt keine technische ID.
Abnahme prüfen
/operations/acceptance und die Abnahmekarte zeigen Auftrag, angenommene und abgelehnte Mengen, Status, Nacharbeitswarnung, Daten, Dokumente und Historie. Eine bestimmte Abnahmekarte lässt sich direkt unter /operations/acceptance/:acceptanceCaseId öffnen. Die Oberfläche kann für den aktuellen Benutzer schreibgeschützt sein; Abnehmen, Nacharbeit und Ablehnen benötigen eigene Rechte und Funktionstrennung. Keine nicht sichtbare Aktion versprechen.
Im gemeinsamen Register wird jede Abnahme nach dem Titel des Ausgangsauftrags benannt; solange
dieser Titel nicht geladen ist, erscheint der neutrale Fallback Abnahme. Die Status werden als
draft (Entwurf), collecting_evidence (Nachweise sammeln), ready_for_submission (Bereit zur
Übermittlung), submitted (An Kunden gesendet), pending (Entscheidung ausstehend),
under_review (In Prüfung), partially_accepted (Teilweise angenommen), accepted, rejected
und cancelled (Zurückgezogen) angezeigt. Bei ready_for_submission zeigt die Oberfläche
An Kunden senden; der Versand startet einen separaten Genehmigungsablauf und kann die
Bestätigung eines zweiten Mitarbeiters gemäß Funktionstrennung erfordern.
Abnahme öffnen gehört zu einer einzelnen Lieferposition mit Status handed_over, nicht
allein zum Lieferstatus: Auch bei einer Lieferung im Status exception kann die Aktion
erscheinen, wenn diese übergebene Position noch abgenommen werden muss. Bei einer
zurückgegebenen oder stornierten Lieferung wird sie nicht angeboten.
Wählen Sie auf der Abnahmekarte zuerst Nachweis hinzufügen: Aus draft wechselt der Fall damit zu collecting_evidence.
Auf der Abnahmekarte kann der Mitarbeiter den Fall nur aus draft zurückziehen; dafür
sind ein nicht leerer Grund und die aktuelle Fallrevision nötig. Bereit zur Übermittlung
erscheint nur aus collecting_evidence und benötigt einen nicht leeren, unveränderlichen
Evidence-Wasserzeichenwert. Bei ready_for_submission startet An Kunden senden den
Genehmigungsantrag; der technische Entscheidungsbezug wird im Benutzertext nicht angezeigt.
Die Entscheidung des Kunden (decide) läuft als eigener Weg der
anderen Partei und ist keine Mitarbeiteraktion. Abnehmen, Nacharbeit und Ablehnen benötigen die
entsprechende Berechtigung und Funktionstrennung.
Hat der Kunde das Ergebnis außerhalb des Portals bestätigt, darf ein manueller Nachweis nur aus einer tatsächlichen externen Bestätigung erfasst werden: bestätigende Person, Grundlage, Zeitpunkt sowie angenommene oder abgelehnte Menge angeben. Der Nachweis wird zuerst erfasst und anschließend mit einer eigenen Bestätigung auf den Fall angewendet. Bei Funktionstrennung darf die Person, die Fall, Lieferung oder Position angelegt hat, nicht erfassen; die erfassende Person darf nicht anwenden. Das sind zwei verschiedene nächste Schritte. Das Portal kann einen erfassten Nachweis nicht an einen Kollegen übergeben und nach Verlassen der Seite nicht über einen technischen Code erneut öffnen. Den Code nicht kopieren, die Regel nicht per Direktaufruf umgehen und die zweite Person vor der Erfassung abstimmen.
Nach einer Entscheidung mit accepted oder partially_accepted bietet die Annahmekarte eine Aktion zum Sicherstellen des Abrechnungspostens und einen Link zu Abrechnungsposten (Route /operations/billing?view=charges). Für den Posten wird kein Betrag eingegeben: Der Server leitet ihn aus angenommener Menge, eingefrorenen Bedingungen und der Richtlinie, Einheitspreis und zulässiger Genauigkeit ab. Eine Wiederholung ist idempotent: Die Karte unterscheidet „Posten erstellt“ von „Posten bereits vorhanden“ und legt keinen zweiten an. Die Aktion erfordert die passende Capability und die Trennung der Aufgaben; ein deaktivierter Abrechnungstrigger, ungültiger Preis/Bedingungen/Genauigkeit, ungültiger Annahmestatus oder -ursprung, nicht gefundener Datensatz und Versionskonflikt sind getrennte Fehler (bei Konflikt Karte neu laden). Betrag nur in der Währung der ausgewählten Locale und Rechtseinheit zeigen; Beispiele synthetisch halten, ohne echte Rechnungen, Bank- oder Kundendaten.
Nachweise, Geld und Datenschutz
Nur synthetische Daten verwenden. Bei Beträgen prüfen, dass die Währung zu Sprache und Rechtsträger passt. Bestätigungen müssen Ereignis, Verantwortlichen und Auftragsversion erklären. Keine echten Verträge, Rechnungen, Bankdaten, Tokens oder Kundendaten zeigen. Nach Fehlern Zustand und Historie prüfen und nur mit der aktuellen Version wiederholen.
Verwandte Seiten