배당수익 범주 점검 — 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 입니다. 점검 화면이므로 의도적으로 넣은 예외 건은 대사 차이와 분리해 기록합니다. 검증용 샘플 데이터에는 점검 필요 10건(K01 4건 · K02 1건 · K03 1건 · K04 2건 · K05 2건)과 확인 필요 3건(K09)이 들어 있고, 이것은 대사 차이 건수 0 과 별개입니다. 점검 코드가 올라오는 것은 화면이 제대로 일하고 있다는 뜻이고, 대사가 어긋나는 것은 화면이 틀렸다는 뜻이므로 둘을 섞어 세지 않습니다.

무엇으로 만들었나

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

실행 화면

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

처음 열었을 때

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

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

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

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

배당 건별 점검 탭은 배당 33건을 한 줄씩 보여 줍니다. 건마다 배당 구분(결산 · 중간 · 특별 · 정정)과 금액, 장부 범주, 전기 범주, 유형 변경 여부, 재계산 범주, 점검 결과, 이동 필요 금액이 한 줄에서 견줘집니다. 범주가 서로 다른 줄은 점검 결과 칸에 ‘점검 필요’가 주황색으로 뜨고, 투자 유형이 비어 있는 줄은 ‘확인 필요’로 뜹니다. 금액은 받은 배당을 양수, 정정으로 줄어든 배당을 음수로 적어 손익계산서와 같은 방향으로 읽을 수 있게 했습니다.

화면은 점검 코드가 올라온 이유를 문장으로 적고(예: 주된 사업활동이 투자가 아닌 회사의 배당수익이 영업범주에 기록되었습니다), 그 아래에 같은 투자처의 건별 비교표를 붙입니다. 사진의 투자처는 결산배당 · 중간배당은 정상이고 마지막 특별배당 한 건만 영업범주에 놓여 있어서, 투자처 전체의 문제가 아니라 한 건의 기록 문제라는 것을 바로 가를 수 있습니다. 오른쪽 위의 큰 금액은 그 건의 배당 금액이고, 표 오른쪽의 ‘이동 필요 금액’은 범주가 다른 건의 금액을 부호를 포함해 보여 줍니다.

유형으로 묶어 보고, 대사로 확인한다

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

유형별 합계 탭은 회사마다 당기손익-공정가치 지분상품 · 기타포괄손익-공정가치 지분상품 · 종속기업 투자 · 관계·공동기업 투자 · 중단영업 소속 투자처 · 유형 미등록으로 묶어 장부 범주 금액과 재계산 범주 금액을 나란히 보여 줍니다. 투자처 한 곳씩 보던 질문을 유형 단위로 올려서, 예를 들어 종속기업 투자에서 받은 배당 가운데 중단영업 범주에 들어간 금액이 얼마인지 한눈에 봅니다. 유형 미등록 행의 금액은 판정 보류 칸으로 모이며, 이 금액이 0 이 되는 것이 도입 준비의 첫 목표가 됩니다.

대사 결과 탭에는 대사 번호 · 대사 구분 · 좌변 · 우변 · 검사 건수 · 차이 건수 · 최대 차이 · 대사식이 한 줄씩 나옵니다. 정합성 대사(INT) 여섯 개와 참고 대사(REF) 한 개가 모두 차이 건수 0 입니다. 요약의 ‘정합성 대사 차이 건수’는 이 탭에서 정합성 대사의 차이 건수를 합한 값입니다. 점검 필요 건이 많다고 대사 차이가 느는 것은 아닙니다 — 점검 필요는 장부가 기준과 다르다는 뜻이고, 대사 차이는 화면의 집계가 어긋났다는 뜻이기 때문입니다.

점검 코드로 좁혀 본다

점검 필요 건이 많아지면 같은 사유로 묶어 보는 일이 가장 자주 쓰입니다. 같은 조건이 요약과 모든 탭에 함께 적용됩니다.

