Hinweise zum Dimensionsdesign

Dimensionen zum Erstellen der Anwendungsstruktur entwerfen

Fügen Sie Account-, Entity- und andere Dimensionen hinzu, um Ihren Geschäftsprozess zu unterstützen.

Dimensionen dienen zur Kategorisierung von Datenwerten. Planning enthält die folgenden Dimensionen: Account, Entity, Scenario, Version, Period und Years. Wenn Sie in mehreren Währungen planen, umfasst Ihre Anwendung auch eine Currency-Dimension.

Sie können die Custom-Dimension verwenden, um eigene Werte zu definieren, z.B. Product, Customer oder Market. Sie können insgesamt über bis zu 32 Dimensionen verfügen. Die Best Practice-Empfehlung lautet jedoch, weniger als 12 Dimensionen zu verwenden. Sie können Dimensionen mit einer Ladedatei hinzufügen oder in Oracle Smart View for Office erstellen.

Videos

Prozess zum Identifizieren von Dimensionen

Verwenden Sie diesen Prozess, um zu identifizieren, welche Dimension in die Anwendung aufgenommen werden soll.

1. Identifizieren Sie eindeutige Planungsprozesse basierend auf Ihren Anforderungen.

   Beispiel: Marketingplanung, Vertriebsplanung, Gemeinkostenplanung, Investitionsplanung, Cashflowplanung, Personalplanung

2. Identifizieren Sie Dimensionen für jeden Planungsprozess.

   Beispiel: Product, Market, Channel, Product Segment, Customer Segment

3. Definieren Sie die Beziehungen zwischen Dimensionen.

   Beispiel: Product hat eine n:n-Beziehung mit Market. Product Segment und Product weisen eine 1:n-Beziehung auf. Labor Resources und Material Resources haben keine Beziehung.

4. Unterteilen Sie Dimensionen für Planung und Reporting in Gruppen.

   Beispiel: Product, Market und Channel sind Planning-Dimensionen, während Product Segment und Customer Segment Reportingdimensionen sind.

5. Ordnen Sie Planungsprozesse Planning Modules zu.

   Beispiel: Konfigurieren Sie die Marketingplanung mit dem Modul "Projekte" oder "Finanzplanung", und konfigurieren Sie die Gemeinkostenplanung und Cashflowplanung mit dem Modul "Finanzplanung" und benutzerdefinierten Cubes.

Häufige Anwendungsfälle für Dimensionen berücksichtigen

Sehen Sie sich diese häufigen Anwendungsfälle für Dimensionen und die Richtlinien zu deren Umsetzung an.

• Standarddimensionen (obligatorisch)

  Die meisten allgemeinen und gängigen Anwendungsfälle der Finanzplanung können mit Standarddimensionen umgesetzt werden. Diese können Sie auch umbenennen.

• Custom- oder optionale Dimensionen

  Erweitern Sie die Dimensionalität mit Custom- oder optionalen Dimensionen, die gemäß Ihren Anforderungen hinzugefügt (aktiviert) oder umbenannt werden können.

• Mehrere Hierarchien in einer Dimension

  Kombinieren Sie zwei oder mehr nicht verknüpfte Dimensionen zu einer einzelnen Dimension, um dimensionsübergreifende Irrelevanz zu vermeiden.

• Alternative Hierarchien für Planung oder Reporting

  Verwenden Sie alternative Hierarchien, wenn dieselben Elemente unter verschiedenen übergeordneten Elementen für Top-down-Umlage oder Reportingzwecke gruppiert werden können.

• Attribute-Dimensionen für Reporting

  Attribute-Dimensionen bieten sich an, um Reportinganforderungen zu erfüllen, wenn sie mit einer Dimension verknüpft sind und die Beziehung zwischen den beiden Dimensionen sich nicht mit der Zeit ändert.

• Smart Lists und ASO-Dimensionen für Reporting

  Verwenden Sie Smart Lists und ASO-Dimensionen für das Reporting, wenn die Beziehung zwischen der Reportingdimension und anderen Dimensionen sich mit der Zeit ändert.

• Smart Lists und BSO-Dimensionen mit mehreren Cubes für Planung

  Diese Strategie bietet sich an, wenn die Planning-Dimension keine primäre Dimension für einen Planungsprozess ist und nicht in Unterprozesse aufgeteilt werden muss.

