투자부동산 손익 범주 점검 — IFRS 18 에서 임대·시세차익 손익이 영업·투자·중단영업 범주 중 맞는 곳에 놓였는지 용도로 다시 구해 장부와 맞춰 보는 화면

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

IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 손익계산서의 수익과 비용을 영업·투자·재무·법인세·중단영업 범주로 나누어 보이도록 요구합니다. 임대수익, 공정가치 평가손익, 감가상각비, 운영비, 처분손익이 한꺼번에 쌓이는 투자부동산은 이 분류에서 가장 먼저 질문이 나오는 자리입니다. 같은 건물이라도 임대 목적인지 시세차익 목적인지, 본사로 쓰는지 판매하려고 들고 있는지, 회사의 주된 사업활동이 부동산 투자인지에 따라 놓여야 할 범주가 달라질 수 있기 때문입니다.

지금은 이 질문에 답하려면 계정별 개별 항목 조회와 자산 마스터 조회, 부동산 목록 엑셀을 번갈아 열어 건마다 손으로 맞춰 봅니다. 이 앱은 그 세 자료를 한 화면에 붙여, 손익 건마다 용도와 주된 사업활동으로 다시 구한 범주(재계산 범주)를 장부에 기록된 범주와 나란히 놓고, 다른 건과 판단 근거가 비어 있는 건을 점검 코드로 가려 줍니다. 기준서 도입 시기는 IFRS 18 이 2027-01-01 이후 개시하는 회계연도부터 적용이며 조기적용을 허용하고 비교기간은 재작성한다는 점까지만 확정 사실로 쓰고, 그 밖의 경과규정은 원문 확인 필요로 둡니다.

손익 범주는 계정이 아니라 용도로 갈린다

같은 임대수익 계정이라도 어느 범주에 놓여야 하는지는 계정 번호만으로 정해지지 않습니다. 임대 목적으로 보유한 투자부동산이면 이 화면은 기본값으로 투자범주를 점검 기준으로 삼고, 자가사용 부동산이나 판매용 부동산이면 영업범주를, 중단영업에 속한 부동산이면 중단영업 범주를 기준으로 삼습니다. 회사의 주된 사업활동이 부동산 투자라면 같은 임대 목적 부동산의 손익이라도 영업범주가 점검 기준이 됩니다. 이 판정 순서는 화면이 쓰는 점검 규칙이며, 투자범주에 들어가는 손익의 범위와 주된 사업활동의 판단 요건은 기준서 원문 확인 필요로 남겨 둡니다.

그래서 계정만 보는 리포트는 이 질문에서 멈춥니다. 계정 단위 잔액은 맞는데 어느 부동산의 어떤 용도에서 나온 금액인지가 붙어 있지 않으면, 자가사용 건물의 감가상각비가 투자범주에 들어갔는지 임대 건물의 운영비가 영업범주에 남았는지를 가릴 수 없습니다. 이 앱은 손익 건마다 용도와 주된 사업활동을 붙여 재계산하기 때문에 그 질문에 건 단위로 답합니다.

장부 범주와 전기 범주를 함께 봐야 한다

용도로 다시 구한 범주가 장부와 같아도 걸리는 일이 하나 더 있습니다. 용도 변경이 없는데 전기와 다른 범주에 기록된 경우입니다. 비교기간 정보와 이어져야 하는 자리라서, 이 앱은 장부 범주와 전기 범주를 같은 줄에 두고 용도 변경 여부를 함께 보여 줍니다. 용도가 바뀐 건은 범주가 달라지는 것이 자연스러우므로 걸리지 않고, 용도 변경이 없는데 달라진 건만 점검 코드 K03 으로 올라옵니다.

이 비교가 필요한 이유는 기준서 도입 시점에 있습니다. 도입 첫해에는 당기와 비교기간을 같은 기준으로 맞춰 놓아야 하고, 그때 “전기에는 영업범주였는데 올해는 투자범주” 같은 이동이 근거 없이 끼어 있으면 설명을 요구받습니다. 도입 전에 미리 이동 건을 한 번 가려 두면 회의가 “어느 건이 움직였나” 찾는 일에서 “움직인 이유가 있나” 확인하는 일로 바뀝니다.

