수입 선급금 정산 점검 — 먼저 보낸 선급금이 선적 송장에 얼마나 정산됐는지 건마다 가려내는 수입 솔루션 화면

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

수입 담당자가 선급금을 보내는 순간부터 그 돈이 송장에 다 정산될 때까지는 짧게는 몇 주, 길게는 반년이 걸립니다. 그 사이 질문은 늘 같습니다. 보낸 선급금 가운데 얼마가 아직 남아 있나, 선적이 끝났는데도 남은 건은 없나, 어느 송장에 얼마를 정산했나. 지금은 이 답이 발주 화면 · 송장 전표 · 공급업체 개별 항목 · 엑셀 대장에 흩어져 있어, 한 건을 확인하려면 화면을 네댓 번 오가야 합니다.

이 앱은 그 흩어진 답을 선급금 지급 건 한 줄에 모읍니다. 지급액 · 정산액 · 반환액 · 잔액을 외화와 원화로 나란히 놓고, 지급 후 경과일과 계약 선적기일 경과일을 계산해, 건마다 ‘정상 · 주의 · 점검 필요’를 판정합니다. 판정은 오류를 단정하는 것이 아니라 먼저 들여다볼 건을 고르는 일입니다. 표준 실행(선급금 요청 · 전기 · 정산)은 SAP 표준 T-code 가 그대로 담당하고, 이 화면은 조회와 검증의 관점을 더해 확장합니다.

정산이 끝난 줄 알았는데 잔액이 남아 있다

선적과 송장 정산이 모두 끝난 발주에 선급금 잔액이 남아 있는 경우가 있습니다. 표준 화면에서는 발주 하나, 공급업체 하나씩 열어야 보이기 때문에 결산 직전에야 발견되곤 합니다. 이 앱은 발주의 선적 누계가 발주 금액에 이른 뒤에도 잔액이 남은 건을 SHIP 판정으로 따로 가려, 정산하거나 돌려받을 대상을 한 번에 보여 줍니다. 이 사례 자료에는 4건이 걸립니다.

송장 금액보다 많이 정산된 줄은 합계에 묻힌다

정산 합계만 보면 선급금 안에서 끝난 것처럼 보여도, 한 송장에 그 송장 금액보다 큰 선급금이 정산된 줄이 섞여 있을 수 있습니다. 합계는 맞고 줄은 틀린 경우입니다. 이 앱은 정산 이력의 줄마다 송장 금액과 비교해 LINE 판정을 내리고, 지급액보다 정산과 반환이 많은 건은 OVER 판정으로 가립니다. 이 사례 자료에서는 줄 단위 2건, 건 단위 3건이 드러납니다.

계약 선적기일을 넘긴 선급금은 날짜를 계산해야 보인다

선급금은 선적을 전제로 보낸 돈이라 선적기일이 지나도록 잔액이 남아 있으면 일정부터 확인해야 합니다. 그런데 기일 초과일은 어느 화면에도 숫자로 적혀 있지 않아 달력과 엑셀로 계산해 왔습니다. 이 앱은 기준일에서 계약 선적기일을 뺀 초과일을 건마다 계산해 DUE 판정과 함께 보여 주고, 지급 후 120일을 넘긴 건과 발주 대비 선급 비율이 30%를 넘는 건은 ‘주의’로 따로 표시합니다(두 기준은 가정값이며 회사 규정에 맞게 바꿉니다).

통화가 섞이면 합계가 의미를 잃는다

USD · EUR · JPY · CNY 선급금을 한 열에 더하면 무엇을 더한 숫자인지 알 수 없습니다. 이 앱은 외화 금액은 통화별로만 집계하고, 요약 숫자는 지급일 환율로 환산한 원화를 따로 둡니다. 두 숫자는 같은 선급금에서 나오므로 서로 맞춰 볼 수 있습니다. 환율 평가와 환차손익은 이 화면의 범위가 아닙니다.

사용 방법