Dieses Arbeitsblatt enthält ein Beispiel für die Planung von Dimensionen, einschließlich Identifizierung von Dimensionen und Auflistung der jeweiligen Anwendungsfälle.

Beispiele für Designstrategien prüfen

Sehen Sie sich diese Beispiele an, um sich mit weiteren Designstrategien für Dimensionen vertraut zu machen.

Attribute-Dimensionen für Reporting verwenden

Die Verwendung von Attribute-Dimensionen für Reporting kann die Erfüllung von Reportinganforderungen erleichtern. Das Attribut ist mit einer Dimension verknüpft, und die Beziehung zwischen den beiden Dimensionen ändert sich nicht mit der Zeit.

Beispiel:

• Definieren Sie ein Attribut namens "Program" in der Project-Dimension.
• Dann können Sie eine Hierarchie von Elementen in der Program-Dimension erstellen. Elemente der obersten Ebene in der Program-Dimension werden automatisch aggregiert.
• Ordnen Sie jedes Project-Element einem Element auf Blattebene in der Program-Dimension in einer Groovy-Regel "Projekt hinzufügen" zu.
• So können Sie Projekte nach Programm filtern.
• Reportingformulare können Aufwendungen und Ertrag auf Programmebene anzeigen.

Smart Lists und ASO-Dimensionen für Reporting verwenden

Verwenden Sie diese Strategie, wenn die Beziehung zwischen der Reportingdimension und anderen Dimensionen sich mit der Zeit ändert.

Beispiel:

• Fügen Sie eine Skillset-Dimension in ASO hinzu, und ordnen Sie die Skillset-Smart List der Skillset-Dimension zu.
• Erstellen Sie eine Datenzuordnung, um Daten von BSO zum ASO-Cube zu verschieben.
• Die Datenzuordnung kann als Batchprozess ausgeführt werden, oder Sie können Smart Push-Aktionen in Formularen oder Groovy-Regeln implementieren.
• Sie können Reportingformulare im ASO-Cube verwenden, um den Personalbedarf nach Qualifikationen über Projekte hinweg anzuzeigen.

Smart Lists und BSO-Design mit mehreren Cubes verwenden

Diese Strategie bietet sich an, wenn die Planning-Dimension keine primäre Dimension für einen Planungsprozess ist und nicht in Unterprozesse aufgeteilt werden muss.

Beispiel:

• "Employee" und "Job" sind Dimensionen im Modul "Personalplanung" sowie Smart Lists im Modul "Project Planning".
• Project Planning nutzt Positionen, um Personalkosten auf Tätigkeits- und Mitarbeiterebene zu planen.

Mehrere Hierarchien in einer Dimension

Sie können mehrere Hierarchien in einer Dimension verwenden. Kombinieren Sie zwei oder mehr nicht verknüpfte Dimensionen zu einer einzelnen Dimension, um dimensionsübergreifende Irrelevanz zu vermeiden.

Beispiel:

• "Jobs", "Equipment" und "Material" sind im Modul "Projekte" nicht verknüpft und werden daher zur Resource Class-Dimension kombiniert.
• "Profit Centers" und "Cost Centers" sind im Modul "Finanzplanung" nicht verknüpft und können daher zu einer einzelnen Entity-Dimension kombiniert werden.

Alternative Hierarchien für Planung und Reporting

Verwenden Sie alternative Hierarchien, wenn dieselben Elemente unter verschiedenen übergeordneten Elementen für Top-down-Umlage oder Reportingzwecke gruppiert werden können.

Beispiel: Erstellen Sie alternative Aggregationen in der Product-Dimension für Planung und Reporting nach den Kategorien für Marke und Produkt.

Top 10-Best Practices für Dimensionen

Befolgen Sie diese wichtigen Best Practices beim Entwerfen von Dimensionen.

1. Die Dimensionsreihenfolge sollte einem geänderten Sanduhrformat folgen.

   Bei diesem Format ist die am dichtesten besetzte Dimension die erste Dimension, gefolgt von weniger dicht besetzten Dimensionen. Darauf sollten Sparse-Dimensionen folgen, mit aggregierenden Sparse-Dimensionen vor Sparse-Dimensionen ohne Aggregation. Bei Sparse-Dimensionen sollten die am dichtesten besetzten Sparse-Dimensionen vor den am wenigsten dicht besetzten Sparse-Dimensionen stehen.

   Bei Hybrid-BSO gilt die gleiche Reihenfolge, außer, dass nicht-dynamische Sparse-Dimensionen vor dynamischen Sparse-Dimensionen stehen sollten.

   Weitere Informationen zu Dense- und Sparse-Dimensionen erhalten Sie in diesem Tutorial: Dimensionen in Cloud EPM verwalten.

