선적·매출 기간귀속 컷오프 점검 — 선적일과 장부 인식일이 다른 달에 걸린 수출 건을 건마다 가려내는 수출 솔루션 (IFRS 15 통제 이전 시점)

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

수출 매출은 물건이 항구를 떠나는 날과 장부에 매출이 잡히는 날이 같지 않습니다. 선적은 월말에 했는데 청구서는 다음 달 초에 나가고, 도착 조건으로 판 건은 배가 닿은 뒤에야 고객에게 통제가 넘어갑니다. 월마감 때마다 수출 담당과 회계 담당이 같은 질문을 주고받습니다. 이 건의 매출은 어느 달 것인가, 장부에는 몇 월에 잡혀 있나, 둘이 다르면 왜 다른가.

지금은 이 세 답이 판매오더 · 납품 · 청구 · 고객 계정 명세 화면과 선적서류 엑셀에 나뉘어 있어, 건마다 선적일과 청구일과 전기일을 옮겨 적고 인코텀즈를 보며 손으로 견줍니다. 이 앱은 그 대조를 한 화면에 모읍니다. 인코텀즈별로 정한 통제 이전 기준일을 장부 인식일과 월 단위로 비교해 같은 기간 · 선인식 · 지연인식 · 보류로 가르고, 기간마다 어느 달로 매출이 넘어갔는지를 이월 유입 · 유출로 보여 줍니다.

관련 기준은 IFRS 15 고객과의 계약에서 생기는 수익(K-IFRS 제1115호)의 수익 인식 시점(통제 이전)입니다. 외화 매출은 IAS 21 환율변동효과(K-IFRS 제1021호)의 환산 관점을 함께 봅니다. 이 화면은 분류와 집계와 대사를 돕는 점검 도구이며, 원인을 단정하거나 인식 시점을 대신 판단하지 않습니다. 기준일 정책표와 비율 기준은 샘플 가정값이고, 실제 판단은 계약 조건별로 회사와 감사인이 합니다.

선적일과 매출일이 다른 달에 걸리면 결산 숫자가 흔들린다

12월 28일에 선적하고 1월 3일에 청구했다면, 통제가 12월에 넘어갔다고 볼 수 있는 건이 1월 매출로 잡혔는지 확인해야 합니다. 반대로 1월 선적 건을 12월에 미리 청구해 장부에 올렸다면 앞 기간에 먼저 잡힌 것입니다. 한 건씩은 작아도 월말에 몰리면 달 매출이 눈에 띄게 달라집니다. 이 앱은 이런 건을 선인식(앞 기간에 먼저 잡힘)과 지연인식(뒤 기간에 늦게 잡힘)으로 갈라 표시합니다. 이 자료에서는 판정 대상 60건 가운데 선인식이 13건, 지연인식이 9건입니다.

인코텀즈마다 통제가 넘어가는 시점이 다르다

EXW · FCA · FOB · CFR · CIF 는 선적 시점을, DAP 는 도착 시점을 기준으로 두는 것이 이 화면의 샘플 정책입니다. 같은 선적일이라도 DAP 건은 도착일이 다음 달로 넘어가면 기준 기간이 달라집니다. 그래서 건마다 기준일이 무엇인지(선적일인지 도착일인지)를 칸으로 보여 주고, 인코텀즈별로 점검 필요 비율을 따로 집계합니다. 어느 조건에서 점검 대상이 몰리는지 보이면, 건별 확인보다 먼저 정책표를 손볼 자리가 드러납니다.

외화 매출은 합계를 더하는 순간 의미가 흐려진다

수출 매출은 USD · EUR · JPY · CNY 로 섞여 있습니다. 서로 다른 통화의 외화 금액은 더할 수 없으므로, 이 앱은 외화 금액과 환율과 원화 환산 금액을 따로 두고 합계는 원화 환산 금액으로만 냅니다. 환산 대사도 통화별로 따로 해서 어느 통화에서 어긋나는지 곧바로 보입니다. 샘플의 환율은 가정값이며 실제 고시값이 아닙니다.

