CRHD vs I_WorkCenter — 작업 센터 조회 차이 #shorts #SAP #ABAP

I_WorkCenter란 무엇인가

I_WorkCenter는 SAP S/4HANA에서 작업 센터(Work Center) 마스터 데이터를 표준화된 형태로 노출하는 ABAP CDS 기본 뷰(Basic Interface View)입니다. 전통적으로 작업 센터는 CRHD(Work Center Header), CRCA(Work Center Capacity Allocation), CRCO(Work Center Cost Center Assignment), CRTX(Work Center Text) 등 여러 클러스터 테이블에 분산 저장되어 있었고, 이를 조회하려면 각 테이블을 JOIN하고 시간 의존(Time-Dependent) 데이터를 직접 필터링하는 복잡한 로직이 필요했습니다. I_WorkCenter는 이러한 작업을 추상화하여, 가상 데이터 모델(VDM) 계층에서 단일 엔티티로 제공합니다.

이 글에서 다루는 내용을 체크리스트 형태로 정리하면 다음과 같습니다.

• I_WorkCenter가 CRHD 등 어떤 기반 테이블 위에 구축되는지 이해
• 작업 센터 ID(WorkCenter), 내부 객체 ID(WorkCenterInternalID) 구분
• 능력(Capacity) 정보 및 라우팅(Routing) 연계 뷰 활용
• ABAP RAP/CDS에서 SELECT, 조인, 화폐 단위 처리 패턴 습득
• 실무 시나리오에서 흔히 발생하는 시간 의존 오류 회피

읽기 전에 갖춰두면 좋은 지식

이 글은 ABAP 개발자가 CDS 뷰 정의(@AbapCatalog.sqlViewName, define view) 문법을 한 번 이상 다뤄봤다는 전제에서 출발합니다. 또한 SAP PP(Production Planning) 모듈의 작업 센터, 라우팅, 능력 개념에 대한 기본 이해가 있으면 좋습니다. CRHD/CRCA 같은 테이블 이름이 낯설어도 따라올 수 있지만, OpenSQL/ABAP SQL의 SELECT ... INTO TABLE 구문은 필수 전제입니다.

실습 환경 및 시스템 전제

이 글의 예제는 SAP S/4HANA 2022 FPS02 또는 이후 릴리스(2023 포함), 그리고 ABAP Development Tools(ADT) 3.40 이상을 기준으로 작성되었습니다. I_WorkCenter는 SAP S/4HANA 1610부터 제공되었으나, 필드 구성과 어소시에이션은 릴리스마다 일부 차이가 있을 수 있으므로 운영 시스템에서 SE11 또는 ADT의 Where-Used로 정확한 시그니처를 먼저 확인하길 권장합니다.

• 시스템: SAP S/4HANA 2022 FPS02 (On-Premise 또는 Private Cloud)
• 개발 도구: Eclipse + ABAP Development Tools 3.40+
• 권한: S_DEVELOP(개발), CDS 뷰 표시 권한 S_RS_AUTH 또는 기본 표시 권한
• 샘플 데이터: 트랜잭션 CR03에서 플랜트 1010의 작업 센터 몇 건을 확인
• 모듈 의존성: 생산 계획(PP), 공장 데이터 관리(PP-BD) 컴포넌트 활성화

운영 시스템에서 처음 I_WorkCenter를 사용한다면, 먼저 ADT에서 뷰를 더블 클릭하여 어소시에이션 목록과 어노테이션(@ObjectModel.usageType.dataClass 등)을 확인하세요. 릴리스 차이로 인해 일부 어소시에이션 이름(예: _Capacity)이 다를 수 있습니다.

CDS 가상 데이터 모델과 작업 센터 도메인 이해

SAP의 가상 데이터 모델(VDM)은 데이터를 세 계층으로 나눕니다. Basic View(I_*)는 정규화된 데이터 소스를 노출하고, Composite View는 비즈니스 관점의 조합을 제공하며, Consumption View(C_*)는 Fiori 앱이 직접 사용합니다. I_WorkCenter는 이 중 Basic 계층에 위치하며, 작업 센터의 "헤더 정보" 역할을 합니다.