2. Eine hohe Blockgröße hat erhebliche Auswirkungen auf die Performance.

   Die Blockgröße wird durch die Anzahl der Dense-Dimensionen und die Elemente in diesen Dense-Dimensionen bestimmt. Die optimale Blockgröße liegt zwischen 8 KB und 500 KB. Reduzieren Sie die Anzahl der Dense-Dimensionen auf maximal 3. Elemente der Ebene 1 und darüber sollten für Dense-Dimensionen auf "Nur Label" oder "Dynamische Berechnung" gesetzt sein.

3. Konten vom Typ "Text", "Smart List", "Datum" und "Gespeicherter Prozentsatz" sollten für die Konsolidierungseigenschaft auf "Nie" gesetzt sein.

   Wenn Sie diese Werte aggregieren, die Konten aber nicht explizit in einem Aggregationsskript ausgeschlossen werden, erhalten Sie nutzlose Daten.

4. Alle Elemente der Generation 2 sollten auf "Ignorieren" gesetzt sein.

   Sie können diese Root-Elemente nicht in Formulare aufnehmen, da Sie keine Sicherheit für diese Elemente definieren können. Es ergibt also keinen Sinn, die Elemente der Generation 2 in der Root zu aggregieren. Außerdem erhöhen Sie dadurch die Anzahl der Blöcke in der Anwendung.

5. Lange oder flache Dimensionen verursachen Probleme mit der Aggregationsperformance.

   Wenn mehr als 200 Elemente unter einem übergeordneten Element vorhanden sind, fügen Sie übergeordnete Zwischenelemente hinzu.

6. Durch die Aktivierung von Dimensionselementen für mehrere Cubes werden dynamische X-Refs erstellt und Performanceprobleme verursacht.

   Verwenden Sie das UDA HSP_NOLINK, um das Erstellen dynamischer X-Refs zu vermeiden. Verwenden Sie Datenzuordnungen oder Smart Push-Aktionen, um Daten zwischen Cubes zu verschieben.

7. Nutzen Sie für einfache Berechnungen mathematische Modellstrukturfunktionen, anstatt Elementformeln zu schreiben.

   Beispiel für eine einfache Berechnung: Konto C = Konto A - Konto B.

8. Verwenden Sie nach Möglichkeit keine übergeordneten Elemente mit nur einem untergeordneten Element.

   Übergeordnete Elemente mit nur einem untergeordneten Element führen zu Implied Shares oder doppelten Blöcken und Daten auf Datenträgern, wenn das übergeordnete Element auf "Nie gemeinsam verwenden" gesetzt wird.

9. Aggregieren Sie große Dimensionen nach Möglichkeit in ASO anstelle von BSO.

   Dadurch wird die Performance beispielweise bei Cube-Aktualisierung und Wartung verbessert.

10. Speichern Sie historische Daten, die mehr als zwei Jahre in der Vergangenheit liegen, in ASO anstelle von BSO.

    Wenn Sie historische Daten aus den letzten 5 oder 10 Jahren nutzen, werden nicht alle Daten für Berechnungen benötigt. Bei Bedarf können Sie einige Jahre von historischen Daten für Berechnungen im BSO-Cube speichern und andere historische Daten in den ASO-Cube verschieben. Für die optimale Performance wird als Best Practice empfohlen, den BSO-Cube nicht zu überladen und sicherzustellen, dass er hauptsächlich die Daten für Berechnungen für die Dateneingabe enthält.

Entity-Dimension planen

Die Entity-Dimension stellt Ihre Organisationsstruktur dar, z.B. Kostenstellen, Abteilungen, Geschäftseinheiten, Unterabteilungen usw.

Sie können Kostenstellen gruppieren, indem Sie Aggregationselemente, als "übergeordnete Elemente" bezeichnet, erstellen, die wiedergeben, wie Ihre Organisation angezeigt wird. Aggregationen können z.B. nach Geschäftseinheit, Unterabteilung oder einer anderen funktionalen Struktur erfolgen. Beispiel: Sie können Kostenstellen erstellen, die in Geschäftseinheiten zusammengefasst werden, die wiederum in Unterabteilungen zusammengefasst werden.