서류가 아직 오지 않은 건은 틀린 것이 아니라 아직 판단할 수 없는 건이다

선적서류(B/L)가 늦게 와서 선적일이 확정되지 않은 건은 통제 이전 기준일이 없습니다. 이런 건을 억지로 판정하면 점검 필요 건수가 부풀려집니다. 이 앱은 보류로 따로 세워 판정에서 빼고, 대사 결과에는 ‘의도적 예외’로 적어 차이 건수와 섞이지 않게 합니다. 서류가 들어오면 다시 조회해 판정에 들어갑니다. 이 자료에서는 보류가 4건입니다.

사용 방법

1. 조회조건 입력 — 회계연도(필수, 4자리)를 확인하고 필요하면 거래처 · 통화 · 인코텀즈 · 이월 구분 · 선적일 범위 · 판정을 고릅니다. 모두 선택 사항이며 비워 두면 전체입니다.
2. 조회 버튼 · Enter — 조회조건 줄 맨 오른쪽의 조회 버튼을 누르거나 회계연도 · 날짜 입력 칸에서 Enter 키를 누릅니다. 화면을 열면 한 번 자동으로 조회합니다.
3. 요약 확인 — 위쪽 요약(선적 건수 · 판정 대상 · 점검 필요 · 선인식 금액 · 지연인식 금액 · 대사 차이 건수)을 먼저 봅니다.
4. 탭 이동 — 선적 명세 → 기간별 이월 → 인코텀즈별 → 거래처별 → 대사 결과 순서로 옮겨 가며 범위를 좁힙니다.
5. 행 클릭 상세 — 행을 누르면 상세 창이 열립니다. 기간 · 인코텀즈 · 거래처 행은 그 조건에 해당하는 선적 건 목록까지 함께 보여 줍니다.
6. 내보내기 — 오른쪽 위 CSV 내려받기로 현재 탭의 조회 결과를 내려받습니다(UTF-8, 엑셀에서 바로 열림).

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

컷오프 점검에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 만드는 쪽에서 먼저 대사식을 세우고 전수로 돌린 결과입니다. 판정 규칙은 건마다 다시 계산해 화면 값과 견주었습니다.

외화 대사의 최대 차이 0.48원은 건별 원 단위 반올림(0.5원 이내)입니다. 보류 4건은 판정에서 빼고 대사 차이 건수와 분리해 둡니다. 서비스 쪽은 구문 검사와 날짜 조건 걸러내기, 함수 호출 응답까지 확인했고, 화면은 헤드리스 브라우저로 조회 · 탭 이동 · 상세 창 · Enter 조회가 콘솔 오류 없이 도는지 확인했습니다.

무엇으로 만들었나

실행 화면

실제 화면 7종입니다. 사용 순서대로 처음 연 화면 → 조건으로 좁힌 결과 → 기간별 이월과 상세 → 인코텀즈 · 거래처 요약 → 대사 결과를 따라갑니다. 그림을 누르면 크게 볼 수 있습니다. 화면의 거래처와 금액은 검증용 샘플 데이터이며 환율은 가정값입니다.

처음 열었을 때

화면을 열면 회계연도 2026 조건으로 한 번 자동 조회합니다. 요약 여섯 칸이 먼저 차고, 그 아래 선적 명세 표가 이어집니다.

요약은 선적 건수 64 · 판정 대상 60 · 점검 필요 22 · 선인식 금액 3,942.0백만원 · 지연인식 금액 3,490.0백만원 · 대사 차이 0건입니다. 판정 대상은 보류 4건을 뺀 수이고, 금액은 원화 환산 백만원 단위입니다. 조회조건은 모두 선택 사항이라 비워 두면 전체이며, 조회 버튼은 조건 줄의 오른쪽 끝에 있습니다. 점검 필요는 ‘확인할 대상’이라는 뜻이지 오류라는 뜻이 아닙니다.