비유하자면 I_WorkCenter는 공장의 각 설비/작업장에 대한 "주민등록증"입니다. 주민등록증에는 이름·주소·등록일 같은 핵심 정보가 있고, 별도의 등본·초본에 가족·소득·자산이 따로 기록되어 있는 것처럼, 능력(Capacity) 정보는 I_WorkCenterCapacity, 비용 센터 연계는 I_WorkCenterCostCenterAssignment로 분리되어 있습니다. I_WorkCenter는 이들을 어소시에이션(_Capacity, _CostCenter 등)으로 연결합니다.

도식으로 표현하면 다음과 같은 구조입니다.

CRHD (Work Center Header, 시간 의존)
  └── I_WorkCenter (Basic View)
        ├── _Plant            → I_Plant
        ├── _WorkCenterType   → I_WorkCenterType
        ├── _Capacity         → I_WorkCenterCapacity (CRCA 기반)
        ├── _CostCenter       → I_WorkCenterCostCenterAssgmt (CRCO 기반)
        └── _Text             → I_WorkCenterText (CRTX 기반)

여기서 핵심은 CRHD가 시간 의존 테이블(필드 DATBI, DATAB 보유)이라는 점입니다. I_WorkCenter는 내부적으로 $session.system_date 또는 키 날짜를 기준으로 유효 레코드를 필터링하므로, 개발자가 WHERE DATBI >= sy-datum 같은 코드를 직접 작성할 필요가 없습니다. 또한 WorkCenter(외부 코드, 예: ASSY-01)와 WorkCenterInternalID(8자리 숫자 키 OBJID)를 모두 노출하여 외부 조회와 내부 조인 모두를 지원합니다.

I_WorkCenter 주요 필드와 의미

실무에서 자주 다루는 필드를 정리하면 다음과 같습니다.

필드	원천	설명
WorkCenter	CRHD-ARBPL	작업 센터 외부 코드(8자)
WorkCenterInternalID	CRHD-OBJID	내부 객체 ID, 다른 뷰 조인 키
Plant	CRHD-WERKS	플랜트 코드
WorkCenterCategoryCode	CRHD-VERWE	용도 코드(라우팅/네트워크 등)
WorkCenterTypeCode	CRHD-WKCT	작업 센터 유형
WorkCenterIsDeleted	CRHD-LVORM	삭제 플래그
WorkCenterResponsiblePerson	CRHD-VGWTS	책임자 키
ValidityStartDate	CRHD-DATAB	유효 시작일
ValidityEndDate	CRHD-DATBI	유효 종료일

실전 예제 1단계: 기본 조회로 감 잡기

가장 단순한 시나리오부터 살펴봅니다. 플랜트 1010의 활성 작업 센터 목록을 조회하는 ABAP 코드입니다. 사내 MES 연계 화면에서 작업 센터 드롭다운을 채우는 용도라고 가정합니다.

REPORT zr_wc_list_basic.

DATA: lt_workcenter TYPE STANDARD TABLE OF i_workcenter,
      ls_workcenter TYPE i_workcenter.

SELECT workcenter,
       workcenterinternalid,
       plant,
       workcentercategorycode,
       workcentertypecode,
       validitystartdate,
       validityenddate
  FROM i_workcenter
  WHERE plant = '1010'
    AND workcenterisdeleted = ''
  INTO TABLE @lt_workcenter
  UP TO 200 ROWS.

LOOP AT lt_workcenter INTO ls_workcenter.
  WRITE: / ls_workcenter-workcenter,
           ls_workcenter-workcentercategorycode,
           ls_workcenter-validityenddate.
ENDLOOP.

여기서 주목할 점은 workcenterisdeleted = '' 조건입니다. CRHD의 LVORM은 논리 삭제 플래그라서, 명시적으로 걸러주지 않으면 폐기된 설비가 결과에 섞입니다. 또한 UP TO 200 ROWS로 안전장치를 둔 것은 운영 플랜트에서 작업 센터가 수천 건에 이를 수 있기 때문입니다.

실전 예제 2단계: 능력 정보와 텍스트를 함께 조회

실제 생산 계획 화면에서는 "작업 센터 코드 + 한글 설명 + 일일 가용 시간"이 한 줄에 보여야 합니다. I_WorkCenter의 어소시에이션을 활용하면 다중 JOIN을 우아하게 처리할 수 있습니다. 아래 예제는 자체 작성한 Consumption View입니다.

