I_ServiceConfirmation 실수 3가지 #shorts #SAP #ABAP

📖 개요와 이 글에서 다루는 내용

SAP S/4HANA에서 설비 정비·현장 서비스가 끝나면 "실제로 무엇을 얼마나 수행했는가"를 기록하는 문서가 서비스 확정(Service Confirmation)입니다. 이를 조회하는 표준 릴리스 CDS 뷰가 I_ServiceConfirmation인데, 실무에서는 이 뷰를 잘못 사용해 성능 저하나 데이터 오독이 자주 발생합니다. 이 글은 중급 ABAP 개발자를 대상으로 자주 반복되는 실수 3가지를 분석하고 올바른 예제를 제시합니다.

• I_ServiceConfirmation의 역할과 ServiceOrder와의 관계를 구분할 수 있다
• 필터 푸시다운을 활용해 대용량 정비 데이터를 안전하게 조회할 수 있다
• 여러 상태 필드(라이프사이클/처리 상태)를 올바르게 해석할 수 있다
• 커스텀 CDS 뷰와 예외 처리를 포함한 프로덕션 수준 코드를 작성할 수 있다

📚 미리 알아두면 좋은 배경

ABAP CDS 뷰 정의와 SELECT ... FROM cds_view 구문, 연관(association) 개념을 알고 있다면 충분합니다. PM(설비 정비) 또는 S/4HANA Service 모듈에서 서비스 주문 → 작업 수행 → 확정으로 이어지는 문서 흐름을 경험해 봤다면 이해가 훨씬 빠릅니다. VDM(Virtual Data Model)의 인터페이스 뷰(I_*) 명명 규칙도 함께 떠올려 두세요.

🔧 환경 · 버전 · 준비 사항

이 글의 예제는 다음 환경을 기준으로 작성했습니다.

• SAP S/4HANA Cloud 또는 S/4HANA 온프레미스 2022 이상 — I_ServiceConfirmation은 S/4HANA Service 영역의 릴리스된 인터페이스 뷰로, 릴리스에 따라 필드 구성이 조금씩 다를 수 있습니다
• ABAP Development Tools(ADT, Eclipse 기반) — CDS 뷰 정의 확인과 Data Preview에 필요
• 서비스 확정 문서를 조회할 수 있는 비즈니스 권한(DCL 접근 제어 대상)
• 테스트용으로 서비스 주문·확정 데이터가 존재하는 클라이언트

시작 전 ADT에서 I_ServiceConfirmation을 열어 자신의 릴리스에서 제공되는 필드 목록을 확인하는 것을 권장합니다. 온프레미스와 클라우드 에디션 간에 일부 필드·연관 이름이 다를 수 있습니다.

💡 핵심 개념 — I_ServiceConfirmation의 구조와 역할

비유하자면 서비스 주문(Service Order)은 "작업 지시서"이고, 서비스 확정(Service Confirmation)은 "작업 완료 보고서"입니다. 지시서에는 계획된 작업·부품·시간이 적혀 있고, 완료 보고서에는 실제 투입된 시간·자재·수행 결과가 적힙니다. 하나의 주문에 여러 건의 확정이 생길 수 있다는 점(부분 확정)도 실제 현장 보고서와 같습니다.

I_ServiceConfirmation은 이 "완료 보고서"의 헤더를 노출하는 인터페이스 뷰이며, 일반적으로 다음과 같은 정보를 담습니다.

구분	대표 필드(예)	의미
키	ServiceConfirmation	확정 문서 번호
유형	ServiceConfirmationType	확정 문서 유형(트랜잭션 타입)
참조	선행 서비스 주문 참조 필드	어떤 주문에 대한 확정인지
상태	ServiceConfLifeCycleStatus 등	문서의 라이프사이클 상태
조직/파트너	SoldToParty, 서비스 조직	고객·조직 정보

문서 흐름은 다음과 같이 요약할 수 있습니다.

서비스 주문(계획) → 기술자 작업 수행 → 서비스 확정(실적) → 릴리스 → 후속 회계/청구 처리

