은행 미결 항목 경과 정리 점검 — 남은 항목이 얼마나 오래됐는지 기한 초과 · 정리 누락 후보 · 장기 미결까지 가려내는 월마감 자금 회계(자금 솔루션)

도입 포인트 — 이 앱을 사용해야 하는 이유

월마감이 가까워지면 자금 담당자는 같은 질문에 다시 답해야 합니다. 은행 잔액과 장부 잔액이 다른데, 그 차이를 이루는 항목이 무엇이고 얼마나 오래 남아 있나. 입금했다고 적었지만 은행에는 아직 없는 돈, 지급했다고 기표했지만 상대가 아직 현금화하지 않은 수표, 은행에는 찍혔는데 장부에는 없는 입금과 출금 — 이 네 가지가 은행 계좌 대사의 “남은 항목”입니다. 합계는 맞춰 볼 수 있어도, 항목마다 언제부터 남아 있는지는 어느 화면에도 한눈에 나오지 않습니다.

지금 방식은 은행 명세, 계정 라인 아이템, 엑셀 대사표를 번갈아 열어 항목마다 발생일을 찾고 기준일에서 빼는 일입니다. 항목 유형마다 정리 기한이 다르고(입금은 며칠, 지급 수표는 몇 주), 반대편에 같은 금액의 항목이 이미 올라와 있어 정리만 빠진 경우도 있습니다. 이 앱은 그 계산과 대조를 한 화면에 올려, 조정 후 잔액이 맞는지와 오래 남은 항목이 무엇인지를 함께 보여 줍니다.

관련 기준서가 따로 있는 화면은 아닙니다. 자금 회계의 월마감 업무를 돕는 분석 화면이며, 대상 영역은 자금 회계입니다. 화면은 항목을 “점검 필요”나 “확인 필요”로 가려 보일 뿐, 회계 처리나 세무 판단을 대신하지 않습니다.

조정 후 잔액이 맞아도 오래 남은 항목은 그대로 남는다

은행 잔액에 미달 입금을 더하고 미결제 지급을 빼면 조정 후 은행 잔액이 나오고, 장부 잔액에 은행 입금 미기표를 더하고 출금 미기표를 빼면 조정 후 장부 잔액이 나옵니다. 두 값이 같으면 대사는 맞습니다. 그런데 그 안에 150일 된 수표가 들어 있어도 합계는 똑같이 맞습니다. 샘플에서 여섯 계좌의 조정 후 잔액은 모두 차이가 0이지만, 미결 항목 72건 가운데 25건이 정리 기한을 넘겼고 4건은 90일을 넘겼습니다. 잔액만 보면 보이지 않는 이야기입니다.

정리 기한은 항목 유형마다 다르다

입금이 은행에 반영되기까지 걸리는 시간과 수표가 현금화되기까지 걸리는 시간은 같지 않습니다. 이 앱은 유형마다 회사가 정하는 정리 기한을 두고(샘플은 미달 입금 5일, 미결제 지급 30일, 은행 입금·출금 미기표 각 3일), 경과일수가 기한을 넘으면 그 초과 일수를 계산합니다. 기한 숫자는 코드가 아니라 정책 표에 있어 회사 사정에 맞게 바꿀 수 있습니다.

반대편에 같은 금액이 이미 있는데 정리만 빠졌을 수 있다

장부에는 “미달 입금”으로 남아 있는데 은행 명세에는 같은 금액의 입금이 이미 들어와 있다면, 그 두 줄은 같은 거래일 가능성이 큽니다. 한쪽에서만 정리하고 다른 쪽을 놓친 것입니다. 앱은 장부 측 항목과 은행 측 항목의 금액·통화·시기를 맞대어 일치 후보를 찾고, 기한을 넘긴 항목에 후보가 있으면 “정리 누락 후보”로 올립니다. 샘플에서는 5건입니다. 같은 거래가 맞는지는 사람이 확인합니다.