@AbapCatalog.sqlViewName: 'ZVWCCAPRPT'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Work Center Capacity Report'

define view ZC_WorkCenter_CapacityReport
  as select from I_WorkCenter as wc

  association [0..1] to I_WorkCenterText as _Text
    on  _Text.WorkCenterInternalID = wc.WorkCenterInternalID
    and _Text.Language             = $session.system_language

  association [0..*] to I_WorkCenterCapacity as _Capacity
    on _Capacity.WorkCenterInternalID = wc.WorkCenterInternalID

{
  key wc.WorkCenter                              as WorkCenterCode,
      wc.Plant                                   as PlantCode,
      wc.WorkCenterCategoryCode                  as CategoryCode,
      _Text.WorkCenterDesc                       as Description,
      _Capacity.CapacityInternalID               as CapacityId,
      _Capacity.CapacityCategoryCode             as CapacityCategory,
      cast( _Capacity.OperatingTimeDailyInSeconds as abap.dec(10,2) )
                                                 as DailySeconds,
      wc.ValidityStartDate,
      wc.ValidityEndDate,

      _Text,
      _Capacity
}
where wc.WorkCenterIsDeleted = ''

위 뷰에서 두 가지 패턴을 익혀두면 좋습니다. 첫째, 텍스트 뷰는 항상 $session.system_language로 사용자 로그온 언어를 필터링합니다. 그렇지 않으면 모든 언어 라인이 카르테시안 곱으로 결합되어 결과가 부풀려집니다. 둘째, _Capacity는 1:N 어소시에이션이므로 SELECT 절에 노출하면 작업 센터별로 능력 라인 수만큼 행이 늘어납니다. 보고서 용도라면 의도된 동작이지만, 카드 형태 UI라면 LEFT OUTER로 명시적 JOIN하거나 별도 호출 패턴을 고려해야 합니다.

실전 예제 3단계: 라우팅 연계와 성능 최적화

실무에서는 "특정 자재의 라우팅에 사용되는 작업 센터들의 가용 시간 합계"를 구하는 시나리오가 빈번합니다. 라우팅은 I_RoutingOperation에서 시작하며, 이 뷰는 WorkCenterInternalID를 통해 I_WorkCenter와 연결됩니다. 다음은 자재 코드 입력 시 관련 작업 센터의 일일 가용 초를 집계하는 ABAP 로직입니다.

CLASS zcl_routing_capacity_calc DEFINITION
  PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    TYPES: BEGIN OF ty_result,
             workcenter    TYPE i_workcenter-workcenter,
             daily_seconds TYPE p LENGTH 10 DECIMALS 2,
           END OF ty_result,
           tt_result TYPE STANDARD TABLE OF ty_result WITH EMPTY KEY.

    METHODS calc_capacity
      IMPORTING iv_material TYPE matnr
                iv_plant    TYPE werks_d
      RETURNING VALUE(rt_result) TYPE tt_result
      RAISING   cx_sy_open_sql_db.
ENDCLASS.

CLASS zcl_routing_capacity_calc IMPLEMENTATION.
  METHOD calc_capacity.
    TRY.
        SELECT wc~workcenter,
               SUM( cap~operatingtimedailyinseconds ) AS daily_seconds
          FROM i_routingoperation AS op
          INNER JOIN i_workcenter AS wc
            ON  wc~workcenterinternalid = op~workcenterinternalid
            AND wc~plant                = @iv_plant
          INNER JOIN i_workcentercapacity AS cap
            ON cap~workcenterinternalid = wc~workcenterinternalid
          WHERE op~material            = @iv_material
            AND wc~workcenterisdeleted = ''
            AND cap~capacitycategorycode = '001'
          GROUP BY wc~workcenter
          INTO TABLE @rt_result.

      CATCH cx_sy_open_sql_db INTO DATA(lx_db).
        " 운영 환경에서는 Application Log(BAL_LOG_*)로 기록 권장
        MESSAGE lx_db->get_text( ) TYPE 'E'.
        RAISE EXCEPTION lx_db.
    ENDTRY.
  ENDMETHOD.
ENDCLASS.

