매출채권 양도 손익 범주 점검 — IFRS 18 에서 팩토링·어음 할인으로 생긴 양도 손익·수수료·할인료가 영업·재무 범주 중 맞는 곳에 놓였는지 다시 구해 장부와 맞춰 보는 화면

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

IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 손익계산서의 수익과 비용을 영업 · 투자 · 재무 같은 범주로 나눠 보이도록 요구합니다. 시행은 2027-01-01 이후 개시하는 회계연도부터이고, 비교기간도 같은 틀로 다시 써야 합니다. 그래서 범주 분류는 “올해 결산에서 바로 보게 될” 문제가 아니라 “지금 계정과 거래 속성을 정리해 두어야 하는” 문제입니다. 범주의 정의와 예외, 문단 번호는 모두 원문 확인 필요이며, 이 화면은 회사가 정한 분류 정책을 점검 규칙으로 옮겨 쓴 것입니다.

매출채권을 팩토링이나 어음 할인으로 넘기면 손익이 세 갈래로 생깁니다. 채권을 넘기며 남는 양도 손익, 금융기관에 내는 수수료, 넘긴 날부터 만기까지 붙는 할인료입니다. 이 셋이 어느 범주에 놓이는지는 상환청구가 있느냐 없느냐에 따라 달라지는 것이 일반적인 설명입니다. 상환청구가 없어 양도로 처리한 건이면 영업 쪽 손익으로 두는 것이 보통이고, 상환청구가 있어 차입으로 처리한 건이면 이자성 비용이라 재무 쪽에 놓입니다. 문제는 현업이 계정과 거래 속성을 건마다 이렇게 맞춰 보기가 어렵다는 점입니다.

지금은 양도 계약 목록 엑셀과 개별 항목 조회, 계정별 손익 잔액을 번갈아 열어 건마다 손으로 맞춥니다. 계약 하나의 손익이 영업과 재무 두 범주에 나뉘어 있어도 계정 잔액만 봐서는 보이지 않고, 계약 조건이 바뀌었는데 계정은 그대로인 경우도 합계로는 드러나지 않습니다. 이 앱은 그 자료를 한 화면에 붙여, 손익 건마다 상환청구 유형과 구성요소로 다시 구한 범주(재계산 범주)를 장부에 기록된 범주와 나란히 놓고, 다른 건과 판단 근거가 비어 있는 건을 점검 대상으로 보여 줍니다.

범주는 계약이 아니라 손익 건 하나하나의 구성요소로 갈린다

한 양도 계약의 손익이 모두 같은 범주에 들어가는 것은 아닙니다. 양도 손익과 수수료는 같은 계약 안에서도 계정이 다르고, 계정마다 속한 범주가 다르게 매핑되어 있을 수 있습니다. 계약 단위로 범주를 한 번에 정해 두면 한 건의 계정이 바뀌었을 때 합계는 같은데 범주별 금액만 틀어진 채 남습니다. 이 앱은 손익 건마다 구성요소(양도 손익 · 수수료 · 할인료)를 읽어 범주를 다시 구하므로, 어느 건이 어느 범주에서 어긋났는지 건 단위로 보입니다.

차입으로 처리한 건의 이자성 비용이 영업에 남아 있는 경우

상환청구가 있어 차입으로 처리한 건의 할인료는 이자 성격의 비용입니다. 이 비용이 영업범주 계정에 기록되어 있으면 점검 대상입니다. 이 화면은 이런 건을 점검 코드 A02 로 모아 보여 줍니다. 반대로 상환청구가 없는 양도의 손익이 재무범주에 기록된 경우는 A01 입니다. 어느 쪽이 맞는지는 계약 조건과 회사의 분류 정책에 따라 달라, 화면은 “확인하라”고만 알립니다.

투자범주나 범주 미지정으로 흘러간 금액이 가장 찾기 어렵다