용도가 비어 있으면 판단을 보류한다

점검 도구가 제일 조심해야 하는 일은 근거 없이 범주를 단정하는 것입니다. 부동산 용도가 등록되지 않은 건은 범주를 판단할 기준이 없으므로 이 앱은 임의로 영업범주나 투자범주를 채우지 않고 “확인 필요”로 표시한 뒤 그 금액을 판정 보류로 따로 모읍니다. 회사가 용도를 먼저 정하고 다시 조회하면 그 건의 재계산 범주가 채워지고, 보류 금액은 줄어듭니다. 대사식에도 보류 금액이 들어 있어서, 판단을 미룬 금액까지 합쳐 순 손익과 맞는지를 매번 검산합니다.

사용 방법

1. 회계연도를 입력합니다(필수, 4자리). 회사·부동산 용도·장부 범주·기록일·부동산명·점검 코드·점검 결과는 필요할 때만 고릅니다.
2. 조회 버튼을 누르거나 입력칸에서 Enter 키를 누릅니다. 조회 버튼은 조회조건 영역의 가장 오른쪽에 있고, 화면을 열면 회계연도 기준으로 한 번 자동 조회됩니다.
3. 위쪽 요약에서 점검한 손익 건수 · 점검 필요 항목 · 확인 필요 항목 · 이동 필요 금액 · 투자범주로 놓인 장부 손익 · 대사 차이 건수를 먼저 봅니다.
4. 탭을 부동산별 범주 판정 → 손익 건별 점검 → 용도별 합계 → 대사 결과 순서로 옮겨 가며 봅니다.
5. 손익 건별 점검 탭에서 행을 누르면 상세가 열려 점검 근거와 같은 부동산의 건별 비교가 나옵니다.
6. CSV 내려받기 버튼으로 지금 보고 있는 탭을 UTF-8 파일로 내려받아 검토 자료에 붙입니다.

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

점검 화면에서 가장 비싼 질문은 “이 합계 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 검증용 샘플 데이터 전체로 돌렸습니다. 아래는 그 결과입니다.

여섯 가지 대사식이 모두 차이 0 입니다. 점검 화면이므로 의도적으로 넣은 예외 건은 대사 차이와 분리해 기록합니다. 검증용 샘플 데이터에는 점검 필요 8건(K01 2건 · K02 1건 · K03 1건 · K04 2건 · K05 2건)과 확인 필요 2건(K09)이 들어 있고, 이것은 대사 차이 건수 0 과 별개입니다. 점검 코드가 올라오는 것은 화면이 제대로 일하고 있다는 뜻이고, 대사가 어긋나는 것은 화면이 틀렸다는 뜻이므로 둘을 섞어 세지 않습니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤과 sap_horizon 테마만 씁니다. 데이터는 OData V2 서비스 하나에서 읽고, 화면은 서비스 주소를 코드에 적지 않고 앱 설정(manifest)에 선언한 상대 경로만 바라봅니다. 조회조건은 모두 필터로 서비스에 보내고, 정렬·건수·페이징도 서비스가 처리합니다.

실행 화면

실제로 돌아가는 화면 6종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 보는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 검증용 샘플 데이터에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다.

처음 열었을 때

조회조건부터 표까지가 한 화면에 세로로 쌓입니다. 화면을 열면 회계연도 기준으로 자동 조회되므로 별도 조작 없이 첫 결과가 나옵니다.

맨 위 파란 안내는 이 화면이 점검 도구이며 최종 판단은 회사와 감사인이 한다는 점을 먼저 밝힙니다. 요약의 ‘38’은 점검한 손익 건수, ‘8’은 점검 필요 항목, ‘2’는 확인 필요 항목이고, 이동 필요 금액은 3,738.0 백만 원으로 보입니다. 아래 표는 부동산 15곳을 한 줄씩 보여 주며 순 손익 합계 · 장부 3범주 · 재계산 3범주 · 점검 결과가 나란히 놓입니다. 조회 전에도 조회조건과 표 틀이 먼저 서 있어서 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 바로 압니다.

