**TITLE**: Overview Pages (SAP Fiori Elements - Overview Page)

**INTRODUCTION**: Brief, action-oriented summary for developers: Overview pages are data-driven SAP Fiori applications built with SAPUI5, OData services, and annotations. They present actionable, visual cards (charts, tables, stack/quick view cards) and use a smart filter and header. Use the SAP Fiori generator and Guided Development to scaffold and extend overview page apps. Configure application behavior in the manifest.json and extend the UI component to reuse the Overview Page base component.

**TAGS**: fiori-elements-framework, overview-page, SAPUI5, OData, annotations, manifest.json, sap-keep-alive, cards, smart-filter, generator

**STEP**: 1 — Core concept and use case

**DESCRIPTION**: Understand the purpose and primary UI building blocks of an Overview Page. Use this step to plan how many cards, which entity sets, and which annotations (UI | Chart | Presentation) to provide. Expected flow: scaffold app → configure manifest.json → define annotations → implement component extension (if needed) → deploy to Fiori Launchpad.

**LANGUAGE**: Text

**CODE**:
```text
Purpose: Display high-level, actionable business information using visual cards bound to OData entity sets and annotated metadata.
```

**STEP**: 2 — Main UI components to implement

**DESCRIPTION**: Implement these components in your application. Each bullet maps to files/configuration or annotations you must provide:
- Application header: configure title/description in manifest and support user account / card management UI.
- Smart filter: provide a SmartFilterBar bound to application-level filter fields (annotations or XML view).
- Cards: create annotation-driven cards. Each card binds to one entity set and renders a chart, table, or stack of quick view cards. Cards are responsive (up to 5 columns) and support drag & drop reorder.

Map these responsibilities to files:
- manifest.json — central application configuration (routing, app metadata, OVP configuration).
- Component extension — a UIComponent that extends the overview page application component.
- Annotations — OData service metadata + local or external annotation files.

**LANGUAGE**: Text

**CODE**:
```text
Main files:
- manifest.json                (application configuration)
- webapp/Component.js or .ts   (UIComponent extending Overview Page app component)
- webapp/annotations/*.xml     (annotation files for cards and smart filter)
- webapp/images/AnnotationOVP_faeb0bd.png  (illustrative image asset)
```

**STEP**: 3 — manifest.json: role and minimal skeleton

**DESCRIPTION**: Edit the manifest.json to declare app metadata, UI5 settings, and the OVP-related configuration. Keep application configuration centralized in manifest.json. Use the "sap.app", "sap.ui5", and an OVP-specific section (commonly "sap.ovp" or equivalent) to configure cards and app behavior. Use routing and component configuration to point to your extended UI component.

**LANGUAGE**: JSON

**CODE**:
```json
{
  "sap.app": {
    "id": "your.app.id",
    "title": "Your Overview Page",
    "applicationVersion": { "version": "1.0.0" }
  },
  "sap.ui5": {
    "rootView": "your.app.namespace.view.App",
    "dependencies": { "minUI5Version": "1.96.0" },
    "componentName": "your.app.namespace"
  },
  "sap.ovp": {
    "/* OVP configuration and card definitions go here */": ""
  }
}
```

**STEP**: 4 — Component extension and placement

**DESCRIPTION**: Create a UIComponent that extends the Overview Page base component (OVP). This component acts as the application entry point and can override lifecycle hooks or add custom card controllers. Register the component in manifest.json under sap.ui5/componentName/rootView as appropriate.

**LANGUAGE**: JavaScript

**CODE**:
```javascript
// webapp/Component.js (minimal skeleton)
sap.ui.define([
  "sap/ui/core/UIComponent"
], function (UIComponent) {
  "use strict";
  return UIComponent.extend("your.app.namespace.Component", {
    metadata: {
      manifest: "json"
    },
    init: function () {
      UIComponent.prototype.init.apply(this, arguments);
      // custom initialization or OVP-specific setup
    }
  });
});
```

**STEP**: 5 — Cards and annotations (binding and content)

**DESCRIPTION**: Define each card using UI annotations (or annotation files). Each card must bind to a single entity set. Cards can be types: KPI, List/Table, Chart (bar/donut), or Stack (quick-view cards). Use presentation and UI annotations to specify card title, data requests, chart properties, and navigation targets.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- Example: reference to an annotation file that defines cards -->
<!-- webapp/manifest.json or annotations registration -->
<annotations>
  <annotation file="annotations/cards_annotations.xml" />
</annotations>
```

**STEP**: 6 — Development workflow and tools

**DESCRIPTION**: Use the SAP Fiori generator to scaffold an Overview Page application and Guided Development feature guides to add or modify cards. After scaffolding, add or update annotation files, update manifest.json, implement component extensions, and test in local Fiori Launchpad runtime or deploy to SAP Fiori launchpad.

**LANGUAGE**: Text

**CODE**:
```text
Recommended flow:
1. Scaffold app with SAP Fiori generator.
2. Add/modify cards using Guided Development feature guides.
3. Implement or extend webapp/Component.js and manifest.json.
4. Provide annotation XML files under webapp/annotations/.
5. Test locally and deploy to Fiori Launchpad.
```

**STEP**: 7 — Compatibility note: sap-keep-alive

**DESCRIPTION**: If you use multiple overview page applications with the sap-keep-alive mode, upgrade SAPUI5 to 1.96.0 or higher to avoid issues. Verify "minUI5Version" in manifest.json and test keep-alive behavior when switching between apps.

**LANGUAGE**: Text

**CODE**:
```text
Note: When using more than one overview page application with sap-keep-alive mode, set SAPUI5 version >= 1.96.0 in manifest.json -> sap.ui5.dependencies.minUI5Version
```

**STEP**: 8 — Assets and related documentation

**DESCRIPTION**: Keep illustrative images and internal documentation links near the app sources. Use provided assets and internal docs to guide implementation.

**LANGUAGE**: Text

**CODE**:
```text
Related files:
- images/AnnotationOVP_faeb0bd.png
- docs/building-an-app-9834a0a.md
```

fiori-elements-framework overview-page SAPUI5 OData annotations manifest.json sap-keep-alive cards smart-filter generator


**TITLE**: Passing Variant IDs as URL Parameters in SAP Fiori Elements

**INTRODUCTION**: Describe how to pass variant IDs (page-level or control-level) as URL parameters when navigating between Fiori Elements apps (Analytical List Page, List Report). Includes URL parameter names, example URLs, how to obtain variant IDs, and manifest.json samples for OData V2 and V4.

**TAGS**: fiori-elements-framework, sap, variants, url-parameters, manifest.json, odata-v2, odata-v4, navigation

**STEP**: 1 — Parameter names and URL examples

**DESCRIPTION**: Use these URL parameter names to set variants on the target app. The parameter value must be the variant ID (not the variant name). Examples below show how to format the navigation URL with variant IDs.

**LANGUAGE**: text

**CODE**:
```text
Parameter names:
- sap-ui-fe-variant-id           : Page variant ID
- sap-ui-fe-filterbar-variant-id: Filter bar control variant ID
- sap-ui-fe-chart-variant-id    : Chart control variant ID
- sap-ui-fe-table-variant-id    : Table control variant ID

URL examples:
- Page variant:
  https://abc.com/ui#SalesOrder-analyze_deliv_perf?sap-ui-fe-variant-id=id_1542011587281_980_page

- Filter bar control variant:
  https://abc.com/ui#SalesOrder-analyze_deliv_perf?sap-ui-fe-filterbar-variant-id=id_1542011587281_230_page

- Chart control variant:
  https://abc.com/ui#SalesOrder-analyze_deliv_perf?sap-ui-fe-chart-variant-id=id_1574157179885_675_chart

- Table control variant:
  https://abc.com/ui#SalesOrder-analyze_deliv_perf?sap-ui-fe-table-variant-id=id_1574157179595_331_table

- Chart and table variants together:
  https://abc.com/ui#SalesOrder-analyze_deliv_perf?sap-ui-fe-chart-variant-id=id_1574157179885_675_chart&sap-ui-fe-table-variant-id=id_1574157179595_331_table
```

**STEP**: 2 — How to obtain the variant ID programmatically

**DESCRIPTION**: Locate the control instance (control-level variant) or the filter bar instance (page-level variant) and call getCurrentVariantId() on that instance to obtain the stable variant ID to use in the URL or manifest. Example shows obtaining a control instance via sap.ui.core.Element.getElementById.

**LANGUAGE**: JavaScript

**CODE**:
```javascript
// Example: get variant ID from a control instance
sap.ui.require(["sap/ui/core/Element"], function(Element) {
  // Replace "stableControlId" with the control's stable ID (the stable ID used in your app/manifest)
  var control = Element.getElementById("stableControlId");
  if (control && typeof control.getCurrentVariantId === "function") {
    var variantId = control.getCurrentVariantId();
    // Use variantId in URL or manifest parameters
    console.log("Current variant ID:", variantId);
  }
});
```

**STEP**: 3 — Behavior rules and notes

**DESCRIPTION**: Important behavior when passing page and control variants and edge cases.

**LANGUAGE**: text

**CODE**:
```text
Behavior rules:
- Always pass the variant ID (do NOT pass the variant name).
- If both a page variant (sap-ui-fe-variant-id) and a control variant (e.g., sap-ui-fe-chart-variant-id) are present:
  - A page-variant-based Analytical List Page or List Report ignores the control variant ID and applies the page-level variant.
  - A control-variant-based Analytical List Page or List Report applies the control variant ID. If the control variant ID is missing, the page variant ID applies to the control.
