Sap Cloud

1. Environment Intake Checklist

When any Cloud PE issue or extension task is reported, collect before answering:

• Cloud PE Version: 2401 / 2402 / 2403 / 2405 / (specific release month/year)
• Tenant Type: Production / Non-Production (Test / Staging)
• Extension Tier: Tier 1 (Key User Extensibility) / Tier 2 (Side-by-Side BTP) / Tier 3 (On-Stack ABAP Cloud)
• Deployment Model: Cloud PE (never mention on-premise SE38/SE80/SMOD/CMOD — they are forbidden)
• Industry Sector: Manufacturing / Finance / Retail / Public Sector / Other
• Change Control: Are you in Fit-to-Standard phase or Operations phase?

2. Clean Core Principles (Non-Negotiable)

SAP S/4HANA Cloud PE enforces Clean Core — no modifications to SAP standard code or tables.

Forbidden T-codes in Cloud PE:

• SE11 (ABAP Dictionary modifications)
• SE38 (Classic ABAP program creation)
• SE80 (Object Navigator for custom code)
• SMOD / CMOD (Exit/Enhancement modification)
• SWDD (Classic Workflow definition)
• SPAM / SAINT (Transport/patch — managed by SAP)

3. Key User Extensibility — Tier 1 (Self-Service)

3.1 Custom Fields (Extensibility Add-Ons)

Enable end users (non-developers) to add business fields without coding.

How to Create Custom Fields:

1. In Cloud PE UI → Manage Your Solution → Custom Fields
2. Select object (Purchase Order, Sales Order, Material Master, etc.)
3. Click Create Custom Field
   • Field Name: ZZ_CUSTOM_FIELD (naming convention)
   • Data Type: Quantity / Amount / Date / Text / Dropdown
   • Label: Business-facing label (Korean: "사용자정의 필드")
4. Deploy: Activation is immediate (no transport)
5. UI Integration: Auto-added to relevant screens (Fiori UIs)

Limitations:

• No transactional logic (no derived fields)
• No cross-object validation
• Max 200 custom fields per object
• Field length: Text max 255 characters

Example: Add "승인 요청 코드" (approval code) to PO header:

• T-code: MANAGE_CUSTOM_FIELDS (Fiori)
• Object: Purchasing Document (PO)
• Field: ZZ_APPR_CODE (Text, length 20)
• Result: Auto-visible in PO Fiori app (no coding needed)

3.2 Custom Logic (ABAP Cloud with RAP)

For business logic beyond custom fields — use Restricted ABAP Programming (RAP) on released SAP APIs.

What is RAP (Restful ABAP Programming)?

• Cloud-native ABAP development model (CDS-based)
• No classic ABAP (SELECT, MODIFY, DELETE) — replaced by CDS + Event Handler
• Event-driven (Create, Update, Delete hooks)
• Published as OData V4 APIs automatically

Tier 1 Custom Logic Entry Points (Key User-friendly):

1. Calculations/Derivations — Automatic field computation

   • Example: "Invoice Amount = Net Amount + Tax" (tax auto-calc on item save)
   • Implementation: CDS Calculation / Transient Field

2. Validations — Block invalid data

   • Example: "PO quantity must not exceed contract qty"
   • Implementation: CDS Validation (CDS element WITH ... , associations)

3. Default Values — Pre-fill fields on creation

   • Example: "Set cost center from user default"
   • Implementation: CDS Default Handler

ABAP Cloud Restrictions:

• ✗ SELECT FROM database table (use CDS instead)
• ✗ MODIFY table directly
• ✗ CALL FUNCTION (classic RFC)
• ✓ CALL API (SAP standard APIs released)
• ✓ SQL queries via CDS Views
• ✓ OData consumption via HTTP

Example: Validate PO quantity vs. contract

CDS View: ZC_PO_CUSTOM
  element ZZ_CONTRACT_QTY : Contract Qty;
  
Validation Rule:
  if (PO_QTY > ZZ_CONTRACT_QTY) {
    raise_severity(error, 'Qty exceeds contract');
  }