선인식 건만 골라 보기

이월 구분을 선인식으로 고르고 조회하면 앞 기간에 먼저 잡힌 건만 남습니다. 지연인식도 같은 방식으로 고릅니다.

선인식은 인식 기간이 통제 이전 기준 기간보다 앞선 건입니다. 선적 전에 먼저 인식했거나, 도착일 기준인데 선적일에 인식한 건이 여기 모입니다. 건마다 통제 이전 기준일 · 장부 인식일 · 기간 차이(일) · 판정 내용이 같은 줄에 있어 어느 날짜가 어긋났는지 바로 읽습니다. 판정 내용은 원인을 단정하지 않고 확인할 대상을 알려 줍니다. 초기화 버튼으로 조건을 비우면 다시 전체가 나옵니다.

기간별 이월 — 어느 달에서 어느 달로 매출이 넘어갔는가

선적 단위가 건별 판정이라면, 기간별 이월은 달 단위 요약입니다. 기준 금액에서 출발해 이월 유입을 더하고 유출을 빼면 장부 인식 금액이 되는 식을 달마다 보여 줍니다.

기준 금액 + 이월 유입 − 이월 유출 = 장부 인식 금액이 모든 기간에서 맞아야 하고, 이 식은 대사 결과의 한 줄로도 다시 검산됩니다. 연말 선적 건이 다음 해 1월 장부에 잡힌 경우를 보려고 13번째 기간(2027년 1월)도 함께 둡니다. 점검 필요 표시가 붙은 기간은 그 행을 눌러 어느 건이 달을 넘겼는지 먼저 확인합니다.

상세 창은 기간 요약의 숫자가 어느 건들에서 나왔는지 거꾸로 따라가는 자리입니다. 목록의 합계가 기간 행의 금액과 맞는지 확인하면 됩니다. 인코텀즈 · 거래처 행도 같은 방식으로 열립니다. 닫기 버튼으로 닫습니다.

인코텀즈별 · 거래처별 — 점검 필요가 어디에 몰리는가

건별로 보면 흩어져 있던 점검 대상이 조건별로 묶이면 패턴이 보입니다. 인코텀즈별 점검 필요 비율이 25.00% 이상이거나 거래처별 비율이 40.00% 이상이면 요약 행에 점검 필요가 붙습니다. 두 기준은 샘플 가정값입니다.

DAP 는 도착일을 기준으로 두므로 선인식 건이 상대적으로 많이 잡히고(이 자료에서 7건), CFR 은 지연인식이 많습니다(4건). 이 숫자는 원인을 단정하지 않습니다. 해당 조건의 기준일 증빙과 인식 절차를 확인해 보라는 안내이며, 행을 누르면 그 조건의 선적 건이 열립니다.

평균 기간 차이는 건마다 |장부 인식일 − 통제 이전 기준일| 을 낸 뒤 판정 대상 건에서 평균한 값입니다. 거래처 쪽 기준일 관리(선적서류 수령 시점 등)를 확인할 자리를 고를 때 씁니다. 통화가 거래처마다 하나이므로 외화 금액이 섞이지 않고, 합계는 원화 환산 금액으로만 냅니다.

대사 결과 — 숫자를 믿을 수 있는지 화면이 말한다

대사 결과 탭은 앞의 모든 숫자가 서로 맞는지를 그대로 보여 줍니다.

모든 대사식의 차이 건수가 0 이어야 정상입니다. 외화 환산 대사는 통화별 네 줄로 나뉘고 최대 차이는 건별 반올림 범위(0.5원 이내)입니다. 보류 4건은 판정에서 뺀 것이 맞는지를 확인하는 줄로, 대사 차이와 섞이지 않습니다. 이 탭이 흔들리면 다른 탭의 숫자도 믿기 어렵다는 신호입니다.

화면 뒤에서 일어나는 일