같은 항목이 두 번 올라오면 잔액이 맞아도 문제가 숨는다

같은 계좌에서 같은 참조 번호와 같은 금액이 둘 이상 남아 있으면 중복 입력이나 중복 수신일 수 있습니다. 이 경우에도 양쪽이 같은 만큼 틀려 조정 후 잔액은 맞아 보입니다. 앱은 계좌·금액·참조가 같은 항목 묶음을 “확인 필요”로 표시합니다. 정상 거래일 수도 있으므로 단정하지 않습니다.

사용 방법

1. 조회조건 입력 — 회계연도와 기간(월)은 필수, 회사·계좌·항목 유형·경과 구간·발생일·점검 코드·점검 결과는 선택입니다. 처음 열면 2026년 09월이 채워져 자동으로 한 번 조회됩니다.
2. 조회 — 조회 버튼은 조회조건 영역 안 가장 오른쪽에 있고, 입력란에서 Enter 키를 눌러도 조회됩니다. 초기화 버튼은 조회 버튼 바로 옆에 있습니다.
3. 요약 확인 — 점검한 미결 항목, 미결 원화 합계, 기한 초과 건수와 금액, 정리 누락 후보, 확인 필요·점검 필요 건수, 정합성 대사 차이 건수가 한 줄로 보입니다.
4. 탭 이동 — 미결 명세 → 경과 구간 → 정리 기한 → 계좌별 대사 → 대사 결과 순서로 봅니다.
5. 행 클릭 상세 — 미결 명세의 행을 누르면 경과일수·정리 기한·초과 일수·일치 후보와 같은 계좌의 다른 미결 항목이 열립니다.
6. CSV 내려받기 — 지금 보고 있는 탭의 조회 결과를 UTF-8 CSV 로 내려받습니다.

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

점검 도구에서 가장 비싼 질문은 “이 숫자가 맞나”입니다. 그래서 화면이 보여 주는 숫자들이 서로 맞는지를 식으로 세우고 전수로 돌렸습니다. 검사 건수 합계 158건에 차이는 0건입니다. 점검 코드가 붙은 항목은 화면이 보여 주려고 일부러 넣은 예외이므로 대사 차이와 섞지 않고 따로 적었습니다.

의도적으로 넣은 점검 대상은 미결 항목 72건 가운데 28건입니다 — 기한 초과 15건(점검 필요), 정리 누락 후보 5건(점검 필요), 장기 미결 4건(확인 필요), 중복으로 보이는 4건(확인 필요). 나머지 44건은 기한 안에 있는 정상 대기 항목입니다. 외화 계좌는 통화별로 따로 대사했고, 금액 합계는 원화 환산 금액으로만 더했습니다. 환율은 모두 가정값입니다.

무엇으로 만들었나

실행 화면

처음 열었을 때

처음 열면 2026년 09월 기준으로 자동 조회가 한 번 돌고, 미결 항목 72건이 미결 명세 탭에 올라옵니다. 화면 위쪽 안내문이 이 화면의 역할 — 정리 제안은 후보일 뿐이고 실제 정리와 기표는 회사가 판단한다는 점 — 을 먼저 말해 줍니다.

조회 버튼은 조회조건 영역 안 가장 오른쪽에 있고 초기화 버튼이 바로 옆에 있습니다. 요약에는 점검한 미결 항목 72건, 원화 합계 1,047.1백만원, 기한 초과 25건과 296.8백만원, 정리 누락 후보 5건, 확인 필요 8건, 점검 필요 20건, 정합성 대사 차이 0건이 한 줄로 나옵니다. 금액 단위는 원이며 외화 항목은 기준일 가정 환율로 환산한 원화입니다. 열 이름 옆의 숫자(72)는 지금 조건에 걸린 행 수입니다.

확인 필요만 모아 보기

