SAP 주식기준보상비용 귀속 점검 — 부서 정책표와 장부 귀속을 견주는 IFRS 18 점검 화면

개발 배경 — 이 앱을 사용해야 하는 이유

주식기준보상은 부여 한 번이 여러 해에 걸쳐 비용이 되고, 그 비용은 직원이 일하는 부서에 따라 매출원가·판매비·관리비·연구개발비로 나뉘어 손익계산서에 오릅니다. 재무제표 표시와 공시 기준(IFRS 18, 국내 K-IFRS 제1118호)은 손익을 영업·투자·재무 같은 범주로 나누어 보이도록 하므로, 부서가 어느 기능과 어느 범주에 속하는지가 이전보다 더 눈에 띕니다. 시행 시점은 국제 기준 기준으로 2027년 1월 1일로 알려져 있으나 국내 적용 시점과 세부 요구사항은 확인 필요입니다.

그런데 현업이 매달 부딪히는 질문은 단순합니다. "이 부서의 보상비용이 정책표에 정한 항목에 들어가 있나?" 보상비용 전표는 총계정원장에, 부서의 기능과 범주는 회사가 정한 정책표에, 부여 건의 가득 기간과 유형은 부여 관리 자료에 흩어져 있습니다. 표준 화면으로 하나씩 열어 엑셀에 붙여 맞추는 방식은 건수가 늘수록 놓치는 자리가 생깁니다.

이 화면은 그 자리를 메웁니다. 부여·부서 건마다 장부가 기록한 항목과 범주를 부서 정책표의 항목·범주와 견주고, 연구개발 부서는 자본화액까지 정책 비율로 다시 구해 보며, 현금결제형은 부채 증감표로 서비스 제공분과 공정가치 변동분을 나눠 봅니다. 관련 기준은 IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)이며 문단 번호나 세부 해석은 이 글에서 단정하지 않고 "확인 필요"로 남깁니다.

같은 비용이 두 곳에 다르게 놓이면 표시 금액이 달라진다

영업범주 안에서도 같은 보상비용이 매출원가에 있느냐 관리비에 있느냐에 따라 기능별 표시 금액이 달라집니다. 정책표가 "이 부서는 연구개발비"라고 정했는데 장부에 판매비로 남아 있으면 합계는 같아도 기능별 표는 달라집니다. 화면은 부여·부서 건마다 장부 항목과 정책 항목을 나란히 놓고 다르면 G01(기능 불일치)로 가립니다.

범주를 벗어난 비용은 합계에서 숨어 버린다

정책표가 투자·재무·중단영업 범주로 정한 부서의 비용이 장부에서는 영업범주 항목에 남아 있을 수 있습니다. 이런 건은 영업범주 금액을 부풀립니다. 화면 위쪽 요약의 "영업범주 밖 정책 귀속"이 그 금액이며, 가상 데이터에서는 2,584.9백만원입니다. 어느 부서의 비용을 어느 범주에 둘지는 회사와 감사인이 판단하고, 화면은 정책표와 장부가 같은지만 견줍니다(G02, 점검 필요).

자본화액은 비율 하나가 어긋나도 눈에 띄지 않는다

개발 활동에 쓰인 직원의 보상은 정책 비율만큼 자산 원가에 넣을 수 있습니다. 비율이 달라져도 비용 합계가 같으면 표준 리포트로는 알아채기 어렵습니다. 화면은 연구개발 부서 비용에 정책 비율을 곱해 정책 자본화액을 구하고 장부 자본화액과 견주어 차이를 보입니다(G03). 비율과 자본화 요건은 회사가 정하며, 화면은 요건 충족 여부를 판단하지 않습니다.

현금결제형은 숫자가 움직이므로 따로 봐야 한다

현금결제형은 주가가 움직이면 부채가 다시 측정되고, 그 변동분도 보상비용에 들어갑니다. 서비스 제공분은 기능별 정책에 따르는데 공정가치 변동분만 다른 범주에 기록하는 일이 생길 수 있습니다(R01). 또 당기 결제액이 기초 부채와 당기 서비스 제공분의 합보다 크면 결제 내역을 다시 봐야 합니다(R02). 화면은 부채 증감표 한 줄을 부여마다 보여 줍니다.

사용 방법

