Dieses Feld steuert die Zuordnung eines Requirements zu dem Produkt.

Dieses Feld ist ein Textfeld, in dem der Name des veranlassenden Sachbearbeiters angegeben wird.

Die Sachbearbeiterkennzeichen können in den Anwendungsprogrammen über den List-Button angezeigt werden.
Richtige Angaben in diesem Feld sind im Hinblick auf Auskunft und statistische Aufbereitung wichtig. So sind manche Druckausgaben, zum Beispiel die Auftragsbestätigungen und die Rechnungen, nach Sachbearbeitern sortiert (nur im Stapelaufruf).
Das Sachbearbeiterkennzeichen wird im Auftragskopf (Bestellkopf) und in den Auftragspositionen (Bestellpositionen) gespeichert. Die Auskunftsprogramme lassen in der Regel eine Eingrenzung nach Sachbearbeiter zu, sodass alle Abfragen entweder für einen oder für alle Sachbearbeiter gestartet werden können.
Außerdem ist das Sachbearbeiterkennzeichen als Schlüssel in der Statistikdatei (ISTOPP) abgespeichert, und somit können alle Umsätze/Auftragseingänge (Bestellungen/Wareneingänge) pro Sachbearbeiter ausgewertet werden.

Für den Verkauf gelten folgende Voraussetzungen:
Das Sachbearbeiterkennzeichen wird, sofern vorhanden, aus dem Kundenstammsatz in den Auftrag übernommen. Ist im Kundenstamm keines vorhanden, so wird das beim Kennwort hinterlegte Sachbearbeiterkennzeichen eingetragen. Dieses kann im Auftrag so lange überschrieben werden, bis eine Auftragsposition erfasst ist. Änderungen danach wirken sich auf bereits erfasste Positionen in der Statistik nicht mehr aus.
Wird ein Kennzeichen eingegeben, muss dieses in der Kennwortdatei angelegt sein.

Das Kennzeichen des Sachbearbeiters wird bei der Neuanlage eines Dokumentes vom System automatisch vergeben.
Siehe auch:
- Sachbearbeiter (Kennzeichen)

Die Problemklasse klassifiziert Entwicklungsobjekte bezüglich ihres Inhaltes. Mit Hilfe der Problemklasse ist eine inhaltlich differenzierte Auswertung von Entwicklungsobjekten möglich.

Die dazugehörige Tabelle ist FRDPKL (Problemklassen für Entwicklungsobjekte).

In diesem Feld wird die Priorität eines Entwicklungsobjektes angegeben.

Die gültigen Werte sind in der Tabelle FRDPRR (Priorität Entwicklungsobjekt) hinterlegt.

In diesem Feld wird die Adresse oder das Personenkonto angegeben, die bearbeitet werden soll. Erlaubt sind beliebige Kombinationen der Ziffern von "0" bis "9".

Erfolgt im Feld "Filiale" keine Eingabe, wird, falls für die eingegebene Adresse mehrere Filialen vorhanden sind, in das Matchcode-Programm "Filialen" verzweigt. Existiert genau eine Filiale, wird diese in das Eingabefeld übertragen.

Erfolgt bei einem Personenkonto keine Angabe der "Kontenart", so wird, falls für die angegebene Adresse mehrere Kontenarten vorhanden sind, in das Matchcode-Programm "Kontenart" verzweigt. Existiert genau eine Kontenart, wird diese in das Eingabefeld übertragen.

Existiert das eingegebene Konto nicht, so wird ein entsprechender Hinweis angezeigt.

Weitere Informationen zur Ermittlung der Nummer des Personenkontos finden sich unter PKNR_Detail.

Die zu einer Adresse hinterlegten Ansprechpartner werden laufend nummeriert. Dadurch wird ein Ansprechpartner durch die 7-stellige Adressnummer, die Filialnummer sowie eine laufende Nummer eindeutig identifiziert.

In diesem Feld ist die aktuelle Release- bzw. Versionsnummer des Programms angegeben.

In diesem Feld wird das Anwendungsgebiet des Designs angegeben. Ein Design wird durch die Design-Anwendung, die Design-Klasse und die Design-ID eindeutig identifiziert.
Die gültigen Werte sind in der Datei UIANWP hinterlegt und können über den List-Button angezeigt werden.

Ein Design wird durch die Design-Klasse und die Design-ID eindeutig identifiziert.
Die Design-ID wird beim Erfassen eines Designs vom System vergeben.