영업과 재무 사이에서 옮겨진 금액은 총액이 같아서 합계 대사로는 잡히지 않습니다. 반면 양도 관련 손익이 투자범주에 기록되었거나(A03) 범주 자체가 비어 있는 건(A05)은 영업 · 재무 소계에서 빠져 합계가 달라 보입니다. 이 앱은 이 두 경우를 따로 모으고, 범주별 합계 탭에서 투자범주와 범주 미지정 줄에 금액이 있는지 한눈에 보게 했습니다.

할인료는 금액까지 다시 구해 본다

범주가 맞아도 금액이 맞는지는 별개입니다. 할인료는 양도채권액 × 연 할인율 × 일수 ÷ 365 로 다시 구할 수 있습니다. 이 앱은 상환청구가 있는 계약마다 이 식으로 할인료를 다시 계산해 장부 할인료와 견주고, 다르면 점검 코드 A04 로 알립니다. 일수 기준이나 반올림 방식이 달라서 생기는 차이일 수 있어, 오류로 단정하지 않고 계산 기준을 확인하라고만 표시합니다.

일부 상환청구면 판단을 보류한다

점검 도구가 제일 조심해야 하는 일은 근거 없이 범주를 단정하는 것입니다. 상환청구가 일부만 있는 조건은 양도와 차입 중 어느 쪽에 가까운지 회사가 먼저 판단해야 하므로, 이 앱은 임의로 범주를 채우지 않고 “확인 필요”(A09)로 표시해 판정 보류에 모읍니다. 회사가 판단을 정한 뒤 다시 조회하면 그 건이 재계산 대상으로 들어옵니다.

사용 방법

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

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

손익 범주 점검에서 가장 비싼 질문은 “범주를 옮겼더니 총액이 달라졌다” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 검증용 샘플 데이터 전체로 돌렸습니다. 아래는 그 결과입니다.

정합성 대사 여섯 식은 모두 차이 0 이고, 참고 대사 한 식(R07)에만 의도적으로 넣은 예외 한 건이 남아 있습니다. 점검 화면이므로 의도적으로 넣은 예외 건은 대사 차이와 분리해 기록합니다. 검증용 샘플 데이터에는 점검 필요 손익 건 16건(A01 4건 · A02 6건 · A03 2건 · A04 2건 · A05 2건), 확인 필요 8건(A09), 할인료 재계산 차이 1계약이 들어 있고, 이 숫자는 정합성 대사 차이 0건과 별개입니다. 이와 별도로 상환청구 유형과 구성요소에서 범주를, 양도 조건에서 할인료를 독립 재계산하는 검증 스크립트가 9개 검사 항목(검사 건수 합계 205건) 모두 차이 0건임을 확인했습니다.

무엇으로 만들었나

실행 화면

실제 사용 순서대로 화면 일곱 장을 싣습니다. 모든 화면은 검증용 샘플 데이터(회사 2곳 · 양도 계약 13건 · 손익 건 52건)로 열었습니다.

처음 열면 양도 계약별 점검이 먼저 보인다

화면을 열면 회계연도를 기준으로 한 번 자동 조회되어, 입력 없이도 양도 계약별 점검이 바로 채워집니다. 요약 지표 여섯 개를 먼저 읽고 표로 내려가는 순서가 기본입니다.

맨 위 파란 안내는 이 화면이 점검 도구이며 최종 판단은 회사와 감사인이 한다는 점을 먼저 밝힙니다. 요약의 ‘52’는 점검한 손익 건수, ‘16’은 점검 필요 항목, ‘8’은 확인 필요 항목이고, 범주 이동 필요 금액은 26.1 백만 원, 영업범주에 기록된 양도 손익은 55.8 백만 원, 정합성 대사 차이는 0건으로 보입니다. 아래 표는 양도 계약 13건을 한 줄씩 보여 주며 영업 · 재무 범주의 장부 금액과 재계산 금액이 줄마다 나란히 놓입니다. 점검 결과 칸의 ‘정상’ · ‘점검 필요’ · ‘확인 필요’로 어느 계약부터 볼지 바로 가려집니다.

손익 건마다 점검하고, 조건으로 좁힌다

계약 단위에서 의심 가는 곳이 보이면 건별 탭으로 내려가 어느 건의 범주가 다른지 확인합니다. 점검 코드로 좁히면 같은 사유의 건만 남습니다.