점검 결과를 “확인 필요”로 고르면 오래 남았거나 중복으로 보이는 항목만 남습니다. 조회조건은 “전체”로 두면 서비스에 보내지 않고, 값을 고른 조건만 필터로 나갑니다.

장기 미결(M03) 4건과 중복으로 보이는 항목(M04) 4건이 모입니다. 점검 코드와 점검 결과는 함께 걸 수 있어, 예를 들어 “점검 필요”이면서 특정 계좌인 항목만 좁혀 볼 수도 있습니다. 코드의 첫 글자(M · G · K · A)에 따라 해당하는 탭에만 적용됩니다.

경과 구간과 정리 기한 — 같은 항목을 집계로 보기

미결 명세가 항목 한 줄씩이라면, 경과 구간 탭과 정리 기한 탭은 같은 항목을 집계한 것입니다. 경과 구간은 항목 유형과 30일 단위 구간(0~30일, 31~60일, 61~90일, 91일 이상)의 교차, 정리 기한은 유형별 기한과 초과 현황입니다.

회사 1000 의 미결제 지급이 구간별로 어떻게 쌓여 있는지 보입니다. 91일 이상 구간에 4건(86.0백만원)이 있고 최장 경과는 150일입니다. 구간 행의 점검 결과는 기한을 넘긴 항목이 있으면 “점검 필요”, 장기 미결이나 중복이 섞여 있으면 “확인 필요”로 표시됩니다. 기한 안에 있는 항목만 있는 구간은 “정상”입니다.

입금 유형은 5일, 지급 유형은 30일, 미기표 유형은 3일처럼 유형마다 다른 기한과 장기 미결 기준(90일)이 한 표에 있습니다. 평균 경과와 최장 경과, 기한 초과 건수·금액, 유형마다 권하는 기본 정리 방법이 함께 나와 어느 유형부터 정리해야 하는지 정할 수 있습니다. 이번 기간에 항목이 없는 유형은 “정상”으로 두고 점검 내용에 항목이 없다고 적습니다.

계좌별 대사 — 조정 후 잔액이 같은가

계좌마다 은행 잔액에 미달 입금을 더하고 미결제 지급을 뺀 조정 후 은행 잔액과, 장부 잔액에 은행 입금 미기표를 더하고 출금 미기표를 뺀 조정 후 장부 잔액을 나란히 놓습니다. 외화 계좌는 해당 통화 그대로 대사하고, 원화로 합치지 않습니다.

여섯 계좌 모두 조정 후 은행 잔액과 조정 후 장부 잔액이 같습니다(차이 0). 그래도 점검 결과는 “정상”이 아닙니다 — 잔액은 맞지만 기한을 넘기거나 장기 미결·중복으로 보이는 항목이 그 안에 있기 때문입니다. 통화가 USD · JPY 인 계좌는 해당 통화 단위로 표시됩니다.

행을 눌러 상세까지

미결 명세에서 행을 누르면 대화상자가 열려 그 항목의 계좌·유형·출처·참조, 발생일에서 기준일까지의 경과, 정리 기한과 초과 일수, 일치 후보, 정리 제안이 나옵니다. 아래에는 같은 계좌의 다른 미결 항목이 이어져, 한 계좌의 사정을 한 번에 훑을 수 있습니다.

경과 1일에 정리 기한 5일이라 기한 안에 있는 정상 대기 항목입니다. 같은 계좌의 다른 항목 표에서 118일 된 수표(초과 88일, 확인 필요)나 일치 후보가 있는 입금 미기표(점검 필요)처럼 같이 봐야 할 항목이 보입니다. 정리 제안 문구는 후보이며, 실제 반제와 기표는 표준 화면에서 회사가 합니다.

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

마지막 탭은 이 화면의 숫자들을 서로 맞춰 보는 열한 가지 식입니다. 좌변과 우변, 검사 건수, 차이 건수가 나오고, 차이가 생기면 요약의 “정합성 대사 차이 건” 숫자가 0 이 아니게 됩니다.