3.3 Custom CDS Views (Read-Only Analytics)

Expose custom data models for reporting without modifying SAP tables.

Use Case: Create custom analytics on top of SAP data.

• Example: "Monthly spend by cost center vs. budget"
• Technology: CDS (Core Data Services)
• Consumption: Fiori Analytical App / Excel / Analytics Cloud

Steps:

1. ABAP Workbench (in Cloud PE) → Create CDS View
2. Define associations to standard SAP tables (PO, Invoice, GL, etc.)
3. Add calculations (SUM, AVG, COUNT)
4. Publish as OData (automatic)
5. Create Fiori app or connect to Analytics Cloud (SAC)

Limitations:

• Read-only (no CRUD operations)
• Max 100M rows per query (performance limits)
• Must use released SAP tables (not custom Z-tables)

3.4 Custom Business Objects (Transactional Objects)

For completely new entities (not extending existing SAP objects).

Example: "Internal Service Request" (separate from Purchase Order)

Technology: ABAP Cloud Business Objects (BO, OData)

Development Steps:

1. Create CDS View (root entity)
2. Define structure (header / items)
3. Create event handler (Create / Update / Delete)
4. Publish as OData V4
5. Create Fiori UI (using SAP Fiori Elements)

4. 3-Tier Extension Model

Decision Tree: Which Tier for Your Use Case?

START
  ↓
Does your need fit Cloud PE standard?
  ├─→ YES → Use Standard Configuration (no extension needed)
  ├─→ NO → Does it require custom fields only?
  │          ├─→ YES → TIER 1 (Custom Fields only, end-user self-service)
  │          ├─→ NO → Does it require business logic (validation, calc) OR analytics?
  │                    ├─→ YES → TIER 1 (Custom Logic via RAP / CDS Views)
  │                    ├─→ NO → Do you need external integration (non-SAP APIs)?
  │                              ├─→ YES → TIER 2 (BTP side-by-side app)
  │                              ├─→ NO → Do you need classic ABAP OR table modifications?
  │                                        ├─→ YES → TIER 3 (On-Stack ABAP Cloud)
  │                                        └─→ NO → Evaluate Tier 2 (cleaner architecture)

Tier 1: Key User Extensibility (In-Cloud, No Coding*)

*No Classic ABAP (SE38); ABAP Cloud is light-weight, CDS-centric.

Release Cycle: Delivered in next Cloud PE Monthly Release (no need to wait for quarterly)

Tier 2: Side-by-Side Extension (BTP, Managed Service)

For use cases requiring:

• External systems integration (CRM, ERP, custom legacy system)
• Non-SAP data models
• Complex workflows (beyond SAP workflows)
• Custom UIs (Web app, Mobile, IoT)

Technology Stack:

• BTP (Business Technology Platform)
• CAP (Cloud Application Programming model)
• JavaScript/TypeScript (Node.js backend)
• Fiori / Custom HTML5 (Frontend)
• Event Mesh (async integration)

Architecture:

Cloud PE SAP
     ↓
  APIs (OData)
     ↓
BTP CAP App ← Custom Logic
     ↓
External Services (3rd-party APIs)
     ↓
Custom UI (Fiori, Mobile, Web)

Example: Integration with vendor procurement system

Cloud PE → API Gateway → BTP CAP Service → Vendor System
   ↑_________________________↓
      (async: purchase order created → notify vendor)

Development Effort: 4-8 weeks (includes BTP setup, CAP, testing, deployment)

Release Cycle: Flexible (deployed directly to BTP, not tied to Cloud PE quarterly release)

Tier 3: On-Stack ABAP Cloud (High-Control, Complex Logic)

For use cases requiring:

• Transactional consistency (multi-step atomic operations)
• Table structure extensions (fields not available via Custom Fields)
• Business object enhancements (complex workflows, side effects)
• Legacy code conversion (ABAP Classic → ABAP Cloud)

Constraints:

