Bug 12447 - DCO-P Cockpit: Bearbeitungskennzeichen kann nach Datenaufbau nicht zugeordnet werden
Summary: DCO-P Cockpit: Bearbeitungskennzeichen kann nach Datenaufbau nicht zugeordnet...
Status: VERIFIED FIXED
Alias: None
Product: Operations
Classification: SCX/Suite
Component: Projekt (show other bugs)
Version: 21.0
Hardware: All All
: P5 trivial
Assignee: Klaas, Martina
QA Contact: Grab, Felix
URL:
Whiteboard:
Keywords: Pegasus
Depends on: T019255 12294
Blocks: 12577
  Show dependency tree
 
Reported: 2020-10-08 09:39 CEST by Klaas, Martina
Modified: 2021-10-26 14:45 CEST (History)
4 users (show)

Kundennummer:
Bestellnummer:
PV Übergabe: ---
Phase Roadmap: ---
Erledigt mit: Pegasus
SAP Release: ---
Transport:
CRM-ID/Ticket:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.