탭을 손익 건별 점검으로 옮기면 손익 건 52건이 한 줄씩 나옵니다. 건마다 양도 계약, 상환청구 유형(양도 처리 · 차입 처리 · 일부 상환청구), 구성요소, 전기일, 금액, 기록 범주, 재계산 범주, 범주 이동 필요 금액, 점검 내용이 나란히 놓입니다. 점검 필요 건은 이동 필요 금액이 0이 아니게 표시되어 합계로 한눈에 훑을 수 있고, 건수가 많을 때는 아래 조회조건으로 좁히면 됩니다.

점검 코드를 A02 로 고르고 조회하면 손익 건별 점검 탭에 6건만 남습니다. 모두 상환청구가 있어 차입으로 처리한 계약의 할인료이거나 수수료인데 영업범주에 기록된 건입니다. 입력칸에서 Enter 키를 눌러도 같은 조회가 일어납니다. 조회조건을 비우고 초기화를 누르면 회계연도 기본값으로 돌아가며, 전기일 시작이 종료보다 늦으면 조회하지 않고 안내 문구를 보입니다.

행을 눌러 근거를 본다

점검 필요로 나온 건은 이유를 설명할 수 있어야 의미가 있습니다. 한 줄을 누르면 근거 문장과 같은 양도 계약의 손익 건이 함께 열립니다.

손익 건별 점검 표에서 한 줄을 누르면 손익 건 상세가 열립니다. 위쪽에는 양도 계약, 양도 상대방, 상환청구 유형, 구성요소, 금액, 기록 범주, 재계산 범주가 나오고, 가운데에는 점검 근거 문장이 나옵니다. 아래 표는 같은 계약의 손익 건을 건별로 보여 주며 어느 건에서 기록 범주와 재계산 범주가 갈라지는지, 이동이 필요한 금액이 얼마인지 읽을 수 있습니다. 닫기를 누르면 조회 결과 그대로 표로 돌아옵니다.

범주별 합계, 할인료 재계산, 대사로 합계를 확인한다

건 단위 점검이 끝나면 범주별 합계로 어느 범주에서 차이가 생기는지 보고, 할인료는 재계산 탭으로 금액이 맞는지 보고, 마지막으로 대사 결과로 합산 과정의 합계가 맞는지 확인합니다.

범주별 합계 탭은 회사와 범주 단위로 8줄이 나옵니다. 장부 금액과 재계산 금액, 두 금액의 차이, 기록 건수, 점검 필요 건수가 한 줄에 놓입니다. 회사 1000 에서는 영업범주의 장부 금액이 재계산보다 1,157,534원 크고 재무범주는 같은 금액만큼 작아, 영업에서 재무로 옮겨 놓일 금액의 위치를 바로 볼 수 있습니다. 회사 2000 에서는 투자범주에 5,600,000원, 범주 미지정에 2,400,000원이 기록되어 있어 각각 점검 대상으로 올라옵니다.

할인료 재계산 탭에는 양도 계약 7건이 한 줄씩 나오며 양도채권액, 연 할인율, 일수, 재계산 할인료, 장부 할인료, 차이, 점검 결과를 보여 줍니다. 한 건에서만 장부 할인료가 재계산보다 521,918원 작게 나오며, 이 건이 점검 코드 A04 로 올라옵니다. 일부 상환청구 조건의 두 건은 금액은 맞지만 양도 성격의 판단이 먼저라서 ‘확인 필요’로 표시됩니다.

대사 결과 탭에는 대사 번호 · 구분 · 대사 항목 · 좌변 · 우변 · 검사 건수 · 차이 건수 · 최대 차이 · 대사식이 한 줄씩 나옵니다. 정합성 대사 여섯 줄은 모두 차이 건수 0 이고 좌변과 우변이 같은 금액입니다. 참고 대사 한 줄(R07)만 차이 건수 1, 최대 차이 521,918원이며, 이것이 의도적으로 넣은 예외 건입니다. 요약의 정합성 대사 차이가 0건인 것은 이 참고 대사를 제외한 값입니다.