손익 건마다 점검하고, 행을 눌러 근거를 본다

부동산 단위 판정에서 의심 가는 곳이 보이면 건별 탭으로 내려가 어떤 건이 범주가 다른지 확인합니다. 한 줄을 누르면 근거와 같은 부동산의 비교가 열립니다.

범주가 서로 다른 줄은 점검 결과 칸에 ‘점검 필요’가 주황색으로 뜨고, 용도가 비어 있는 줄은 ‘확인 필요’로 뜹니다. 금액은 수익·이익을 양수, 비용·손실을 음수로 적어 손익계산서와 같은 방향으로 읽을 수 있게 했습니다. 표 위의 점검 코드와 점검 결과 조건을 바꾸면 해당 건만 남기므로, 점검 필요 건만 모아 CSV 로 내려받아 담당자에게 보낼 수 있습니다.

화면은 점검 코드가 올라온 이유를 문장으로 적고(예: 투자부동산의 손익이 영업범주에 기록됐습니다), 그 아래에 같은 부동산의 건별 비교표를 붙입니다. 같은 부동산에서 1건은 정상이고 2건이 점검 필요라면, 한 건이 아니라 부동산 단위 이동인지 건별 오기록인지를 바로 가를 수 있습니다. 오른쪽 아래 ‘이동 필요 금액’은 범주가 다른 건의 손익 금액이며 부호를 포함해 보여 줍니다.

용도로 묶어 보고, 대사로 확인한다

건별로 본 것을 용도 단위로 올려 보면 어떤 용도의 장부 범주가 흔들리는지 보입니다. 마지막으로 대사 탭에서 합계가 어긋나지 않았는지 확인합니다.

부동산 한 곳씩 보던 질문을 용도 단위로 올려서, 예를 들어 임대 목적 투자부동산 전체에서 영업범주로 남은 금액이 얼마인지 한눈에 봅니다. 용도 미등록 행의 금액은 판정 보류 칸으로 모이며, 이 금액이 0 이 되는 것이 도입 준비의 첫 목표가 됩니다. 합계는 부동산별 합계의 합과 같아야 하고, 대사 결과 탭이 그 등식을 매번 검산합니다.

요약의 ‘대사 차이 건수’는 이 탭의 차이 건수를 합한 값입니다. 점검 필요 건이 많다고 대사 차이가 느는 것은 아닙니다 — 점검 필요는 장부가 기준과 다르다는 뜻이고, 대사 차이는 화면의 집계가 어긋났다는 뜻이기 때문입니다. 참고 대사는 원장 계정별 합계를 따로 더해 건별 합계와 맞춰 보는 독립 검산입니다.

조건으로 좁혀 본다

부동산이 많아지면 이름 조건이 가장 자주 쓰입니다. 같은 조건이 요약과 모든 탭에 함께 적용됩니다.

부동산명 조건은 이름 일부를 포함하는 검색입니다. 요약 지표와 탭 건수도 같은 조건으로 다시 계산되므로, 특정 부동산의 점검 필요 금액만 따로 읽을 수 있습니다. 조건을 비우려면 초기화 버튼을 누르며, 그러면 회계연도 기준 첫 조회로 돌아갑니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 조회조건을 필터로 바꿔 OData 서비스에 보내고, 서비스가 손익 건을 읽어 재계산 범주를 정한 뒤 장부 범주와 비교해 점검 코드를 붙입니다. 부동산별 · 용도별 · 대사 탭은 같은 손익 건을 다른 단위로 합산한 결과라서 어느 탭을 열어도 같은 숫자에서 출발합니다. 요약의 점검 필요 건수만 서비스 펑션 FlagCount 가 따로 계산해 돌려줍니다.