1. 회계연도와 기간(월)을 입력합니다. 이 둘은 필수이고, 회사·부여 유형·정책 귀속 항목·부여일 기간·점검 코드·점검 결과는 필요할 때만 고릅니다. 비워 두거나 "전체"이면 그 조건은 걸리지 않습니다.
2. 조회 버튼은 조회조건 영역의 입력 칸 맨 오른쪽에 있습니다. 입력 칸에서 Enter 키를 눌러도 같은 조회가 실행되고, 처음 열면 자동으로 한 번 조회합니다.
3. 위쪽 요약 여덟 칸을 먼저 봅니다 — 점검한 부여·부서 건, 비용 인식액, 정책과 다른 귀속 건, 영향 금액, 영업범주 밖 정책 귀속, 자본화 차이, 확인 필요 건, 정합성 대사 차이.
4. 탭은 부여·부서 판정 → 기능·범주 집계 → 현금결제형 부채 → 대사 결과 순서로 옮겨 가며 봅니다.
5. 부여·부서 판정에서 행을 누르면 장부 귀속과 정책 귀속의 비교, 자본화 내역, 판정 근거와 같은 부여의 다른 부서 행이 상세 창으로 열립니다.
6. CSV 내려받기를 누르면 지금 보는 탭의 조회 결과가 UTF-8 CSV 로 내려옵니다.

숫자를 믿을 수 있는가 — 검증 결과

대사식 여섯 가지를 전수로 돌린 결과입니다. 대사는 화면 안의 집계가 서로 맞는지 보는 것이고, 정책표 자체의 옳고 그름은 판단하지 않습니다.

아래 두 줄은 의도적으로 넣은 예외입니다. 대사 차이가 아니라 "점검 대상 건수"이며 대사 차이와 섞지 않습니다.

무엇으로 만들었나

앱 정보는 아래와 같습니다.

실행 화면

실제로 돌아가는 화면 7종을 사용 순서대로 보여 드립니다. 모든 숫자는 가상 회사 두 곳의 예시 데이터입니다.

처음 열었을 때

처음 열면 조회조건, 요약, 판정 표가 한 화면에 나옵니다.

처음 열면 2026년 10월 전체가 자동 조회되어 114건이 나옵니다. 위쪽 요약에서 비용 인식액 10,871.8백만원, 정책과 다른 귀속 18건, 영향 금액 1,329.4백만원, 확인 필요 1건, 정합성 대사 차이 0을 먼저 읽습니다. 조회 버튼은 입력 칸 오른쪽 끝에 있고 Enter 키로도 조회됩니다. 금액 단위는 요약은 백만원, 표는 원입니다.

정책과 다른 건을 가려내기

점검 결과와 코드를 좁혀 다시 볼 건만 남깁니다.

조회조건에서 점검 결과를 바꾸고 조회를 누르면 같은 표가 18건으로 줄어듭니다. 점검 코드까지 함께 고르면 G02(범주 불일치) 12건, G03(자본화액 차이) 4건, G01(기능 불일치) 2건으로 더 좁힐 수 있습니다. "전체"로 되돌리면 그 조건은 요청에서 빠집니다.

기능·범주와 현금결제형 부채

부여 단위가 아니라 항목 단위, 부채 단위로 올려 봅니다.

매출원가·판매비·관리비·연구개발비와 투자·재무·중단영업 범주, 정책 미설정 항목이 회사별로 16줄로 모입니다. 장부 금액 − 정책 금액이 차이 열이며 0이 아니면 F01(귀속 금액 차이), 정책표에 없는 부서의 비용이 남으면 F02(확인 필요)입니다. 주식결제형·현금결제형 금액도 열로 나뉩니다.

현금결제형 부여 9건의 부채 증감표입니다. 계산한 기말과 장부 기말이 같은지 차이 열로 보고, 변동분을 정책과 다른 범주에 기록한 건(R01)과 결제액이 기초·서비스 합보다 큰 건(R02)을 점검 필요로 표시합니다. 부여 이름을 누르는 대신 부여·부서 판정 탭에서 같은 부여의 부서 행을 볼 수 있습니다.

대사와 상세

숫자가 맞는지, 한 건이 왜 그렇게 판정됐는지 봅니다.

대사 6종은 모두 차이 0건입니다. 아래 두 줄은 대사 차이가 아니라 "점검 대상 건수"입니다 — 정책과 다른 귀속 18건(최대 158,260,000원)과 정책 미설정 부서 1건(57,400,000원). 의도적으로 넣은 예외라서 대사 차이와 섞지 않고 구분 열로 갈라 놓았습니다.

