Bug 12447

Summary:	DCO-P Cockpit: Bearbeitungskennzeichen kann nach Datenaufbau nicht zugeordnet werden
Product:	[SCX/Suite] Operations	Reporter:	Klaas, Martina <Martina.Klaas>
Component:	Projekt	Assignee:	Klaas, Martina <Martina.Klaas>
Status:	VERIFIED FIXED	QA Contact:	Grab, Felix <Felix.Grab>
Severity:	trivial
Priority:	P5	CC:	Andreas.Krebs, Sascha.Barbas, skr, sli
Version:	21.0	Keywords:	Pegasus
Hardware:	All
OS:	All
Whiteboard:
Kundennummer:		Bestellnummer:
PV Übergabe:	---	Phase Roadmap:	---
Erledigt mit:	Pegasus	SAP Release:	---
Transport:		CRM-ID/Ticket:
Bug Depends on:	11413, 12294
Bug Blocks:	12577

Description Klaas, Martina intern

2020-10-08 09:39:39 CEST

Bei Veränderungen der selektierten Projekte im Datenaufbau kann es zum Verlust des Bearbeitungskennzeichens kommen.

Die Zuordnung des Bearbeitungskennzeichens erfolgt durch Abgleich der neu aufgebauten Aktivitäten mit den Sätzen in der Tabelle /GIB/DCO_PDATA_A.
Dabei werden zur eindeutigen Identifikation derzeit alle Schlüsselfelder inkl.  PARENT_ID_PSP und ID_SUB verglichen.

Die PARENT_ID_PSP verändert sich jedoch ggf. beim erneuten Datenaufbau, da sie von der Anzahl einbezogener Projektelemente abhängig ist. D.h. sobald die Anzahl einbezogener Projekte variiert. Das Feld ist also zur eindeutigen Identifikation des Satzes nicht nutzbar.

Auch die ID_SUB kann sich verändern, z.B. wenn zu einem Projektelement weitere Zugangselemente hinzu kommen. In diesem Fall ist die Rücksetzung des Bearbeitungskennzeichens aber ggf. sinnvoll, da sich an der bearbeiteten Planungssituation Veränderungen ergeben haben.

Ist ein Material mehrfach in einem Projekt enthalten, ist eine eindeutige Identifikation des Satzes nur mittels der ID_SUB nicht möglich.

Das Feld PARENT_ID ist derzeit nicht in der Tabelle /GIB/DCO_PDATA_A enthalten; da es sich analog zur PARENT_ID_PSP beim Datenaufbau verändert, kann es für eine eindeutige Identifikation nicht genutzt werden. 

Derzeit ist daher eine eindeutige Zuordnung der Bearbeitungskennzeichen nicht möglich.

Comment 2 Klaas, Martina intern

2020-11-25 10:23:44 CET

Umstellung der Bearbeitungskennzeichen auf PROJ-GUID Logik analog zu Bemerkungen, d.h. es sind keine Aktivitäten ohne GUID ab Release 21.0 zulässig.

Erweiterung der Aktivitäten um PROJ_GUID (Tabelle /GIB/DCO_PDATA_A, inkl. Index ID zum schnellen Zugriff per GUID).
Beim Datenaufbau (MATCH_ACTIVITIES) werden ggf. fehlende GUIDs für alle Aktivitäten erzeugt, so dass in BAdI und Formeln die Erzeugung der GUID nicht berücksichtigt werden muss.
Aktivitäten auf Mehrfachdeckern (REC_MULTI_KZ = P) sind aus Konsistenzgründen (eindeutiger Zugriff) auch aus BAdI nicht mehr möglich.

Beim Absprung ins Cockpit werden (analog zur Zählung im Control) für Aktivitäten mit gelber und roter Ampel keine Planungselemente mit Bearbeitungskennzeichen mehr angezeigt. Aktivitäten mit grüner und grauer Ampel werden unabhängig vom Bearbeitungskennzeichen des Planungselements immer angezeigt. D.h. das im Control ein Planungselement bei Aktivitäten mit roter Ampel aufgrund des Bearbeitungskennzeichens nicht angezeigt wird, aber immer bei Aktivitäten mit grüner Ampel mitgezählt wird. Das passt dazu, dass im Cockpit kein Bearbeitungskennzeichen für ausschließlich grüne Ampeln angeboten wird, da diese Aktivitäten wie "Offene FA" ja kein Problem im eigentlichen Sinne darstellen, sondern einen Überblick geben sollen. Dazu wurde der Planungsparameter PA_WOPRC im Cockpit eingefügt.

Weitere Anpassungen an /GIB/DCO_PROJ_CLEAN (Berücksichtigung Bearbeitungskennzeichen bei Inkonsistenzprüfung für Tabelle /GIB/DCO_P_GUID) und /GIB/DCO_PROJ_MIG_PNOTE.

Comment 1 Klaas, Martina intern

2020-10-08 09:42:53 CEST

Lösungsansatz:
Analog zu Bug 12294 über die Verwendung einer eindeutigen GUID in Tabelle /GIB/DCO_PDATA_A.