Sie können auch mehrere Reportingstrukturen erstellen. Sie können z.B. eine alternative Struktur zum Unterstützen des regionalen Reportings erstellen. Wenn Sie in mehreren Währungen planen, legen Sie die Basiswährung jeder Entity fest.

Die Entity-Dimension ist eine der primären Dimensionen, die für den Budgetierungsprozess verwendet werden. Zusammen mit der Scenario- und Version-Dimension wird die Entity-Dimension zum Definieren einer Genehmigungseinheit verwendet, einer einzelnen Komponente, die für die Genehmigung oder Prüfung durch die Kollegen eines Benutzers hoch- oder herabgestuft werden kann.

Elemente aller Dimensionen außerhalb der Genehmigungseinheit werden zusammen mit der Genehmigungseinheit selbst hoch- oder herabgestuft. Beispiel: Alle zwölf Monate werden zusammen hochgestuft, wenn eine Genehmigungseinheit hochgestuft wird. Monate können nicht einzeln hochgestuft werden.

Nachdem eine Dimension geladen oder aktualisiert wurde, sollte als Best Practice die Anwendung aktualisiert werden.

Account-Dimension planen

Die Account-Dimension ist der richtige Ort für Ihren Kontenplan. Sie sollte die Elemente enthalten, für die Sie Pläne oder Prognosen erstellen. Sie enthält nicht notwendigerweise alle Konten in Ihrem Plan.

Ihre Account-Dimension kann z.B. Konten für die Erfolgsrechnung, die Bilanz und den Cashflow enthalten. Oder sie kann Konten für KPIs und Verhältnisse enthalten. In manchen Fällen weisen Ihre Konten Unterkonten auf, dies ist aber nicht die Regel.

Die Account-Dimension enthält Finanzanalysen. Die folgenden Kontentypen werden unterstützt:

• Aufwand: Kosten für Geschäftstätigkeit

• Ertrag: Einnahmequelle

• Anlage: Unternehmensressourcen

• Passiva und Eigenkapital: Restzinsen oder Verpflichtung gegenüber Kreditgebern

• Gespeicherte Annahme: Zentralisierte Planungsannahmen zur Wahrung der anwendungsweiten Konsistenz

Die Einstellungen für den Kontentyp werden zum Melden von Gesamtwerten für das Quartal und für das Jahr sowie für Abweichungsanalysen verwendet.

Planning verwendet eine hierarchische Struktur, um Zwischensummen und Gesamtsummen für Kontengruppierungen zu erstellen. Jeder Kontengruppe wird ein Konsolidierungsoperator zugewiesen, der bestimmt, wie sie in ihrem übergeordneten Element zusammengefasst wird.

Beispiel:

Nettoeinkommen = Gesamterträge - Gesamtaufwendungen

In diesem Beispiel ist der Konsolidierungsoperator für Gesamterträge "Addition", und der Konsolidierungsoperator für Gesamtaufwand ist "Minus".

Die Account-Dimension kann durch das Laden von Daten oder mit Smart View aufgefüllt werden. Damit Daten aus einer Datei geladen werden können, muss das Dateiformat bestimmte Anforderungen erfüllen.

Nachdem eine Dimension geladen oder aktualisiert wurde, sollte als Best Practice die Anwendung aktualisiert werden.

Best Practices:

• Elemente der oberen Ebene sollten auf "Dynamische Berechnung" gesetzt werden.

• Setzen Sie Elementformeln, die zum Berechnen von Verhältnissen und anderen Arten von KPIs oder Prozentsätzen verwendet werden, auf "Dynamische Berechnung, Zweistufig". Mit der Einstellung "Zweistufig" werden Prozentsätze auf höheren Ebenen ordnungsgemäß berechnet.

Version-Dimension planen

Sie können Versionen dazu verwenden, unterschiedliche Iterationen des Planungsprozesses beizubehalten. Versionen sind auch nützlich, um den Lese- oder Schreibzugriff auf Daten zu steuern.

Diese zwei Typen von Versionen sind verfügbar:

• Standardziel: Eingabedaten können in höhere Ebenen eingegeben werden.

• Standard-Bottom-up: Eingabedaten können nur in Ebene 0 eingegeben werden.

Die Funktionen für Genehmigungen und Workflows können nur für Bottom-up-Versionen aktiviert werden.

Als Best Practice werden die folgenden Versionen empfohlen:

• Arbeitsversion: Hier führen Benutzer ihre Aufgaben aus, einschließlich der Prüfung von Istergebnissen und der Entwicklung von Planung und Prognose.

• 1. Pass: Wenn Sie mehrere Iterationen Ihres Plans beibehalten möchten, können Sie einen Pass davon in dieser Version beibehalten. Sie können weitere Elemente erstellen, wenn Sie mehrere gespeicherte Iterationen benötigen. Sie können die Funktionalität "Daten kopieren" dazu nutzen, Daten in diese Version zu verschieben. Mit "Daten kopieren" werden Daten und Texteingaben kopiert.

• Was-wäre-wenn: Stellt einen Platzhalter bereit, mit dem Benutzer Annahmen ändern und das Ergebnis analysieren können.

Nachdem im Build-Prozess eine Dimension geladen oder aktualisiert wurde, sollte als Best Practice die Anwendung aktualisiert werden.

Currency-Dimension planen

Wenn Sie mehrere Währungen für Ihre Anwendung aktiviert haben, können Sie die Währungen hinzufügen, die Sie zum Planen und Berichten verwenden.

Danach können Sie Wechselkurse nach Szenario und Jahr definieren, die in Umrechnungen verwendet werden sollen. Ein Berechnungsskript wird erstellt, mit dem Sie Währungsumrechnungen durchführen können. Die Schritte zum Eingeben von Wechselkursen finden Sie unter Wechselkurse festlegen in der Dokumentation Planning verwalten.

Best Practices:

• Begrenzen Sie die Anzahl der Berichtswährungen. In der Regel haben Kunden nur eine Berichtswährung.

• Geben Sie Wechselkurse für jede gültige Kombination aus Szenario und Jahr ein.

• Ab diesem Punkt können Währungsumrechnungen durch das Ausführen der Geschäftsregel "Währungen berechnen" durchgeführt werden, die standardmäßig jedem Formular zugeordnet ist.

• Der Wechselkurstyp eines Kontos wird geändert, z.B. von Endwechselkurs in Durchschnittswechselkurs.

Führen Sie das Skript zur Währungsumrechnung aus, bevor Sie

• aktualisierte lokale Daten in Berichtswährungen prüfen.

• bestimmte Berechnungen ausführen, die möglicherweise von Berichtswährungsdaten abhängig sind.

Wechselkurse planen

Für jede Anwendung wird beim Erstellen der Anwendung eine Standardwährung festgelegt. Wenn Sie Wechselkurstabellen einrichten, geben Sie Wechselkurse aus allen Quellwährungen in die Standardwährung ein. Eine Umrechnung in alle anderen Berichtswährungen erfolgt anhand von Triangulation.

Wechselkurse werden von Scenario nach Jahr für Durchschnitts- und Endwechselkurse festgelegt.

Period-Dimension planen

Verwenden Sie die Period-Dimension, um den Kalenderbereich innerhalb eines bestimmten Jahres festzulegen, z.B. nach Monat.

Best Practices:

• Verwenden Sie Substitutionsvariablen für diese Dimension, um Berichterstellung und Berechnungen zu unterstützen. Potenzielle Substitutionsvariablen sind: CurrMo, CurrQtr und PriorMo. Diese Variablen müssen jeden Monat aktualisiert werden.

• Um Zeitperiodenberechnungen wie "Jahr kumuliert" (Y-T-D, Year to Date) oder "Quartal kumuliert" zu verwenden, wählen Sie das Dynamic Time Series-Symbol in der Period-Dimension aus. Daraufhin können Sie auswählen, welche Zeitperiodenberechnungen Sie zur Unterstützung Ihres Prozesses benötigen.

• Übersichtszeitperioden wie Quartals- und Jahresgesamtbeträge sollten auf dynamische Berechnungen gesetzt werden, um die Berechnungszeit zu reduzieren.

• Nachdem eine Dimension geladen oder aktualisiert wurde, aktualisieren Sie die Anwendung.

Jahre und Substitutionsvariablen planen

Years wird an vielen Stellen in die Anwendung einbezogen, z.B. in Formularen, Berechnungen, Berichten und in Smart View. Da Sie die Anwendung mehrere Jahre lang verwenden werden, sollten Sie als Best Practice mit einer Substitutionsvariablen auf diese Dimension verweisen.

Substitutionsvariablen fungieren als globale Platzhalter für Informationen, die sich regelmäßig ändern. Variable und Wert entsprechen dem Jahr, und der Wert kann jederzeit geändert werden.