1. 조회조건 입력 — 통화 · 점검 상태 · 발주 번호(앞부분) · 지급일 범위를 고릅니다. 모두 선택 사항이며 비워 두면 그 조건은 걸리지 않습니다.
2. 조회 버튼 또는 Enter 키 — 조회 버튼은 조회조건 줄 오른쪽에 있고, 입력 칸에서 Enter 를 눌러도 같은 조회가 됩니다. 화면을 처음 열 때는 자동으로 한 번 조회합니다.
3. 요약 숫자 확인 — 선급금 건수 · 선급금 · 정산 · 반환 · 잔액 · 초과 정산(원화)과 점검 필요 건수를 위쪽 숫자에서 봅니다.
4. 탭 이동 — 선급금 명세 → 발주별 → 통화별 → 경과 구간별 → 정산 이력 → 대사 결과 순서로 넓은 곳에서 좁은 곳으로 봅니다.
5. 행 선택으로 상세 — 발주별 · 선급금 명세 · 정산 이력의 행을 누르면 발주 상세 창이 열려 지급 건과 정산 · 반환 이력을 함께 봅니다. 통화별 · 경과 구간별 행을 누르면 그 통화로 선급금 명세를 다시 조회합니다.
6. CSV 내려받기 — 화면 아래 버튼으로 지금 보고 있는 탭을 UTF-8 CSV 로 내려받습니다.

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

선급금 점검에서 가장 비싼 질문은 “이 잔액 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 이 사례 자료 전체에 돌렸습니다. 아래는 그 결과입니다.

일곱 가지 대사가 모두 차이 0 이고 최대 차이는 0원입니다. 이 자료에는 점검 대상이 일부러 섞여 있습니다 — 정산 초과 3건 · 송장 초과 정산 2건 · 선적 완료 뒤 잔액 4건 · 선급 비율 초과 2건이 그것이며, 이것은 대사가 어긋난 것이 아니라 판정이 가려내야 할 건이라 차이 건수와 따로 적습니다. 화면 쪽은 별도로 브라우저 자동화로 확인했습니다 — 요약 숫자가 대사 결과의 좌변과 같은지, 행을 눌렀을 때 상세 창의 합계가 그 발주와 같은지, 조회조건이 요청에 그대로 실리는지를 다시 잽니다.

무엇으로 만들었나

실행 화면

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

처음 열었을 때와 점검 대상 고르기

요약 숫자 일곱 칸과 선급금 명세가 먼저 서고, 조회조건으로 점검 필요 건만 좁힙니다.

위쪽 줄은 조회조건이고 그 아래가 요약 숫자 일곱 칸입니다. 선급금 건수 65건, 선급금 7,114,884,274원, 정산 3,852,030,624원, 반환 340,808,767원, 잔액 2,922,044,883원, 초과 정산 63,027,211원, 점검 필요 27건이 처음 열자마자 보입니다. 기본 탭은 선급금 명세이며 지급일 최근 순으로 정렬됩니다. 원화 숫자는 모두 지급일 환율로 환산한 값입니다.

조회조건의 점검 상태를 바꾸고 조회 버튼(또는 입력 칸에서 Enter)을 누르면 표가 점검 필요 건만 남깁니다. 사유 열의 문장이 “지급 후 몇 일 경과”, “선적기일을 며칠 넘김”처럼 무엇을 확인하라는 것인지 말해 줍니다. 초기화 버튼을 누르면 조건이 비워지고 전체 65건으로 돌아옵니다.

넓은 곳에서 좁은 곳으로

발주별 → 통화별 → 경과 구간별 순으로 같은 선급금을 다른 단면으로 봅니다.

선급금이 여러 차에 걸쳐 나간 발주는 이 탭에서 한 줄로 읽힙니다. 선급 비율은 발주별 선급금 합계를 발주 금액으로 나눈 값이고, 선적률은 선적 누계를 발주 금액으로 나눈 값입니다. 선적률이 100%에 이르렀는데 잔액이 남아 있으면 SHIP 판정으로 점검 필요에 올라옵니다. 행을 누르면 발주 상세 창이 열립니다.

USD · EUR · JPY · CNY 네 줄이며 통화마다 지급 건수 · 외화 잔액 · 원화 환산 잔액 · 평균 지급 환율 · 기일 경과 건수 · 점검 건수가 있습니다. 행을 누르면 그 통화로 조건을 채워 선급금 명세 탭이 다시 조회됩니다.

0~30일 · 31~60일 · 61~90일처럼 구간을 세로로, 통화를 가로로 둔 모양입니다. 오래 묵은 잔액이 어느 구간에 몰려 있는지 한눈에 보이며, 구간 합계는 통화별 미정산 잔액과 같아야 합니다(초과 정산분은 구간에서 제외하고 그 차이를 대사 결과에서 설명합니다). 행을 누르면 그 통화의 선급금 명세로 이동합니다.