재계산 범주는 이렇게 정한다

재계산 범주는 부동산에 등록한 용도와 회사의 주된 사업활동 여부에서 구합니다. 아래는 화면이 쓰는 점검 규칙이며, 투자범주에 들어가는 손익의 범위와 주된 사업활동의 판단은 회사가 정하는 일이고 기준서 원문 확인 필요입니다.

점검 코드 — 판정 조건 → 결과 상태 → 사용자 조치

손익 건 하나에는 점검 코드 하나가 붙습니다. 결과는 “점검 필요”와 “확인 필요”까지만 말하고 원인을 단정하지 않습니다. 같은 건이 K01 이면서 용도 변경 여부도 걸리는지 같은 판단은 화면이 아니라 사람이 합니다.

산출·대사 순서

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

화면 폭이 좁아지면 조회조건과 요약 지표는 한 줄에 다 담지 않고 줄을 바꿔 이어지며, 표는 가로로 스크롤해 열을 모두 읽습니다. 열을 숨기지 않으므로 좁은 화면에서도 같은 숫자를 같은 이름의 열로 읽습니다.

파일 구성

앱 폴더/
├─ index.html · readme.html · Component.js · manifest.json
├─ controller/   화면 제어 2개
├─ view/         본 화면 · 상세 창
├─ model/        표시 형식 · 오류 안내
├─ css/ · i18n/  스타일 · 한글 문구
├─ odata/        서비스 정의와 서비스 로직, 데이터 파일 5개
└─ media/        소개 영상 · 표지 이미지

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준 화면 사이에서 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 리포트를 없애야 하느냐”는 질문이 꼭 나오는데, 답은 없애지 않고 둔다입니다. 대사와 감사 대응, 법정 공시용 출력은 표준 거래가 맡는 편이 안전합니다.

표준 화면의 값을 이 앱에서 다시 볼 때는 같은 회사 · 회계연도 · 기록일을 조회조건에 넣으면 됩니다. 반대로 이 앱의 결과를 표준에서 확인할 때는 건별 탭의 기록일과 부동산을 기준으로 위 거래를 엽니다.

요구사항 매핑표

기준서 원문에서 직접 확인하지 못한 항목은 문단 번호를 적지 않고 요구사항 명칭만 적었으며, 해석이 필요한 부분은 확인 필요로 남겼습니다.

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

S/4HANA 에서는 CDS 뷰 위에 분석 쿼리를 올려 Fiori 분석 앱이나 Analysis for Office 에서 같은 모델을 읽는 구성이 일반적입니다. 이 앱의 화면은 OData 서비스를 읽고, 그 서비스를 뒷받침하는 CDS 구성은 아래 CDS 구성 절에 코드와 함께 적었습니다. 그래서 화면은 이 앱의 화면을 그대로 두고, 같은 분석 쿼리를 표준 분석 도구에도 노출하는 것이 가능합니다. 어느 쪽을 정식 조회 창구로 삼을지는 고객사가 정할 일이며, 이 앱은 화면과 분석 도구가 같은 CDS 를 읽으므로 숫자가 갈리지 않는다는 점만 보장하면 됩니다. 표준 분석 앱의 구체 이름과 활성화 방법은 릴리스에 따라 달라 확인 필요입니다.

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

CDS 구성

이 사례의 화면은 검증용 샘플 데이터를 서비스가 읽어 점검 코드를 붙입니다. 운영에서는 같은 일을 CDS 로 내려서 DB 가 하게 합니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스와 고객사 환경에 따라 다르므로 그대로 붙여 넣기 전에 View Browser 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 “확인 필요”로 적었습니다.

뷰 레이어 구성

① 매핑 테이블 — 계정과 용도