이 코드에는 세 가지 프로덕션 고려사항이 녹아 있습니다. 첫째, capacitycategorycode = '001'로 능력 종류(보통 머신 능력)를 명시했습니다. 능력은 인력/머신/공구 등 여러 카테고리가 동시에 존재하므로 필터링하지 않으면 중복 합산됩니다. 둘째, 예외 처리에서 cx_sy_open_sql_db를 잡아 호출자에게 다시 던집니다. 운영에서는 단순 MESSAGE가 아니라 BAL(Application Log)이나 자체 모니터링 채널로 보내는 것이 일반적으로 권장됩니다. 셋째, 단위 테스트 관점에서 메서드 시그니처는 사이드 이펙트가 없고 결정적이므로 ABAP Unit + CDS Test Double Framework(cl_cds_test_environment)로 격리 테스트가 가능합니다.

자주 마주치는 함정과 해결법

I_WorkCenter는 추상화 수준이 높은 만큼, 처음 사용할 때 헷갈리는 지점이 몇 가지 있습니다.

Q1. WorkCenter 코드로 조회했는데 결과가 0건입니다.
가장 흔한 원인은 플랜트 누락입니다. WorkCenter(ARBPL)는 플랜트 내에서만 유일하므로 항상 Plant와 함께 키로 사용해야 합니다. 또한 시간 의존 필터가 자동 적용되므로, 폐기된 라인이나 미래 일자 라인은 기본 조회에서 제외됩니다. 과거 시점 데이터를 보려면 I_WorkCenter 대신 CRHD 직접 조회 또는 키 날짜 파라미터를 가진 변형 뷰를 고려해야 합니다.

Q2. _Capacity 어소시에이션에서 행이 중복됩니다.
한 작업 센터에는 여러 능력 카테고리(머신/인력/툴)가 매핑될 수 있고, 각 카테고리는 다시 능력 버전(Active/Planning)을 가질 수 있습니다. 보고서가 1행 1작업 센터를 기대한다면 capacitycategorycode로 필터하거나 표준 능력(StandardCapacityCategoryCode) 필드를 활용해 가장 대표적인 능력만 선택해야 합니다.

Q3. CDS 뷰 활성화 시 "Field WorkCenterDesc unknown" 오류가 납니다.
릴리스에 따라 텍스트 필드명이 WorkCenterDesc 또는 WorkCenterDescription으로 다를 수 있습니다. ADT에서 I_WorkCenterText를 열어 실제 필드를 확인 후 매핑하세요. 또한 @ObjectModel.text.element 어노테이션으로 텍스트 연결을 선언적으로 처리하는 패턴도 함께 고려할 만합니다.

Q4. 권한 오류(NOT_AUTHORIZED)가 발생합니다.
I_WorkCenter는 DCL(Data Control Language)을 통해 플랜트 단위 권한이 자동 적용됩니다. 사용자가 해당 플랜트의 C_WERK 권한 객체를 보유하지 않으면 결과에서 제외됩니다. 테스트 시 본인 사용자에 권한 부여 후 재시도하세요.

이후 확장하면 좋은 주제

I_WorkCenter를 익혔다면 다음 단계로 진도를 넓혀볼 만합니다.

• I_WorkCenterCapacity / I_WorkCenterCostCenterAssgmt: 능력 상세와 비용 센터 매핑 뷰. 원가 분석 보고서의 핵심 소스
• I_RoutingOperation / I_ProductionOrder: 라우팅과 생산 오더에서 작업 센터 부하 추적
• RAP(ABAP RESTful Application Programming): I_WorkCenter를 Behavior가 없는 Read-Only Service로 노출하여 Fiori Elements List Report 자동 생성
• CDS Annotation 기반 분석 모델: @Analytics.dataCategory: #DIMENSION을 활용한 SAC/Embedded Analytics 연계
• CDS Test Double Framework: cl_cds_test_environment로 단위 테스트 시 CRHD 의존성 제거

더 깊이 파고들 때 참고할 만한 자료

• SAP Help Portal — SAP S/4HANA Product Documentation (CDS Views for Production)
• SAP Help Portal — ABAP CDS Development Guide
• SAP Help Portal — Work Center (PP-BD-WKC) Functional Documentation
• SAP API Business Hub — Production Planning Work Center APIs
• SAP Community Blogs — Tag: CDS Views (실무 패턴 사례)
• SAP Community — ABAP Development 토론(현장 Q&A 검색에 유용)