중요한 점은 헤더 뷰인 I_ServiceConfirmation과 아이템 뷰인 I_ServiceConfirmationItem이 분리되어 있다는 것입니다. 실제 투입 시간·자재 수량 같은 실적 상세는 아이템 레벨에 있으므로, 헤더만 조회하고 "실적 데이터가 없다"고 오해하는 경우가 없어야 합니다. 또한 이 뷰는 DCL 접근 제어(@AccessControl.authorizationCheck: #CHECK)가 걸려 있는 것이 일반적이므로, 권한이 없는 사용자는 데이터가 있어도 빈 결과를 받게 됩니다.

💻 실전 코드 3단계

1단계 — 기본 예제: 필터를 갖춘 안전한 조회

실수 1: 필터 조건 없이 전체 데이터 읽기. PM/서비스 데이터는 수년치가 누적되면 수백만 건에 달합니다. WHERE 없이 읽으면 HANA에서 풀 스캔이 발생하고, 애플리케이션 서버 메모리로 전량 전송됩니다. 반드시 기간·유형·상태로 범위를 좁히고 필요한 컬럼만 지정하세요.

" 잘못된 예 — 전체 풀 스캔 + 전 컬럼 전송
SELECT * FROM i_serviceconfirmation
  INTO TABLE @DATA(lt_all_conf).   " 수백만 건이 메모리로 유입될 위험

" 올바른 예 — 기간/유형 필터 + 필요한 컬럼만
SELECT FROM i_serviceconfirmation
  FIELDS serviceconfirmation,
         serviceconfirmationtype,
         soldtoparty,
         creationdate
  WHERE creationdate            >= @lv_from_date
    AND serviceconfirmationtype =  @lv_conf_type
  ORDER BY creationdate DESCENDING
  INTO TABLE @DATA(lt_confirmations)
  UP TO 200 ROWS.

UP TO n ROWS와 컬럼 지정은 HANA 푸시다운을 살리는 가장 기본적인 습관입니다.

2단계 — 실무 시나리오: 설비 정비 완료 후 확정 조회

실수 2: ServiceConfirmation과 ServiceOrder 혼동. "주문 번호로 확정 뷰를 조회했는데 결과가 없다"는 문의가 잦습니다. 주문 번호와 확정 번호는 서로 다른 문서 번호 체계입니다. 확정 헤더의 선행 주문 참조 필드(릴리스에 따라 아이템 레벨 참조일 수 있음)로 연결해야 합니다. 아래는 특정 설비 정비 주문의 확정 실적을 조회하며 예외 처리와 로깅을 포함한 예제입니다.

CLASS zcl_maint_conf_reader DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS get_confirmations_for_order
      IMPORTING iv_service_order      TYPE crmt_object_id_db
      RETURNING VALUE(rt_result)      TYPE ztt_maint_conf
      RAISING   zcx_maint_conf_error.
ENDCLASS.

CLASS zcl_maint_conf_reader IMPLEMENTATION.
  METHOD get_confirmations_for_order.
    " 확정 아이템에서 선행 주문을 참조 → 헤더와 조인
    SELECT FROM i_serviceconfirmationitem AS item
      INNER JOIN i_serviceconfirmation  AS conf
        ON item~serviceconfirmation = conf~serviceconfirmation
      FIELDS conf~serviceconfirmation,
             conf~serviceconfirmationtype,
             conf~creationdate,
             item~serviceconfirmationitem
      WHERE item~referenceserviceorder = @iv_service_order
      INTO CORRESPONDING FIELDS OF TABLE @rt_result.

    IF sy-subrc <> 0.
      " 애플리케이션 로그 기록 후 의미 있는 예외로 변환
      zcl_app_log=>get_instance( )->add_warning(
        |주문 { iv_service_order }에 대한 확정 문서 없음| ).
      RAISE EXCEPTION TYPE zcx_maint_conf_error
        EXPORTING textid = zcx_maint_conf_error=>no_confirmation_found.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

참조 필드명(ReferenceServiceOrder 등)은 릴리스별로 다를 수 있으니 ADT에서 실제 이름을 확인 후 적용하세요. 핵심은 주문 뷰가 아니라 확정 뷰의 참조 필드로 역추적한다는 패턴입니다.

3단계 — 프로덕션: 상태 필드를 명확히 다루는 커스텀 뷰

실수 3: Status 필드 오해. 확정 문서에는 라이프사이클 상태, 릴리스 여부, 후속 처리 상태 등 성격이 다른 상태 정보가 공존합니다. "완료(Completed)"는 문서 작성이 끝났다는 뜻이지 회계 반영까지 끝났다는 뜻이 아닙니다. 프로덕션에서는 커스텀 CDS 뷰에서 상태를 의미 있는 이름으로 노출해 소비자 코드의 오독을 차단하는 방식을 권장합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '설비 정비 확정 요약 (완료+릴리스만)'
define view entity ZI_MaintConfCompleted
  as select from I_ServiceConfirmation
{
  key ServiceConfirmation,
      ServiceConfirmationType,
      SoldToParty,
      CreationDate,
      ServiceConfLifeCycleStatus,
      // 상태 의미를 이름으로 명시해 소비자 오독 방지
      case ServiceConfLifeCycleStatus
        when 'C' then 'X'
        else ''
      end as IsDocumentCompleted
}
where
  ServiceConfLifeCycleStatus = 'C'   // 완료된 문서만 노출

테스트는 CDS Test Double Framework로 뷰 로직을, ABAP Unit으로 소비 클래스를 검증합니다.

METHOD completed_only_is_returned.
  cl_cds_test_environment=>create( 'ZI_MAINTCONFCOMPLETED' ).
  " 완료('C') 1건 + 미완료('A') 1건 주입 후, 결과가 1건인지 검증
  cl_abap_unit_assert=>assert_equals( act = lines( lt_result )
                                      exp = 1 ).
ENDMETHOD.

보안 측면에서는 커스텀 뷰에도 반드시 DCL을 정의해 표준 뷰의 접근 제어가 우회되지 않도록 해야 합니다. 상태 코드 값('C' 등)은 시스템 구성에 따라 다를 수 있으므로 도메인 고정값을 먼저 확인하세요.

⚠️ 흔한 실수 정리와 트러블슈팅 FAQ

• 실수 1 — 무필터 풀 스캔: 날짜·유형·상태 필터와 컬럼 지정, UP TO n ROWS를 기본으로. 루프 내 SELECT 대신 FOR ALL ENTRIES보다 조인을 우선 검토
• 실수 2 — 주문/확정 혼동: 두 문서는 번호 체계가 다름. 확정 측 참조 필드로 연결
• 실수 3 — 상태 필드 혼동: 라이프사이클 상태와 후속 처리 상태는 별개. 요구사항이 "회계 반영 완료"라면 라이프사이클 상태만으로 판단 금지

Q1. 조회 결과가 항상 비어 있습니다. 데이터는 분명히 있는데요?
DCL 접근 제어에 걸렸을 가능성이 큽니다. ADT Data Preview에서 같은 사용자로 조회해 보고, 권한 트레이스(STAUTHTRACE)로 확인하세요.

Q2. 서비스 주문 번호로 ServiceConfirmation 필드를 조회하면 왜 안 되나요?
ServiceConfirmation은 확정 문서 자체의 번호입니다. 주문 번호는 참조 필드에 들어 있으므로 참조 필드로 조건을 걸어야 합니다.

Q3. 상태가 완료('C')인데 청구/회계 문서가 없습니다.
정상일 수 있습니다. 완료는 문서 처리 단계의 상태이고, 후속 전기는 별도 프로세스입니다. 후속 문서 흐름은 관련 흐름 뷰나 청구 문서 뷰에서 확인하세요.

Q4. 커스텀 뷰가 표준보다 느립니다.
CASE·계산 필드에 필터를 거는 경우 푸시다운이 깨질 수 있습니다. 필터는 가급적 원본 필드에 직접 적용하고 PlanViz로 실행 계획을 확인하세요.

🚀 이어서 살펴볼 주제

• I_ServiceConfirmationItem — 실적 시간·자재 등 아이템 레벨 상세 분석
• I_ServiceOrder / I_ServiceOrderItem — 계획 데이터와 실적 데이터 비교 리포트
• Service Confirmation OData API — 외부 시스템(모바일 정비 앱)에서의 확정 생성 자동화
• RAP 기반 커스텀 확정 요약 앱 — 이 글의 커스텀 뷰를 UI까지 확장
• CDS 접근 제어(DCL) 심화 — 조직 단위별 확정 데이터 권한 분리

📚 참고 링크

• SAP Help Portal — SAP S/4HANA Cloud (Service Confirmation 프로세스 문서)
• SAP Help Portal — ABAP Platform: ABAP CDS 개발 가이드
• SAP Help Portal — SAP S/4HANA 온프레미스 (VDM CDS 뷰 목록)
• SAP Business Accelerator Hub — Service Confirmation API 및 CDS 뷰 검색
• SAP Community — S/4HANA Service / CDS 관련 실무 사례
• SAP Community — ABAP Development 토픽 페이지