범주 판정의 모든 숫자가 이 두 표에서 갈립니다. 어느 계정이 어느 범주이고 어떤 자산이 어떤 용도인지를 정하는 자리라, 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 중간에 체계가 바뀌어도 과거 숫자가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZPNL_ACCTCAT — 손익 계정 → 장부 범주 매핑 (투명 테이블)
"  어느 손익 계정이 영업 · 투자 · 중단영업 범주에 놓이는지를 정한다.
"  코드에 박지 않는 이유 : 계정은 늘 늘어나고, 늘어날 때마다
"  개발자를 부르게 만들면 점검이 금방 낡는다.
"  범주 정의 자체는 회사가 정하며 기준서 원문 확인 필요.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '손익 계정 범주 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpnl_acctcat {
  key mandt    : mandt not null;
  key ktopl    : ktopl not null;        " 계정과목표
  key saknr    : saknr not null;        " 계정
  key valid_to : abap.dats not null;    " 유효 종료일
  valid_from   : abap.dats;
  book_cat     : abap.char(4);          " OPR 영업 · INV 투자 · DISC 중단영업
  line_type    : abap.char(1);          " R 임대수익 · V 평가손익 · D 감가상각비 · E 운영비 · G 처분손익
}

" ────────────────────────────────────────────────────────────────
"  ZPNL_PROPUSE — 자산 → 부동산 용도 매핑 (투명 테이블)
"  용도를 자산 마스터의 어느 필드에 둘지는 고객사 설정이라 확인 필요.
"  필드에 두기 어려우면 이 테이블에 용도를 따로 관리한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '부동산 용도 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpnl_propuse {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;
  key anln1    : anln1 not null;        " 자산번호(부동산 단위)
  key valid_to : abap.dats not null;
  valid_from   : abap.dats;
  use_type     : abap.char(3);          " RNT 임대 · APR 시세차익 · OWN 자가사용 · STK 판매용 · DSC 중단영업 · 공란 = 미등록
  main_biz     : abap.char(1);          " Y = 이 회사의 주된 사업활동이 부동산 투자
  use_chg      : abap.char(1);          " Y = 당기에 용도가 바뀐 부동산
}

② 부동산 차원 뷰

자산 마스터와 용도 매핑을 한 번만 붙여 두는 뷰입니다. 이후 모든 뷰가 이 뷰를 통해 부동산을 읽으므로, 자산의 분류 기준이 바뀌어도 고칠 곳이 여기 하나입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_PropertyUse — 부동산 차원
"  부동산 하나당 한 행. 자산 마스터(ANLA)에 용도 매핑을 붙인다.
"  차원 뷰를 따로 두는 이유 : join 을 한 번만 걸고,
"  값 도움말 · 텍스트가 이 뷰 하나를 보게 하기 위해서다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '부동산 차원'
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'AssetNumber'
define view entity ZI_PropertyUse
  as select from anla as a
  left outer join zpnl_propuse as u
    on  u.bukrs = a.bukrs
    and u.anln1 = a.anln1
    and u.valid_to >= $session.system_date
    and u.valid_from <= $session.system_date
{
  key a.bukrs                    as CompanyCode,
  key a.anln1                    as AssetNumber,
      @Semantics.text: true
      a.txt50                    as PropertyName,
      a.anlkl                    as AssetClass,        // 자산 클래스로 부동산을 가르는 방식은 확인 필요
      coalesce( u.use_type, '' ) as UseType,
      coalesce( u.main_biz, 'N' ) as MainBusiness,
      coalesce( u.use_chg,  'N' ) as UseChanged
}
where a.deakt = '00000000'                              // 비활성(폐기) 자산 제외 — 조건은 확인 필요

③ 손익 건 기본 뷰 — ACDOCA 에서 부동산 단위로