조회조건의 점검 코드를 K01 로 고르고 조회하면 투자 목적 배당이 영업범주에 기록된 건만 4건 남고, 요약의 점검한 배당 건수와 범주 이동 필요 금액(450.0 백만 원)도 같은 조건으로 다시 계산됩니다. 점검 필요 항목 ‘10’은 회계연도와 회사를 기준으로 서비스 펑션이 따로 세는 값이라 코드를 바꿔도 그대로입니다. 조건을 비우려면 초기화 버튼을 누르며, 그러면 회계연도 기준 첫 조회로 돌아갑니다. 투자처명 입력칸에서 Enter 키를 눌러도 같은 조회가 됩니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 조회조건을 필터로 바꿔 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 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 “확인 필요”로 적었습니다.

뷰 레이어 구성

① 매핑 테이블 — 계정과 투자 유형

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

" ────────────────────────────────────────────────────────────────
"  ZDIV_ACCTCAT — 배당수익 계정 → 장부 범주 매핑 (투명 테이블)
"  어느 계정의 배당수익이 영업 · 투자 · 중단영업 범주에 놓이는지를 정한다.
"  코드에 박지 않는 이유 : 계정은 늘 늘어나고, 늘어날 때마다
"  개발자를 부르게 만들면 점검이 금방 낡는다.
"  범주 정의 자체는 회사가 정하며 기준서 원문 확인 필요.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '배당수익 계정 범주 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zdiv_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);          " D 결산배당 · I 중간배당 · S 특별배당 · C 배당 정정
}

" ────────────────────────────────────────────────────────────────
"  ZDIV_INVTYPE — 투자처 → 투자 유형 매핑 (투명 테이블)
"  유형을 거래처 · 자산 · 투자 마스터의 어느 필드에 둘지는 고객사 설정이라 확인 필요.
"  필드에 두기 어려우면 이 테이블에 유형을 따로 관리한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '투자처 투자 유형 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zdiv_invtype {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;
  key inv_no   : abap.char(10) not null;   " 투자처 번호
  key valid_to : abap.dats not null;
  valid_from   : abap.dats;
  inst_type    : abap.char(3);          " FVP · FVO 지분상품 · SUB 종속 · JNT 관계·공동 · DSC 중단영업 · 공란 = 미등록
  main_biz     : abap.char(1);          " Y = 이 회사의 주된 사업활동이 투자
  type_chg     : abap.char(1);          " Y = 당기에 투자 유형이 바뀐 투자처
}

② 투자처 차원 뷰

투자 유형 매핑을 한 번만 붙여 두는 뷰입니다. 이후 모든 뷰가 이 뷰를 통해 투자처를 읽으므로, 투자 유형의 분류 기준이 바뀌어도 고칠 곳이 여기 하나입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_DividendInvestee — 투자처 차원
"  투자처 하나당 한 행. 거래처 마스터(LFA1)에 유형 매핑을 붙인다.
"  차원 뷰를 따로 두는 이유 : join 을 한 번만 걸고,
"  값 도움말 · 텍스트가 이 뷰 하나를 보게 하기 위해서다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '배당 투자처 차원'
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'InvesteeNo'
define view entity ZI_DividendInvestee
  as select from zdiv_invtype as u
  left outer join lfa1 as a
    on a.lifnr = u.inv_no                   // 투자처를 거래처 번호로 관리하는지는 확인 필요
{
  key u.bukrs                      as CompanyCode,
  key u.inv_no                     as InvesteeNo,
      @Semantics.text: true
      a.name1                      as InvesteeName,
      coalesce( u.inst_type, '' )  as InstType,
      coalesce( u.main_biz,  'N' ) as MainBusiness,
      coalesce( u.type_chg,  'N' ) as TypeChanged
}
where u.valid_to   >= $session.system_date
  and u.valid_from <= $session.system_date

③ 배당 건 기본 뷰 — ACDOCA 에서 투자처 단위로

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

" ────────────────────────────────────────────────────────────────
"  ZI_DividendLine — 배당 건 (기본 뷰)
"  ACDOCA 의 배당수익 계정 라인 한 줄 = 배당 건 하나.
"  장부 범주는 계정 매핑에서, 투자처는 라인의 연결 필드에서 온다.
"  원천 필드 이름은 릴리스에 따라 확인 필요.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '배당 건'
define view entity ZI_DividendLine
  as select from acdoca as j
  inner join zdiv_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.lifnr                              as InvesteeNo,         // 투자처가 라인에 달리지 않는 환경은 확인 필요
      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_DividendCategory — 재계산 범주 · 점검 코드