통화별 조정 후 잔액 대사 4건, 탭 사이 건수·금액 합계 대사 3건, 경과일수·기한 초과 일수를 항목마다 다시 계산한 대사 2건, 기한 초과 건수와 계좌별 건수의 대사 2건이 있습니다. 모든 식의 차이는 0 입니다. 통화가 다른 금액은 원화로 섞어 더하지 않고, 통화 단위별로 따로 견줍니다.

화면 뒤에서 일어나는 일

항목 하나가 “정상”에서 “점검 필요”나 “확인 필요”가 되기까지의 순서는 다음과 같습니다.

1. 경과일수 — 기준일(조회 기간 말일)에서 발생일을 뺍니다.
2. 정리 기한 — 항목 유형별 기한과 견주어, 넘으면 초과 일수를 구합니다(경과일수 − 기한).
3. 경과 구간 — 0~30일 · 31~60일 · 61~90일 · 91일 이상으로 나눕니다.
4. 일치 후보 — 반대편 항목과 금액·통화가 맞고 시기가 가까우면 후보로 붙입니다.
5. 장기·중복 — 경과 90일 초과는 장기 미결, 계좌·금액·참조가 같은 항목이 둘 이상이면 중복으로 보이는 항목입니다.
6. 점검 코드 — 위 결과를 코드 하나로 모아 결과 상태(정상 · 점검 필요 · 확인 필요)와 사용자 조치를 정합니다.

판정 조건 → 결과 상태 → 사용자 조치

조회조건

발생일의 시작과 종료를 각각 필터로 따로 걸면 같은 칸의 두 조건이 “또는”으로 묶여 모든 기간이 통과합니다. 그래서 둘 다 있을 때는 하나의 범위 조건으로 보냅니다.

결과 컬럼

좁은 화면에서 달라지는 것

조회조건은 화면 폭에 맞춰 줄을 바꾸도록 구성했습니다. 이번 공개분에는 좁은 화면 캡처가 없어 휴대폰 폭에서의 표 모양은 확인 필요로 남깁니다.

파일 구성

index.html · Component.js · manifest.json
controller/ (BaseController · Main.controller)
view/ (Main.view · DetailDialog.fragment)
model/ (formatter · ErrorHandler)
css/ · i18n/
서비스 정의 폴더 (메타데이터 · 서비스 로직 · 엔티티셋별 데이터)
media/ (소개 영상 · 첫 장면)
설명서(readme.html)

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 아래는 어디까지가 표준이고 어디서부터가 이 앱인지, 표준 화면과 숫자를 어떻게 맞춰 보는지를 정리한 것입니다.

표준으로 되는 것과 이 앱이 더하는 것

T-code 별 연계 지점

운영 전환 때 “기존 화면을 없애야 하느냐”는 질문이 자주 나옵니다. 없애지 않습니다. 명세 입력, 후처리, 반제, 기표는 표준 화면에 두고, 이 앱은 그 앞뒤에서 얼마나 오래 남았는지를 보는 조회·검증 화면으로 둡니다.

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

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 도구가 있습니다. 이 앱은 그 도구들을 대체하지 않고, 같은 CDS 계층에 자금 회계 전용 경과·기한 판정을 얹는 방식을 택했습니다. 표준 분석 도구에서 이미 쓰는 뷰가 있으면 이 앱의 큐브가 그 뷰를 읽도록 바꾸면 됩니다. 어떤 표준 뷰와 앱이 있는지는 설치 환경과 버전에 따라 달라 확인이 필요합니다.

이 앱이 하지 않는 일

• 전표를 만들거나 반제하지 않습니다. 정리 제안은 후보이며, 실제 반제와 기표는 표준 T-code 에서 회사가 합니다.
• 회계·세무 판단을 대신하지 않습니다. “점검 필요”와 “확인 필요”는 사람이 볼 항목을 가리는 표시이며, 처리 방법의 옳고 그름을 말하지 않습니다.
• 정리 기한을 정하지 않습니다. 샘플의 기한은 가정값이고, 운영에서는 회사가 정책 표에 정합니다.
• 외화 금액을 섞어 더하지 않습니다. 통화가 다르면 원화 환산 금액으로만 합산합니다.