이력과 상세 — 숫자의 근거까지

정산 · 반환 이력과 발주 상세에서 한 건의 흐름을 따라갑니다.

구분 열이 정산 또는 반환이고, 정산 줄에는 대상 선적 번호와 그 송장 금액이 함께 있어 정산액이 송장 금액을 넘는지 줄 단위로 비교됩니다. 넘는 줄은 LINE 판정으로 점검 필요에 올라갑니다. 행을 누르면 해당 발주의 상세 창이 열립니다.

제목에 발주 번호를 두고, 위쪽 요약 칸에 거래처 · 통화 · 발주 금액 · 선급금과 선급 비율 · 정산과 반환 · 잔액 · 선적 누계와 선적률 · 계약 선적기일과 최장 경과일 · 점검 결과를 놓았습니다. 그 아래에 선급금 지급 건 표와 정산 · 반환 이력 표가 이어집니다. 이 화면은 정산액이 지급액을 넘은 발주라 잔액이 음수로 나오고 OVER 판정이 붙어 있습니다. 지급 건 표와 이력 표를 같은 창에 두어 서로 합계를 맞춰 볼 수 있습니다.

대사 결과 — 화면 숫자가 맞는가

일곱 가지 대사로 화면의 모든 합계를 서로 맞춰 봅니다.

이 탭은 “화면 숫자가 맞는가”에 대한 답입니다. 대사마다 산식과 좌우변 금액, 검사한 건수, 차이 건수, 그리고 판정이 가려낸 점검 대상 건수가 나란히 있습니다. 점검 대상은 대사 차이가 아니라 판정 결과이므로 차이 건수 0 과 나란히 놓여도 모순이 아닙니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 조회조건을 표준 필터와 정렬로 바꿔 서비스에 보냅니다. 통화와 점검 상태는 같음 조건, 발주 번호는 앞부분 일치, 지급일 범위는 같은 항목의 시작과 끝 두 조건을 하나의 AND 묶음으로 보냅니다. 서비스는 판정과 환산을 마친 값을 건수와 함께 돌려주고, 화면은 그 값을 표에 붙이기만 합니다. 요약 숫자 일곱 칸도 서비스가 돌려준 지급 건 전체를 한 곳에서 합산해 만들기 때문에 탭을 오가도 합계가 갈라지지 않습니다.

점검 판정 규칙

판정은 아래 순서로 보고, 먼저 맞는 조건 하나가 그 건의 상태가 됩니다. 판정은 점검 대상을 가리는 용도이며 원인을 단정하지 않습니다.

이 사례 자료의 65건은 정상 33건, 주의 5건(AGED 3 · RATIO 2), 점검 필요 27건(DUE 18 · SHIP 4 · OVER 3 · LINE 2)으로 갈립니다. 허용 경과일 120일과 선급 비율 한도 30%는 가정값이며, 운영에서는 회사 규정의 값을 기준 테이블에 넣습니다.

산출 순서

1. 선급금(외화) = 정산(외화) + 반환(외화) + 잔액(외화)
2. 선급금 · 정산 · 반환(원화) = 외화 × 지급일 환율(반올림), 잔액(원화) = 선급금 − 정산 − 반환
3. 경과일 = 기준일 − 지급일(잔액이 남은 건만), 기일 초과일 = 기준일 − 선적기일
4. 선급 비율 = 발주별 선급금 합계 ÷ 발주 금액 × 100
5. 경과 구간 합계 = 통화별 미정산 잔액 합계(초과 정산분 제외)

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

이 화면은 업무용 데스크톱 화면을 기준으로 만들었고 휴대폰 전용 화면은 따로 두지 않았습니다. 창 폭이 줄면 조회조건과 요약 숫자 칸은 줄을 바꿔 아래로 쌓이고, 표는 칸 폭을 지킨 채 가로로 밀어 볼 수 있습니다. 표는 한 번에 여섯 줄을 보여 주고 그 아래는 스크롤로 이어지므로, 좁은 창에서는 탭과 조회조건으로 먼저 범위를 줄이는 쪽이 편합니다.

파일 구성