"  투자 유형 + 주된 사업활동 → 재계산 범주(ExpectCat)
"  재계산 범주 vs 장부 범주 · 전기 범주 → 점검 코드(CheckCode)
"  규칙을 한 곳에만 두는 이유 : 화면 · 배치 · 분석 도구가
"  서로 다른 답을 내는 일을 막기 위해서다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '재계산 범주와 점검 코드'
define view entity ZC_DividendCategory
  as select from ZI_DividendLine as p
  left outer join ZI_DividendInvestee as u
    on  u.CompanyCode = p.CompanyCode
    and u.InvesteeNo  = p.InvesteeNo
  left outer join ZI_DividendLinePrev as v        // 전기 같은 투자처 · 같은 배당 구분의 장부 범주를 모은 뷰 — 스케치 생략
    on  v.CompanyCode = p.CompanyCode
    and v.InvesteeNo  = p.InvesteeNo
    and v.LineType    = p.LineType
{
  key p.CompanyCode, key p.FiscalYear, key p.AccountingDocument, key p.LedgerGLLineItem,
      p.InvesteeNo, p.BookedCat, p.DisplayAmount, p.PostingDate,
      u.InstType, u.MainBusiness, u.TypeChanged,
      v.PrevCat,

      case
        when u.InstType = ''                   then 'NONE'   // 유형 미등록 — 판정 보류
        when u.InstType = 'DSC'                then 'DISC'
        when u.MainBusiness = 'Y'              then 'OPR'
        else 'INV'
      end                                      as ExpectCat,

      case
        when u.InstType = ''                                                       then 'K09'
        when u.InstType = 'DSC' and p.BookedCat <> 'DISC'                         then 'K05'
        when u.InstType <> 'DSC' and p.BookedCat = 'DISC'                         then 'K02'
        when u.InstType <> 'DSC' and u.MainBusiness = 'N' and p.BookedCat = 'OPR' then 'K01'
        when u.InstType <> 'DSC' and u.MainBusiness = 'Y' and p.BookedCat = 'INV' then 'K04'
        when u.TypeChanged = 'N' and v.PrevCat is not null
                                 and v.PrevCat <> p.BookedCat                      then 'K03'
        else 'K00'
      end                                      as CheckCode
}

⑤ 투자처 · 유형 합계 큐브

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

" ────────────────────────────────────────────────────────────────
"  ZI_DividendCube — 투자처 단위 합계 (큐브)
"  장부 범주와 재계산 범주를 같은 줄에 나란히 두는 것이 목적이다.
"  합계를 화면에서 더하지 않고 여기서 한 번만 정의한다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '배당수익 범주 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZI_DividendCube
  as select from ZC_DividendCategory as c
{
  key c.CompanyCode,
  key c.FiscalYear,
  key c.InvesteeNo,
      c.InstType,
      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.InvesteeNo, c.InstType, c.MainBusiness

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

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

" ────────────────────────────────────────────────────────────────
"  ZC_DividendQuery — 분석 쿼리 (Consumption)
"  회계연도 필수, 회사 · 투자 유형 · 점검 결과는 선택.
"  이름은 화면 필드와 맞춘다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '배당수익 범주 점검'
@Analytics.query : true
@OData.publish : false
define view entity ZC_DividendQuery
  as select from ZI_DividendCube
{
  @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 InvesteeNo,

  @Consumption.filter.selectionType : #RANGE
  InstType,

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

⑦ 접근 제어(DCL)

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

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

⑧ 서비스 정의와 바인딩

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

" ────────────────────────────────────────────────────────────────
"  Service Definition — 쿼리를 서비스에 노출
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '배당수익 범주 점검 서비스'
define service ZUI_DividendCheck {
  expose ZC_DividendQuery    as InvSet;
  expose ZC_DividendCategory as LineSet;   // 건별 점검 — 읽기 전용
}

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

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

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

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

자주 묻는 질문

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

판정 규칙과 숫자

화면과 조작

표준 기능과의 관계

도입과 운영