분석 지표 정의표

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

CDS 구성

화면이 보여 주는 판정은 서비스 쪽에서 만들어집니다. 운영에서는 그 서비스가 CDS 뷰 위에 서야 대용량에서도 버티고, 권한을 표준 방식으로 걸 수 있습니다. 아래는 이 화면의 판정을 CDS 로 옮길 때의 구성입니다. 뷰 이름은 기능을 뜻하는 이름으로 새로 지은 것이고, 표준 뷰 이름과 필드명 가운데 확인하지 못한 곳은 “확인 필요”로 적었습니다. 지면을 아끼려 계좌 기초 집계 같은 보조 뷰는 생략한 스케치입니다.

뷰 레이어 구성

① 정리 기한 표

유형마다 며칠 안에 정리해야 하는지, 며칠을 넘으면 장기 미결로 보는지는 회사가 정할 일입니다. 코드에 박지 않고 표로 두면 개발 없이 바꿀 수 있습니다. 유효 기간 칸을 두어 기한을 바꿔도 과거 기간의 판정이 달라지지 않게 합니다.

" ─────────────────────────────────────────────────────────────────
"  ZBOPN_POLICY — 항목 유형별 정리 기한 · 장기 미결 기준 (투명 테이블)
"  회사가 정하는 표이므로 코드에 박지 않고 전송(TR)으로 옮긴다.
"  유효 기간을 두어, 기한을 바꿔도 과거 기간의 판정이 흔들리지 않게 한다.
" ─────────────────────────────────────────────────────────────────
@EndUserText.label : '은행 미결 항목 정리 기한'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zbopn_policy {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;          " 회사코드
  key item_type  : abap.char(2) not null;   " DT 미달 입금 · OC 미결제 지급 · BC/BD 은행 측 미기표
  key valid_from : abap.dats not null;
  valid_to       : abap.dats;
  limit_days     : abap.int4;               " 정리 기한(일)
  long_days      : abap.int4;               " 장기 미결 기준(일)
  action_text    : abap.char(60);           " 기본 정리 방법 문구
}

② 항목 유형 차원

큐브에는 유형 코드만 두고 이름과 출처는 차원에서 붙입니다. 유형이 늘어도 큐브를 고치지 않아도 되고, 화면의 이름이 한 곳에서 정해집니다.

" ─────────────────────────────────────────────────────────────────
"  ZI_BankOpenTypeDim — 항목 유형 차원
"  코드 → 이름 · 출처(장부 측 / 은행 측). 큐브는 코드만 들고 간다.
" ─────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '항목 유형(차원)'
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'ItemType'
define view entity ZI_BankOpenTypeDim
  as select from zbopn_type
{
  key item_type as ItemType,
      type_name as TypeName,      // 미달 입금 · 미결제 지급 · 은행 입금 미기표 · 은행 출금 미기표
      origin    as Origin         // 장부 측 / 은행 측
}

③ 미결 항목 통합

장부 측 항목은 은행 G/L 계정의 열린 항목에서, 은행 측 항목은 명세 항목 가운데 아직 기표되지 않은 것에서 옵니다. 두 원천의 모양이 달라 먼저 한 모양으로 합쳐 둡니다. 이후의 모든 뷰는 이 뷰만 봅니다.