선적 건마다 정책표로 통제 이전 기준일을 정하고, 장부에 매출이 잡힌 날의 기간(월)과 견줍니다. 판정은 아래 표대로 움직이며, 기준일 정책과 비율 기준은 샘플 가정값입니다.

처리 순서는 다음과 같습니다.

1. 건 읽기 — 회계연도 조건으로 선적 건을 읽고, 인코텀즈로 정책표를 찾아 통제 이전 기준일을 정합니다(서류 대기 건은 기준일 없음).
2. 기간 만들기 — 기준일과 장부 인식일 각각의 연월을 기간으로 만들고 두 기간을 비교해 이월 구분(같은 기간 · 선인식 · 지연인식 · 보류)을 붙입니다.
3. 금액 환산 — 외화 금액 × 가정 환율을 건별 원 단위로 반올림해 원화 환산 금액을 만듭니다.
4. 기간별 집계 — 기준 기간별 기준 금액, 인식 기간별 장부 금액, 그 사이의 이월 유입 · 유출을 합산합니다.
5. 조건별 요약 — 인코텀즈별 · 거래처별 건수와 점검 필요 비율을 계산합니다.
6. 대사 — 아래 식으로 서로 맞는지 검산해 대사 결과 탭에 냅니다.

기간 차이(일) = |장부 인식일 − 통제 이전 기준일|
기간별 통제 이전 기준 금액 + 이월 유입 − 이월 유출 = 기간별 장부 인식 금액   (원화 환산 금액 기준)
기간별 기준 금액 합계 = 기간별 장부 금액 합계 = 판정 대상 원화 합계
선적 수량 = 청구 수량 + 미청구 수량
같은 기간 + 선인식 + 지연인식 + 보류 건수 = 전체 선적 건수
외화 금액 × 가정 환율 = 원화 환산 금액   (통화별로 따로 대사, 서로 다른 통화의 외화 금액은 더하지 않음)

조회조건

“전체”를 고르면 코드값을 보내지 않고 그 조건을 $filter 에서 뺍니다. 날짜 조건은 서비스가 직접 걸러 정렬 · 건너뛰기 · 건수 집계까지 처리합니다.

결과 컬럼

탭마다 컬럼이 다릅니다. 선적 명세와 기간별 이월의 주요 컬럼입니다.

좁은 화면에서 달라지는 것

폭 390px 휴대폰 크기로 열어 보면 가로 스크롤 없이 한 열로 쌓입니다. 조회조건은 여러 줄로 접히고 요약 여섯 칸은 두 칸씩 줄을 바꿔 놓입니다. 탭이 폭을 넘으면 ‘더 보기’ 메뉴로 접히며, 표는 표 안에서만 가로로 움직입니다. 넓은 화면에서 보던 모든 탭과 조회조건을 같은 방식으로 쓸 수 있습니다.

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json
├─ controller/   화면 제어(공통 기본 제어 · 메인 제어)
├─ view/         메인 화면 · 상세 창 조각
├─ model/        표시 서식 · 오류 안내
├─ css/          화면 스타일
├─ i18n/         화면 글자(한국어)
├─ odata/<서비스>/   서비스 정의 · 서비스 로직 · 자료 묶음
└─ media/        소개 영상 · 대표 이미지

SAP 표준 기능 확장 포인트 — 표준 T-code 와 어떻게 연계되는지

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 수주 · 납품 · 청구 · 회계 전표를 만드는 일은 표준 거래에 그대로 두고, 이 앱은 그 결과가 남긴 날짜들을 한 줄에 모아 견주는 자리를 더합니다.

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

T-code 별 연계 지점

맞닿은 표준 T-code 마다 이 앱이 어떤 데이터를 이어받고, 두 화면의 숫자를 어디서 맞춰 보며, 표준에 무엇을 남겨 두는지를 정리했습니다.