화면 진입 · 설명서        index.html · readme.html · Component.js · manifest.json
controller/              화면 제어 (조회 · 집계 · 상세 · CSV)
view/                    화면 정의 · 발주 상세 창
model/                   표시 형식 · 오류 안내
css/ · i18n/             스타일 · 한국어 문구
odata/                   서비스 정의(메타데이터) · 서비스 구현 · 갈래별 데이터
media/                   소개 영상 · 포스터

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 화면을 없애야 하느냐”는 질문이 꼭 나오는데, 없애지 않고 둡니다. 실행과 감사 대응은 표준 거래가 맡는 편이 안전하고, 이 앱은 그 앞에서 ‘어느 건을 열어 볼지’를 정하는 데 씁니다.

오가는 방법은 단순합니다. 이 앱에서 점검 필요 건을 찾으면 발주 번호를 복사해 ME23N 에서 발주를, FBL1N 에서 잔액을 확인합니다. 반대로 표준 화면에서 의심스러운 발주를 만나면 이 앱의 조회조건에 발주 번호 앞부분을 넣어 정산 이력과 판정을 한 번에 봅니다. 법정 · 감사 · 세무 신고 대응은 표준 거래와 회사의 절차에 그대로 남겨 둡니다.

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

S/4HANA 에서는 CDS 분석 쿼리와 Fiori 분석 화면으로 구매 · 지급 현황을 볼 수 있습니다. 이 앱의 점검 로직은 그 아래 층(CDS 뷰)에 그대로 내려 앉도록 만들었습니다 — 판정과 환산을 화면이 아니라 서비스가 하므로, 운영에서는 서비스 구현만 CDS 기반 OData 서비스로 바꾸고 화면은 그대로 둡니다. 표준 Fiori 분석 앱의 이름과 범위는 릴리스마다 달라 이 글에서는 단정하지 않으며, 도입 전에 고객사 시스템에서 확인합니다(확인 필요). Analysis for Office 같은 도구로 같은 CDS 쿼리를 읽는 것도 가능합니다.

분석 지표 정의

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

CDS 구성

이 사례의 화면은 샘플 서비스가 돌려준 값을 그대로 보여 줍니다. 운영에서는 그 서비스를 CDS 위의 OData 서비스로 바꿔 끼우며, 아래는 그때 만드는 객체들을 레이어 순서대로 적은 것입니다. 코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 하며, 확인이 필요한 자리는 주석에 적었습니다.

뷰 레이어 구성

① 판정 기준 파라미터 테이블

리포트의 판정이 이 테이블에서 갈립니다. 허용 경과일과 선급 비율 한도를 코드에 박으면 규정이 바뀔 때마다 개발자를 불러야 하므로, 회사코드별 · 유효기간별 값으로 빼 둡니다. 운영 전환에서 가장 먼저 합의해야 하는 항목입니다.

" ────────────────────────────────────────────────────────────────
"  ZIMP_ADVCFG — 선급금 점검 판정 기준 (투명 테이블)
"  역할    : 회사코드별 허용 경과일 · 선급 비율 한도를 보관한다.
"  나눈 이유: 규정이 바뀔 때 값만 고치고 이송(TR)으로 옮기기 위해서다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '선급금 점검 판정 기준'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zimp_advcfg {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;          " 회사코드
  key valid_from : abap.dats not null;      " 유효 시작일
  valid_to       : abap.dats;
  aged_days      : abap.int4;               " 지급 후 허용 경과일 (샘플 120)
  ratio_limit    : abap.dec(5,2);           " 발주 대비 선급 비율 한도 % (샘플 30)
  spl_gl_ind     : umskz;                   " 선급 항목 특별 G/L 지시자 (확인 필요)
}

② 선급금 지급 건 뷰