" ─────────────────────────────────────────────────────────────────
"  ZI_BankOpenItem — 장부 측 열린 항목 + 은행 측 미기표 항목 (스케치)
"  장부 측 : 은행 계정의 열린 항목(미반제)  → DT 미달 입금 · OC 미결제 지급
"  은행 측 : 명세 항목 가운데 장부에 반영되지 않은 것 → BC 입금 · BD 출금
"  필드명 · 미기표 판정 조건은 환경에 맞춰 확인 필요 (FEBAN 후처리 대상 기준과 맞출 것)
" ─────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행 미결 항목(스케치)'
define view entity ZI_BankOpenItem
  as select from acdoca as a
    inner join   zbopn_bankgl as g on  g.bukrs = a.rbukrs
                                   and g.glacct = a.racct       // 은행 계정 목록
{
  key a.rbukrs                as Bukrs,
  key a.belnr                 as DocNo,
  key a.docln                 as DocLine,
      cast( 'BOOK' as abap.char(4) ) as Origin,
      case when a.hsl >= 0 then 'DT' else 'OC' end as ItemType,   // 차변 열린 항목 = 미달 입금 등
      a.budat                 as OrigDate,
      a.rhcur                 as Waers,
      a.hsl                   as Amount
}
where a.augbl = ''                                                  // 아직 반제되지 않은 항목
union all
  select from febep as e
    inner join febko as k on k.kukey = e.kukey
{
  key k.bukrs                 as Bukrs,
  key e.kukey                 as DocNo,
  key e.esnum                 as DocLine,
      cast( 'BANK' as abap.char(4) ) as Origin,
      case when e.kwbtr >= 0 then 'BC' else 'BD' end as ItemType,
      e.budat                 as OrigDate,
      e.waers                 as Waers,
      e.kwbtr                 as Amount
}
where e.belnr = ''                                                  // 장부 반영 전 — 판정 조건은 확인 필요

④ 경과 판정

기준일을 파라미터로 받아 경과일수와 기한 초과를 계산합니다. 같은 데이터를 월말 기준으로도, 어제 기준으로도 다시 볼 수 있습니다. 정리 기한은 정책 표에서 가져옵니다.

" ─────────────────────────────────────────────────────────────────
"  ZI_BankOpenAged — 경과일수 · 기한 초과 · 구간 · 장기 미결
"  기준일은 파라미터. 정리 기한은 ZBOPN_POLICY 에서(유효 기간 안의 행).
"  통화가 다른 금액은 더하지 않으므로 원화 환산 금액을 함께 만든다.
" ─────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행 미결 항목 경과 판정(스케치)'
define view entity ZI_BankOpenAged
  with parameters
    p_BaseDate : abap.dats
  as select from ZI_BankOpenItem as i
    inner join   zbopn_policy    as p on  p.bukrs     = i.Bukrs
                                      and p.item_type = i.ItemType
                                      and p.valid_from <= $parameters.p_BaseDate
                                      and ( p.valid_to is initial or p.valid_to >= $parameters.p_BaseDate )
{
  key i.Bukrs, key i.DocNo, key i.DocLine,
      i.Origin, i.ItemType, i.OrigDate, i.Waers, i.Amount,
      currency_conversion( amount => i.Amount, source_currency => i.Waers,
                           target_currency => cast( 'KRW' as abap.cuky ),
                           exchange_rate_date => $parameters.p_BaseDate,
                           exchange_rate_type => 'M',            // 환율 유형은 회사가 정함(확인 필요)
                           error_handling => 'SET_TO_NULL' )                as AmountKrw,
      p.limit_days                                                    as LimitDays,
      dats_days_between( i.OrigDate, $parameters.p_BaseDate )         as AgeDays,
      case when dats_days_between( i.OrigDate, $parameters.p_BaseDate ) > p.limit_days
           then dats_days_between( i.OrigDate, $parameters.p_BaseDate ) - p.limit_days
           else 0 end                                                 as OverdueDays,
      case when dats_days_between( i.OrigDate, $parameters.p_BaseDate ) <= 30 then 'B1'
           when dats_days_between( i.OrigDate, $parameters.p_BaseDate ) <= 60 then 'B2'
           when dats_days_between( i.OrigDate, $parameters.p_BaseDate ) <= 90 then 'B3'
           else 'B4' end                                              as AgeBucket,
      case when dats_days_between( i.OrigDate, $parameters.p_BaseDate ) > p.long_days
           then 'X' else '' end                                       as IsLong
}