운영으로 옮긴다고 기존 리포트를 없앨 필요는 없습니다. 법정 보고 · 감사 대응 · 세무 신고에 쓰는 표준 화면과 리포트는 그대로 두고, 이 앱은 월마감 전에 기간귀속을 점검하는 보조 화면으로 함께 둡니다. 두 화면의 숫자가 다를 때는 위 표의 대조 지점부터 맞춰 봅니다.

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

S/4HANA 에서는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 도구로 매출과 청구 현황을 분석할 수 있습니다. 이 앱은 그 분석 스택과 겹치지 않게, 통제 이전 시점과 장부 인식 시점을 건마다 견주는 관점만 더합니다. 같은 원천 테이블(납품 · 청구 · 회계 전표)에서 CDS 큐브를 세우면 분석 쿼리와 Analysis for Office 에서도 같은 숫자를 쓸 수 있습니다. 이 글에서 다룬 구성이 실제 시스템의 어떤 표준 CDS 뷰와 맞닿는지는 릴리스마다 다르므로 확인 필요로 두고, 아래 CDS 구성은 원천 테이블 기준으로 적었습니다.

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

요구사항 매핑표

분석 지표 정의표

CDS 구성

화면에 쓰는 서비스를 운영 시스템에서 CDS 로 세우는 구성입니다. 객체 이름은 기능을 뜻하는 영문으로 지었고, 원천은 표준 테이블 기준으로 적었습니다. 표준 CDS 뷰로 바꿀 수 있는지는 릴리스마다 다르므로 확인 필요입니다.

뷰 레이어 구성

① 기준 테이블 — 인코텀즈별 통제 이전 기준일

컷오프 판정의 출발점은 “이 조건이면 통제가 언제 넘어가는가”입니다. 이 표 한 줄이 같은 인코텀즈의 모든 건에 적용되므로 운영에서 가장 먼저 합의해야 하는 객체입니다. 계약 조건별 예외는 이 표가 아니라 회사 판단 절차로 다룹니다.

" ─────────────────────────────────────────────────────────────────
"  ZSHCUT_POLICY  — 인코텀즈별 통제 이전 기준일 정책
"  역할  : 어느 인코텀즈를 선적일(S)로, 어느 것을 도착일(A)로 볼지 적어 둔다.
"  나눈 이유 : 기준일 판단을 뷰 안에 case 로 박아 두면 정책이 바뀔 때마다
"           뷰를 고쳐 이송해야 한다. 표로 빼 두면 현업이 값만 고친다.
" ─────────────────────────────────────────────────────────────────
@EndUserText.label : '인코텀즈별 통제 이전 기준일 정책'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zshcut_policy {
  key client     : abap.clnt not null;
  key inco1      : inco1 not null;           " EXW · FCA · FOB · CFR · CIF · DAP …
  basis          : abap.char(1) not null;    " S = 선적일, A = 도착일
  valid_from     : abap.dats;                " 정책 적용 시작일
  changed_by     : abap.uname;
}

② 선적 건 기준 뷰 — 날짜와 금액을 한 줄로

납품 · 청구 · 회계 전표를 이어 선적 건마다 선적일 · 도착일 · 청구일 · 장부 전기일 · 외화 금액을 모읍니다. 선적일(B/L 일자)과 도착일은 표준 필드를 확인하지 못해 확인 필요로 표시했고, 맞지 않으면 고객 확장 필드로 받는 자리입니다. 수량은 납품 수량과 청구 수량을 따로 두어 미청구 수량을 구할 수 있게 합니다.