ACDOCA 의 HSL 은 차변이 양수, 대변이 음수입니다. 수익은 대변에 놓이므로 원장에는 음수로 들어 있습니다. 화면은 수익·이익을 양수로 읽게 하려고, 범주 매핑의 손익 구분을 보고 부호를 뒤집은 값을 함께 둡니다. 원장과 대사할 때는 원장 금액 그대로, 사람이 읽을 때는 표시 금액입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_PropertyPnl — 부동산 손익 건 (기본 뷰)
"  ACDOCA 의 손익 계정 라인 한 줄 = 손익 건 하나.
"  장부 범주는 계정 매핑에서, 부동산은 자산 필드에서 온다.
"  원천 필드 이름은 릴리스에 따라 확인 필요.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '부동산 손익 건'
define view entity ZI_PropertyPnl
  as select from acdoca as j
  inner join zpnl_acctcat as m
    on  m.saknr = j.racct
    and m.valid_from <= j.budat
    and m.valid_to   >= j.budat
{
  key j.rldnr                              as Ledger,
  key j.rbukrs                             as CompanyCode,
  key j.gjahr                              as FiscalYear,
  key j.belnr                              as AccountingDocument,
  key j.docln                              as LedgerGLLineItem,
      j.anln1                              as AssetNumber,        // 부동산이 자산 라인에 달리지 않는 환경은 확인 필요
      j.racct                              as GlAccount,
      j.budat                              as PostingDate,
      m.book_cat                           as BookedCat,
      m.line_type                          as LineType,
      @Semantics.amount.currencyCode : 'Currency'
      j.hsl                                as LedgerAmount,       // 원장 금액 — 대사용
      @Semantics.amount.currencyCode : 'Currency'
      cast( j.hsl * -1 as abap.curr(23,2) ) as DisplayAmount,     // 수익 · 이익 +, 비용 · 손실 −
      j.rhcur                              as Currency
}
where j.rldnr = '0L'

④ 재계산 범주와 점검 코드

이 뷰가 이 앱의 핵심입니다. 용도와 주된 사업활동으로 재계산 범주를 구하고, 장부 범주 · 전기 범주 · 용도 변경과 견줘 점검 코드를 붙입니다. 판정이 여기 한 곳에만 있어서 화면이든 배치든 분석 도구든 같은 코드를 받습니다. 규칙의 범위와 주된 사업활동의 판단 요건은 기준서 원문 확인 필요로 두고, 점검 코드는 “확인합니다” 계열의 문구만 붙입니다.

" ────────────────────────────────────────────────────────────────
"  ZC_PropertyPnlCategory — 재계산 범주 · 점검 코드
"  용도 + 주된 사업활동 → 재계산 범주(ExpectCat)
"  재계산 범주 vs 장부 범주 · 전기 범주 → 점검 코드(CheckCode)
"  규칙을 한 곳에만 두는 이유 : 화면 · 배치 · 분석 도구가
"  서로 다른 답을 내는 일을 막기 위해서다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '재계산 범주와 점검 코드'
define view entity ZC_PropertyPnlCategory
  as select from ZI_PropertyPnl as p
  left outer join ZI_PropertyUse as u
    on  u.CompanyCode = p.CompanyCode
    and u.AssetNumber = p.AssetNumber
  left outer join ZI_PropertyPnlPrev as v         // 전기 같은 부동산 · 같은 손익 구분의 장부 범주를 모은 뷰 — 스케치 생략
    on  v.CompanyCode = p.CompanyCode
    and v.AssetNumber = p.AssetNumber
    and v.LineType    = p.LineType
{
  key p.CompanyCode, key p.FiscalYear, key p.AccountingDocument, key p.LedgerGLLineItem,
      p.AssetNumber, p.BookedCat, p.DisplayAmount, p.PostingDate,
      u.UseType, u.MainBusiness, u.UseChanged,
      v.PrevCat,

      case
        when u.UseType = ''                    then 'NONE'   // 용도 미등록 — 판정 보류
        when u.UseType = 'DSC'                 then 'DISC'
        when u.UseType = 'OWN' or u.UseType = 'STK' then 'OPR'
        when u.UseType = 'RNT' or u.UseType = 'APR'
             then case when u.MainBusiness = 'Y' then 'OPR' else 'INV' end
        else 'NONE'
      end                                      as ExpectCat,

      case
        when u.UseType = ''                                                        then 'K09'
        when u.UseType = 'DSC'  and p.BookedCat <> 'DISC'                          then 'K05'
        when ( u.UseType = 'OWN' or u.UseType = 'STK' ) and p.BookedCat = 'INV'    then 'K02'
        when ( u.UseType = 'RNT' or u.UseType = 'APR' ) and u.MainBusiness = 'N'
                                and p.BookedCat = 'OPR'                            then 'K01'
        when ( u.UseType = 'RNT' or u.UseType = 'APR' ) and u.MainBusiness = 'Y'
                                and p.BookedCat = 'INV'                            then 'K04'
        when u.UseChanged = 'N' and v.PrevCat is not null
                                and v.PrevCat <> p.BookedCat                       then 'K03'
        else 'K00'
      end                                      as CheckCode
}