⑤ 경과 구간 큐브

경과 구간 탭과 정리 기한 탭은 같은 집계를 서로 다른 모양으로 봅니다. 한 번 집계해 두면 두 탭의 건수와 금액이 어긋날 수 없습니다. 원화 환산은 환율 유형과 기준일을 정해 큐브 안에서 끝냅니다.

" ─────────────────────────────────────────────────────────────────
"  ZI_BankOpenAgeCube — 회사 × 유형 × 구간 집계
"  건수 · 원화 환산 금액 · 기한 초과 건수/금액 · 최장 경과일.
"  통화가 다른 금액은 더하지 않는다 → 환산한 금액만 합산 (환율 유형은 회사가 정함, 확인 필요)
" ─────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행 미결 항목 경과 큐브(스케치)'
@Analytics.dataCategory : #CUBE
define view entity ZI_BankOpenAgeCube
  with parameters
    p_BaseDate : abap.dats
  as select from ZI_BankOpenAged( p_BaseDate : $parameters.p_BaseDate ) as a
  association [0..1] to ZI_BankOpenTypeDim as _Type on _Type.ItemType = a.ItemType
{
  key a.Bukrs,
  key a.ItemType,
  key a.AgeBucket,
      @Aggregation.default : #SUM
      count( * )                                  as ItemCnt,
      @Aggregation.default : #SUM
      sum( a.AmountKrw )                          as AmtKrw,        // 원화 환산 금액(환산 방식은 확인 필요)
      @Aggregation.default : #SUM
      sum( case when a.OverdueDays > 0 then 1 else 0 end ) as OverdueCnt,
      @Aggregation.default : #MAX
      max( a.AgeDays )                            as MaxAge,
      _Type
}
group by a.Bukrs, a.ItemType, a.AgeBucket

⑥ 계좌별 조정 후 잔액 대사

계좌마다 은행 잔액에 미달 입금을 더하고 미결제 지급을 뺀 값과, 장부 잔액에 은행 입금 미기표를 더하고 출금 미기표를 뺀 값을 만듭니다. 통화별로 따로 계산해야 하므로 계좌 단위에서 끝내고, 합계는 원화 환산 금액으로만 냅니다.

" ─────────────────────────────────────────────────────────────────
"  ZI_BankOpenAcctRecon — 계좌별 조정 후 잔액 대사
"  조정 후 은행 잔액 = 은행 잔액 + 미달 입금 − 미결제 지급
"  조정 후 장부 잔액 = 장부 잔액 + 은행 입금 미기표 − 은행 출금 미기표
"  두 값의 차이가 0 이 아니면 대사 차이(요약의 정합성 대사 차이 건에 잡힌다)
" ─────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '계좌별 조정 후 잔액 대사(스케치)'
define view entity ZI_BankOpenAcctRecon
  with parameters
    p_BaseDate : abap.dats
  as select from ZI_BankOpenAcctBase( p_BaseDate : $parameters.p_BaseDate ) as b
{
  key b.Bukrs,
  key b.AcctNo,
      b.Waers,
      b.BankBal,                                                   // 은행 명세 기말 잔액
      b.BookBal,                                                   // 장부 잔액(FS10N 과 대사)
      b.BankBal + b.DepTr - b.OsChk                    as AdjBank,   // 조정 후 은행 잔액
      b.BookBal + b.BkCr  - b.BkDr                     as AdjBook,   // 조정 후 장부 잔액
      ( b.BankBal + b.DepTr - b.OsChk )
        - ( b.BookBal + b.BkCr - b.BkDr )              as Diff
}

⑦ 조회 쿼리