Der Wert der Substitutionsvariable wird auf Formularen und Berichten als Platzhalter angezeigt. Dadurch wird der Wartungsbedarf für die Anwendung reduziert.

Erstellen Sie als Best Practice Substitutionsvariablen für jedes in Ihrem Prozess enthaltene Jahr. Beispiel:

• CurrY, laufendes Jahr

• NextYr, Budgetjahr (Planjahr)

• PriorYr, Vorjahr

Custom-Dimensionen entwerfen

Sie können eine Custom-Dimension verwenden, um Ihre Daten weiter zu kategorisieren. Beispiele für Custom-Dimensionen sind Product oder Markets.

Denken Sie daran, dass Zugriffsberechtigungen nicht auf Dimensionsebene, auch als "Generation 1" bezeichnet, erteilt werden können. Beispiel: Zugriffsberechtigungen können nicht direkt dem Product-Element für alle abhängigen Elemente zugewiesen werden. Wenn Sie die Sicherheit für Ihre Custom-Dimension aktivieren, wird empfohlen, Generation 2 für alle Custom-Dimensionen, auf die Sicherheitseinstellungen angewendet werden, unter Beachtung der Sicherheitszugriffszuweisungen zu entwerfen.

Nachdem eine Dimension geladen oder ein Update dafür durchgeführt wurde, hat es sich bewährt, die Anwendung zu aktualisieren.

Zusätzliche Best Practices

Führen Sie diese Aufgaben aus, nachdem Sie Dimensionen hinzugefügt oder aktualisiert haben.

• Aktualisieren Sie die Anwendung.

  Sie müssen die Anwendung jedes Mal aktualisieren, wenn Sie die Anwendungsstruktur ändern.

  An der Anwendung vorgenommene Änderungen werden für Benutzer, die Dateneingabe- und Genehmigungsaufgaben durchführen, erst dargestellt, wenn die Anwendung aktualisiert wird.

  Beispiel: Wenn Sie Eigenschaften eines Entity-Elements ändern, ein Szenario hinzufügen oder Zugriffsberechtigungen ändern, werden diese Änderungen für Benutzer dargestellt, nachdem Sie die Anwendung aktualisiert haben.

• Laden Sie historische Daten.

  Nachdem Sie alle Ihre Strukturen geladen haben, z.B. Konten und Entitys, können Sie historische Daten laden. Dazu können Daten aus tatsächlichen Ergebnissen des Vorjahres und aus Plan und Budget für das laufende Jahr gehören.

  Das Laden historischer Daten bietet Benutzern eine Möglichkeit, Ergebnisse zu analysieren, Trends zu prüfen und aussagekräftige Vergleiche vorzunehmen.

  Außerdem hilft es beim Prüfen der Strukturen, die Sie in Ihre Anwendung aufgenommen haben. Sie können z.B. prüfen, ob die Daten mit zuvor erstellten Berichten übereinstimmen. Wenn die Daten nicht übereinstimmen, müssen Sie prüfen, ob ein echtes Datenproblem oder lediglich ein Strukturproblem vorliegt.

  Erstellen Sie eine Aggregationsregel, um konsolidierte Daten in Ihrer Anwendung anzuzeigen.

• Planen Sie gültige Schnittmengen.

  Mit gültigen Schnittmengen können Serviceadministratoren sogenannte "Regeln für gültige Schnittmengen" definieren, mit denen Dimensionsschnittmengen gefiltert werden, wenn Benutzer Daten eingeben oder Runtime Prompts auswählen. Beispiel: Sie können angeben, dass bestimmte Programme nur für bestimmte Abteilungen gültig sind. Nutzen Sie gültige Schnittmengen, um die Dateneingabe nur für gültige Schnittmengen zu steuern.

  Beachten Sie diese Punkte zu gültigen Schnittmengen beim Formulardesign.

  • Wenn sich Dimensionen mit gültigen Schnittmengen auf der Seite befinden, werden dem Benutzer nur gültige Kombinationen in der Elementauswahl angezeigt.
  • Wenn sich Dimensionen mit gültigen Schnittmengen in der Spalte oder Zeile befinden, kann der Formulardesigner ungültige Schnittmengen vollständig unterdrücken. Wenn die Unterdrückungsoption nicht ausgewählt ist, sind ungültige Schnittmengengruppen schreibgeschützt.