부여 이름·유형·가득 기간, 부서와 인원, 장부 계정과 항목·범주, 정책표의 항목·범주, 자본화액(장부·정책·차이), 비용 흐름(부여 비용 − 자본화액 = 비용 인식액)이 위에서 아래로 놓입니다. 아래에는 판정 코드가 말하는 규칙 문장이 있고, 같은 부여의 다른 부서 행이 표로 따라옵니다. 닫기 버튼으로 닫습니다.

조회조건 조합

회사·유형·기간을 겹쳐 좁힙니다.

회사 2000, 현금결제형, 부여일 시작 2025-01-01을 걸고 Enter 로 조회한 화면입니다. 부여일 기간은 서비스가 날짜 비교를 직접 처리하는 BT 필터로 갑니다. 조건에 맞는 건이 없으면 0건 안내가 뜨고 요약은 0으로 돌아갑니다.

화면 뒤에서 일어나는 일

판정 규칙 — 조건 → 결과 상태 → 사용자 조치

우선순위는 표의 위에서 아래입니다. "점검 필요"는 다시 볼 대상을 가리는 표시이며 잘못되었다는 뜻이 아닙니다.

처리 단계와 대사식

1. 부서 정책표 대응 — 부여·부서 건마다 부서의 기능(매출원가·판매비·관리비·연구개발비)과 손익 범주(영업·투자·재무·중단영업)를 정책표에서 찾습니다. 없으면 판정하지 않고 확인 필요로 남깁니다.
2. 비용 인식액 = 부여 비용 − 자본화액.
3. 정책 자본화액 — 연구개발 부서는 비용 × 정책 자본화 비율, 그 밖의 부서는 0 으로 봅니다. 비율과 요건은 회사가 정합니다.
4. 귀속 비교 — 장부 항목·범주가 정책표와 다르면 G01·G02, 자본화액이 다르면 G03 으로 표시합니다.
5. 기능·범주 집계 — 항목별로 장부 귀속액과 정책 귀속액을 합산하고 차이를 구합니다. 주식결제형·현금결제형 금액도 나눕니다.
6. 현금결제형 부채 — 기초 + 서비스 제공분 + 공정가치 변동분 − 결제액이 기말 부채와 같은지 보고, 결제액 초과(R02)와 변동분 범주(R01)를 점검합니다.
7. 정합성 대사 — 여섯 가지 대사식을 전수로 돌리고, 의도적 예외(정책과 다른 귀속, 정책 미설정)는 대사 차이가 아니라 점검 대상으로 따로 기록합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

창 폭이 760px 이하로 좁아지면 조회조건이 여러 줄로 접히고 요약은 두 줄로 나뉘며, 표는 가로로 스크롤됩니다. 탭 구성과 판정은 그대로입니다. 표 열 머리와 행 클릭 동작도 같습니다.

파일 구성

앱 폴더/
├─ index.html            앱 진입점
├─ readme.html           설명서
├─ Component.js · manifest.json
├─ controller/           BaseController · Main.controller
├─ view/                 Main.view.xml · DetailDialog.fragment.xml
├─ model/                formatter · ErrorHandler
├─ css/ · i18n/
├─ odata/                metadata · service.js · 엔티티셋별 JSON
└─ media/                소개 영상 · 포스터

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다.

표준으로 되는 것과 안 되는 것

T-code 별 연계 지점

맞닿은 표준 T-code 마다 이 앱이 이어받는 데이터와 두 화면 숫자를 맞춰 보는 지점입니다. 이 앱의 결과에서 원천을 확인할 때는 아래 표준 T-code 로 오가고, 표준 화면의 값은 이 앱의 부여·부서 판정과 기능·범주 집계에서 다시 봅니다. 법정·감사 대응은 표준에 남겨 두므로 기존 리포트를 없앨 필요가 없습니다.

S/4HANA 분석 스택과의 자리

표준 CDS 분석 쿼리나 Fiori 분석 앱은 계정 잔액과 손익 구조를 보는 데 강합니다. 이 화면은 그 위에 "부서 정책표와 장부가 같은가"라는 하나의 질문을 얹은 점검용 화면입니다. 분석 쿼리의 결과와 이 앱 집계가 같은 원천에서 나오도록 CDS 구성을 맞추면 두 화면의 숫자를 대조할 수 있습니다.

Analysis for Office 같은 도구로 같은 데이터를 피벗으로 열어 볼 수도 있습니다. 판정(G·F·R 코드)과 정책표 대응은 이 앱의 서비스가 맡고, 피벗 도구에서는 집계 값 위주로 확인하는 구분을 권합니다.

요구사항 매핑표