화면 뒤에서 일어나는 일

손익 건마다 상환청구 유형과 구성요소로 재계산 범주를 구하고 기록 범주와 견주는 순서와 판정 결과는 아래와 같습니다. 이 순서는 화면의 점검 규칙이며, 기준은 점검용 단순화 규칙입니다.

처리 순서는 다섯 단계입니다. 먼저 손익 건마다 재계산 범주를 구해 점검 코드를 붙이고, 같은 건을 양도 계약 단위와 범주 단위로 각각 합산하며, 상환청구 있는 계약은 할인료를 다시 계산하고, 마지막으로 대사 일곱 식으로 합계를 맞춥니다. 판정 규칙은 서비스 로직 한 곳에만 있어서 화면 · 합계 · 대사가 같은 숫자를 씁니다.

조회조건

결과 컬럼

금액은 원 단위로 보이고, 요약만 백만 원 단위로 보입니다.

좁은 화면에서 달라지는 것

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

파일 구성

앱 폴더/
├─ index.html · readme.html · Component.js · manifest.json
├─ controller/   화면 제어 2개
├─ view/         본 화면 · 상세 창
├─ model/        표시 형식 · 오류 처리
├─ css/ · i18n/  스타일 · 문구
├─ odata/        서비스 정의와 로직, 데이터(검증용 샘플)
└─ media/        소개 영상 · 표지 그림

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

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

표준에 남겨 둘 일은 손익계산서 범주 표시 자체와 법정 출력, 감사인에게 내는 원장 증빙입니다. 이 앱의 CSV 는 검토 자료를 보조하는 용도이며 공시 문서를 대신하지 않습니다.

요구사항 매핑표

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

표준 CDS 분석 쿼리나 Fiori 분석 앱, Analysis for Office 는 계정과 기간 축으로 합계를 보는 데 강합니다. 이 앱은 그 위에서 쓰는 점검 화면이 아니라 상환청구 유형이라는 별도 축을 가진 점검 전용 서비스입니다. 표준 분석 앱으로 합계를 확인하고, 합계가 다른 이유를 건 단위로 설명할 때 이 앱을 쓰는 순서가 자연스럽습니다. 같은 CDS 뷰를 분석 앱에서도 읽을 수 있게 열어 두면 두 화면의 숫자는 같은 원천에서 나옵니다. 표준 뷰의 이름과 필드는 대상 릴리스에서 확인이 필요합니다.

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

CDS 구성

화면이 읽는 서비스의 뒤쪽을 S/4HANA 의 CDS 뷰로 옮긴다면 어떻게 짤지를 코드와 함께 적습니다. 원천은 유니버설 저널(ACDOCA)과 양도 계약 속성이고, 판단에 쓰는 값(범주 정책 · 계정 범주 매핑 · 회사 설정)은 회사가 관리하는 매핑 테이블에 둡니다. 아래 코드는 구조를 보여 주는 참고안이며, 표준 뷰 이름과 필드, 고객사 테이블은 대상 릴리스와 환경에서 확인이 필요합니다.

뷰 레이어 구성

① 매핑 테이블 — 범주 정책과 계정 범주

점검의 출발점은 상환청구 유형과 구성요소가 어느 범주에 놓여야 하는지(정책)와, 손익 계정이 현재 어느 범주에 매핑되어 있는지(장부 기록)입니다. 정책은 회사가 정하는 판단이라 코드에 박지 않고 테이블로 둡니다. 정책이 비어 있는 조합은 판정 보류(확인 필요)로 올라옵니다.

" ─────────────────────────────────────────────────────────────
" ZARFC_POLICY · ZARFC_ACCMAP : 범주 정책과 계정 범주 매핑
" 역할 : 점검 판정의 입력값. 회사가 관리한다.
" 이렇게 나눈 이유 : 정책을 바꿔도 뷰 코드를 고치지 않게 하고, 정책과 원장 라인을 분리해 두려는 것이다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '양도 손익 범주 정책'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zarfc_policy {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  key tr_type   : abap.char(1) not null;   " N 상환청구 없음  R 있음  P 일부
  key comp_type : abap.char(1) not null;   " L 양도 손익  F 수수료  D 할인료
  exp_cat       : abap.char(3);            " OPR 영업  FIN 재무  비면 판정 보류
  valid_from    : abap.dats;
}