In diesem Feld kann ein Begriff angegeben werden, unter dem Requests zu einer Gruppe zusammengefasst werden.
Beispiel:
AUSKUNFT
Alle Requests, die diese Thematik behandeln, werden diesem Stichwort zugeordnet.

Dieses Feld beschreibt den Namen des Dokuments.

Der in diesem Feld angegebener Wert steuert, ob das Dokument als PC-Dokument abgelegt wird.

Datum der erstmaligen Erfassung. Bei der Neuanlage einer Änderungsdokumentation wird als Default das Systemdatum eingestellt.

In diesem Feld wird der Name des Objektes angegeben, das bearbeitet werden soll. Wenn mehrere Programme bearbeitet werden müssen oder bei "VVs" muss der Eintrag "ALLGEM" vorgenommen werden.

Die Ticketnummer identifiziert zusammen mit der Firma einen Eintrag im SAS-Helpdesk eindeutig. Die Nummer wird maschinell ermittelt und fortlaufend hochgezählt.

Hier wird der Aufwand in Tagen angegeben. Der kleinste mögliche Wert ist 0,5 Tage.

Der Fertigstellungsgrad Design ist eine Prozentzahl, die den Entwicklungszustand eines Designs widerspiegelt.

Wenn ein Design freigegeben wird, wird der Fertigstellungsgrad automatisch auf "100" gesetzt.

Geschätzter Aufwand in Tagen. Der kleinste mögliche Wert ist 0,5 Tage.
Wenn sich der Aufwand für die Realisierung eines Designs ändert, muss dieses Feld aktualisiert werden.

Der Projektleiter trägt in regelmäßigen Abständen den aktuellen Stand der Designbearbeitung als Prozentzahl ein.

Nach der Realisierung eines Designs (Status "250") wird automatisch der Wert "100" eingestellt.

Geschätzter Aufwand in Tagen. Der kleinste mögliche Wert ist 0,5 Tage.
Wenn sich der QS-Aufwand für ein Design ändert, muss das Feld aktualisiert werden.

Prozentzahl, die den Stand des Testes angibt.

Dieses Datum gibt an, wann mit der Realisierung des Entwicklungsobjektes begonnen werden kann.

Dieses Feld hat keine steuernde Funktion.

Dieses Datum gibt an, wann die Realisierung des Entwicklungsobjektes beendet sein sollte.

Dieses Feld hat keine steuernde Funktion.

Dieses Datum gibt an, wann der Test des Entwicklungsobjektes beendet sein sollte.

Das Feld kann immer dann mit einer separaten Projektunternummer gefüllt werden, wenn die Designerstellung voraussichtlich mehr als 3 MT Aufwand bedeutet.

Sachbearbeiterkennzeichen der verantwortlichen Person für ein Objekt und eine Aufgabe.
Bei einer Kopiervorlage für Workflows kann für ausgewählte Bereiche auch ein Platzhalter wie z.B. "&&PRL" für Projektleiter aus dem Projektkopf eingetragen werden. Wird die Kopiervorlage für einen konkreten Beleg oder Vorgang verwendet, so ersetzt das Programm den korrekten Sachbearbeiter.

Lesen Sie auch hier nach:
Handbuch Workflow
Wichtige Tabellen:
FRDSFK Sachbearbeiter für Kopiervorlage

Dieses Feld soll gefüllt werden, wenn der Designersteller eine andere Person als der Designverantwortliche ist.

Für Browser- und RSS-Gadgets kann in diesem Feld eine URL hinterlegt werden. Diese URL wird in der Regel benötigt um Daten von diesem angegebenen Speicherort anzuzeigen (Browser-Gadget: Homepage; RSS-Gadget: Nachrichten). Beim Hinzufügen von Gadgets zu Dashboards wird die hier hinterlegte Adresse/URL bei dem entsprechenden Gadget vorbelegt, um Konfigurationsaufwand zu sparen.

In diesem Feld wird der Status des entsprechenden Requests/ Designs angegeben. Die gültigen Werte sind in der Tabelle FRDSTA (Status von Entwicklungsobjekten) hinterlegt.

Diese Feld hat keinen festen Inhalt und wird zurzeit nicht verwendet.

Dieses Feld beschreibt die Außensicht der internen Statuswerte in der RQ-/Designverwaltung und ist für die Anzeige in der Internet-RQ-Verwaltung gedacht. Es fasst die mannigfachen Ausprägungen des internen RQ-/Design-Status FRDSTA in vier Ausprägungen wie folgt zusammen:

• * - Status unbestimmt (nur für technische Zwecke)
• 1 - Eingegangen (es ist noch keine Entscheidung über sofortige Ablehnung oder potentielle Realisierung gefallen, interner Status "100")
• 2 - Abgelehnt (Ablehnung entweder explizit durch Setzung des internen Status "160" / "260" oder implizite Ablehnung wegen Alters - FRDRLG
• 3 - In Entscheidungsfindung (solange der RQ nicht realisiert ist, interner Status < "250" bzw. "270" / "280")
• 4 - Realisiert (der RQ ist realisiert, interner Status 150, 151, 25*, 29*)

Ablehnungsgründe dokumentieren Entscheidungen, die zur Ablehnung von Entwicklungsobjekten geführt haben. Mit Hilfe der Ablehnungsgründe ist es möglich, abgelehnte Entwicklungsobjekte differenziert auszuwerten. Hierzu können z.B. Auswertungen aller Designs gehören, die auf das nächste Release verschoben wurden.

Die gültigen Werte sind in oben genannter Tabelle hinterlegt und können über den List-Button angezeigt werden.

Datum, an dem ein RQ-Brief abgesendet worden ist.

In diesem Feld wird der Name des Dokumentes angegeben, das an einen Kunden versendet worden ist.
Jeder Kunde erhält bei Einsendung eines Requests einen Brief, der ihn über die weitere Vorgehensweise informiert.

Die Online Freigabe bestimmt, ob das Ticket auf der Internetseite der oxaion gmbh angezeigt wird. Für die permanente RQ-Abstimmung über die oxaion Tickets werden alle entsprechend gekennzeichneten Requests angezeigt. Für andere Tickets, die im Supportbereich des Kunden angezeigt werden, erfolgt die Vorbelegung dieses Feldes aus der Ticketart (Tabelle FRDTDT und kann bei Bedarf in der internen Ticketverwaltung durch einen oxaion Mitarbeiter geändert werden.

Der Text enthält die Internet-Beschreibung des RQ. Es können bis zu 1024 Zeichen erfasst werden.

In diesem Feld wird der Status des entsprechenden Requests/ Designs angegeben. Die gültigen Werte sind in der Tabelle FRDSTA (Status von Entwicklungsobjekten) hinterlegt.

Ablehnungsgründe dokumentieren Entscheidungen, die zur Ablehnung von Entwicklungsobjekten geführt haben. Mit Hilfe der Ablehnungsgründe ist es möglich, abgelehnte Entwicklungsobjekte differenziert auszuwerten. Hierzu können z.B. Auswertungen aller Designs gehören, die auf das nächste Release verschoben wurden.

Die gültigen Werte sind in oben genannter Tabelle hinterlegt und können über den List-Button angezeigt werden.

Hier kann ein konstanter Text angegeben werden, der an Stelle eines Feldes ausgegeben wird. Der Text muss nicht in Hochkommata eingeschlossen werden. Angegebene Hochkommata werden mit ausgegeben.

Dieses Datum gibt an, wann mit der Realisierung des Entwicklungsobjektes begonnen werden kann.

Dieses Feld hat keine steuernde Funktion.

Dieses Datum gibt an, wann die Realisierung des Entwicklungsobjektes beendet sein sollte.

Dieses Feld hat keine steuernde Funktion.

In diesem Feld kann angegeben werden, ob für das Design ein Testfall erstellt werden soll.

Der Name des Testfalles muss für die Dokumentation und Nachvollziehbarkeit hier hinterlegt werden. Wenn mehrere Testfälle erstellt worden sind, reicht es aus, den ersten Testfall zu hinterlegen.

Dieses Datum gibt an, wann der Test des Entwicklungsobjektes beendet sein sollte.

Angabe der Projektunternummer, die zur weiteren Aufschlüsselung eines Projektes dient.

Der Projektleiter ist für die ordnungsgemäße Durchführung eines Projektes verantwortlich.
Spätestens mit der Freigabe eines Designs wird durch PP bei übergreifenden Designs oder durch den Entwicklungsverantwortlichen bei fachspezifischen Designs der Projektleiter für die Realisierung bestimmt.
Realisierte Designs erhalten durch den Projektleiter den Status "250".

Angabe der Projektunternummer, die zur weiteren Aufschlüsselung eines Projektes dient.

Dieses Feld beschreibt das Release, in welchem das vorliegende Design voraussichtlich realisiert wird oder in welchem es tatsächlich realisiert worden ist.

Geschätzter Aufwand in Tagen. Der kleinste mögliche Wert ist 0,5 Tage.
Wenn sich der Aufwand für die Realisierung eines Designs ändert, muss dieses Feld aktualisiert werden.

Geschätzter Aufwand in Tagen. Der kleinste mögliche Wert ist 0,5 Tage.
Wenn sich der QS-Aufwand für ein Design ändert, muss das Feld aktualisiert werden.

Der Projektleiter trägt in regelmäßigen Abständen den aktuellen Stand der Designbearbeitung als Prozentzahl ein.

Nach der Realisierung eines Designs (Status "250") wird automatisch der Wert "100" eingestellt.

Prozentzahl, die den Stand des Testes angibt.

In diesem Feld wird der Status des entsprechenden Requests/ Designs angegeben. Die gültigen Werte sind in der Tabelle FRDSTA (Status von Entwicklungsobjekten) hinterlegt.

Ablehnungsgründe dokumentieren Entscheidungen, die zur Ablehnung von Entwicklungsobjekten geführt haben. Mit Hilfe der Ablehnungsgründe ist es möglich, abgelehnte Entwicklungsobjekte differenziert auszuwerten. Hierzu können z.B. Auswertungen aller Designs gehören, die auf das nächste Release verschoben wurden.

Die gültigen Werte sind in oben genannter Tabelle hinterlegt und können über den List-Button angezeigt werden.

Hier kann ein konstanter Text angegeben werden, der an Stelle eines Feldes ausgegeben wird. Der Text muss nicht in Hochkommata eingeschlossen werden. Angegebene Hochkommata werden mit ausgegeben.

Dieses Datum gibt an, wann mit der Realisierung des Entwicklungsobjektes begonnen werden kann.

Dieses Feld hat keine steuernde Funktion.

Dieses Datum gibt an, wann die Realisierung des Entwicklungsobjektes beendet sein sollte.

Dieses Feld hat keine steuernde Funktion.

In diesem Feld kann angegeben werden, ob für das Design ein Testfall erstellt werden soll.

Der Name des Testfalles muss für die Dokumentation und Nachvollziehbarkeit hier hinterlegt werden. Wenn mehrere Testfälle erstellt worden sind, reicht es aus, den ersten Testfall zu hinterlegen.

Dieses Datum gibt an, wann der Test des Entwicklungsobjektes beendet sein sollte.

Angabe der Projektunternummer, die zur weiteren Aufschlüsselung eines Projektes dient.

Der Projektleiter ist für die ordnungsgemäße Durchführung eines Projektes verantwortlich.
Spätestens mit der Freigabe eines Designs wird durch PP bei übergreifenden Designs oder durch den Entwicklungsverantwortlichen bei fachspezifischen Designs der Projektleiter für die Realisierung bestimmt.
Realisierte Designs erhalten durch den Projektleiter den Status "250".

Angabe der Projektunternummer, die zur weiteren Aufschlüsselung eines Projektes dient.

Dieses Feld beschreibt das Release, in welchem das vorliegende Design voraussichtlich realisiert wird oder in welchem es tatsächlich realisiert worden ist.

Geschätzter Aufwand in Tagen. Der kleinste mögliche Wert ist 0,5 Tage.
Wenn sich der Aufwand für die Realisierung eines Designs ändert, muss dieses Feld aktualisiert werden.

Geschätzter Aufwand in Tagen. Der kleinste mögliche Wert ist 0,5 Tage.
Wenn sich der QS-Aufwand für ein Design ändert, muss das Feld aktualisiert werden.

Der Projektleiter trägt in regelmäßigen Abständen den aktuellen Stand der Designbearbeitung als Prozentzahl ein.

Nach der Realisierung eines Designs (Status "250") wird automatisch der Wert "100" eingestellt.

Prozentzahl, die den Stand des Testes angibt.

Unter einer Anwendung werden Programme und Dateien zusammengefasst, die ein bestimmtes Cockpit betreffen (z.B. Einkaufssystem oder Finanzbuchhaltung).

Die gültigen Anwendungen sind in Tabelle Anwendung (FRDANW) hinterlegt.

Die Entwicklungsobjekt-Identifikation ist eine fortlaufende Nummerierung innerhalb einer Objektklasse.
Der Name der RQ-Dokumente bzw. Designdokumente setzt sich aus der Objektklasse und der Entwicklungs-Identifikation zusammen.
Beispiel:
Für RQ-Dokument
--> Im Ordner DOKV5.3/UST/RQ wird das Dokument R00016 erstellt.
Für Design-Dokument
--> Im Ordner DOKV5.3/UST/Design wird das Dokument D0001000 erstellt.
Für VV-Dokument
--> Im Ordner DOKV5.3/UST/VV wird das Dokument Z00034 erstellt.