관련 기준은 IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)이며 문단 번호는 확인되지 않아 적지 않았습니다. 확인하지 못한 항목은 "확인 필요"입니다.

확장 포인트 — 운영에서 실제로 손대는 자리

CDS 구성

이 사례의 판정은 서비스 뷰 한 곳에서 결정됩니다. 아래 코드는 구조를 보여 주는 스케치이며, 표준 필드명(원장·코스트센터·확장 필드)과 정책표 구조는 활성화 전에 확인해야 합니다. 확인하지 못한 항목은 주석에 "확인 필요"로 남겼습니다.

뷰 레이어 구성

① 부서 정책표 — 기준 데이터

정책표는 이 앱의 모든 판정이 기대는 기준입니다. 부서마다 기능, 범주, 자본화 비율을 유효기간과 함께 둡니다. 비율이나 범주가 바뀌면 행을 더하기만 하면 되고, 지난 기간 조회는 그 시점에 유효했던 행으로 이뤄집니다. 이 표가 비어 있거나 부서가 빠지면 G04(확인 필요)가 늘어납니다.

" ─────────────────────────────────────────────────────────────
" 이름   : ZSBP_DEPTPOL  (부서 정책표)
" 역할   : 부서 → 기능·범주·자본화 비율. 판정의 기준값.
" 이유   : 정책은 회사가 정하고 바뀌는 값이라 코드에 박지 않고 데이터로 둔다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '주식기준보상 부서 정책표'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zsbp_deptpol {
  key client      : abap.clnt not null;
  key bukrs       : bukrs not null;
  key kostl       : kostl not null;            " 코스트센터 = 부서 (확인 필요)
  key valid_from  : datum not null;
  valid_to        : datum;
  func_item       : abap.char(4);              " COGS/SELL/ADMN/RND
  pl_category     : abap.char(4);              " OPER/INVT/FIN/DISC
  cap_rate        : abap.dec(5,2);             " 자본화 비율(%) — 회사가 정함
  changed_by      : syuname;
  changed_at      : timestampl;
}

② 계정 매핑 — 어느 손익 항목으로 가는가

보상비용 계정이 어느 손익 항목에 매핑되는지를 두는 표입니다. 장부 귀속(장부 항목)은 이 매핑에서 나옵니다. 계정 마스터는 FS00 에서 확인하고, 새 계정이 생기면 이 표에 행을 더합니다. 매핑이 없는 계정은 큐브에서 미분류로 떨어져 대사 차이로 드러나게 합니다.

" ─────────────────────────────────────────────────────────────
" 이름   : ZSBP_ACCTMAP  (계정 → 손익 항목 매핑)
" 역할   : 보상비용 계정이 장부상 어느 기능·범주 항목에 놓이는지.
" 이유   : 계정이 늘어도 뷰를 고치지 않고 행만 더하도록 데이터로 분리.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '보상비용 계정 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zsbp_acctmap {
  key client      : abap.clnt not null;
  key ktopl       : ktopl not null;
  key saknr       : saknr not null;
  book_item       : abap.char(4);              " 장부 기능 항목
  book_category   : abap.char(4);              " 장부 손익 범주
  cap_flag        : abap.char(1);              " 자본화 계정 여부
}

③ 정책 차원 — 유효기간까지 읽는 뷰

정책표를 읽어 기준일에 유효한 행만 돌려주는 차원 뷰입니다. 기준일 파라미터를 받아 지난 기간 조회도 같은 뷰로 처리합니다. 큐브는 이 뷰를 association 으로 붙여 정책 항목과 정책 범주를 읽습니다.

" ─────────────────────────────────────────────────────────────
" 이름   : ZI_SbpDeptPolicy
" 역할   : 기준일에 유효한 부서 정책 행을 돌려주는 차원.
" 이유   : 정책 이력을 두어 지난 기간도 그 시점 기준으로 다시 본다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '주식기준보상 부서 정책'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #S, dataClass: #CUSTOMIZING }
@Analytics.dataCategory: #DIMENSION
define view entity ZI_SbpDeptPolicy
  with parameters
    p_keydate : abap.dats
  as select from zsbp_deptpol as pol
{
  key pol.bukrs       as CompanyCode,
  key pol.kostl       as CostCenter,
      pol.func_item   as PolicyItem,
      pol.pl_category as PolicyCategory,
      pol.cap_rate    as PolicyCapRate
}
where pol.valid_from <= $parameters.p_keydate
  and ( pol.valid_to is initial or pol.valid_to >= $parameters.p_keydate )