• Must use released SAP APIs only (CHECK /IWBEP/SBCO_APPL_TYPES)
• No classic ABAP (no SELECT ... FROM ... statements — use CDS)
• No standard table modifications (use Custom Fields + RAP)
• Code deployed via Cloud ALM (Custom Software Package)

Technology:

• ABAP Cloud (subset of ABAP on Cloud PE)
• RAP (Restful ABAP Programming)
• CDS (Core Data Services)
• Event Handlers (Create/Update/Delete/Save)

Example: Complex PO validation

ABAP Cloud Event Handler (Tier 3):

CLASS zcl_po_validation DEFINITION FINAL CREATE PRIVATE
  ...
  METHODS validate( po_data TYPE STRUCT ) RAISING EXCEPTION;
    
    IF po_data-qty > contract_qty THEN
      RAISE EXCEPTION ...
    ENDIF.
    
    IF po_data-price > price_limit THEN
      RAISE EXCEPTION ...
    ENDIF.
END CLASS.

Release Cycle: Deployed via Cloud ALM (can be mid-cycle if urgent, coordinated with SAP)

5. Fit-to-Standard Methodology

Goal: Minimize custom extensions by adapting business process to SAP Cloud PE standard.

5.1 Fit-to-Standard Workshop (Day 1-3)

Participants: Business analyst, functional consultant, IT lead, SAP solution architect

Phase 1: Current State (Day 1)

1. Map customer's current business processes (draw swimlanes)
2. Document all deviations from SAP standard
   • Custom fields in use?
   • Custom screens?
   • Custom reports?
   • Manual workarounds?

Phase 2: Future State — Standard SAP (Day 2)

1. Walk through SAP Cloud PE standard processes
2. Identify which customer requirements are already satisfied by SAP
3. Document remaining gaps (true business needs vs. legacy habits)

Phase 3: Gap Analysis (Day 2-3)

1. For each gap, decide:
   • Fit: Change business process to match SAP standard (no extension needed)
   • Extend: Custom field / custom logic (use Tier 1/2/3)
   • Workaround: Manual process (not ideal, but sometimes business decision)

Example Gap Resolution:

5.2 Delta Design (Post-Workshop)

Create document (delivered to customer):

DELTA DESIGN DOCUMENT
====================

1. Processes Fitting Standard (0 extensions needed)
   - Purchasing (PO to GR to IV)
   - Accounts Payable
   - Sales Order to Invoice

2. Required Extensions (Tier 1/2/3)
   a) Custom Field: Cost Center Sub-Division (Tier 1)
      Effort: 2 days
      Release: Next monthly release
   
   b) Custom Logic: PO Approval Workflow (Tier 1, CDS validation)
      Effort: 5 days
      Release: Next monthly release
   
   c) Side-by-Side: Vendor Portal (Tier 2, BTP CAP)
      Effort: 6 weeks
      Deployment: Separate BTP tenant

3. Workarounds (Manual Steps)
   - Monthly reconciliation report generation (IT manual export)
   - Legacy data migration (via LSMW, one-time)

TOTAL EXTENSION EFFORT: 7 weeks (vs. 6 months if no Fit-to-Standard)
CUSTOM CODE FOOTPRINT: 2 Tier 1 + 1 Tier 2 (minimal maintenance)

6. Cloud ALM (Application Lifecycle Management)

SAP's governance tool for Cloud PE updates, extensions, and quality assurance.

6.1 Cloud ALM Phases

IMPLEMENTATION PHASE (Go-Live Preparation)
  ├─ Test cycles (SIT, UAT)
  ├─ Regression testing
  ├─ Go-live cutover planning
  └─ Data load validation

OPERATIONS PHASE (Post Go-Live)
  ├─ Quarterly SAP release upgrades (automatic)
  ├─ Custom extensions deployment
  ├─ Hotfix management
  └─ Issue management & change requests

6.2 Deployment via Custom Software Package (CSP)

CSP = deliverable unit for Tier 1 / Tier 3 custom extensions.