" ─────────────────────────────────────────────────────────────────
"  ZI_ShipCutoffBase  — 선적 건 기준 뷰 (납품 → 청구 → 회계 전표)
"  역할  : 선적 건 하나에 선적일 · 도착일 · 청구일 · 통화 · 금액 · 장부 전기일을
"          한 줄로 모은다. 판정은 여기서 하지 않는다.
"  나눈 이유 : 원천을 잇는 일과 판정하는 일을 나눠 두면, 원천 필드가
"          확인 필요인 두 자리(B/L 일자 · 도착일)만 이 뷰에서 바꾸면 된다.
" ─────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '선적·매출 기간귀속 점검 — 선적 건 기준'
@ObjectModel.usageType: { serviceQuality: #C, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZI_ShipCutoffBase
  as select from likp as d
    inner join   lips as i  on  i.vbeln = d.vbeln
    inner join   vbrp as bp on  bp.vgbel = i.vbeln
                            and bp.vgpos = i.posnr
    inner join   vbrk as bh on  bh.vbeln = bp.vbeln
    inner join   vbak as so on  so.vbeln = bp.aubel
    inner join   vbkd as kd on  kd.vbeln = so.vbeln
                            and kd.posnr = '000000'
    left outer join bkpf as fi on  fi.bukrs = bh.bukrs
                               and fi.belnr = bh.belnr
                               and fi.gjahr = bh.gjahr
{
  key d.vbeln                       as ShipId,
      so.kunnr                      as Customer,
      so.vkorg                      as SalesOrganization,
      kd.inco1                      as Incoterms,
      d.wadat_ist                   as ShipDate,      // B/L 일자는 확인 필요
      d.zz_arrdate                  as ArrivalDate,   // 고객 확장 필드 — 확인 필요
      bh.fkdat                      as BillingDate,
      fi.budat                      as PostingDate,   // 장부 인식일(전기일)
      bh.waerk                      as DocumentCurrency,
      bh.kurrf                      as ExchangeRate,
      @Semantics.amount.currencyCode: 'DocumentCurrency'
      bp.netwr                      as NetAmount,
      @Semantics.quantity.unitOfMeasure: 'SalesUnit'
      i.lfimg                       as ShippedQuantity,
      @Semantics.quantity.unitOfMeasure: 'SalesUnit'
      bp.fkimg                      as BilledQuantity,
      bp.vrkme                      as SalesUnit
}

③ 판정 뷰 — 기준일 · 기간 · 이월 구분

이 뷰가 컷오프 규칙의 전부입니다. 정책표로 기준일을 고르고 두 날짜의 연월을 비교해 이월 구분을 붙입니다. 기준일이 비면 억지로 판정하지 않고 보류로 둡니다. 화면 · 분석 쿼리 · 대사가 모두 이 뷰를 읽으므로 규칙이 바뀌면 여기만 고칩니다.

" ─────────────────────────────────────────────────────────────────
"  ZI_ShipCutoffJudge  — 통제 이전 기준일 · 기간 · 이월 구분 판정
"  역할  : 정책표로 기준일을 고르고, 기준 기간과 인식 기간을 비교해
"          NONE(같은 기간) · EARLY(선인식) · LATE(지연인식) · HOLD(보류)를 붙인다.
"  나눈 이유 : 판정 규칙이 이 뷰 한 곳에만 있어야 화면 · 분석 쿼리 ·
"          대사가 같은 규칙을 쓴다.
" ─────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '선적·매출 기간귀속 점검 — 판정'
define view entity ZI_ShipCutoffJudge
  as select from ZI_ShipCutoffBase as b
    left outer join zshcut_policy  as p on p.inco1 = b.Incoterms
{
  key b.ShipId,
      b.Customer,
      b.SalesOrganization,
      b.Incoterms,
      b.DocumentCurrency,
      b.PostingDate,
      b.NetAmount,

      // ① 통제 이전 기준일 — 정책표가 A 이면 도착일, 아니면 선적일
      case when p.basis = 'A' then b.ArrivalDate
           else b.ShipDate
      end                                                    as TransferDate,

      // ② 두 날짜의 연월(기간)
      substring( cast( case when p.basis = 'A' then b.ArrivalDate
                            else b.ShipDate end as abap.char( 8 ) ), 1, 6 )
                                                             as TransferPeriod,
      substring( cast( b.PostingDate as abap.char( 8 ) ), 1, 6 )
                                                             as RevenuePeriod,

      // ③ 이월 구분 — 기준일이 비어 있으면 판정하지 않고 보류
      case
        when ( p.basis = 'A' and b.ArrivalDate is initial )
          or ( coalesce( p.basis, 'S' ) = 'S' and b.ShipDate is initial )
                                                             then 'HOLD'
        when substring( cast( b.PostingDate as abap.char( 8 ) ), 1, 6 )
           = substring( cast( case when p.basis = 'A' then b.ArrivalDate
                                   else b.ShipDate end as abap.char( 8 ) ), 1, 6 )
                                                             then 'NONE'
        when substring( cast( b.PostingDate as abap.char( 8 ) ), 1, 6 )
           < substring( cast( case when p.basis = 'A' then b.ArrivalDate
                                   else b.ShipDate end as abap.char( 8 ) ), 1, 6 )
                                                             then 'EARLY'
        else 'LATE'
      end                                                    as CutType
}

④ 큐브 — 건별 환산 후 기간별 집계

원화 환산은 집계하기 전에 건별로 합니다. 통화가 섞인 금액을 먼저 더하면 어느 통화에서 어긋났는지 알 수 없기 때문입니다. 환율 유형은 샘플의 가정 환율 자리를 대신해 회계팀이 정하는 값입니다.

" ─────────────────────────────────────────────────────────────────
"  ZI_ShipCutoffPeriodCube  — 기간별 이월 큐브(원화 환산 포함)
"  역할  : 건별 원화 환산 금액을 만들고, 기준 기간 · 인식 기간별로 집계해
"          기준 + 이월 유입 − 이월 유출 = 장부 식이 나오게 한다.
"  나눈 이유 : 환산을 집계 전에 건별로 해야 통화별 대사와
"          원 단위 반올림 차이를 설명할 수 있다.
" ─────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '기간별 이월 큐브'
define view entity ZI_ShipCutoffPeriodCube
  as select from ZI_ShipCutoffJudge as j
{
  key j.TransferPeriod,
  key j.RevenuePeriod,
  key j.CutType,
  key j.SalesOrganization,
  key j.Incoterms,
  key j.Customer,
      cast( 'KRW' as abap.cuky )                              as DisplayCurrency,

      @Semantics.amount.currencyCode: 'DisplayCurrency'
      sum( currency_conversion(
             amount             => j.NetAmount,
             source_currency    => j.DocumentCurrency,
             target_currency    => cast( 'KRW' as abap.cuky ),
             exchange_rate_date => j.PostingDate,
             exchange_rate_type => 'M',           // 환율 유형은 회계팀이 정한다
             error_handling     => 'SET_TO_NULL' ) )          as AmountKrw,

      @DefaultAggregation: #SUM
      count( distinct j.ShipId )                              as ShipmentCount
}
where j.CutType <> 'HOLD'                 // 보류 건은 판정 · 집계에서 뺀다
group by j.TransferPeriod, j.RevenuePeriod, j.CutType,
         j.SalesOrganization, j.Incoterms, j.Customer

⑤ 분석 쿼리 — 축과 필터

큐브 위에 기간 · 이월 구분 · 인코텀즈 · 거래처 축과 필터를 올립니다. 어노테이션 이름과 조합은 릴리스에 따라 다를 수 있어 시스템에서 확인이 필요합니다.

" ─────────────────────────────────────────────────────────────────
"  ZC_ShipCutoffQuery  — 분석 쿼리(Consumption)
"  역할  : 기간 · 인코텀즈 · 거래처 축과 필터를 정해 화면과 분석 도구가
"          같은 조회 조건으로 읽게 한다.
"  나눈 이유 : 큐브는 재사용하고 보는 방식(축 · 필터 · 표시 순서)만
"          쿼리에서 바꾼다. 어노테이션 세트는 릴리스마다 다르므로
"          시스템에서 확인 필요.
" ─────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '선적·매출 기간귀속 컷오프 점검'
@Analytics.query: true
@VDM.viewType: #CONSUMPTION
define view entity ZC_ShipCutoffQuery
  as select from ZI_ShipCutoffPeriodCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @UI.selectionField: [{ position: 10 }]
  @Consumption.filter: { selectionType: #RANGE, mandatory: true }
  TransferPeriod,

  @AnalyticsDetails.query.axis: #COLUMNS
  @Consumption.filter.selectionType: #SINGLE
  CutType,

  @AnalyticsDetails.query.axis: #ROWS
  @UI.selectionField: [{ position: 20 }]
  @Consumption.filter.selectionType: #MULTIPLE
  Incoterms,

  @AnalyticsDetails.query.axis: #ROWS
  @UI.selectionField: [{ position: 30 }]
  Customer,

  @AnalyticsDetails.query.axis: #COLUMNS
  @AnalyticsDetails.query.decimals: 0
  AmountKrw,

  @AnalyticsDetails.query.axis: #COLUMNS
  ShipmentCount
}

⑥ 접근 제어 — 영업조직별 범위

권한은 쿼리에 거는 접근 제어에서 제한합니다. 권한 객체와 필드는 회사의 권한 설계에 맞춰 정하며, 아래는 영업조직 기준 예시입니다.

" ─────────────────────────────────────────────────────────────────
"  ZC_ShipCutoffQuery 의 접근 제어(DCL)
"  역할  : 영업조직별로 볼 수 있는 건을 제한한다.
"  나눈 이유 : 권한을 화면이 아니라 데이터 쪽에 걸어야
"          표·상세·내려받기가 같은 범위만 보여 준다.
" ─────────────────────────────────────────────────────────────────
@EndUserText.label: '선적·매출 기간귀속 점검 — 영업조직 권한'
@MappingRole: true
define role ZC_ShipCutoffQuery {
  grant select on ZC_ShipCutoffQuery
    where ( SalesOrganization ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );
}

⑦ 서비스 정의 — 화면이 부르는 이름

서비스 정의에서 엔티티셋 이름이 정해집니다. 바인딩은 ADT 에서 OData V2 로 게시하고, 화면 쪽은 서비스 주소만 바꿉니다.

" ─────────────────────────────────────────────────────────────────
"  ZUI_ShipCutoff  — Service Definition (Binding 은 ADT 에서 OData V2 로 게시)
"  역할  : 쿼리를 서비스로 내보낸다. 화면이 부르는 엔티티셋 이름이 여기서 정해진다.
"  나눈 이유 : 화면의 manifest 는 서비스 주소만 알면 되므로,
"          운영 전환은 서비스 바인딩을 게시하고 주소를 바꾸는 일로 끝난다.
" ─────────────────────────────────────────────────────────────────
@EndUserText.label: '선적·매출 기간귀속 컷오프 점검 서비스'
define service ZUI_ShipCutoff {
  expose ZC_ShipCutoffQuery as ShipCutoffSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 앞쪽 항목이 정해져야 숫자가 기존 보고서와 맞기 시작합니다.

운영 데이터로 갈 때

선적 건이 연간 수천 건인 샘플과 달리, 운영에서는 납품 · 청구 · 회계 전표가 수백만~수천만 건이 될 수 있습니다. 먼저 회계연도와 기간을 필수 조건으로 두어 큐브가 읽는 범위를 좁힙니다. 집계는 화면이 아니라 CDS 큐브에서 하고, 건별 목록은 조회 조건이 걸린 뒤에만 불러옵니다. 납품 · 청구 · 전표를 잇는 조건에 쓰는 키에는 인덱스 영향을 점검하고, 응답 시간은 “기간 한 달 조회 몇 초 이내”처럼 회사가 기준을 정해 두었다가 시험 환경에서 실제 자료로 재어 봅니다. 구체적인 수치는 시스템 사양에 따라 달라 확인이 필요합니다.

자주 묻는 질문

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

숫자와 판정 규칙

화면과 조작

데이터와 정합성

도입과 운영