④ 부여·부서 큐브 — 판정 값을 만드는 곳

이 뷰에서 판정이 결정됩니다. 전표 라인(보상비용·자본화)을 부여 번호·부서로 모으고 계정 매핑으로 장부 항목을 붙인 뒤 정책 차원과 견주어 G 코드를 만듭니다. 화면·CSV·대사가 모두 이 뷰의 값을 쓰므로 운영에서 숫자가 갈라질 자리가 없습니다. 부여 번호를 전표 라인에 싣는 방법(확장 필드)은 확인 필요입니다.

" ─────────────────────────────────────────────────────────────
" 이름   : ZI_SbpGrantCube
" 역할   : 부여·부서 건 단위 집계 + 정책 대조 + 판정 코드.
" 이유   : 판정 로직을 한 곳에 모아 화면·CSV·대사가 같은 숫자를 쓰게 한다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '주식기준보상 부여·부서 큐브'
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XL, dataClass: #MIXED }
@Analytics.dataCategory: #CUBE
define view entity ZI_SbpGrantCube
  with parameters
    p_gjahr : gjahr,
    p_monat : monat
  as select from acdoca as j                                   // 전표 라인(원장 확인 필요)
    inner join   zsbp_acctmap as m on m.saknr = j.racct
    association [0..1] to ZI_SbpDeptPolicy as _Pol
      on  _Pol.CompanyCode = $projection.CompanyCode
      and _Pol.CostCenter  = $projection.CostCenter
{
  key j.rbukrs                                  as CompanyCode,
  key j.zz_grantno                              as GrantNo,        // 확장 필드 — 확인 필요
  key j.rcntr                                   as CostCenter,
      m.book_item                               as BookItem,
      m.book_category                           as BookCategory,
      @Semantics.amount.currencyCode: 'Currency'
      sum( case when m.cap_flag = ' ' then j.hsl else 0 end ) as ExpenseAmount,
      @Semantics.amount.currencyCode: 'Currency'
      sum( case when m.cap_flag = 'X' then j.hsl else 0 end ) as CapitalizedAmount,
      j.rhcur                                   as Currency,
      _Pol( p_keydate : $session.system_date ).PolicyItem      as PolicyItem,
      _Pol( p_keydate : $session.system_date ).PolicyCategory  as PolicyCategory,
      _Pol( p_keydate : $session.system_date ).PolicyCapRate   as PolicyCapRate,
      case
        when _Pol( p_keydate : $session.system_date ).PolicyItem is null                         then 'G04'
        when _Pol( p_keydate : $session.system_date ).PolicyCategory <> 'OPER'
         and m.book_category     =  'OPER'                   then 'G02'
        when _Pol( p_keydate : $session.system_date ).PolicyItem <> m.book_item                  then 'G01'
        else 'G00'
      end                                       as CheckCode
}
where j.gjahr = $parameters.p_gjahr
  and j.poper = $parameters.p_monat
group by j.rbukrs, j.zz_grantno, j.rcntr, m.book_item, m.book_category, j.rhcur

⑤ 현금결제형 부채 증감 — 부여 단위 뷰

현금결제형 부채는 건 단위가 아니라 부여 단위로 증감표를 봅니다. 기초 부채에 서비스 제공분과 공정가치 변동분을 더하고 결제액을 빼 기말을 계산하며, 장부 기말과 같은지 차이를 구합니다. 증감 자료의 원천(부채 계정 이력 또는 별도 부여 관리 자료)은 확인 필요입니다.

" ─────────────────────────────────────────────────────────────
" 이름   : ZI_SbpLiabRollfwd
" 역할   : 현금결제형 부여마다 기초 + 서비스 + 변동 − 결제 = 기말 대사.
" 이유   : 부채 증감은 부여 단위라 부여·부서 큐브와 분리한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '현금결제형 부채 증감'
@Analytics.dataCategory: #CUBE
define view entity ZI_SbpLiabRollfwd
  as select from zsbp_liab as l                              // 증감 자료 — 원천 확인 필요
{
  key l.bukrs                                   as CompanyCode,
  key l.grant_no                                as GrantNo,
      l.open_liab                               as OpenLiability,
      l.svc_amt                                 as ServiceAmount,
      l.fv_chg_amt                              as FairValueChange,
      l.paid_amt                                as PaidAmount,
      l.close_liab                              as CloseLiability,
      cast( l.open_liab + l.svc_amt + l.fv_chg_amt - l.paid_amt as abap.dec(20,0) )
                                                as CalcClose,
      cast( l.close_liab - ( l.open_liab + l.svc_amt + l.fv_chg_amt - l.paid_amt )
            as abap.dec(20,0) )                 as CloseDiff,
      case
        when l.paid_amt > l.open_liab + l.svc_amt then 'R02'
        when l.fv_chg_cat <> l.svc_cat            then 'R01'
        else 'R00'
      end                                       as CheckCode
}