⑤ 부동산 · 용도 합계 큐브

판정된 손익 건을 부동산 단위로 합산합니다. 장부 3범주와 재계산 3범주, 판정 보류, 이동 필요 금액이 모두 여기서 계산되므로 화면이 합계를 더할 일이 없습니다. 이 뷰의 측정값이 대사 R01~R05 의 좌변과 우변이 됩니다.

" ────────────────────────────────────────────────────────────────
"  ZI_PropertyPnlCube — 부동산 단위 합계 (큐브)
"  장부 범주와 재계산 범주를 같은 줄에 나란히 두는 것이 목적이다.
"  합계를 화면에서 더하지 않고 여기서 한 번만 정의한다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '부동산 손익 범주 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZI_PropertyPnlCube
  as select from ZC_PropertyPnlCategory as c
{
  key c.CompanyCode,
  key c.FiscalYear,
  key c.AssetNumber,
      c.UseType,
      c.MainBusiness,
      @Aggregation.default : #SUM
      sum( c.DisplayAmount )                                                       as NetAmount,
      @Aggregation.default : #SUM
      sum( case when c.BookedCat = 'OPR'  then c.DisplayAmount else 0 end )        as LedgerOperating,
      @Aggregation.default : #SUM
      sum( case when c.BookedCat = 'INV'  then c.DisplayAmount else 0 end )        as LedgerInvesting,
      @Aggregation.default : #SUM
      sum( case when c.BookedCat = 'DISC' then c.DisplayAmount else 0 end )        as LedgerDiscontinued,
      @Aggregation.default : #SUM
      sum( case when c.ExpectCat = 'OPR'  then c.DisplayAmount else 0 end )        as ExpectOperating,
      @Aggregation.default : #SUM
      sum( case when c.ExpectCat = 'INV'  then c.DisplayAmount else 0 end )        as ExpectInvesting,
      @Aggregation.default : #SUM
      sum( case when c.ExpectCat = 'DISC' then c.DisplayAmount else 0 end )        as ExpectDiscontinued,
      @Aggregation.default : #SUM
      sum( case when c.ExpectCat = 'NONE' then c.DisplayAmount else 0 end )        as HoldAmount,   // 판정 보류
      @Aggregation.default : #SUM
      sum( case when c.CheckCode between 'K01' and 'K05' and c.ExpectCat <> c.BookedCat
                then c.DisplayAmount else 0 end )                                  as MoveAmount,   // 요약에는 절대값 합계로 표시
      count( * )                                                                   as LineCount,
      sum( case when c.CheckCode between 'K01' and 'K05' then 1 else 0 end )       as FlagCount,
      sum( case when c.CheckCode = 'K09' then 1 else 0 end )                       as ConfirmCount
}
group by c.CompanyCode, c.FiscalYear, c.AssetNumber, c.UseType, c.MainBusiness

⑥ 분석 쿼리 — 화면이 읽는 모양