Contents:

• CDS Views (custom logic, analytics)
• RAP Behavior (validations, calculations)
• Fiori UI components
• Custom business objects
• Transport artifacts

Deployment Process:

1. Developer → Package extension in ABAP Workbench
2. Quality Gate → Run Cloud ALM quality checks (ABAP Unit, Integration tests)
3. SAP Review (optional, for Tier 3) → SAP validates against released API list
4. Upload to Cloud ALM → CSP package
5. Cloud PE Apply → Deploy to production tenant (with rollback capability)

6.3 Quarterly Release Management

SAP releases Cloud PE updates every month (for security/minor features) and major release every quarter (functional features, UI updates).

Key: Cloud PE upgrades are mandatory and happen overnight (UTC). Plan testing for next day.

7. Feature Scope Description (FSD)

Before each quarterly release, SAP publishes FSD — detailed list of new features, deprecations, and breaking changes.

How to Use FSD:

1. Download from SAP (Cloud PE Release Notes)
2. Filter for your industry (Manufacturing / Finance / Retail / etc.)
3. Identify business impact
   • New features we want to enable → activate in Cloud ALM
   • Deprecated features we use → plan migration
   • Breaking changes → test custom extensions immediately

Example FSD Entry:

Feature: Enhanced PO Approval Workflow
Status: NEW
Availability: 2405 release (May 2024)
Industry: Manufacturing
Description: New approval levels, delegation support, email notifications
Business Impact: Can now retire custom approval system (Tier 2 BTP)
Action Required: Review current PO approval process, consider migration
Custom Code Impact: RAP validations will continue to work (backward compatible)

8. Korean Cloud PE Considerations

8.1 데이터 레지던시 (Data Residency)

SAP Cloud PE for Korea runs in 서울 Region (ap-northeast-2) on AWS.

• 데이터는 한국에만 저장 (금융위원회 규정)
• 백업도 한국 리전 (재해복구 목적)
• 감사 추적 (audit log) — 모든 변경사항 기록 (K-SOX 대비)

Implication for Extensions:

• Tier 2 BTP apps can call external APIs, but data must not leave Korea
• Tier 3 custom logic runs in-database (data stays in Korea)

8.2 한국 비즈니스 프로세스 특성

8.3 IT 거버넌스 (한국 금융감독 대비)

• 감사증적 (Audit trail) — all changes to Financials module → stored 3년
• 이중승인 (Dual Control) — FI document posting requires 2 approvers (OBC4 configuration)
• 권한 분리 (Segregation of Duty) — Create ≠ Approve ≠ Post (role configuration)

9. ECC vs S/4HANA vs Cloud PE Differences

Functional Comparison

Development & Deployment

10. Standard Response Format

All answers follow this structure:

Issue (사용자 보고사항 재정의) → Environment (Cloud PE 버전, extension tier, current state) → Root Cause (가능한 원인) → Check (Fiori UI path / Cloud ALM check / T-code in dev tenantif applicable) → Fix (단계별 해결 방법) → Prevention (설정/governance 권장) → References (관련 SAP docs / FSD / Cloud ALM best practices)

11. References

• plugins/sap-cloud/skills/sap-cloud/references/img/overview.md — Cloud ALM IMG 구조
• plugins/sap-cloud/skills/sap-cloud/references/img/key-user-extensibility.md — Custom Fields/Logic/CDS 구성
• plugins/sap-cloud/skills/sap-cloud/references/img/fit-to-standard.md — 워크숍 절차
• plugins/sap-cloud/skills/sap-cloud/references/best-practices/operational.md — Cloud PE 일상 운영 BP
• plugins/sap-cloud/skills/sap-cloud/references/best-practices/period-end.md — 기간마감 BP
• plugins/sap-cloud/skills/sap-cloud/references/best-practices/governance.md — 거버넌스 (릴리즈, 확장 통제)
• plugins/sap-cloud/skills/sap-cloud/references/ko/quick-guide.md — 한국어 퀵가이드