- If the passed variant ID is invalid, the app falls back to the default/standard variant.
- Adding the variant ID to the URL overrides the user's default variant ID.
```

**STEP**: 4 — manifest.json example for SAP Fiori Elements (OData V2)

**DESCRIPTION**: To pass a variant ID during cross-application navigation in OData V2, add the parameter to the outbound definition in manifest.json. The sample below shows adding sap-ui-fe-variant-id to an outbound.

**LANGUAGE**: JSON

**CODE**:
```json
...
"crossNavigation": {
  "inbounds": {
...
  },
"outbounds": {
  "EPMProductManage": {
    "parameters": {
    "sap-ui-fe-variant-id":"id_1542011587281_980_page"
    }
  }
}
}
```

**STEP**: 5 — manifest.json example for SAP Fiori Elements (OData V4)

**DESCRIPTION**: For OData V4, define the outbound parameter using the "value" object to pass the variant ID (format "plain"). The sample shows sap-ui-fe-variant-id configured in an outbound.

**LANGUAGE**: JSON

**CODE**:
```json
"outbounds": {
    "ProductDetails": {
        "semanticObject": "Manage",
        "action": "items",
        "parameters": {
            "sap-ui-fe-variant-id": {
                "value": {
                    "value": "id_1633600133090_222",
                    "format": "plain"
                }
            }
        }
    }
}
```

**STEP**: 6 — Related information

**DESCRIPTION**: Read about managing variants and variant structures for filter and content areas.

**LANGUAGE**: text

**CODE**:
```text
Related: Managing Variants
Path: managing-variants-8ce658e.md
Title: Allows you to manage variants with different structures in the filter and content areas.
```


**TITLE**: Placing Reuse Component Instances on the Object Page (OData V2 & V4)

**INTRODUCTION**: Practical, code-focused instructions to place, group, hide, refresh, and title reuse component instances on SAP Fiori elements Object Pages for OData V2 and OData V4 apps. Includes manifest and controller examples to embed reuse components as sections or subsections, control visibility via extension APIs, and trigger refresh behavior.

**TAGS**: fiori-elements, reuse-component, object-page, manifest, routing, OData-v2, OData-v4, embeddedComponents, extensionAPI, stRefreshTrigger

STEP: 1 — Add a reuse component as a subsection to an existing section (OData V2)

DESCRIPTION: Use the manifest "embeddedComponents" entry and set "leadingSectionIdOrPath" to the target section ID or facet path. Provide "navigationProperty" or other settings under "settings". During templating the reuse component is attached as a subsection to the specified section.

LANGUAGE: JSON

CODE:
```json
"embeddedComponents": {
    "tableTest": {
        "id": "tableTest",
        "componentName": "STTA_MP.reuseComponents.tableTest",
        "title": "{{SalesPriceReuse}}",
        "leadingSectionIdOrPath": "GeneralInformation",
        "settings": {
            "navigationProperty": "to_ProductSalesPrice"
        }
    }
}
```

STEP: 2 — Group reuse components into a single section (OData V2)

DESCRIPTION: Group multiple reuse components by assigning one as the leading component (use its ID in "leadingSectionIdOrPath") and use "groupTitle" on grouped components to set the group (section) title. If grouping config is invalid (e.g., reuse component already used elsewhere), the framework falls back to separate sections.

LANGUAGE: JSON

CODE:
```json
"embeddedComponents": {
    "stateTest": {
        "id": "stateTest",
        "componentUsage": "stateTest",
        "title": "{{stateReuse}}",
        "groupTitle": "{{reuseGroupTitle}}"
    },
    "situationsTest": {
        "id": "situationsTest",
        "componentName": "STTA_MP.reuseComponents.situationsTest",
        "title": "{{situationsReuse}}",
        "settings": {
            "productKey": "{ProductForEdit}"
        },
        "leadingSectionIdOrPath": "stateTest"
    }
}
```

STEP: 3 — Hide reuse components via SetSectionHidden API (OData V2)

DESCRIPTION: Call the extension API setSectionHidden in the reuse component's component.js (or controller) to hide or unhide the section/subsection. The API accepts a single Boolean argument: true to hide, false to show. Use attachPageDataLoaded to react to page data and call setSectionHidden accordingly.

LANGUAGE: JavaScript

CODE:
```javascript
function fnRegisterOnPageDataLoaded(oExtensionAPI) {
    oExtensionAPI.attachPageDataLoaded(function (oEvent) {
        var oContextData = oEvent.context.getObject();
        // Hide section if ProductCategory !== "Notebooks"
        (oExtensionAPI.setSectionHidden || jQuery.noop)(oContextData.ProductCategory !== "Notebooks");
    });
}
```

STEP: 4 — Refresh reuse components via stRefreshTrigger (OData V2)

DESCRIPTION: Reuse components expose a stRefresh function. Trigger framework refresh by configuring "stRefreshTrigger" in the manifest component settings. Examples below show triggers for single properties, multiple properties, and combined expressions.

LANGUAGE: JSON

CODE:
```json
// Trigger refresh when changing the value of a property
"embeddedComponents": {
  "priceComponentEmbedding": {
    "id": "priceComponentEmbedding",
    "componentUsage": "priceComponentUsage",
    "title": "{{I18N_KEY_FOR_PRICE_COMPONENT_TITLE}}",
    "settings": {
      "stRefreshTrigger": "{Price}"
    }
  }
}
```

```json
// Trigger refresh when changing the values of one of the properties
"embeddedComponents": {
  "priceComponentEmbedding": {
    "id": "priceComponentEmbedding",
    "componentUsage": "priceComponentUsage",
    "title": "{{I18N_KEY_FOR_PRICE_COMPONENT_TITLE}}",
    "settings": {
      "stRefreshTrigger": "{Price}{Supplier}"
    }
  }
}
```

```json
// Trigger refresh when changing the values of a combination of properties (expression)
"embeddedComponents": {
  "priceComponentEmbedding": {
    "id": "priceComponentEmbedding",
    "componentUsage": "priceComponentUsage",
    "title": "{{I18N_KEY_FOR_PRICE_COMPONENT_TITLE}}",
    "settings": {
      "stRefreshTrigger": "{= ${Price}+${Supplier}}"
    }
  }
}
```

STEP: 5 — Set section title to the control within a reuse component: SmartTable/SmartChart scenario (OData V2)

DESCRIPTION: For table or chart inside the reuse component, define the control with an "initialise" handler and call extensionAPI.setAsTitleOwner with the SmartTable or SmartChart instance from that handler. This hides the section title and uses the control header/text as the section title.

LANGUAGE: XML

CODE:
```xml
<st:SmartTable id="SalesPriceFacetID" initialise="SalesPriceInitialise"/>
```

STEP: 6 — Set section title to the control within a reuse component: controller implementation (OData V2)

DESCRIPTION: Implement the initialise handler in the reuse component controller, get the extension API for the control, and call setAsTitleOwner(control) so the control's header becomes the section title. The control must expose header or text properties.

LANGUAGE: JavaScript

CODE:
```javascript
SalesPriceInitialise: function (oEvent) {
    var oSmartTable = oEvent.getSource();
    var oExtensionAPI = extensionAPI.getExtensionAPI(oSmartTable);
    oExtensionAPI.setAsTitleOwner(oSmartTable);
}
```

STEP: 7 — Add reuse components to Object Page via SAPUI5 routing (OData V4)

DESCRIPTION: Place reuse components into custom subsections by defining object page content sections/subSections with controlId(s), then add reuse component(s) as separate routing targets. Required manifest target properties: type=component, controlAggregation=blocks, clearControlAggregation=true, parent=object page target name, controlId=subsection controlId, options.settings contain reuse component settings.

LANGUAGE: JSON

CODE:
```json
{
  "sap.ui5": {
    "routing": {
      "routes": [
        {
          "pattern": "myEntitySet({key}):?query:",
          "name": "myObjectPage",
          "target": ["myObjectPage", "ReuseComponent", "ReuseComponent2"]
        }
      ],
      "targets": {
        "myObjectPage": {
          "type": "Component",
          "id": "myObjectPage",
          "name": "sap.fe.templates.ObjectPage",
          "options": {
            "settings": {
              "content": {
                "body": {
                  "sections": {
                    "mySection": {
                      "subSections": {
                        "ReuseContainer": {
                          "title": "{i18n>reuseTitle}",
                          "controlId": "firstReuseContainer",
                          "position": {
                            "placement": "After",
                            "anchor": "someSubSection"
                          }
                        }
                      }
                    },
                    "ReuseComponentContainer": {
                      "position": {
                        "placement": "Before",
                        "anchor": "mySubSection"
                      },
                      "title": "Reuse Container",
                      "subSections": {
                        "ReuseContainer": {
                          "controlId": "secondReuseContainer"
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        },
        "ReuseComponent": {
          "type": "Component",
          "id": "Reuse",
          "name": "path/to/reuseComponent",
          "options": {
            "settings": {
              "exampleSettings": "{somePropertyName}"
            }
          },
          "parent": "myObjectPage",
          "controlId": "firstReuseContainer",
          "controlAggregation": "blocks",
          "clearControlAggregation": true
        },
        "ReuseComponent2": {
          "type": "Component",
          "id": "Reuse2",
          "name": "path/to/reuseComponent2",
          "options": {
            "settings": {
              "exampleSettings": "{somePropertyName}"
            }
          },
          "parent": "myObjectPage",
          "controlId": "secondReuseContainer",
          "controlAggregation": "blocks",
          "clearControlAggregation": true
        }
      }
    }
  }
}
```

STEP: 8 — Hide a reuse component placed in a subsection (OData V4)

DESCRIPTION: A reuse component is bound to its custom subsection. Hide the reuse component by hiding the subsection (use extension points for subsections on the object page). Implement hiding logic at the subsection level (for example: manipulate subsection visibility in an extension or via controller logic).

LANGUAGE: JavaScript

CODE:
```javascript
// Example: hide the subsection by controlling its visibility in an extension/controller
// Actual implementation depends on extension points for subsections on the object page.
oSubSection.setVisible(false); // where oSubSection is the subsection control instance
```

STEP: 9 — Refresh reuse components (OData V4)

DESCRIPTION: Reuse components refresh themselves based on exposed properties. When a page change updates a bound property, implement the corresponding setter method in the reuse component to react to property changes (e.g., refresh internal data or call relevant component methods).

LANGUAGE: JavaScript

CODE:
```javascript
// In the reuse component's control or controller, implement the setter for the bound property:
setExampleProperty: function (sValue) {
  this._exampleProperty = sValue;
  // React to change (refresh internal state, trigger re-render, call fetch, etc.)
  this._refreshComponent();
}
```

fiori-elements reuse-component object-page manifest routing OData-v2 OData-v4 embeddedComponents extensionAPI stRefreshTrigger


**TITLE**: Plain Text Facet for Object Page Header

**INTRODUCTION**: Add a plain text facet to the object page header to display a single field/block of text with a title (e.g., a description). The facet uses UI.ReferenceFacet (Label → title) that targets a UI.FieldGroup (Data → UI.DataField.Value → description). Mark the property with UI.MultiLineText when it contains multiline content.

**TAGS**: fiori-elements, annotations, ui.referencefacet, ui.fieldgroup, ui.multilinetext, CDS, ABAP, CAP, XML, object-page, header-facet

STEP: 1A — Add UI.ReferenceFacet (XML)
DESCRIPTION: Define a UI.ReferenceFacet in the header that shows a label as title and references a FieldGroup qualifier (PlainText). Use AnnotationPath to point to the FieldGroup qualifier on the navigation property.
LANGUAGE: XML
CODE:
```xml

<Record Type="UI.ReferenceFacet">
    <PropertyValue Property="Label" String="{@i18n>@ProductDescription}"/>
    <PropertyValue Property="Target" AnnotationPath="to_ProductTextInCurrentLang/@UI.FieldGroup#PlainText"/>
</Record>
```

STEP: 1B — Add UI.ReferenceFacet (ABAP CDS)
DESCRIPTION: Define the same ReferenceFacet in ABAP CDS. Use type #FIELDGROUP_REFERENCE and targetQualifier 'PlainText' to reference the FieldGroup qualifier.
LANGUAGE: CDS
CODE:
```

 @UI.facet: [
  {
   label:        '{@i18n>@ProductDescription}',
   purpose:      #STANDARD,
   type:         #FIELDGROUP_REFERENCE,
   targetElement: '_ProductTextInCurrentLang',
   targetQualifier: 'PlainText'
  }
}

```

STEP: 1C — Add UI.ReferenceFacet (CAP CDS / JSON-like)
DESCRIPTION: Define the ReferenceFacet for CAP model JSON/annotation format. Label and Target reference the FieldGroup qualifier path.
LANGUAGE: JSON
CODE:
```

{
    $Type : 'UI.ReferenceFacet',
    Label : '{@i18n>@ProductDescription}',
    Target : 'to_ProductTextInCurrentLang/@UI.FieldGroup#PlainText'
}
```

STEP: 2A — Define UI.FieldGroup Qualifier "PlainText" (XML)
DESCRIPTION: Create a FieldGroup annotation qualifier PlainText. Put a UI.DataField in Data with Value bound to the Description property.
LANGUAGE: XML
CODE:
```xml

<Annotation Term="UI.FieldGroup" Qualifier="PlainText">
    <Record>
        <PropertyValue Property="Data">
            <Collection>
                <Record Type="UI.DataField">
                    <PropertyValue Property="Value" Path="Description"/>
                </Record>
            </Collection>
        </PropertyValue>
    </Record>
</Annotation>

```

STEP: 2B — Define UI.FieldGroup Qualifier "PlainText" (ABAP CDS)
DESCRIPTION: Declare a fieldGroup qualifier named PlainText in ABAP CDS and bind Description as the field in the group.
LANGUAGE: CDS
CODE:
```

@UI.fieldGroup: [
  {
    qualifier: 'PlainText'
  }
]
DESCRIPTION;
```

STEP: 2C — Define UI.FieldGroup Qualifier "PlainText" (CAP CDS)
DESCRIPTION: Define the FieldGroup qualifier in CAP annotations. Use UI.DataField value bound to Description.
LANGUAGE: JSON
CODE:
```

UI.FieldGroup #PlainText : {
    Data : [
        {
            $Type : 'UI.DataField',
            Value : Description
        }
    ]
}
```

STEP: 3A — Annotate Description as UI.MultiLineText (XML)
DESCRIPTION: Mark the Description property with UI.MultiLineText so the framework treats it as multiline text in the plain text facet.
LANGUAGE: XML
CODE:
```xml

<Annotations Target="STTA_PROD_MAN.STTA_C_MP_ProductTextType/Description">

    <Annotation Term="UI.MultiLineText"/>

</Annotations>

```

STEP: 3B — Annotate Description as UI.MultiLineText (ABAP CDS)
DESCRIPTION: In ABAP CDS, annotate the view element or field to indicate multiLineText behavior.
LANGUAGE: CDS
CODE:
```

annotate view STTA_C_MP_PRODUCTTEXTTYPE with {
  @UI.multiLineText: true
  description;
}
```

STEP: 3C — Annotate Description as UI.MultiLineText (CAP CDS)
DESCRIPTION: Mark the Description field with @UI.MultiLineText in CAP CDS annotate block.
LANGUAGE: CDS
CODE:
```

annotate STTA_PROD_MAN.STTA_C_MP_ProductTextType with {
	@UI.MultiLineText
	Description
};
```

STEP: 4A — CDS Annotation Definition (optional reusable element)
DESCRIPTION: Define a reusable CDS annotation element for multiLineText (scope #ELEMENT). Use when creating custom annotation definitions in CDS.
LANGUAGE: XML
CODE:
```xml

//@Scope: #ELEMENT

multiLineText: Boolean default true;

```

STEP: 4B — CDS Source (optional usage example)
DESCRIPTION: Example of applying the multiLineText CDS annotation to a field in CDS source.
LANGUAGE: XML
CODE:
```xml

@UI.multiLineText

Description: String;

```

Plain Text Facet for Object Page Header

fiori-elements annotations ui.referencefacet ui.fieldgroup ui.multilinetext CDS ABAP CAP XML object-page header-facet


**TITLE**: Prefilling Fields Using the DefaultValuesFunction

**INTRODUCTION**: Configure a DefaultValuesFunction to prefill fields when creating entities or action parameters in SAP Fiori elements apps. Includes sample OData annotation snippets for root entity create and navigation-property/item create. Applicable scenarios and multiselect behavior are noted.

**TAGS**: fiori-elements-framework, odata-v2, default-values, annotations, create, navigation, draft, inline-creation

**STEP**: Applicability and multiselect behavior

**DESCRIPTION**: Use DefaultValuesFunction only in supported application scenarios. Note multiselect behavior: when multiselect is used, only the DefaultValuesFunction without input parameters is called.

**LANGUAGE**: Text

**CODE**:
```Text
Applicable cases:
- SAP Fiori elements for OData V2 non-draft applications.
- SAP Fiori elements for OData V2 and SAP Fiori elements for OData V4 draft applications when using empty row (inline creation) mode.

Multiselect note:
- In case of multiselect only the DefaultValuesFunction without any input parameters is called.
```

**STEP**: Configure DefaultValuesFunction for create entity (root)

**DESCRIPTION**: Add a FunctionImport that returns the default-values type and annotate the entity set (or the entity container target) with the DefaultValuesFunction annotation. Place these snippets into your service metadata extension or annotations XML used by your Fiori elements application. The FunctionImport should reference the function name used in the annotation String value.

**LANGUAGE**: XML

**CODE**:
```xml
<FunctionImport Name="GetDefaultsForRoot" ReturnType="cds_zrc_dv_defaultvalues.ZRC_DV_A_Create" m:HttpMethod="GET"/>

<Annotations xmlns=http://docs.oasis-open.org/odata/ns/edm Target="cds_zrc_dv_defaultvalues.cds_zrc_dv_defaultvalues_Entities/Root">
<Annotation Term="com.sap.vocabularies.Common.v1.DefaultValuesFunction" String="GetDefaultsForRoot"/>
</Annotations>
```

**STEP**: Configure DefaultValuesFunction for navigation property / item create

**DESCRIPTION**: For navigation-property/item-level creation, expose a FunctionImport that accepts the parent key as parameter (e.g., UUID) and annotate the navigation property target with DefaultValuesFunction referencing that function. Ensure sap:action-for or equivalent target mapping is used if required by your service metadata and runtime.

**LANGUAGE**: XML

**CODE**:
```xml
<FunctionImport Name="GetDefaultsForItem" ReturnType="cds_zrc_dv_defaultvalues.ZRC_DV_A_Create" m:HttpMethod="GET" sap:action-for="cds_zrc_dv_defaultvalues.RootType">
<Parameter Name="UUID" Type="Edm.Guid" Mode="In"/>
</FunctionImport>

<Annotations xmlns=http://docs.oasis-open.org/odata/ns/edm Target="cds_zrc_dv_defaultvalues.RootType/to_Item">
<Annotation Term="com.sap.vocabularies.Common.v1.DefaultValuesFunction" String="GetDefaultsForItem"/>
</Annotations>
```

**STEP**: Related documentation and examples

**DESCRIPTION**: Reference further how-to guides and extension point examples for prefilling fields and inline creation behavior.

**LANGUAGE**: Text

**CODE**:
```Text
See:
- prefilling-fields-when-creating-a-new-entity-11ff444.md
- prefilling-fields-when-creating-a-new-entity-using-an-extension-point-189e2d8.md
- enabling-inline-creation-mode-or-empty-row-mode-for-table-entries-cfb04f0.md
- actions-cbf16c5.md
```

fiori-elements-framework odata-v2 default-values annotations create navigation draft inline-creation


**TITLE**: Prefilling Fields When Creating a New Entity

**INTRODUCTION**: Describe how to prefill fields when a user creates a new entity in SAP Fiori Elements. Covers draft-enabled service-side prefilling, transferring prefill data from the front end, OData V2 UI options (extension point, DefaultValuesFunction), and OData V4 NewAction annotation sample. Includes caution about user expectations and visibility of prefilled fields.

**TAGS**: fiori-elements-framework, odata-v2, odata-v4, draft, prefilling, annotations, defaultvaluesfunction, extension-point, newaction

**STEP**: 1 — Use service implementation for draft-enabled entities

**DESCRIPTION**: For draft-enabled entities, implement server-side logic in the relevant service implementation to set default/prefill values when creating a draft. If the values depend on prior user interactions in the UI, transfer those values from the front end to the back end (for example, via navigation parameters or by including them in the create request payload). Review cross-app navigation handling of the preferredMode parameter when creation is triggered from another application.

- Important: Use prefilling carefully — do not prefill fields that are not visible to the user or that the user might not expect to be set automatically.

**LANGUAGE**: Text

**CODE**:
```Text
<!-- Implement default-value assignment in your backend service logic for draft creation.
No specific code snippet provided here because implementation is service/platform dependent. -->
```

**STEP**: 2 — OData V2: Prefilling using an extension point

**DESCRIPTION**: For SAP Fiori Elements OData V2 apps, use the provided extension point to customize UI behavior and prefill fields prior to creation. Implement the extension point in your app's extension code to set UI control values or to inject creation parameters into the payload used for new-entity creation.

- See: "Prefilling Fields When Creating a New Entity Using an Extension Point" for actionable examples and extension point names.

**LANGUAGE**: Text

**CODE**:
```Text
<!-- Implement your extension point in the app's extension file (controller/JS) and set values on controls or on the creation payload.
No single code snippet provided in the source document. -->
```

**STEP**: 3 — OData V2: Prefilling using DefaultValuesFunction

**DESCRIPTION**: For OData V2, implement the DefaultValuesFunction on the backend to compute and return default values for fields when a new entity is created. This function runs server-side and supplies values that the UI will display as initial values for the new entity.

- See: "Prefilling Fields Using the DefaultValuesFunction" for concrete backend implementation examples and bindings.

**LANGUAGE**: Text

**CODE**:
```Text
<!-- Implement DefaultValuesFunction per your OData V2 service framework conventions.
No concrete code snippet provided in the source document. -->
```

**STEP**: 4 — OData V4: Use NewAction to get parameters during creation (List Report)

**DESCRIPTION**: In OData V4 applications (List Report only), define a NewAction with parameters so end users can provide parameter values during creation. For POST-based creation, the framework will still show a dialog if there are any non-computed key fields or immutable fields. Add the NewAction in the entity annotation (Common.DraftRoot) to point to the action implementation.

- The sample below shows how to set NewAction in the Common.DraftRoot annotation. Replace the String value with your action's fully qualified name.

**LANGUAGE**: XML

**CODE**:
```XML
<Annotation Term="Common.DraftRoot">
    <Record Type="Common.DraftRootType">
        <PropertyValue Property="NewAction" String="com.sap.gateway.srvd.c_salesordermanage_sd.v0001.CreateWithSalesOrderType"/>
        ....
        ....
    </Record>
</Annotation>
```

**STEP**: 5 — Related references and cautions

**DESCRIPTION**: Related topics to consult for implementation details and examples:
- Handling of the preferredMode parameter (cross-app navigation scenarios)
- Prefilling Fields When Creating a New Entity Using an Extension Point
- Prefilling Fields Using the DefaultValuesFunction
- Actions in the List Report (for NewAction behavior)

- Caution: Do not use prefilling if fields might be hidden from the user or if automatic values would conflict with user expectations.

**LANGUAGE**: Text

**CODE**:
```Text
<!-- Reference related documentation pages and follow the referenced examples for implementation details. -->
```

fiori-elements-framework odata-v2 odata-v4 draft prefilling annotations defaultvaluesfunction extension-point newaction


**TITLE**: Prefilling Fields When Creating a New Entity Using an Extension Point (Fiori elements, OData V2)

**INTRODUCTION**: This guide shows how to prefill fields when creating a new entity in a Fiori elements List Report (OData V2). It covers enabling the Create-with-Filters menu, transferring filter-bar values into the creation payload via the getPredefinedValuesForCreateExtension extension, and combining filter values with DefaultValuesFunction results.

**TAGS**: fiori-elements-framework, OData V2, list report, filter bar, manifest.json, extension point, prefill, createWithFilters, getPredefinedValuesForCreateExtension

**STEP**: 1 — Enable "Create with Filters" in manifest.json

**DESCRIPTION**: Update the List Report page configuration in manifest.json to replace the standard Create button with a menu offering "Create Object" and "Create with Filters". This enables the Create-with-Filters flow that allows transferring filter values entered by the end user to the new entity.

- File: manifest.json
- Behavior notes:
  - The standard Create button becomes a menu button with two options. The label for the main create option comes from the i18n key CREATE_NEW_OBJECT (default: "Create Object"); consider providing a domain-specific label (for example "Create New Product").
  - The second option is "Create with Filters" (do not override this label).
  - The "Create with Filters" option is enabled only when the table data corresponds to the displayed filter values. The end user might need to click "Go" to trigger the selection state.

**LANGUAGE**: JSON

**CODE**:
```json
...
"sap.ui.generic.app": {
    "_version": "???",
    "settings": {   ...   },
    "pages": {
        "ListReport|myEntitySet": {
            "entitySet": "myEntitySet",
            "component": {
                "name": "sap.suite.ui.generic.template.ListReport",
                "list": true,
                "settings": {
                    "createWithFilters": {
                        "strategy": "extension"
                    },
            ...
```

**STEP**: 2 — Implement getPredefinedValuesForCreateExtension to transfer filter-bar values

**DESCRIPTION**: Implement the extension function getPredefinedValuesForCreateExtension(oSmartFilterBar) to extract values from the SmartFilterBar selection variant and return an object of name-value pairs used during instance creation. Use this when you want to transfer explicit filter entries (only when they are unique/equality filters). Limit usage to fields that are available and editable on the object page and not modifiable via UI adaptation to avoid hidden/uneditable defaults.

- Signature: getPredefinedValuesForCreateExtension(oSmartFilterBar)
- Parameter: oSmartFilterBar — instance of sap.ui.comp.smartfilterbar.SmartFilterBar
- Return: object whose keys are property names and values are the values to prefill on the new entity

**LANGUAGE**: JavaScript

**CODE**:
```javascript
getPredefinedValuesForCreateExtension: function(oSmartFilterBar){
    var oRet = {};
    var oSelectionVariant = oSmartFilterBar.getUiState().getSelectionVariant();
    var aSelectOptions = oSelectionVariant.SelectOptions;
    var fnTransfer = function(sFieldname){
        for (var i = 0; i < aSelectOptions.length; i++){
            var oSelectOption = aSelectOptions[i];
            if (oSelectOption.PropertyName === sFieldname){
                if (oSelectOption.Ranges.length === 1){
                    var oFilter = oSelectOption.Ranges[0];
                    if (oFilter.Sign === "I" && oFilter.Option === "EQ"){
                        oRet[sFieldname] = oFilter.Low;
                    }
                }
                break;
            }
        }
    };
    fnTransfer("ProductCategory");
    fnTransfer("Supplier");
    return oRet;
},
```

**STEP**: 3 — Combine filter values with DefaultValuesFunction results (optional)

**DESCRIPTION**: If you also support DefaultValuesFunction, implement the variant of getPredefinedValuesForCreateExtension that accepts oDefaultValues and uses those values when filters do not provide a unique value. This code extracts unique EQ filter values for specified fields; if not available, it falls back to the corresponding oDefaultValues entry.

- Signature: getPredefinedValuesForCreateExtension(oSmartFilterBar, oDefaultValues)
- Parameter: oDefaultValues — object with default name-value pairs provided by DefaultValuesFunction
- Behavior: For each field of interest, prefer a unique EQ filter value; otherwise use oDefaultValues[field] when available.

**LANGUAGE**: JavaScript

**CODE**:
```javascript
getPredefinedValuesForCreateExtension: function(oSmartFilterBar, oDefaultValues ){
    var oRet = {};
    var oSelectionVariant = oSmartFilterBar.getUiState().getSelectionVariant();
    var aSelectOptions = oSelectionVariant.SelectOptions;
    var fnTransfer = function(sFieldname){
        for (var i = 0; i < aSelectOptions.length; i++){
            var oSelectOption = aSelectOptions[i];
            if (oSelectOption.PropertyName === sFieldname){
                if (oSelectOption.Ranges.length === 1){
                    var oFilter = oSelectOption.Ranges[0];
                    if (oFilter.Sign === "I" && oFilter.Option === "EQ"){
                        oRet[sFieldname] = oFilter.Low;
                    }
                }
                break;
            }  else if (oDefaultValues && Object.keys(oDefaultValues).includes(sFieldname)) {
                oRet[sFieldname] = oDefaultValues[sFieldname];
            }
        }
    };
    fnTransfer("ProductCategory");
    fnTransfer("Supplier");
    return oRet;
},
```

**STEP**: 4 — Additional considerations

**DESCRIPTION**: Summary of important points to apply during implementation:

- This topic applies only to SAP Fiori elements for OData V2.
- Use the createWithFilters strategy "extension" in manifest.json to activate the extension-point behavior.
- Keep prefilled fields editable on the resulting object page unless you intentionally prevent edits.
- For cross-app navigation prefilling scenarios, see Prefilling Fields When Creating a New Entity (cross-app navigation) — implement separately if required.

fiori-elements-framework
OData V2
list report
filter bar
manifest.json
extension point
prefill
createWithFilters
getPredefinedValuesForCreateExtension


**TITLE**: Prerequisites for Using SAP Fiori Elements (OData V4)

**INTRODUCTION**: This document lists the actionable prerequisites and checks required before building SAP Fiori elements apps (OData V4). Use this as a checklist to validate OData services, tooling, back-end compatibility, system versions, and learning resources before generating or configuring app code.

**TAGS**: fiori-elements-framework, odata-v4, sap-fiori, cap, abap, sap-fiori-tools, valuehelp, kpi, draft, security

**STEP**: 1 — Validate single service usage and OData V4 query options

**DESCRIPTION**: Ensure your Fiori elements app uses a single OData service for all data-bound controls. Exceptions: KPI tags on the analytical list page and ValueHelp annotation for OData V4. For OData V4 services (including value help services referenced via ValueListReference), verify support for the required OData query options used by Fiori elements for paging and counts.

**LANGUAGE**: Text

**CODE**:
```text
Requirements for OData V4 services:
- Use a single OData service as the data source for all controls (exceptions: KPI tags, ValueHelp annotations).
- Required OData query options (OData V4):
  - $count
  - $skip
  - $top

Notes:
- Value help services used via the ValueListReference annotation must also support the same query options.
```

**STEP**: 2 — Tooling: use SAP Fiori tools and IDE support

**DESCRIPTION**: Use SAP Fiori tools (extensions for SAP Business Application Studio and VS Code) to generate, scaffold, and maintain Fiori elements apps. Confirm edit scenarios only work with draft-enabled services for OData V4.

**LANGUAGE**: Text

**CODE**:
```text
Recommended tooling:
- SAP Fiori tools (extensions for VS Code and SAP Business Application Studio)
  - Product info: https://help.sap.com/viewer/product/SAP_FIORI_tools/Latest/en-US
- SAP Business Application Studio documentation:
  - https://help.sap.com/viewer/product/SAP%20Business%20Application%20Studio/Cloud/en-US

Important note:
- In Fiori elements (OData V4), edit scenarios require a draft-enabled service.
```

**STEP**: 3 — Back-end platforms and documentation references

**DESCRIPTION**: Use the appropriate back-end platform and implementation patterns (ABAP RAP or CAP). Verify OData protocol version compatibility and ensure back-end security configuration is compatible with your Fiori app design.

**LANGUAGE**: Text

**CODE**:
```text
Back-end resources:
- SAP S/4HANA: ABAP RESTful Application Programming Model (RAP)
  - https://help.sap.com/viewer/fc4c71aa50014fd1b43721701471913d/latest/en-US
- SAP BTP ABAP Environment: ABAP RESTful Application Programming Model
  - https://help.sap.com/viewer/923180ddb98240829d935862025004d6/Cloud/en-US/289477a81eec4d4e84c0302fb6835035.html
- SAP Cloud Application Programming Model (CAP)
  - https://cap.cloud.sap/docs/

Protocol/version notes:
- CAP defaults to OData V4. Some projects may need to fallback to OData V2 (for compatibility with existing V2-based UIs).
- If using CAP with Fiori elements (OData V4), ensure back-end security configurations are compatible with the app.
  - See: security-configuration-ba0484b.md
```

**STEP**: 4 — System requirements for draft-capable transactional apps

**DESCRIPTION**: Confirm ABAP server and release-level support for draft handling before enabling edit/draft scenarios in transactional apps.

**LANGUAGE**: Text

**CODE**:
```text
System requirements for draft capabilities:
- New transactional apps with draft capabilities require:
  - ABAP Application Server as of SAP NetWeaver AS for ABAP 7.51 innovation package SP02 or higher.
- Draft capabilities are NOT available with SAP NetWeaver AS for ABAP 7.50.
- Recommendation: download the most up-to-date versions to ensure latest features. (Reference mentions 7.5 SP01 or higher.)
- See: draft-handling-ed9aa41.md
```

**STEP**: 5 — Tutorials and example projects

**DESCRIPTION**: Use the provided tutorials and example projects to learn Fiori tools + OData V4 patterns and to bootstrap sample apps.

**LANGUAGE**: Text

**CODE**:
```text
Tutorials:
- Travel example (Fiori tools + OData V4):
  - https://developers.sap.com/group.fiori-tools-odata-v4-travel.html
- Incident example (Fiori tools + OData V4):
  - https://developers.sap.com/group.fiori-tools-odata-v4-incident.html
```

fiori-elements-framework odata-v4 sap-fiori cap abap sap-fiori-tools valuehelp kpi draft security


**TITLE**: Progress Indicator Facet — Annotations for Object Page Header (UI.DataPoint, ReferenceFacet, UoM)

**INTRODUCTION**: Add a progress indicator to an object page header facet by annotating a ReferenceFacet that points to a UI.DataPoint with Visualization = Progress. This guide provides exact XML, ABAP CDS, and CAP CDS annotation examples for: UI.HeaderFacets (ReferenceFacet), UI.DataPoint, unit-of-measure (Measures.Unit / Measures.ISOCurrency) and Common.Label for footer. Use these snippets directly in your service metadata or CDS sources.

**TAGS**: fiori-elements-framework, UI.DataPoint, UI.HeaderFacets, ReferenceFacet, UoM, Measures.Unit, Measures.ISOCurrency, Common.Label, CDS, ABAP, CAP, XML, ODataV2, ODataV4

STEP: 1a — Add ReferenceFacet (XML)
DESCRIPTION: Add a record to UI.HeaderFacets of type UI.ReferenceFacet. Set the Target AnnotationPath to a UI.DataPoint qualifier that has Visualization = Progress. "UI" is an alias for com.sap.vocabularies.UI.v1.
LANGUAGE: XML
CODE:
```xml
<Annotations Target="STTA_PROD_MAN.STTA_C_MP_ProjectType">
   <Annotation Term="UI.HeaderFacets">
      <Collection>
         <Record Type="UI.ReferenceFacet">
            <PropertyValue Property="Target"
            AnnotationPath="to_ProgressType/@UI.DataPoint#Progress"/>
         </Record>
      </Collection>
   </Annotation>
</Annotations>
```

STEP: 1b — Add ReferenceFacet (ABAP CDS)
DESCRIPTION: In ABAP CDS, add a UI.Facet entry of type #DATAPOINT_REFERENCE pointing to the target element (navigation). Use purpose: #HEADER for header facets.
LANGUAGE: ABAP CDS
CODE:
```
annotate view STTA_C_MP_PROJECTTYPE with {
@UI.Facet: [
  {
    targetQualifier: 'Progress',
    targetElement: 'TO_PROGRESSTYPE',
    type: #DATAPOINT_REFERENCE,
    purpose: #HEADER
  }
]
test;
}
```

STEP: 1c — Add ReferenceFacet (CAP CDS)
DESCRIPTION: In CAP CDS, add UI.HeaderFacets with a UI.ReferenceFacet Target referencing the DataPoint qualifier via navigation path.
LANGUAGE: CAP CDS
CODE:
```
annotate STTA_PROD_MAN.STTA_C_MP_ProjectType @(
  UI.HeaderFacets : [
    {
        $Type : 'UI.ReferenceFacet',
        Target : 'to_ProgressType/@UI.DataPoint#Progress',
    }
  ]
);
```

STEP: 2a — Define UI.DataPoint (XML)
DESCRIPTION: Annotate the entity type (DataPoint target) with UI.DataPoint Qualifier "Progress". Provide Title, Description, Value, TargetValue, Criticality, and Visualization set to UI.VisualizationType/Progress.
LANGUAGE: XML
CODE:
```xml
<Annotations Target="STTA_PROD_MAN.STTA_C_MP_ProgressType">
   <Annotation Term="UI.DataPoint" Qualifier="Progress">
      <Record>
         <PropertyValue Property="Title" String="{@i18n>Title}"/>
         <PropertyValue Property="Description" String="{@i18n>SubTitle}"/>
         <PropertyValue Property="Value" Path="Progress"/>
         <PropertyValue Property="TargetValue" Decimal="150"/>
         <PropertyValue Property="Criticality" Path="Criticality "/>
         <PropertyValue Property="Visualization" EnumMember="UI.VisualizationType/Progress"/>
      </Record>
   </Annotation>
</Annotations>
```

STEP: 2b — Define UI.DataPoint (ABAP CDS)
DESCRIPTION: In ABAP CDS annotate the view with @UI.dataPoint including title, description, targetValue, criticality, and visualization = #PROGRESS. The property name used as qualifier will be the annotation target.
LANGUAGE: ABAP CDS
CODE:
```
annotate view STTA_C_MP_PROGRESSTYPE with {
@UI.dataPoint: {
  title: '{@i18n>Title}',
  description: '{@i18n>SubTitle}',
  targetValue: 150,
  criticality: 'Criticality ',
  visualization: #PROGRESS
}
progress;
}
```

STEP: 2c — Define UI.DataPoint (CAP CDS)
DESCRIPTION: In CAP CDS annotate the entity type with UI.DataPoint qualifier #Progress. Map Value, TargetValue, Title, Criticality, Visualization to the model fields or literals.
LANGUAGE: CAP CDS
CODE:
```
annotate STTA_PROD_MAN.STTA_C_MP_ProgressType @(
UI.DataPoint #Progress : {
    Title : '{@i18n>Title}',
    Description : '{@i18n>SubTitle}',
    Value : Progress,
    TargetValue : 150,
    Criticality : Criticality ,
    Visualization : #Progress
  }
);
```

STEP: 3a — Annotate UoM and Footer (Unit) — XML
DESCRIPTION: Annotate the Value property with Measures.Unit and Common.Label to provide a unit-of-measure and footer label. The Target path for this annotation is the Value property of the DataPoint entity type.
LANGUAGE: XML
CODE:
```xml
<Annotations Target="STTA_PROD_MAN.STTA_C_MP_ProgressType/Value">
   <Annotation Term="Measures.Unit" Path="UoM"/>
   <Annotation Term="Common.Label" String="{@i18n>Footer}"/>
</Annotations>
```

STEP: 3b — Annotate UoM and Footer (Unit) — ABAP CDS
DESCRIPTION: Mark the unit property with @Semantics.unitOfMeasure and link the Value property to that unit via @Semantics.quantity.unitOfMeasure.
LANGUAGE: ABAP CDS
CODE:
```xml
@Semantics.unitOfMeasure: true
UoM;
@Semantics.quantity.unitOfMeasure: 'UoM'
Value;
```

STEP: 3c — Annotate UoM and Footer (Unit) — CAP CDS
DESCRIPTION: In CAP CDS, annotate the entity type so Measures.Unit references the UoM property and apply Common.Label for footer. (Use the Value property annotation target.)
LANGUAGE: CAP CDS
CODE:
```
annotate STTA_PROD_MAN.STTA_C_MP_ ProgressType with {
  @Measures.Unit : UoM
  Common.Label : '{@i18n>Footer}'
  Value
};
```

STEP: 4a — Annotate UoM and Footer (ISOCurrency) — XML
DESCRIPTION: Use Measures.ISOCurrency when the unit is a currency. Annotate the Value property with Measures.ISOCurrency and apply Common.Label for footer.
LANGUAGE: XML
CODE:
```xml
<Annotations Target="STTA_PROD_MAN.STTA_C_MP_ ProgressType/Value">
   <Annotation Term="Measures.ISOCurrency" Path="UoM"/>
   <Annotation Term="Common.Label" Path="Footer/">
</Annotations>
```

STEP: 4b — Annotate UoM and Footer (ISOCurrency) — ABAP CDS
DESCRIPTION: Use @Semantics.currencyCode on the currency property and link the amount property via @Semantics.amount.currencyCode.
LANGUAGE: ABAP CDS
CODE:
```xml
@Semantics.currencyCode:true
UoM;
@Semantics.amount.currencyCode: 'UoM'
Value;
```

STEP: 4c — Annotate UoM and Footer (ISOCurrency) — CAP CDS
DESCRIPTION: In CAP CDS, annotate Measures.ISOCurrency to reference the UoM property and set Common.Label for the footer.
LANGUAGE: CAP CDS
CODE:
```
annotate STTA_PROD_MAN.STTA_C_MP_ ProgressType with {
    Measures.ISOCurrency : UoM
    @Common.Label : Footer
    Value
};
```

STEP: 5 — Rendering Rules and Mandatory Checks
DESCRIPTION: Implement these rules in model/annotation validation and UI expectations. These are functional requirements the UI relies on when rendering the progress indicator.
LANGUAGE: Text
CODE:
```
- Value and Title properties are mandatory. Without Value the progress cannot be calculated. Title is required for the DataPoint term in the UI vocabulary.
- TargetValue is mandatory when using a UoM not expressed as "%" (e.g., currency, CM, PC) or when no UoM is provided.
- Unit of Measure, Subtitle, and Footer are optional.
- If Unit of Measure is "%", Value is treated directly as a percentage.
- If Unit of Measure is not "%" or not provided, progress = Value / TargetValue.
- Division by zero => progress = 0.
- If progress < 0 => no color in progress bar (value still displayed).
- If progress > 100 => progress bar fully colored (value still displayed).
```

STEP: 6a — Additional Feature: DataPoint in ABAP CDS (OData V2)
DESCRIPTION: Example ABAP CDS style annotation for UI.DataPoint for SAP Fiori elements OData V2 within a CDS view.
LANGUAGE: ABAP CDS
CODE:
```xml
@UI.dataPoint: {
    title:'{@i18n>Title}',
    description: {@i18n>SubTitle},
    targetValue: 150,
    criticality: 'Criticality',
    visualization: #PROGRESS
}
ProjectProgress.Progress
```

STEP: 6b — Additional Feature: DataPoint in CAP CDS (OData V4)
DESCRIPTION: Example CAP CDS annotation for UI.DataPoint for SAP Fiori elements OData V4.
LANGUAGE: CAP CDS
CODE:
```
@UI: DataPoint #Progress              : {
        Value         : Progress,
        TargetValue   : 100,
        Title         : 'Progress',
        Visualization : #Progress
    }
```


**TITLE**: Providing Editable Key Fields for Draft Applications (OData V2)

**INTRODUCTION**: This guide explains how to allow users to edit a key-like field in SAP Fiori elements draft applications by introducing an additional editable field that mirrors the real key in active instances and is transferred to the real key on draft activation. It includes applicability notes, modeling guidance, and exact annotation examples (XML and CAP CDS) needed to map navigation parameters to the editable field.

**TAGS**: fiori-elements, odata-v2, draft, annotations, EditableFieldFor, UI, model

STEP: 1 — Applicability and design considerations

DESCRIPTION:
- Use this pattern only for SAP Fiori elements with OData V2 and draft handling.
- If you control the data model from scratch, prefer an artificial key (e.g., GUID) and keep semantic fields non-key. This guide targets systems with existing databases where changing the key is impractical.
- For non-draft apps this workaround is unnecessary because saving returns the new instance.

LANGUAGE: Text

CODE:
```text
Applicability:
- SAP Fiori elements for OData V2 only.
- Relevant for applications using existing databases and draft handling.
- Not required for non-draft applications.
```

STEP: 2 — Modeling approach (add an editable surrogate field)

DESCRIPTION:
- Introduce an additional property (non-key, editable) that represents the semantic meaning of the key (e.g., SalesOrderForEdit).
- Keep the existing key property (e.g., SalesOrder) as the technical key in the persistent model.
- Behavior:
  - Active instance: editable field value == key value (synchronized).
  - Draft instance: user edits only the editable field; changes are kept in the draft.
  - On draft activation: transfer the editable field value to the real key; system navigates automatically to the active instance.
- On the UI: show only the editable field to users. Continue using the real key for navigation parameters and semantic object attributes.

LANGUAGE: Text

CODE:
```text
Modeling steps (conceptual):
1. Add non-key editable property, e.g., SalesOrderForEdit.
2. Keep SalesOrder as the key property.
3. Ensure active instances synchronize SalesOrderForEdit == SalesOrder.
4. Implement transfer on draft activation: SalesOrder := SalesOrderForEdit.
5. Display only SalesOrderForEdit in the UI; use SalesOrder for navigation parameters.
```

STEP: 3 — Map navigation parameters to the editable field using EditableFieldFor (XML annotation)

DESCRIPTION:
- When navigation parameters are not selective enough to find the object directly, set them in the List Report/Object Page filters. The framework needs to map the incoming navigation parameter value (which maps semantically to the key) to the editable field. Use the com.sap.vocabularies.Common.v1.EditableFieldFor annotation to declare this mapping for the editable property.

LANGUAGE: XML

CODE:
```xml
<Annotations Target="STTA_SALES_ORDER_WD_20_SRV.C_STTA_SalesOrderItem_WD_20Type/SalesOrderForEdit">
    <Annotation Term="com.sap.vocabularies.Common.v1..EditableFieldFor" PropertyPath="SalesOrder"/>
</Annotations>

<Annotations Target="STTA_SALES_ORDER_WD_20_SRV.C_STTA_SalesOrderItem_WD_20Type/SalesOrderItemForEdit">
    <Annotation Term="com.sap.vocabularies.Common.v1.EditableFieldFor" PropertyPath="SalesOrderItem"/>
</Annotations>
```

STEP: 4 — Map navigation parameters to the editable field using CAP CDS annotations

DESCRIPTION:
- If using CAP CDS, annotate the editable properties with @Common.EditableFieldFor pointing to the real key property. This performs the same mapping as the XML annotation, telling Fiori elements to map incoming navigation parameter values to the editable field.

LANGUAGE: CDS

CODE:
```
annotate STTA_SALES_ORDER_WD_20_SRV.C_STTA_SalesOrderItem_WD_20Type with {
  @Common.EditableFieldFor : SalesOrder
  SalesOrderForEdit
};

annotate STTA_SALES_ORDER_WD_20_SRV.C_STTA_SalesOrderItem_WD_20Type with {
   @Common.EditableFieldFor : SalesOrderItem
   SalesOrderItemForEdit
};
```

STEP: 5 — UI and navigation implementation checklist

DESCRIPTION:
- Ensure the UI displays only the editable property (SalesOrderForEdit).
- Ensure navigation uses the real key (SalesOrder) as navigation parameter consistent with semantic object attributes.
- If users navigate into the app via non-selective parameters, set values into the filter bar; the EditableFieldFor mapping ensures the filter uses the editable field on the draft side.
- Verify activation logic transfers editable value to key and triggers navigation to the active instance.

LANGUAGE: Text

CODE:
```text
UI checklist:
- Display: SalesOrderForEdit only.
- Navigation param: SalesOrder (key).
- Semantic object attributes: align with SalesOrder navigation parameter.
- Filter behavior: map incoming param -> SalesOrderForEdit via EditableFieldFor.
- Activation: copy SalesOrderForEdit -> SalesOrder and navigate to active object.
```

fiori-elements odata-v2 draft annotations EditableFieldFor UI model


**TITLE**: Quick View Cards — Configuration and Manifest Examples

**INTRODUCTION**: Quick view cards display detailed information for a single record using the UI annotations HeaderInfo and Facets. This guide provides actionable configuration details and manifest.json examples for:
- mapping HeaderInfo and Facets annotations,
- exposing FieldGroup/IsSummary content,
- adding identification/actions to the card footer,
- manifest settings and qualifiers.

**TAGS**: fiori-elements-framework, quick-view-card, sap.ovp, annotations, com.sap.vocabularies.UI.v1, manifest.json, Identification, Facets

**STEP**: 1 — HeaderInfo and Facets: purpose and required properties

**DESCRIPTION**: Use these UI annotation terms to design the quick view card content and header:
- com.sap.vocabularies.UI.v1.HeaderInfo — presents entity header information (expose TypeNamePlural, ImageUrl, Title, Description).
- com.sap.vocabularies.UI.v1.Facets — presents detailed information in the content area.
- The content area displays FieldGroup records from referenceFacet items that have IsSummary set (com.sap.vocabularies.UI.v1.IsSummary).
- If you use qualifiers, reference the qualified annotation via annotationPath in the manifest; if omitted, the unqualified Facets term is used.

**LANGUAGE**: PlainText

**CODE**:
```text
HeaderInfo properties to expose:
- TypeNamePlural
- ImageUrl
- Title
- Description

Content selection:
- Use com.sap.vocabularies.UI.v1.Facets referenceFacet -> FieldGroup entries
- Mark FieldGroup items with com.sap.vocabularies.UI.v1.IsSummary to include them in the quick view card content area
```

**STEP**: 2 — How to set annotationPath (Facets) for object stream cards in manifest.json

**DESCRIPTION**: When your quick view card is used as an object stream card in a stack card, set objectStreamCardsSettings.annotationPath to point to the qualified Facets annotation. If omitted, the unqualified Facets term is used.

**LANGUAGE**: JSON

**CODE**:
```json
"sap.ovp": {
    ...
    "cards": {
        "card00": {
            "model": "ZCD204_EPM_DEMO_SRV",
            "template": "sap.ovp.cards.stack",
            "settings": {
                "category": "{{card01_category}}",
                "entitySet": "BusinessPartners",
                "objectStreamCardsSettings": {
                    "annotationPath": "com.sap.vocabularies.UI.v1.Facets#Qualifier2"
                }
            }
        },
        ...
    }
}
```

**STEP**: 3 — How to set identificationAnnotationPath (actions) for a card in manifest.json

**DESCRIPTION**: To map Identification annotations (used for footer actions and identification fields) for a specific card, set identificationAnnotationPath in the card settings to the qualified Identification annotation.

**LANGUAGE**: JSON

**CODE**:
```json
"sap.ovp": {
    ...
    "cards": {
        ...
        "card01": {
            "model": "ZCD204_EPM_DEMO_SRV",
            "template": "sap.ovp.cards.table",
            "settings": {
                ...
                "identificationAnnotationPath": "com.sap.vocabularies.UI.v1.Identification#Qualifier1",
                ...
            }
        },
        ...
    }
}
```

**STEP**: 4 — Card footer actions: annotation types, behavior, and invocation

**DESCRIPTION**: Configure footer actions via Identification annotations. Two supported annotation action types:
- com.sap.vocabularies.UI.v1.DataFieldForIntentBasedNavigation — intent/navigation actions
- com.sap.vocabularies.UI.v1.DataFieldForAction — OData action/function invocation

Display rules:
- 0 actions: footer is not displayed.
- 1 action: single button aligned to the right of the footer.
- 2 actions: two buttons displayed (order/importance matters; recommended: positive action on left).
- >2 actions: a single Actions button opens an ActionSheet listing defined actions in metadata order.

Invocation:
- Each OData action is translated into a request per the annotation.
- Simple actions invoke the OData service request directly.
- Complex actions open a dialog for parameters or a confirmation message before invoking.

**LANGUAGE**: PlainText

**CODE**:
```text
Footer action mapping:
- Annotation types: DataFieldForIntentBasedNavigation, DataFieldForAction
- UI behavior:
  - 0 actions => no footer
  - 1 action => right-aligned button
  - 2 actions => both buttons shown (order = importance)
  - >2 actions => Actions button => ActionSheet listing actions in metadata order
- Execution:
  - Simple => immediate OData request
  - Complex => open dialog for params or confirmation, then request
```

**STEP**: 5 — Interaction controls and layout notes

**DESCRIPTION**: Interaction buttons are rendered inside sap.m.OverflowToolbar so buttons adapt to card width. When necessary, remaining actions appear in the overflow area. Quick view card height is aligned to its content; header and footer are fixed. Content area scrolls vertically if content overflows (only content area scrolls).

**LANGUAGE**: PlainText

**CODE**:
```text
Rendering and layout:
- Buttons placed in sap.m.OverflowToolbar for responsive behavior
- If overflowed, remaining actions appear in overflow toolbar
- Card sizing:
  - Height aligns to content
  - Header and footer remain fixed
  - Only content area scrolls vertically when content exceeds visible area
```


**TITLE**: Quick Views: Further Configuration Examples (Currency & Supplier Quick Views)

**INTRODUCTION**: Examples showing how to configure Quick View facets for fields used in object page tables and OData V2 services. Includes EDmx Association with referential constraint, XML UI annotations, ABAP CDS annotations, and CAP CDS annotations. Use these snippets to enable Quick View popups (UI.QuickViewFacets) for currency and supplier fields when the service or metadata lacks referential constraints or when you need to define field groups and facets.

**TAGS**: fiori-elements-framework, quick-view, UI.QuickViewFacets, annotations, OData, EDMX, XML, ABAP CDS, CAP CDS, metadata

STEP: 1 — Add missing referential constraint for Currency in EDMX

DESCRIPTION: If the OData service does not define a referential constraint for the Currency property, add an Association with a ReferentialConstraint in the EDMX (service metadata) so the Quick View can resolve the relationship. Insert this Association element into the service metadata (EDMX).

LANGUAGE: XML

CODE:
```xml
<Association Name="assoc_6D52161C1362D99A31996E5BB23202E8" sap:content-version="1">
    <End Type="STTA_PROD_MAN.STTA_C_MP_ProductSalesDataType" Multiplicity="1" Role="FromRole_assoc_6D52161C1362D99A31996E5BB23202E8"/>
    <End Type="STTA_PROD_MAN.I_CurrencyType" Multiplicity="0..1" Role="ToRole_assoc_6D52161C1362D99A31996E5BB23202E8"/>
    <ReferentialConstraint>
        <Principal Role="FromRole_assoc_6D52161C1362D99A31996E5BB23202E8">
            <PropertyRef Name="Currency"/>
        </Principal>
        <Dependent Role="ToRole_assoc_6D52161C1362D99A31996E5BB23202E8">
            <PropertyRef Name="Currency"/>
        </Dependent>
    </ReferentialConstraint>
</Association>
```

STEP: 2 — XML Annotation: QuickViewFacets for Currency

DESCRIPTION: Add UI.QuickViewFacets and field group annotations for the Currency type in the XML annotation file. This configures the Quick View facets and the fields to display (Decimals, CurrencyISOCode, AlternativeCurrencyKey). Target the Currency property on the ProductSalesDataType with a semantic object (EPMProduct).

LANGUAGE: XML

CODE:
```xml
<!-- QuickViewFacets annotation for Currency-->
<Annotations Target="STTA_PROD_MAN.STTA_C_MP_ProductSalesDataType/Currency">
    <Annotation Term="Common.SemanticObject" String="EPMProduct"/>
</Annotations>
<Annotations Target="STTA_PROD_MAN.I_CurrencyType">
    <Annotation Term="UI.QuickViewFacets">
        <Collection>
            <Record Type="UI.ReferenceFacet">
                <PropertyValue Property="Target" AnnotationPath="@UI.FieldGroup#CurrencyQuickViewPOC_FieldGroup_1" />
            </Record>
        </Collection>
    </Annotation>
    <Annotation Term="UI.FieldGroup" Qualifier="CurrencyQuickViewPOC_FieldGroup_1">
        <Record>
            <PropertyValue Property="Data">
                <Collection>
                    <Record Type="UI.DataField">
                        <PropertyValue Property="Label" String="Decimals" />
                        <PropertyValue Property="Value" Path="Decimals"/>
                    </Record>
                    <Record Type="UI.DataField">
                        <PropertyValue Property="Label" String="CurrencyISOCode" />
                        <PropertyValue Property="Value" Path="CurrencyISOCode"/>
                    </Record>
                    <Record Type="UI.DataField">
                        <PropertyValue Property="Label" String="AlternativeCurrencyKey" />
                        <PropertyValue Property="Value" Path="AlternativeCurrencyKey"/>
                    </Record>
                </Collection>
            </PropertyValue>
        </Record>
    </Annotation>
</Annotations>
```

STEP: 3 — ABAP CDS Annotation: Quick View Facet for Currency

DESCRIPTION: Use ABAP CDS annotations to set the semantic object on the ProductSalesData view and to define a Quick View field group and facet on the I_CURRENCYTYPE view. Apply UI.Facet with purpose #QUICK_VIEW and UI.fieldGroup entries with qualifier CurrencyQuickViewPOC_FieldGroup_1. Insert into the relevant CDS view annotations.

LANGUAGE: ABAP CDS

CODE:
```abap
annotate view STTA_C_MP_PRODUCTSALESDATA with {
  @Consumption.semanticObject: 'EPMProduct'
  currency;
}

annotate view I_CURRENCYTYPE with {
@UI.Facet: [
  {
    targetQualifier: 'CurrencyQuickViewPOC_FieldGroup_1',
    type: #FIELDGROUP_REFERENCE,
    purpose: #QUICK_VIEW
  }
]
@UI.fieldGroup: [
  {
    label: 'Decimals',
    value: 'DECIMALS',
    type: #STANDARD,
    position: 1 ,
    qualifier: 'CurrencyQuickViewPOC_FieldGroup_1'
  }
]
decimals;
@UI.fieldGroup: [
  {
    label: 'CurrencyISOCode',
    value: 'CURRENCYISOCODE',
    type: #STANDARD,
    position: 2 ,
    qualifier: 'CurrencyQuickViewPOC_FieldGroup_1'
  }
]
currencyisocode;
@UI.fieldGroup: [
  {
    label: 'AlternativeCurrencyKey',
    value: 'ALTERNATIVECURRENCYKEY',
    type: #STANDARD,
    position: 3 ,
    qualifier: 'CurrencyQuickViewPOC_FieldGroup_1'
  }
]
alternativecurrencykey;
}
```

STEP: 4 — CAP CDS Annotation: Quick View Facet for Currency

DESCRIPTION: For CAP (SAP Cloud Application Programming Model) CDS, annotate the ProductSalesDataType and I_CurrencyType to define Common.SemanticObject and UI.QuickViewFacets with a ReferenceFacet to the field group qualifier. Define UI.FieldGroup with Data entries for Decimals, CurrencyISOCode, and AlternativeCurrencyKey.

LANGUAGE: CDS

CODE:
```cds
annotate STTA_PROD_MAN.STTA_C_MP_ProductSalesDataType with {
    @Common.SemanticObject : 'EPMProduct'
    Currency
};
annotate STTA_PROD_MAN.I_CurrencyType with @(
    UI.QuickViewFacets : [
        {
            $Type : 'UI.ReferenceFacet',
            Target : '@UI.FieldGroup#CurrencyQuickViewPOC_FieldGroup_1'
        }
    ],
    UI.FieldGroup #CurrencyQuickViewPOC_FieldGroup_1 : {
        Data : [
            {
                $Type : 'UI.DataField',
                Label : 'Decimals',
                Value : Decimals
            },
            {
                $Type : 'UI.DataField',
                Label : 'CurrencyISOCode',
                Value : CurrencyISOCode
            },
            {
                $Type : 'UI.DataField',
                Label : 'AlternativeCurrencyKey',
                Value : AlternativeCurrencyKey
            }
        ]
    }
);
```

STEP: 5 — XML Annotation: QuickViewFacets and contact semantics for Supplier (OData V2)

DESCRIPTION: For Supplier quick views in OData V2, add communication semantics (IsEmailAddress, IsUrl, IsPhoneNumber) and UI.QuickViewFacets with two ReferenceFacet entries. Define two UI.FieldGroup qualifiers (SupplierQuickViewPOC_FieldGroup_1 and _2) that list the Data fields and nested navigation paths (to_Address/FormattedAddress etc.). Use the XML annotation file that targets STTA_PROD_MAN.STTA_C_MP_SupplierType and property targets. (Images referenced: images/Quick_View_Example_1_8633539.png)

LANGUAGE: XML

CODE:
```xml
<!-- QuickViewFacets annotation for Supplier-->
            <Annotations Target="STTA_PROD_MAN.STTA_C_MP_SupplierType/EmailAddress" xmlns="http://docs.oasis-open.org/odata/ns/edm">
                  <Annotation Term="com.sap.vocabularies.Communication.v1.IsEmailAddress" Bool="true"/>
            </Annotations>

            <Annotations Target="STTA_PROD_MAN.STTA_C_MP_SupplierType/URL" xmlns="http://docs.oasis-open.org/odata/ns/edm">
                  <Annotation Term="Org.OData.Core.V1.IsUrl" Bool="true"/>
            </Annotations>
            <Annotations Target="STTA_PROD_MAN.STTA_C_MP_SupplierType/PhoneNumber" xmlns="http://docs.oasis-open.org/odata/ns/edm">
                  <Annotation Term="com.sap.vocabularies.Communication.v1.IsPhoneNumber" Bool="true"/>
            </Annotations>
            <Annotations Target="STTA_PROD_MAN.STTA_C_MP_SupplierType">
                <Annotation Term="UI.QuickViewFacets">
                    <Collection>
                        <Record Type="UI.ReferenceFacet">
                            <PropertyValue Property="Target" AnnotationPath="@UI.FieldGroup#SupplierQuickViewPOC_FieldGroup_1" />
                        </Record>
                        <Record Type="UI.ReferenceFacet">
                            <PropertyValue Property="Target" AnnotationPath="@UI.FieldGroup#SupplierQuickViewPOC_FieldGroup_2" />
                        </Record>

                    </Collection>
                </Annotation>
                <Annotation Term="UI.FieldGroup" Qualifier="SupplierQuickViewPOC_FieldGroup_1">
                    <Record>
                        <PropertyValue Property="Label" String="The first field group label" />
                        <PropertyValue Property="Data">
                            <Collection>
                                <Record Type="UI.DataField">
                                    <PropertyValue Property="Label" String="Supplier" />
                                    <PropertyValue Property="Value" Path="Supplier"/>
                                </Record>
                                <Record Type="UI.DataField">
                                    <PropertyValue Property="Label" String="Company Name" />
                                    <PropertyValue Property="Value" Path="CompanyName"/>
                                </Record>
                                <Record Type="UI.DataField">
                                    <PropertyValue Property="Label" String="Email Address" />
                                    <PropertyValue Property="Value" Path="EmailAddress"/>
                                </Record>
                                <Record Type="UI.DataField">
                                    <PropertyValue Property="Label" String="to_Address / FormattedAddress" />
                                    <PropertyValue Property="Value" Path="to_Address/FormattedAddress"/>
                                </Record>
                            </Collection>
                        </PropertyValue>
                    </Record>
                </Annotation>
                <Annotation Term="UI.FieldGroup" Qualifier="SupplierQuickViewPOC_FieldGroup_2">
                    <Record>
                        <PropertyValue Property="Label" String="The second field group label" />
                        <PropertyValue Property="Data">
                            <Collection>
                                <Record Type="UI.DataField">
                                    <PropertyValue Property="Label" String="Phone Number" />
                                    <PropertyValue Property="Value" Path="PhoneNumber"/>
                                </Record>
                                <Record Type="UI.DataField">
                                    <PropertyValue Property="Label" String="URL" />
                                    <PropertyValue Property="Value" Path="URL"/>
                                </Record>
                                <Record Type="UI.DataField">
                                    <PropertyValue Property="Label" String="to_Address / AddressValidityStartDate" />
                                    <PropertyValue Property="Value" Path="to_Address/AddressValidityStartDate"/>
                                </Record>
                            </Collection>
                        </PropertyValue>
                    </Record>
                </Annotation>
            </Annotations>
```

STEP: 6 — ABAP CDS Annotation: Quick View Facets for Supplier

DESCRIPTION: ABAP CDS annotations for the Supplier view to define two Quick View field group references and fieldGroup entries. Include semantical annotations for email and telephone where used. Add fieldGroup qualifiers SupplierQuickViewPOC_FieldGroup_1 and SupplierQuickViewPOC_FieldGroup_2 with positions and labels to form the Quick View content.

LANGUAGE: ABAP CDS

CODE:
```abap
annotate view STTA_C_MP_SUPPLIER with {
@UI.Facet: [
  {
    targetQualifier: 'SupplierQuickViewPOC_FieldGroup_1',
    type: #FIELDGROUP_REFERENCE,
    purpose: #QUICK_VIEW
  },
  {
    targetQualifier: 'SupplierQuickViewPOC_FieldGroup_2',
    type: #FIELDGROUP_REFERENCE,
    purpose: #QUICK_VIEW
  }
]
@UI.fieldGroup: [
  {
    label: 'Supplier',
    value: 'SUPPLIER',
    type: #STANDARD,
    position: 1 ,
    qualifier: 'SupplierQuickViewPOC_FieldGroup_1',
    groupLabel: 'The first field group label'
  }
]
supplier;
@UI.fieldGroup: [
  {
    label: 'Company Name',
    value: 'COMPANYNAME',
    type: #STANDARD,
    position: 2 ,
    qualifier: 'SupplierQuickViewPOC_FieldGroup_1'
  }
]
companyname;
@UI.fieldGroup: [
  {
    label: 'Email Address',
    value: 'EMAILADDRESS',
    type: #STANDARD,
    position: 3 ,
    qualifier: 'SupplierQuickViewPOC_FieldGroup_1'
  }
]
@Semantics:   { eMail: { address: true, type:  [ #PREF, #WORK ] } }
emailaddress;
@UI.fieldGroup: [
  {
    label: 'to_Address / FormattedAddress',
    value: 'TO_ADDRESS/FORMATTEDADDRESS',
    type: #STANDARD,
    position: 4 ,
    qualifier: 'SupplierQuickViewPOC_FieldGroup_1'
  }
]
to_address/formattedaddress;
@UI.fieldGroup: [
  {
    label: 'Phone Number',
    value: 'PHONENUMBER',
    type: #STANDARD,
    position: 5 ,
    qualifier: 'SupplierQuickViewPOC_FieldGroup_2'
  }
]
@Semantics.telephone.type: #WORK
phonenumber;
@UI.fieldGroup: [
  {
    label: 'URL',
    value: 'URL',
    type: #STANDARD,
    position: 6 ,
    qualifier: 'SupplierQuickViewPOC_FieldGroup_2'
  }
]
url;
@UI.fieldGroup: [
  {
    label: 'to_Address / AddressValidityStartDate',
    value: 'TO_ADDRESS/ADDRESSVALIDITYSTARTDATE',
    type: #STANDARD,
    position: 7 ,
    qualifier: 'SupplierQuickViewPOC_FieldGroup_2'
  }
]
to_address/addressvaliditystartdate;
}
```

fiori-elements-framework
quick-view
UI.QuickViewFacets
annotations
OData
EDMX
XML
ABAP CDS
CAP CDS
metadata


**TITLE**: Radial Micro Chart — UI.Chart and UI.DataPoint Annotations (XML, ABAP CDS, CAP CDS)

**INTRODUCTION**: Quick reference and actionable code examples to implement a Radial Micro Chart (single percentage value) using metadata annotations. Includes XML, ABAP CDS, and CAP CDS examples for UI.Chart and UI.DataPoint. Lists mandatory annotations and semantic coloring rules required for a valid radial micro chart.

**TAGS**: fiori-elements-framework, radial-micro-chart, UI.Chart, UI.DataPoint, annotations, CDS, ABAP, CAP, XML

**STEP**: 1 — UI.Chart Annotation (XML)

**DESCRIPTION**: Use UI.Chart to define the radial micro chart properties. Title → chart title, Description → subtitle. ChartType must be Donut for radial micro chart. Specify Measures and MeasureAttributes with a DataPoint reference. The example uses Qualifier "SpecificationWidthRadialChart" and Measure "Width".

**LANGUAGE**: XML

**CODE**:
```xml
<Annotation Term="UI.Chart" Qualifier="SpecificationWidthRadialChart">
    <Record Type="UI.ChartDefinitionType">
        <PropertyValue Property="Title" String="Product Width Specification"/>
        <PropertyValue Property="Description" String="No navigation with qualifier"/>
        <PropertyValue Property="ChartType" EnumMember="UI.ChartType/Donut"/>
        <PropertyValue Property="Measures">
            <Collection>
                <PropertyPath>Width</PropertyPath>
            </Collection>
        </PropertyValue>
        <PropertyValue Property="MeasureAttributes">
            <Collection>
                <Record Type="UI.ChartMeasureAttributeType">
                    <PropertyValue Property="Measure" PropertyPath="Width"/>
                    <PropertyValue Property="Role" EnumMember="UI.ChartMeasureRoleType/Axis1"/>
                    <PropertyValue Property="DataPoint" AnnotationPath="@UI.DataPoint#Width"/>
                </Record>
            </Collection>
        </PropertyValue>
    </Record>
</Annotation>
```

**STEP**: 2 — UI.Chart Annotation (ABAP CDS)

**DESCRIPTION**: ABAP CDS equivalent for defining the radial micro chart. Ensure chartType is #DONUT and specify measures and measureAttributes including asDataPoint or DataPoint link. Qualifier is provided for referencing.

**LANGUAGE**: ABAP CDS

**CODE**:
```
@UI.Chart: [
  {
    title: 'Product Width Specification',
    description: 'No navigation with qualifier',
    chartType: #DONUT,
    measures: [
      'WIDTH'
    ],
    measureAttributes: [
      {
        measure: 'Width',
        role: #AXIS_1,
        asDataPoint: true
      }
    ],
    qualifier: 'SpecificationWidthRadialChart'
  }
]
annotate view STTA_C_MP_PRODUCT with {

}
```

**STEP**: 3 — UI.Chart Annotation (CAP CDS)

**DESCRIPTION**: CAP CDS (Cdl) variant of the UI.Chart annotation. Use ChartType #Donut and include Measures and MeasureAttributes. Reference DataPoint with '@UI.DataPoint#Width' for semantic coloring and percentage value binding.

**LANGUAGE**: CAP CDS

**CODE**:
```
UI.Chart #SpecificationWidthRadialChart : {
    $Type : 'UI.ChartDefinitionType',
    Title : 'Product Width Specification',
    Description : 'No navigation with qualifier',
    ChartType : #Donut,
    Measures : [
        Width
    ],
    MeasureAttributes : [
        {
            $Type : 'UI.ChartMeasureAttributeType',
            Measure : Width,
            Role : #Axis1,
            DataPoint : '@UI.DataPoint#Width'
        }
    ]
}
```

**STEP**: 4 — UI.DataPoint Annotation (XML)

**DESCRIPTION**: Define the DataPoint referenced by the chart's MeasureAttributes. Provide Value (bind to measure), optional TargetValue, and Criticality (or CriticalityCalculation) for semantic coloring. Example qualifier "Width" is used and Value maps to Width.

**LANGUAGE**: XML

**CODE**:
```xml
<Annotation Term="UI.DataPoint" Qualifier="Width">
    <Record>
        <PropertyValue Property="Value" Path="Width"/>
        <PropertyValue Property="TargetValue" Path="Weight"/>
        <PropertyValue Property="Criticality" Path="criticalityValue"/>
    </Record>
</Annotation>
```

**STEP**: 5 — UI.DataPoint Annotation (ABAP CDS)

**DESCRIPTION**: ABAP CDS snippet showing DataPoint criticality binding. Use criticality or criticality calculation fields as needed.

**LANGUAGE**: ABAP CDS

**CODE**:
```
@UI.dataPoint: {
  criticality: 'criticalityValue'
}
Width;
```

**STEP**: 6 — UI.DataPoint Annotation (CAP CDS)

**DESCRIPTION**: CAP CDS DataPoint definition. Map Value to Width, TargetValue to Weight, and Criticality to criticalityValue. Use qualifier #Width to match the chart's DataPoint reference.

**LANGUAGE**: CAP CDS

**CODE**:
```
UI.DataPoint #Width : {
    Value : Width,
    TargetValue : Weight,
    Criticality : criticalityValue
}
```

**STEP**: 7 — Mandatory Annotations and Semantic Coloring Rules

**DESCRIPTION**: Required annotation elements and coloring precedence for radial micro chart. Follow these rules when generating metadata:

**LANGUAGE**: PlainText

**CODE**:
```
Mandatory annotations for radial micro chart:
- UI.Chart → ChartType: "Donut"
- UI.Chart → Measures
- UI.Chart → MeasureAttributes → DataPoint (reference to a UI.DataPoint)
- UI.DataPoint → Value

If using CriticalityCalculation for semantic coloring, include:
- UI.DataPoint → CriticalityCalculation
- UI.DataPoint → CriticalityCalculation/ImprovementDirection

Semantic coloring precedence:
- UI.DataPoint → Criticality overrides UI.DataPoint → CriticalityCalculation (i.e., if Criticality is present, it takes precedence).
- Both Criticality and CriticalityCalculation are supported, but do not rely on both for conflicting values.

Display behavior:
- The radial micro chart displays percentage values. The unit-of-measure label is invalid for this chart type and will not be rendered.
```

**STEP**: 8 — Implementation Notes & References

**DESCRIPTION**: Practical reminders for code generation and validation.

**LANGUAGE**: PlainText

**CODE**:
```
- Ensure ChartType is explicitly set to Donut to render a radial micro chart.
- Ensure the Measure referenced in UI.Chart Measures is the same measure used in MeasureAttributes and in UI.DataPoint → Value.
- Use the same Qualifier names to link UI.Chart MeasureAttributes DataPoint to UI.DataPoint (e.g., @UI.DataPoint#Width).
- For CAP and ABAP CDS, follow respective syntax for qualifiers and DataPoint linking.
- Reference sample and rendering details: https://ui5.sap.com/1.82.5/#/entity/sap.suite.ui.microchart.RadialMicroChart
```

fiori-elements-framework radial-micro-chart UI.Chart UI.DataPoint annotations CDS ABAP CAP XML


**TITLE**: Rating Indicator Facet for Fiori Elements Object Page Header

**INTRODUCTION**: Add a read-only rating indicator to the Object Page header using UI.ReferenceFacet that points to a UI.DataPoint with Visualization = Rating. Use aggregated (average + sample size + footer) or non-aggregated (single rating) variants depending on the use case. This document provides actionable annotation examples (XML, ABAP CDS, CAP CDS) and key properties to configure stars, subtitle, and behavior in edit mode.

**TAGS**: fiori-elements-framework, rating, UI.DataPoint, UI.Facets, annotations, XML, ABAP CDS, CAP CDS, OData V4

**STEP**: 1 — Add a rating indicator facet (overview)

**DESCRIPTION**: Use a UI.ReferenceFacet within UI.Facets that targets a UI.DataPoint qualifier whose Visualization is UI.VisualizationType/Rating. The UI.DataPoint supplies Value (rating), optional TargetValue (max stars), SampleSize (for aggregated subtitle), Description (for non-aggregated subtitle), and Title.

**LANGUAGE**: XML

**CODE**:
```xml
<Annotation Term="UI.Facets">
    <Record Type="UI.ReferenceFacet">
        <PropertyValue Property="Target" AnnotationPath="to_ProductRating/@UI.DataPoint#Aggregated" />
    </Record>
</Annotation>
<Annotation Term="UI.DataPoint" Qualifier="Aggregated">
    <Record>
        <PropertyValue Property="Title" String="{@i18n>@ProductAverageRating}" />
        <PropertyValue Property="Value" Path="AverageRating" />
        <PropertyValue Property="TargetValue" Int="3" />
        <PropertyValue Property="Visualization" EnumMember="UI.VisualizationType/Rating" />
        <PropertyValue Property="SampleSize" Path="ReviewCount" />
    </Record>
</Annotation>
```

**STEP**: 2 — Aggregated rating (description, subtitle, and requirements)

**DESCRIPTION**: Aggregated rating shows average rating, total number of ratings (SampleSize) as subtitle, rating stars (Value), and footer average. Use local annotations for aggregated rating (not CDS annotations). To change subtitle text, annotate SampleSize with Common.Label. Use TargetValue to set max stars statically (Int) or via a path.

**LANGUAGE**: CAP CDS

**CODE**:
```
UI.Facets : {
    $Type : 'UI.ReferenceFacet',
    Target : 'to_ProductRating/@UI.DataPoint#Aggregated'
},
UI.DataPoint #Aggregated : {
    Title : '{@i18n>@ProductAverageRating}',
    Value : AverageRating,
    TargetValue : 3,
    Visualization : #Rating,
    SampleSize : ReviewCount
}
```

**LANGUAGE**: ABAP CDS

**CODE**:
```
@UI.headerInfo: {
  typeName: 'Sales Order',
  typeNamePlural: 'Sales Orders',
  title: {
    value: 'SO_ID',
    type: #STANDARD
  }
}
annotate view STTA_C_MP_PRODUCT with {

}
```

**STEP**: 3 — Non-aggregated rating (user's single rating)

**DESCRIPTION**: Non-aggregated shows a single rating (e.g., user's own rating) with Title, Subtitle (Description), and Rating control. Can use local annotations or CDS annotations. Use TargetValue as a path to the backend MaxRating field to determine max stars dynamically.

**LANGUAGE**: XML

**CODE**:
```xml
<Record Type="UI.ReferenceFacet">
    <PropertyValue Property="Target" AnnotationPath="to_ProductRating/@UI.DataPoint#NonAggregated"/
</Record>
<!-- non aggregated rating -->
<Annotation Term="UI.DataPoint" Qualifier="NonAggregated">
   <Record>
      <PropertyValue Property="Title" String="{@i18n>@ProductUserRating}"/>
      <PropertyValue Property="Description" String="@i18n>@MyRating}"/>
      <PropertyValue Property="Value" Path="Rating"/>
      <PropertyValue Property="TargetValue" Path="MaxRating"/>
      <PropertyValue Property="Visualization" EnumMember="UI.VisualizationType/Rating"/>
   </Record>
</Annotation>
```

**LANGUAGE**: ABAP CDS

**CODE**:
```
@UI.facet: [
 {
  id:           'rating',
  type:         #DATAPOINT_REFERENCE,
  targetElement: '_ProductRating',
  targetQualifier: 'NonAggregated'
 }
]
product;

@UI.dataPoint: {
  title: '{@i18n>@ProductUserRating}',
  description: '@i18n>@MyRating}',
  targetValueElement: 'MaxRating',
  visualization: #RATING
}
Rating;
```

**LANGUAGE**: CAP CDS

**CODE**:
```
UI.Facets : {
    $Type : 'UI.ReferenceFacet',
    Target : 'to_ProductRating/@UI.DataPoint#NonAggregated'
},

UI.DataPoint #NonAggregated : {
    Title : '{@i18n>@ProductUserRating}',
    Description : '@i18n>@MyRating}',
    Value : Rating,
    TargetValue : MaxRating,
    Visualization : #Rating
}
```

**STEP**: 4 — Set maximum number of stars (TargetValue)

**DESCRIPTION**: Configure TargetValue to set the maximum number of stars (TargetValue). You can set the max statically in the annotation (Int) or dynamically via Path to a backend field (Path/targetValueElement).

**LANGUAGE**: XML

**CODE**:
```xml
<!-- static max stars -->
<PropertyValue Property="TargetValue" Int="3" />
```

**LANGUAGE**: XML

**CODE**:
```xml
<!-- dynamic max stars from backend -->
<PropertyValue Property="TargetValue" Path="MaxRating"/>
```

**STEP**: 5 — Change subtitle text (SampleSize and Description)

**DESCRIPTION**: For aggregated ratings, set SampleSize on UI.DataPoint (path to count) and annotate that SampleSize with Common.Label to customize the text (e.g., "139 user reviews"); otherwise default text "ratings" is used. For non-aggregated ratings, set Description on UI.DataPoint to render the subtitle text.

**LANGUAGE**: XML

**CODE**:
```xml
<PropertyValue Property="SampleSize" Path="ReviewCount" />
<!-- Annotate SampleSize with Common.Label to change the trailing text (e.g., 'user reviews') -->
```

**LANGUAGE**: XML

**CODE**:
```xml
<PropertyValue Property="Description" String="@i18n>@MyRating}"/>
```

**STEP**: 6 — Edit mode behavior

**DESCRIPTION**: In Edit mode the rating indicator moves into the header facet and displays title only; aggregated ratings show the number of ratings in parentheses after the stars. The rating control stays read-only in Edit mode.

**LANGUAGE**: PlainText

**CODE**:
```text
Edit mode: rating indicator moves into header facet, shows title only; aggregated ratings show sample size in parentheses; control remains read-only.
```

**STEP**: 7 — Additional features: SAP Fiori Elements for OData V4 (CDS DataPoint example)

**DESCRIPTION**: Example DataPoint CDS annotation for OData V4 that sets Value, TargetValue, Title and Visualization = #Rating.

**LANGUAGE**: CDS

**CODE**:
```xml
@UI: DataPoint #Rating               : {
        Value         : Rating,
        TargetValue   : 5.0,
        Title         : 'Rating',
        Visualization : #Rating
    }
```

fiori-elements-framework
rating
UI.DataPoint
UI.Facets
annotations
XML
ABAP CDS
CAP CDS
OData V4


**TITLE**: Read Before Extending a Generated SAP Fiori Elements App (Actionable Guide for Extension Coding)

**INTRODUCTION**: Brief, code-focused guidance for writing safe SAP Fiori elements extensions. Describes which APIs and models you may access, what to avoid, and small code snippets showing common, allowed actions inside view/controller extensions. Use this as a checklist and code reference when generating extension code.

**TAGS**: fiori-elements, extensionAPI, SAPUI5, OData, models, best-practices, manifest.json

STEP: 1 — High-level rules and caution

DESCRIPTION: Follow these rules before creating or generating an extension. Always prefer manifest settings or annotations before writing extension code. Use only the official SAP Fiori elements extensionAPI when interacting with template-provided controls and system logic. Once you add extension code, display and runtime behavior are the app's responsibility.

LANGUAGE: Plain

CODE:
```text
Caution:
- Use app extensions only when required; prefer manifest settings/annotations.
- When interacting with template/provided controls or template system logic, use the official extensionAPI only.
- Do NOT access or manipulate internal template objects (controls, models, properties) outside the scope of your view/controller extension.
```

STEP: 2 — Use the standard SAPUI5 API only within your extension scope

DESCRIPTION: You may use the SAPUI5 API in extension views/controllers, but limit access to UI elements you defined within your view extension. Access these elements by their IDs (this.byId or this.getView().byId). Do not access controls created by the template or other extensions — this risks breakage in future SAPUI5 versions.

LANGUAGE: JavaScript

CODE:
```javascript
// Allowed: access element defined in your extension view by ID
const oMyButton = this.byId("myExtensionButton");
if (oMyButton) {
  oMyButton.setVisible(false);
}

// Forbidden: DO NOT access template-only controls
// e.g., avoid calls like this.byId("templateControlId") if control is not part of your extension view
```

STEP: 3 — Accessing models (general)

DESCRIPTION: The generated app has multiple models. You can use the default OData model for data binding and the named "ui" model for read-only UI state. Never access or modify the SAP Fiori elements private model. If you attach your own models, use a unique namespace name and attach them scoped to your extension view unless absolutely necessary to use a higher level.

LANGUAGE: JavaScript

CODE:
```javascript
// Get default OData model (as defined in manifest.json)
const oODataModel = this.getView().getModel();            // default model

// Get named UI model (read-only)
const oUIModel = this.getView().getModel("ui");
const bEnabled = oUIModel.getProperty("/enabled");       // allowed (read)
 // DO NOT call oUIModel.setProperty("/enabled", false)  // forbidden (no writes)

// Attach an app-specific JSON model scoped to your extension view
const oMyJsonModel = new sap.ui.model.json.JSONModel({ foo: "bar" });
this.getView().setModel(oMyJsonModel, "com.mycompany.myModel"); // use your namespace

// Access model only within extension scope; be careful with side effects on default model
```

STEP: 4 — Rules about SAP Fiori Elements private model and application-specific models

DESCRIPTION: The SAP Fiori Elements private/internal model is forbidden to access. If you must create models, attach them to UI elements exclusive to your extension or, if attached higher, use a namespaced model name to prevent collisions.

LANGUAGE: Plain

CODE:
```text
Rules:
- Forbidden: Access any SAP Fiori Elements private model (do not call getModel() with unknown names).
- Allowed: Use default OData model and "ui" model (read-only).
- Allowed: Create JSON models for your extension and attach with a unique namespaced name:
    this.getView().setModel(new JSONModel(...), "com.mycompany.myModel");
- Prefer scoping custom models to the extension view instead of the global view.
```

STEP: 5 — OData V2: interacting with template-provided functions and function imports

DESCRIPTION: For OData V2, always use the extensionAPI to interact with template-provided functions or to invoke function imports to avoid interfering with template lifecycle and side effects. If your extension only touches controls generated within the extension, extensionAPI may not be required.

LANGUAGE: JavaScript

CODE:
```javascript
// Example: use extensionAPI to invoke actions/functionality provided by the template
// NOTE: extensionAPI is the official interface; obtain it from the controller context when available.
// Pseudocode (actual signature depends on runtime extensionAPI implementation):
if (this.extensionAPI && typeof this.extensionAPI.invokeActions === "function") {
  // Pass action description(s) according to the extensionAPI contract
  this.extensionAPI.invokeActions(/* actionParameters */)
    .then(function (result) { /* handle success */ })
    .catch(function (err) { /* handle error */ });
} else {
  // Fallback: do NOT call OData function imports directly on the template model
}
```

STEP: 6 — Avoid using internal or freestyle-only services

DESCRIPTION: Do not use services intended for freestyle SAPUI5 apps or internal template usage. Accessing these services can cause side effects or break compatibility.

LANGUAGE: Plain

CODE:
```text
Do NOT use:
- sap.ui.generic.app
- sap.fe.navigation
- sap.ui.generic.template (directly)

Reason:
- These namespaces are for freestyle apps or internal template code. Using them in extensions can create unwanted side effects or break template behavior.
```

STEP: 7 — UI model properties (for code checks and read usage)

DESCRIPTION: Read these UI model properties to adapt extension UI state or logic. Do not change these properties programmatically because the template controls when they are set/reset.

LANGUAGE: JavaScript

CODE:
```javascript
// OData V2 UI model Boolean properties (read-only)
const oUIModel = this.getView().getModel("ui");
const bEnabled = oUIModel.getProperty("/enabled");    // whether active UI elements should be enabled
const bEditable = oUIModel.getProperty("/editable");  // whether inputs are editable
const bCreateMode = oUIModel.getProperty("/createMode"); // true when creating a new entity

// OData V4 UI model properties
const sEditMode = oUIModel.getProperty("/editMode");  // "Editable" or "Display"
```

STEP: 8 — File references and manifest context

DESCRIPTION: The OData default model is the model defined in your app's manifest.json. When generating or modifying extension code, ensure you reference the correct model name and manifest configuration.

LANGUAGE: Plain

CODE:
```text
File: manifest.json
- Default OData model is configured in the manifest under "sap.app"/"dataSources" and "sap.ui5"/"models".
- Access this default model in extension controllers via:
    const oODataModel = this.getView().getModel();    // default
- Named models (e.g., "ui") are accessed by name:
    const oUIModel = this.getView().getModel("ui");
```

STEP: 9 — Summary checklist for code generation

DESCRIPTION: Quick checklist to enforce via code generation templates.

LANGUAGE: Plain

CODE:
```text
Checklist:
- Prefer manifest settings/annotations over extensions.
- Use extensionAPI for template/system interactions (invokeActions for function imports).
- Access only controls you created in your extension view (use this.byId or this.getView().byId).
- Use default OData model and "ui" model only as allowed (read-only for "ui").
- Never access SAP Fiori Elements private model.
- Avoid sap.ui.generic.app, sap.fe.navigation, sap.ui.generic.template.
- Scope custom JSON models to your extension view and use a namespaced model name.
```

fiori-elements extensionAPI SAPUI5 OData models best-practices manifest.json