@EndUserText.label : '손익 계정 범주 매핑'
@AbapCatalog.deliveryClass : #C
define table zarfc_accmap {
  key client    : abap.clnt not null;
  key bukrs     : bukrs not null;
  key racct     : racct not null;
  comp_type     : abap.char(1);            " 계정이 나타내는 구성요소
  booked_cat    : abap.char(3);            " OPR  INV  FIN  비면 범주 미지정(NON)
}

② 양도 계약 차원 뷰

계약 번호와 상대방, 상환청구 유형, 양도채권액, 연 할인율, 일수는 모든 뷰가 같은 이름으로 써야 하는 속성이라 차원 뷰로 한 번만 정의합니다. 계약 마스터가 없는 환경에서는 업로드 테이블을 같은 이름의 뷰 뒤에서 읽도록 바꿉니다.

" ─────────────────────────────────────────────────────────────
" ZI_ArFactContract : 양도 계약 차원
" 역할 : 계약 단위 속성을 한 곳에서 제공한다.
" 이렇게 나눈 이유 : 건 · 합계 · 쿼리가 같은 계약 이름과 조건을 쓰게 하려는 것이다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '매출채권 양도 계약 차원'
@ObjectModel.representativeKey: 'FactNo'
@Analytics.dataCategory: #DIMENSION
define view entity ZI_ArFactContract
  as select from zarfc_contract              " 고객사 양도 계약 테이블(확인 필요)
{
  key bukrs         as Bukrs,
  key fact_no       as FactNo,
      partner_name  as PartnerName,
      tr_type       as TrType,               " N  R  P
      @Semantics.amount.currencyCode: 'Currency'
      transfer_amt  as TransferAmt,
      ann_rate      as AnnRate,              " 연 할인율(%)
      days          as Days,
      waers         as Currency
}

③ 손익 건 기본 뷰 — 원장 라인에서 건 단위로

이 뷰는 ACDOCA 의 손익 계정 라인 하나를 손익 건 하나로 만들고, 계약과 구성요소, 장부에 기록된 범주를 붙입니다. 원장 라인과 1대1로 맞아야 표준 원장 조회와 대조할 수 있으므로 이 뷰에서는 줄을 늘리거나 합치지 않습니다. 계약 연결은 회사가 쓰는 참조 필드(예: 배정 필드)로 하며, 어느 필드를 쓰는지는 확인이 필요합니다.

" ─────────────────────────────────────────────────────────────
" ZI_ArFactLine : 손익 건 기본 뷰
" 역할 : 원장 라인 하나 = 손익 건 하나. 계약과 기록 범주를 붙인다.
" 이렇게 나눈 이유 : 줄 수를 바꾸지 않아야 원장 라인과 합계를 맞출 수 있다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '양도 손익 건 기본'
define view entity ZI_ArFactLine
  as select from acdoca        as j
    inner join   zarfc_accmap  as m on  m.bukrs = j.rbukrs
                                    and m.racct = j.racct
    inner join   ZI_ArFactContract as c on  c.Bukrs  = j.rbukrs
                                        and c.FactNo = j.zuonr        " 배정 필드로 연결(확인 필요)
{
  key j.rbukrs                       as Bukrs,
  key j.gjahr                        as Gjahr,
  key j.belnr                        as DocNo,
  key j.docln                        as DocLine,
      c.FactNo,
      c.PartnerName,
      c.TrType,
      m.comp_type                    as CompType,
      j.budat                        as PostDate,
      @Semantics.amount.currencyCode: 'Currency'
      j.hsl                          as Amount,     " 지출은 +  (원천 부호 유지)
      j.rhcur                        as Currency,
      case when m.booked_cat is initial then 'NON'
           else m.booked_cat end     as BookedCat
}
where j.rldnr = '0L'
  and j.rbukrs <> ''