화면이 쓰는 필터와 표시 정보를 소비 뷰에 모읍니다. 기준일 파라미터는 화면이 조회 기간 말일로 채우고, 값 도움말이 필요한 필터에는 차원을 연결합니다.

" ─────────────────────────────────────────────────────────────────
"  ZC_BankOpenAgeQuery — 화면 조회용 소비 뷰
"  필터 · 표시 정보를 주석으로 붙인다. 파라미터는 기준일 하나.
" ─────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행 미결 항목 경과 조회'
@Analytics.query : true
@VDM.viewType : #CONSUMPTION
define view entity ZC_BankOpenAgeQuery
  with parameters
    @Consumption.derivation : { lookupEntity : 'ZI_BankOpenPeriodEnd', resultElement : 'BaseDate',
                                binding : [ { targetParameter : 'p_PeriodKey', type : #PARAMETER, value : 'p_PeriodKey' } ] }
    p_BaseDate : abap.dats
  as select from ZI_BankOpenAgeCube( p_BaseDate : $parameters.p_BaseDate )
{
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key Bukrs,
  @Consumption.filter.selectionType : #RANGE
  key ItemType,
  @AnalyticsDetails.query.axis : #ROWS
  key AgeBucket,
  @AnalyticsDetails.query.axis : #COLUMNS
  ItemCnt,
  AmtKrw,
  OverdueCnt,
  MaxAge
}

⑧ 접근 제어

권한은 합계가 아니라 명세를 읽는 뷰에 걸어야 합니다. 합계 화면에만 걸면 전체 합계에서 자기 몫을 빼서 다른 회사의 숫자를 알아낼 수 있기 때문입니다.

" ─────────────────────────────────────────────────────────────────
"  ZC_BankOpenAgeQuery 의 접근 제어 — 회사코드 권한
"  명세를 읽는 기본 뷰(ZI_BankOpenItem)에도 같은 규칙을 건다.
" ─────────────────────────────────────────────────────────────────
@EndUserText.label : '은행 미결 항목 — 회사코드 권한'
@MappingRole : true
define role ZC_BankOpenAgeQuery {
  grant select on ZC_BankOpenAgeQuery
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑨ 서비스 정의

서비스 정의는 어떤 뷰를 내보낼지만 적고, 게시와 활성화는 바인딩에서 합니다. 화면의 서비스 주소를 바꾸는 일이 곧 이 바인딩의 주소를 가져다 쓰는 일입니다.

" ─────────────────────────────────────────────────────────────────
"  ZUI_BankOpen — 서비스 정의 (OData V2 바인딩으로 게시)
" ─────────────────────────────────────────────────────────────────
@EndUserText.label : '은행 미결 항목 경과 정리 점검'
define service ZUI_BankOpen {
  expose ZC_BankOpenAgeQuery as AgeSet;
  expose ZI_BankOpenItem      as ItemSet;
  expose ZI_BankOpenAcctRecon as AcctSet;
  expose ZI_BankOpenTypeDim   as TypeSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 코딩이 아니라 합의입니다.

운영 데이터로 갈 때

명세는 한 달에 수만 건, 열린 항목은 수천 건이 될 수 있습니다. 판정은 CDS 에서 하고, 화면은 조회 기간으로 범위를 좁혀 첫 페이지만 읽습니다. 기준일 파라미터는 필수로 두고, 큐브는 유형·구간 수준에서 끝나 행 수가 작게 유지되도록 합니다. 항목 한 줄을 읽는 미결 명세는 페이지 단위로 읽고 건수는 별도로 가져옵니다. 응답 시간 기준은 조회 기간별로 정해 두는 편이 좋습니다.

자주 묻는 질문

도입을 검토하는 분들이 가장 자주 묻는 것을 네 묶음으로 정리했습니다. 답은 모두 이 화면이 실제로 하는 일을 기준으로 적었고, 확인하지 못한 것은 확인 필요로 남겼습니다.

숫자와 판정

화면과 조작

표준 기능과 도입

운영과 권한