⑥ Consumption 뷰 — 화면이 읽는 모양

화면에 나오는 컬럼, 기본 조회조건, 정렬을 선언한 쿼리 뷰입니다. 조회조건을 서비스에 선언해 두면 화면이 달라져도 의미가 같고, OData 의 $filter 가 그대로 이 선언을 따릅니다. 판정 결과(점검 결과)는 코드에서 상태로 바꿔 보입니다.

" ─────────────────────────────────────────────────────────────
" 이름   : ZC_SbpGrantCheck
" 역할   : 화면 컬럼·조회조건·정렬 선언(OData 엔티티셋의 원천).
" 이유   : 조회조건을 서비스에 고정해 화면이 바뀌어도 의미가 같게 한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '주식기준보상 귀속 점검'
@Metadata.allowExtensions: true
define view entity ZC_SbpGrantCheck
  with parameters
    p_gjahr : gjahr,
    p_monat : monat
  as select from ZI_SbpGrantCube( p_gjahr : $parameters.p_gjahr,
                                  p_monat : $parameters.p_monat )
{
      @UI.lineItem: [{ position: 10 }]
  key CompanyCode,
      @UI.lineItem: [{ position: 20 }]
  key GrantNo,
      @UI.lineItem: [{ position: 30 }]
  key CostCenter,
      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true }
      CheckCode,
      @UI.lineItem: [{ position: 50 }]
      ExpenseAmount,
      @UI.lineItem: [{ position: 60 }]
      CapitalizedAmount,
      ExpenseAmount - CapitalizedAmount            as NetExpense,
      case when CheckCode = 'G00' then 'OK'
           when CheckCode = 'G04' then 'CONF'
           else 'CHECK' end                        as CheckStatus,
      BookItem, PolicyItem, BookCategory, PolicyCategory
}

⑦ DCL 과 서비스 — 권한과 노출

집계 단계에 회사코드·코스트센터 권한을 겁니다. 드릴 행에만 권한을 걸면 합계가 다른 부서 금액을 포함해 새어 나갑니다. 서비스는 정의와 바인딩을 나눠 OData V2 로 게시하며, 활성화 방법은 환경에 따라 /IWFND/MAINT_SERVICE 또는 Binding 게시입니다.

" ─────────────────────────────────────────────────────────────
" 이름   : ZSBP_GRANT_DCL + ZUI_SbpCheck
" 역할   : 집계 단계 권한 + OData 노출.
" 이유   : 합계로 다른 부서 숫자가 새지 않게 집계 뷰에서 권한을 건다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '보상비용 귀속 점검 권한'
@MappingRole: true
define role ZSBP_GRANT_DCL {
  grant select on ZI_SbpGrantCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
      and ( CostCenter )  = aspect pfcg_auth( K_CCA, KOSTL, ACTVT = '03' );   " 확인 필요
}

@EndUserText.label: '보상비용 귀속 점검 서비스'
define service ZUI_SbpCheck {
  expose ZC_SbpGrantCheck as GrantSet;
  expose ZI_SbpLiabRollfwd as RemeasSet;
}
" 바인딩: OData V2 - UI  (프로젝트 환경에 맞게 Service Binding 에서 게시)

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

운영 데이터로 갈 때

운영 전표가 수천만 건이면 집계는 CDS 쪽에서 끝내고 화면에는 부여·부서 건 단위만 보냅니다. 회계연도와 기간을 필수 파라미터로 두어 전체 스캔을 막고, 전표 라인의 부여 번호·코스트센터·계정에 인덱스가 있는지 확인합니다.

응답 시간 기준(예: 첫 조회 몇 초 이내)은 운영 규모에서 정하고, 큐브를 실시간 뷰로 둘지 야간 적재 테이블로 둘지는 그 기준과 정책표 변경 빈도로 결정합니다. 대용량에서는 페이지 단위로 받는 $top·$skip 요청이 화면의 기본 동작입니다.

자주 묻는 질문

도입 상담과 검토 자리에서 자주 나오는 질문 24개를 주제별로 묶었습니다.

숫자와 산식

화면과 조작

분석 관점

도입과 운영