④ 재계산 범주와 점검 코드

판정 규칙이 모이는 뷰입니다. 정책 테이블에서 재계산 범주를 읽어 기록 범주와 견주고, 점검 코드와 이동 필요 금액을 만듭니다. 이 뷰 한 곳에만 규칙이 있어서 화면 · 합계 · 대사의 숫자가 같습니다. 일부 상환청구(P)는 정책을 읽지 않고 곧바로 확인 필요로 보냅니다.

" ─────────────────────────────────────────────────────────────
" ZI_ArFactCheck : 재계산 범주 · 점검 코드
" 역할 : 손익 건마다 재계산 범주와 점검 코드를 붙인다.
" 이렇게 나눈 이유 : 규칙을 한 뷰에만 두어 화면 · 분석 · 서비스가 같은 판정을 쓰게 하려는 것이다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '양도 손익 범주 점검'
define view entity ZI_ArFactCheck
  as select from ZI_ArFactLine as l
    left outer join zarfc_policy as p on  p.bukrs     = l.Bukrs
                                      and p.tr_type   = l.TrType
                                      and p.comp_type = l.CompType
{
  key l.Bukrs, key l.Gjahr, key l.DocNo, key l.DocLine,
      l.FactNo, l.PartnerName, l.TrType, l.CompType, l.PostDate,
      l.Amount, l.Currency, l.BookedCat,

      case when l.TrType = 'P'          then ''           " 판정 보류
           else p.exp_cat end           as ExpectCat,

      case
        when l.TrType = 'P'                                       then 'A09'
        when l.BookedCat = 'NON'                                  then 'A05'
        when l.BookedCat = 'INV'                                  then 'A03'
        when l.BookedCat <> p.exp_cat and p.exp_cat = 'OPR'       then 'A01'
        when l.BookedCat <> p.exp_cat and p.exp_cat = 'FIN'       then 'A02'
        else 'A00'
      end                               as CheckCode,

      case when l.TrType <> 'P' and l.BookedCat <> p.exp_cat
           then l.Amount else 0 end     as MoveAmt
}

A04(할인료 금액 차이)는 건 단위가 아니라 계약 단위로 계산하므로 아래 큐브에서 다룹니다. 건 단위 판정이 같은 범주라고 하더라도 금액이 맞는지는 별도 식으로 봐야 하기 때문입니다.

⑤ 계약 · 범주 합계 큐브

합산은 이 큐브 한 곳에서만 합니다. 계약별 영업 · 재무 · 그 밖의 장부 금액과 재계산 금액, 할인료 재계산이 모두 여기서 나오며 대사식의 좌변이 됩니다. 할인료는 양도채권액 × 연 할인율 × 일수 ÷ 365 를 반올림해 다시 구합니다.

" ─────────────────────────────────────────────────────────────
" ZI_ArFactCube : 계약 · 범주 합계 큐브
" 역할 : 건을 계약 · 범주 단위로 합산하고 할인료를 다시 구한다.
" 이렇게 나눈 이유 : 합산을 한 곳에서만 해야 대사 R01 ~ R06 이 의미를 갖는다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '양도 손익 범주 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_ArFactCube
  as select from ZI_ArFactCheck as k
    inner join   ZI_ArFactContract as c on  c.Bukrs  = k.Bukrs
                                        and c.FactNo = k.FactNo
{
  key k.Bukrs, key k.Gjahr, key k.FactNo,
      @Semantics.amount.currencyCode: 'Currency'
      sum( k.Amount )                                              as TotalAmt,
      sum( case when k.BookedCat = 'OPR' then k.Amount else 0 end ) as OprBook,
      sum( case when k.BookedCat = 'FIN' then k.Amount else 0 end ) as FinBook,
      sum( case when k.ExpectCat = 'OPR' then k.Amount else 0 end ) as OprExp,
      sum( case when k.ExpectCat = 'FIN' then k.Amount else 0 end ) as FinExp,
      sum( k.MoveAmt )                                             as MoveAmt,
      sum( case when k.CompType = 'D' then k.Amount else 0 end )    as BookDisc,
      cast( round( c.TransferAmt * c.AnnRate / 100 * c.Days / 365, 0 )
            as abap.curr(15,2) )                                   as CalcDisc,
      count( * )                                                   as LineCnt,
      k.Currency
}
group by k.Bukrs, k.Gjahr, k.FactNo, k.Currency,
         c.TransferAmt, c.AnnRate, c.Days

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