지급 건 한 줄이 만들어지는 자리입니다. 선급 항목 전표와 발주를 한 번만 연결해 두면 이후 모든 뷰가 이 뷰 하나를 봅니다. S/4HANA 에서는 호환 뷰보다 ACDOCA 기준이 맞는 경우가 많아 아래 원천은 스케치이며, 실제 필드는 View Browser(F2170)로 확인합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ImpAdvDownPay — 선급금 지급 건 (기본 뷰)
"  역할    : 선급 항목 전표 한 줄 = 지급 건 한 줄. 발주 · 통화 · 환율 포함.
"  나눈 이유: 전표 ↔ 발주 연결을 여기서 한 번만 정의한다.
"  확인 필요: 특별 G/L 선급 항목 원천(BSEG / ACDOCA)은 릴리스에 따라 다름.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '선급금 지급 건'
@ObjectModel.usageType: { serviceQuality: #X, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZI_ImpAdvDownPay
  as select from bseg
  inner join   ekko on ekko.ebeln = bseg.ebeln
{
  key bseg.bukrs                            as CompanyCode,
  key bseg.belnr                            as AccountingDocument,
  key bseg.gjahr                            as FiscalYear,
  key bseg.buzei                            as AccountingDocumentItem,
      bseg.ebeln                            as PurchaseOrder,
      ekko.lifnr                            as Supplier,
      bseg.pswsl                            as TransactionCurrency,
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      bseg.pswbt                            as DownPayAmountFc,
      bseg.h_budat                          as PostingDate,
      bseg.umskz                            as SpecialGLIndicator
}
where bseg.koart = 'K'
  and bseg.umskz = 'A'            " 선급금(공급업체 특별 G/L) — 값은 회사 설정에 맞춘다

③ 정산 · 반환 이력 뷰

정산과 반환을 한 뷰에 두고 구분 열로 가릅니다. 정산 줄에는 대상 송장 금액을 함께 두어야 LINE 판정(송장 금액 초과)이 가능하므로, 송장 검증 전표와의 연결을 여기서 정의합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ImpAdvSettle — 선급금 정산 · 반환 이력
"  역할    : 구매 오더 이력 중 선급금 정산 줄과 송장 금액을 한 줄로.
"  나눈 이유: 정산 줄 ↔ 송장 금액 비교를 쿼리가 아니라 뷰에서 보장한다.
"  확인 필요: 이력 구분(VGABE) 값과 선급금 정산 식별 방법.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '선급금 정산 이력'
define view entity ZI_ImpAdvSettle
  as select from ekbe
  left outer join rseg
    on  rseg.belnr = ekbe.belnr
    and rseg.gjahr = ekbe.gjahr
    and rseg.buzei = ekbe.buzei
{
  key ekbe.ebeln                            as PurchaseOrder,
  key ekbe.zekkn                            as AccountAssignment,
  key ekbe.belnr                            as ReferenceDocument,
  key ekbe.buzei                            as ReferenceDocumentItem,
      ekbe.budat                            as SettlementDate,
      ekbe.waers                            as DocumentCurrency,
      @Semantics.amount.currencyCode: 'DocumentCurrency'
      ekbe.wrbtr                            as SettleAmountFc,
      @Semantics.amount.currencyCode: 'DocumentCurrency'
      rseg.wrbtr                            as InvoiceAmountFc,
      case ekbe.shkzg when 'S' then 'SETTLE'
                      else 'REFUND' end     as SettleKind        " 정산 / 반환 구분은 확인 필요
}
where ekbe.vgabe = '2'            " 송장 입고 이력 — 선급금 정산 식별 조건 추가 필요

④ 큐브 — 잔액 · 경과일 · 원화 환산

화면이 계산하던 일을 DB 로 내리는 자리입니다. 정산과 반환을 지급 건에 합산하고, 지급일 환율로 원화를 환산한 뒤 잔액을 마지막에 차감으로 구합니다. 이렇게 해야 지급 = 정산 + 반환 + 잔액 항등식이 1원도 어긋나지 않습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ImpAdvOpenCube — 지급 건 단위 큐브 (정산 · 반환 · 잔액 · 경과일)
"  역할    : 지급 건에 정산 · 반환을 합산하고 지급일 환율로 원화 환산.
"  나눈 이유: 판정 쿼리가 합산을 다시 하지 않게 하고, 항등식을 한 곳에서 보장.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '선급금 잔액 큐브'
define view entity ZI_ImpAdvOpenCube
  as select from ZI_ImpAdvDownPay as d
  association [0..*] to ZI_ImpAdvSettle as _Settle
    on _Settle.PurchaseOrder = $projection.PurchaseOrder
{
  key d.CompanyCode,
  key d.AccountingDocument,
  key d.FiscalYear,
  key d.AccountingDocumentItem,
      d.PurchaseOrder,
      d.Supplier,
      d.TransactionCurrency,
      d.PostingDate,
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      @DefaultAggregation: #SUM
      d.DownPayAmountFc,
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      @DefaultAggregation: #SUM
      cast( 0 as abap.curr(15,2) )          as SettledAmountFc,   " _Settle 합산으로 대체 (스케치)
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      @DefaultAggregation: #SUM
      cast( 0 as abap.curr(15,2) )          as RefundAmountFc,
      dats_days_between( d.PostingDate, $session.system_date ) as AgeDays,
      _Settle
}

⑤ 분석 쿼리 — 판정 코드

판정 순서(OVER → LINE → SHIP → DUE → AGED → RATIO → OK)가 정의되는 자리입니다. 화면 · 배치 · 다른 앱이 같은 판정을 얻으려면 판정은 이 쿼리의 case 식 하나에만 있어야 합니다.

" ────────────────────────────────────────────────────────────────
"  ZC_ImpAdvCheckQuery — 점검 판정 쿼리 (Consumption)
"  역할    : 큐브 위에 점검 코드와 상태를 계산해 서비스에 노출.
"  나눈 이유: 판정 규칙을 한 곳에 두어 화면 · 배치가 같은 결과를 얻게 한다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@Analytics.query: true
@EndUserText.label: '선급금 점검 판정'
@UI.headerInfo: { typeName: '선급금', typeNamePlural: '선급금' }
define view entity ZC_ImpAdvCheckQuery
  as select from ZI_ImpAdvOpenCube as c
  inner join     zimp_advcfg       as cfg on cfg.bukrs = c.CompanyCode
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: false }
  key c.PurchaseOrder,
  key c.AccountingDocument,
      @Consumption.filter.selectionType: #SINGLE
      c.TransactionCurrency,
      @AnalyticsDetails.query.axis: #COLUMNS
      c.DownPayAmountFc,
      c.AgeDays,
      case
        when c.SettledAmountFc + c.RefundAmountFc > c.DownPayAmountFc then 'OVER'
        when c.AgeDays > cfg.aged_days                                  then 'AGED'
        else 'OK'
      end                                   as CheckCode          " 전체 순서는 본문 판정 표 참조
}