쿼리는 조회조건과 기본 열 배치, 화면에서 쓰는 필드 이름을 정합니다. 표준 Fiori 분석 앱이나 Analysis for Office 에서도 이 쿼리를 띄울 수 있어, 같은 정의를 이 앱의 화면과 표준 분석 도구가 함께 쓸 수 있습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_PropertyPnlQuery — 분석 쿼리 (Consumption)
"  회계연도 필수, 회사 · 용도 · 점검 결과는 선택.
"  이름은 화면 필드와 맞춘다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '부동산 손익 범주 점검'
@Analytics.query : true
@OData.publish : false
define view entity ZC_PropertyPnlQuery
  as select from ZI_PropertyPnlCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key FiscalYear,

  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter.selectionType : #SINGLE
  key CompanyCode,

  @AnalyticsDetails.query.axis : #ROWS
  key AssetNumber,

  @Consumption.filter.selectionType : #RANGE
  UseType,

  @AnalyticsDetails.query.axis : #COLUMNS
  NetAmount, LedgerOperating, LedgerInvesting, LedgerDiscontinued,
  ExpectOperating, ExpectInvesting, ExpectDiscontinued, HoldAmount,
  MoveAmount, LineCount, FlagCount, ConfirmCount
}

⑦ 접근 제어(DCL)

합계에 권한을 걸지 않으면 전사 합계와 자기 몫의 차이로 남의 부동산 숫자를 알아낼 수 있습니다. 그래서 권한은 건별 상세가 아니라 큐브를 읽는 자리에 겁니다.

" ────────────────────────────────────────────────────────────────
"  ZI_PROPERTYPNLCUBE — 접근 제어
"  회사코드(F_BKPF_BUK) 권한이 있는 데이터만 읽게 한다.
"  권한 오브젝트와 필드는 고객사 권한 설계에 따라 확인 필요.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '부동산 손익 범주 큐브 권한'
@MappingRole : true
define role ZI_PROPERTYPNLCUBE {
  grant select on ZI_PropertyPnlCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

쿼리를 OData V2 서비스로 게시하는 자리입니다. 이 단계가 끝나면 화면이 읽던 서비스 주소만 운영 주소로 바뀌고 화면 코드는 그대로입니다.

" ────────────────────────────────────────────────────────────────
"  Service Definition — 쿼리를 서비스에 노출
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '부동산 손익 범주 점검 서비스'
define service ZUI_PropertyPnlCheck {
  expose ZC_PropertyPnlQuery as PropSet;
  expose ZC_PropertyPnlCategory as LineSet;   // 건별 점검 — 읽기 전용
}

" Service Binding : OData V2 - UI, 이름 ZUI_PROPERTYPNLCHECK_O2
" 활성화는 /IWFND/MAINT_SERVICE 또는 Binding 의 게시(Publish)로 한다.
" 게시한 뒤 이 앱의 서비스 주소(manifest)만 교체한다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래를 정하지 않고 코드부터 올리면 첫 대사에서 숫자가 어긋납니다.

운영 데이터로 갈 때

검증용 샘플 데이터는 부동산 15곳 · 손익 38건이라 화면이 전부 읽어도 부담이 없습니다. 운영에서는 부동산이 수백 곳, 손익 건이 수만~수십만 건이 될 수 있고 ACDOCA 전체는 그보다 훨씬 큽니다. 그래서 집계를 CDS 로 내려 DB 에서 하게 하고, 화면은 요약과 부동산 단위 합계만 먼저 읽은 뒤 건별은 행을 눌렀을 때 읽는 방식으로 바꾸는 것이 안전합니다.

회계연도와 회사코드는 쿼리의 필수 파라미터로 두고, 손익 계정으로 먼저 걸러 읽는 조건이 인덱스를 타는지 실제 데이터로 확인해야 합니다. 응답 시간 목표는 고객사가 정할 일이며, 건별 탭은 건수가 일정 수를 넘으면 범위를 좁히라고 안내하는 편이 낫습니다. 이 단계의 구체 성능 수치는 운영 데이터 규모와 시스템 구성에 따라 달라 확인 필요입니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문들입니다. 네 묶음으로 나눠 적었습니다.

판정 규칙과 숫자

화면과 조작

표준 기능과의 관계

도입과 운영