Remove Leading Zero of a Field in CDS (ADT)

Example: Field QAPP.PPSORTKEY

Original Code

      /*-- Sample / Inspection Point (from QAPP) ---------------------------*/
      qapp.probenr    as SampleInspectionPoint,
      qapp.ppsortkey, as InspectionPoint

The change, using ltrim (supported in CDS view entities):

New Code

      /*-- Sample / Inspection Point (from QAPP) ---------------------------*/
      qapp.probenr    as SampleInspectionPoint,
      ltrim( qapp.ppsortkey, '0' ) as InspectionPoint

Two notes on this:
ltrim( field, '0' ) removes only leading '0' characters — an all-zero value becomes an empty string. If you'd rather show '0' in that case, wrap it: case when ltrim(...) = '' then '0' else ltrim(...) end. I didn't add that since you didn't ask.
The result type stays character, same length — no dictionary impact, activation-safe. If the Fiori app later sorts or filters on InspectionPoint, remember it's now text-sorted without zero padding, so ordering across values of different lengths will look wrong ('12' before '3' is gone, but '3' now comes after '12' alphabetically... actually '12' < '3' as text). If sorting matters, keep the raw field as a hidden sort column.

CDS View Types in SAP: Basic, Composite, and Consumption Views

These three types represent a layered architecture (also called the VDM – Virtual Data Model) used in SAP S/4HANA to structure CDS views by responsibility and reuse.

---

1. Basic View (@VDM.viewType: #BASIC)

• Purpose: Sits directly on top of database tables or database views. It maps raw persistence layer data into a semantically meaningful structure.
• Characteristics:
  • Accesses only one or very few base tables (minimal joins)
  • Contains no aggregations
  • Defines primary key, associations, and field-level annotations (e.g., @Semantics)
  • Acts as the single source of truth for a business entity
• Example use: A basic view on EKKO (Purchase Order Header) that exposes PO fields cleanly.

---

2. Composite View (@VDM.viewType: #COMPOSITE)

• Purpose: Combines and joins multiple Basic Views (or other Composite Views) to build a richer, more complete business object or business context.
• Characteristics:
  • No direct access to database tables — always consumes Basic or other Composite views
  • Can include joins, unions, and calculated fields
  • Still mostly transactional/reporting-neutral — focuses on combining entities
  • Reusable across multiple consumption scenarios
• Example use: A composite view joining PO Header and PO Item basic views to form a complete purchase order view.

---

3. Consumption View (@VDM.viewType: #CONSUMPTION)

• Purpose: Tailored for a specific consumer — an app, report, API, or UI. It is the outermost layer exposed to the end user or application.
• Characteristics:
  • Consumes Basic or Composite views (never touches tables directly)
  • Contains use-case-specific projections, filters, and annotations
  • Heavily annotated for the target consumer: @UI, @OData, @Analytics, @Search, etc.
  • May include aggregations (for analytical consumption)
  • Often not reused by other CDS views — it's purpose-built
• Example use: A Fiori Elements list report view for Purchase Orders, with @UI.lineItem annotations.

---

Summary Table

Aspect	Basic View	Composite View	Consumption View
Accesses DB Tables	✅ Yes	❌ No	❌ No
Joins other CDS views	Minimal	✅ Yes	✅ Yes
Reusability	High	High	Low (purpose-built)
UI/OData Annotations	Rare	Rare	✅ Heavy
Aggregations	❌ No	Rarely	✅ Yes (analytics)
VDM Annotation	#BASIC	#COMPOSITE	#CONSUMPTION

---

Key Design Principle

Changes cascade upward, not downward.

If a table structure changes, you only fix the Basic View — Composite and Consumption views remain stable. This layering promotes stability, reuse, and separation of concerns, which is central to SAP's clean core philosophy in S/4HANA.