Bug 6776

Summary:	Customizing der Sperren innerhalb des DCFs ermöglichen
Product:	[SCX/Suite] Forecast	Reporter:	jel
Component:	DCF Administration	Assignee:	Lenz, Florian <florian.lenz>
Status:	VERIFIED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	alexander.falge, frs, gzi, hatef.abedi, jel, Martina.Klaas, mfr, rhe
Version:	7.3	Keywords:	Lupus
Hardware:	All
OS:	All
Whiteboard:
Kundennummer:		Bestellnummer:
PV Übergabe:	---	Phase Roadmap:	---
Erledigt mit:	Lupus	SAP Release:	---
Transport:		CRM-ID/Ticket:

Description jel intern

2016-11-09 13:39:42 CET

Momentan existieren folgende Grenzen bei der Erstellung von Sperren:
Maximal 99 Materialien auf Blattebene;
Maximal 700 Hierarchieelemente (wobei die Hierarchieelemente sich wie folgt berechnen: Anzahl Materialien * Anzahl Blattebenen (unabhängig davon, ob ein Material auf der jeweiligen Ebene vorhanden ist)).

Generell wäre es gut, wenn die 99 Materialien (bzw. 700 Elemente) einstellbar sind (selbstverständlich immer mit Abstimmung mit dem Kunden, da hier eine kritische Funktion angepasst wird. Aus Beratersicht (und IT-Sicht) muss die Größe der Sperrtabelle untersucht werden und eine sinnvolle Größe gewählt werden). 
Worauf das ganze hier aber abzielen soll: Neben den oben genannten Parametern soll auch eine angepasste Form der Prüfung der Hierarchieelemente erzeugt werden. Momentan wird einfach die Anzahl der Blattebenen genutzt. Dies soll via Einstellung so geändert werden, dass die Blattebenen weiter geprüft werden und die Materialsets entsprechend ausgelesen werden. Es müssen nur die Material/Hierarchiekombinationen gesperrt werden, die wirklich bearbeitet werden. Diese Option darf dann nur genutzt werden, wenn kein Materialset vererbt wird.

Comment 7 jel intern

2018-03-09 13:56:45 CET

Durch die Korrektur konnte das in Kommentar 5 beschriebene Vorgehen nicht mehr genutzt werden. Sollte somit passen.

Comment 6 Lenz, Florian intern

2017-03-16 19:46:41 CET

Form own_lock_planning in /GIB/DCF_MAINTENANCE_OWN_F01 angepasst, es wird jetzt immer eine Sperre auf allen Blättern der Hierarchie abgesetzt und zurückgenommen und geprüft ob dort bereits ein Benutzer sperrt. Bis diese Prüfung abgeschlossen ist wird das Szenario auf der Superhierarchie gesperrt.

Comment 5 jel intern

2017-03-14 14:16:18 CET

Gesetzte Sperreinträge sehen gut aus. Abfrage auf Anzahl Sperreinträge funktioniert auch. Zudem wird auch genau geprüft, ob ein Material auf mehreren Ebenen vorhanden ist (nicht wie vorher Anzahl Materialien * Anzahl Hierarchie). Folgendes ist dennoch aufgefallen:
1. Modus: Einstieg auf Material 100-100 und 100-101 auf Ebene 64 (Q74, Szenario JEL, dies ist eine Blattebene).
2. Modus: Einstieg auf Ebene 62 (64 ist darunter), ohne Einschränkung.

In dem 2. Modus wird eine Änderung für Artikel 100-100 durchgeführt (im Detailbild, für Ebene 64 PRO). Ergebnis wird gesichert. Modus 1 ist weiterhin geöffnet, dort wird nun für die gleiche Periode (ohne Auffrischen) eine Änderung eingetragen. Beim Speichern wird darüber informiert, dass das Objekt gesperrt sei (komischerweise ist man ja überhaupt in die Ebene reingekommen), anschließend fliegt man aus dem Sheet. Dennoch wurde die Änderung aus Modus 1 übernommen!

Comment 4 Lenz, Florian intern

2017-02-24 16:41:36 CET

*** Bug 4899 has been marked as a duplicate of this bug. ***

Comment 1 Lenz, Florian intern

2017-01-06 18:14:36 CET

/GIB/DCF_MAINTENANCE_OWN_F01 Form own_lock_planning angepasst. Neues Tabellenfeld in den globalen DCF Daten "Anzahl Sperreinträge" /GIB/DCF_C001-LOCKC. Ist dort ein Wert eingetragen gilt dieser als maximale Anzahl Sperreinträge.
Weiterhin wird vor absetzen eines Sperreintrags geprüft ob das Material auf der Blatteebene im Materialset vorhanden ist oder geerbt wurde. 
Ergibt Anzahl Hierarchien * Anzahl Materialien > maximale Anzahl Sperreinträge wird geprüft ob nicht auf Blattebene in Summe doch weniger Materialien vorhanden sind und die exakte Anzahl ermittelt, dann kann ggf. die Sperre des gesamten Sheets vermieden werden.