⑥ 접근 제어 (DCL)

권한은 집계를 읽는 자리에 걸어야 합니다. 상세 화면에만 걸면 합계에서 뺄셈으로 다른 범위의 숫자가 새어 나갑니다.

" ────────────────────────────────────────────────────────────────
"  ZC_ImpAdvCheckQuery — DCL
"  역할    : 회사코드 단위로 조회 범위를 제한한다.
"  확인 필요: 구매 조직 · 공급업체 그룹 권한 객체를 쓸지 여부.
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '선급금 점검 접근 제어'
@MappingRole: true
define role ZC_ImpAdvCheckQuery {
  grant select on ZC_ImpAdvCheckQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의

화면이 부르는 OData 서비스의 노출 범위를 정합니다. 샘플 서비스와 같은 모양의 여섯 갈래 조회를 노출하면 화면은 서비스 주소만 바꿔 그대로 동작합니다.

" ────────────────────────────────────────────────────────────────
"  ZSD_ImpAdvPayCheck — 서비스 정의
"  역할    : 점검 쿼리를 OData 로 노출한다. 바인딩(V2)은 Service Binding 에서 게시.
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '수입 선급금 정산 점검 서비스'
define service ZSD_ImpAdvPayCheck {
  expose ZC_ImpAdvCheckQuery as AdvanceCheck;
  expose ZI_ImpAdvSettle     as AdvanceSettle;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 코딩이 아니라 합의로 끝나는 항목들입니다.

운영 데이터로 갈 때

샘플은 선급금 65건이지만 운영에서는 전표 · 구매 오더 이력이 수백만 건이 될 수 있습니다. 먼저 집계와 판정을 CDS 로 내려 화면이 받는 행 수를 지급 건 단위로 줄입니다. 지급일 범위나 회사코드를 필수 조건으로 두어 전체 조회를 막고, 원천 테이블의 조회 조건 필드에 맞는 인덱스를 확인합니다. 응답 시간 기준(예: 조회 5초 이내)은 도입 전에 정해 두고, 이를 넘으면 구체화 뷰나 미리 집계한 테이블을 검토합니다. 요약 숫자 일곱 칸은 서비스가 합계를 따로 돌려주도록 바꾸는 것이 좋습니다.

자주 묻는 질문

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

숫자와 판정

화면과 사용

SAP 표준과의 관계

도입과 운영