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.

| Activity | On-Premise (ECC/S/4HANA OP) | Cloud PE | |----------|------------------------------|----------| | ABAP Modifications (SE38) | ✓ Allowed | ✗ FORBIDDEN | | Function Module Enhancements (SMOD/CMOD) | ✓ Allowed | ✗ FORBIDDEN | | Workflow Customizing (SWDD) | ✓ Allowed | △ Limited (no code exits) | | IMG Configuration | ✓ Full (SPRO) | △ Limited (Manage Your Solution) | | BAdI Implementation | ✓ Standard (SE19) | ✗ FORBIDDEN (use RAP instead) | | Enhancement Spots | ✓ Full (BADI_DEF) | ✗ FORBIDDEN | | Standard Table Modifications | ✓ Allowed (append structures) | ✗ FORBIDDEN | | Transport Mechanism | ✓ TMS (TP/TP4) | ✗ Direct upload to Cloud ALM |

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: "사용자정의 필드")

1. Deploy: Activation is immediate (no transport)
2. 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: MANAGECUSTOMFIELDS (Fiori)
• Object: Purchasing Document (PO)
• Field: ZZAPPRCODE (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

1. Validations — Block invalid data

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

1. 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*)

| Capability | Tier 1 | Delivery | Ownership | |---|---|---|---| | Custom Fields | ✓ | Immediate (Fiori UI) | End User / Functional consultant | | Custom Validations | ✓ | 1-2 days (CDS Validation) | Functional consultant (no ABAP needed) | | Custom Calculations | ✓ | 1-2 days (CDS Calculation) | Functional consultant | | Custom CDS Views | ✓ | 3-5 days | ABAP Cloud developer | | Standard APIs | ✓ | 3-5 days (RAP event handler) | ABAP Cloud developer | | Custom UI (Fiori) | ✓ | 1-2 weeks | SAP Fiori developer (low-code) |

*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:

| Current (Legacy) | SAP Standard | Decision | |---|---|---| | "Approval workflow must go to 3 approvers" | SAP workflows support multi-level approval | Fit — use standard SAP workflow (no custom code) | | "Cost center must be auto-filled from cost center master" | Standard provides default values | Fit — configure default values (no custom logic) | | "Invoice must reject if VAT% doesn't match contract" | SAP validation engine (CDS) exists | Extend — Tier 1 Custom Logic (1-2 days) | | "System must call legacy SMTP gateway for email" | SAP Cloud PE cannot call legacy on-premise | Workaround — use BTP Email Service or Tier 2 |

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).

| Activity | Frequency | Your Action | |---|---|---| | Security patches | Monthly (1st Tuesday) | Auto-applied by SAP (0 downtime) | | Feature releases | Quarterly | Review FSD (Feature Scope Description) | | Custom extension re-validation | Monthly | Check if your custom code still works | | Regression testing | Quarterly | Full regression suite (Cloud ALM) |

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 한국 비즈니스 프로세스 특성

| Process | SAP Standard | Korean Adaptation | Extension Needed? | |---|---|---|---| | 부가세 (VAT) | EU VAT standard | 한국식 3단계 부가세 (조기환급, 선수금) | NO (standard config) | | 원천세 (Withholding Tax) | Generic withholding tax | 한국 근로소득, 이자, 배당 세율 | NO (standard config) | | 원가마감 (Period-End Cost Close) | Monthly/Quarterly | 한국 회사는 월마감 필수 | NO (standard config) | | 자산회계 (Fixed Assets) | Standard depreciation | 한국식 감가상각법 (정액법, 정률법, 년수합계법) | NO (standard config) | | 보조금 회계 (Subsidy Accounting) | Not standard | 정부지원금 추적 필요 (기업 특성) | YES (Tier 1 custom logic) | | 관세 (Customs) | Not standard | 해외 수입/수출 관세 | YES (Tier 2 for customs broker integration) | | 외환 (Foreign Ex

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: BoxLogoDev
• Source: BoxLogoDev/sapstack
• License: MIT

Install and usage instructions live in the source repository linked above.