쿼리는 화면이 읽는 이름과 필터를 정리하는 얇은 층입니다. 조회조건에 쓰이는 필드를 선택 파라미터가 아니라 필터 대상으로 열어 두고, 회계연도만 필수로 둡니다. 화면이 바뀌어도 아래 레이어를 건드리지 않게 하는 자리입니다.

" ─────────────────────────────────────────────────────────────
" ZC_ArFactQuery : 분석 쿼리
" 역할 : 화면 요구에 맞춰 이름 · 필터 · 정렬을 정리한다.
" 이렇게 나눈 이유 : 화면 요구가 바뀌어도 판정과 합산 뷰를 건드리지 않게 하려는 것이다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '양도 손익 범주 점검 쿼리'
@Analytics.query: true
@OData.publish: false
define view entity ZC_ArFactQuery
  as select from ZI_ArFactCube
{
  @AnalyticsDetails.query.axis: #FREE
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key Gjahr,
  @Consumption.filter.selectionType: #SINGLE
  key Bukrs,
  key FactNo,
      TotalAmt,
      OprBook, FinBook, OprExp, FinExp,
      MoveAmt,
      BookDisc, CalcDisc,
      BookDisc - CalcDisc as DiscDiff,
      LineCnt
}

⑦ 접근 제어(DCL)

합계만 읽을 수 있는 사람이 건 단위 조회와 합계의 차이로 다른 회사 숫자를 알아내는 일을 막으려면, 건 · 큐브 · 쿼리에 같은 제어를 걸어야 합니다. 회사코드 단위로 권한 오브젝트를 연결하는 예입니다.

" ─────────────────────────────────────────────────────────────
" ZC_ArFactQuery : 접근 제어
" 역할 : 회사코드 단위 접근을 제한한다.
" 이렇게 나눈 이유 : 합계 뷰와 건 뷰의 권한이 달라지면 뺄셈으로 숫자가 드러난다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '양도 손익 범주 점검 접근 제어'
@MappingRole: true
define role ZC_ArFactQuery {
  grant select on ZC_ArFactQuery
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

마지막으로 쿼리와 건 뷰를 서비스로 내보냅니다. 서비스 이름은 화면의 서비스 주소에 쓰이므로 운영 전환 때 화면 설정만 바꾸면 됩니다.

" ─────────────────────────────────────────────────────────────
" ZUI_ArFact : 서비스 정의
" 역할 : 쿼리와 손익 건을 OData 로 게시한다.
" 이렇게 나눈 이유 : 화면은 이 서비스 주소만 알면 된다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '양도 손익 범주 점검 서비스'
define service ZUI_ArFact {
  expose ZC_ArFactQuery as FactSet;
  expose ZI_ArFactCheck as LineSet;
}
"  서비스 바인딩: 이름 ZUI_ARFACT_O2, 바인딩 유형 OData V2 - UI
"  게시 후 /IWFND/MAINT_SERVICE 에서 활성화 상태 확인

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

양도 계약이 수천 건, 손익 건이 수십만 건으로 늘어도 구조는 같지만 집계 위치와 필수 조건이 성능을 좌우합니다. 회계연도와 회사코드는 쿼리의 필수 파라미터로 두고, 원장 라인을 읽는 조건이 인덱스를 타는지 실제 데이터로 확인해야 합니다. 합산은 큐브에서 데이터베이스가 하도록 두고 화면이 손익 건을 모두 내려받지 않게 합니다. 구체 응답 시간은 시스템 구성에 따라 달라 이 글에서는 약속하지 않습니다.

자주 묻는 질문

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

판정 규칙과 숫자

화면과 조작

표준 기능과의 관계

도입과 운영