SAP 보증금·예치금 예치 자금 다차원 분석 — 어디에 얼마나 묶였고 계획과 왜 달랐는지 한 화면에서 따라가는 자금 리포트

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

월말 자금 회의의 질문은 매번 비슷합니다. 보증금과 예치금이 어느 유형 · 은행 · 통화에 얼마나 묶여 있나, 계획과 왜 달랐나, 누가 무엇을 확인해야 하나. 지금은 이 세 답이 계정 개별 항목 조회 · 엑셀 표 · 메일로 흩어져 있어서, 숫자를 맞추는 데 시간이 쓰이고 “어느 숫자가 맞나”가 회의의 주제가 되곤 합니다. 이 앱은 세 답을 한 화면에 붙여 예치 현황 보고를 만드는 손일을 줄입니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 숫자가 같은데 내용은 달랐던 임차보증금

검증용 샘플 데이터(2026년 1월~9월)에서 임차보증금은 계획 2,739.65억원, 실적 2,747.07억원으로 차이가 +7.42억원(+0.3%)에 불과합니다. 숫자만 보면 계획대로 간 것처럼 보이지만 일곱 요인으로 가르면 계획 외 예치 +90.55억원과 계획 예치 미발생 −96.03억원이 서로 상쇄하고 있습니다. 상쇄가 만든 평온한 숫자 뒤에서 어떤 계약이 빠지고 어떤 계약이 새로 들어왔는지를 확인해야 한다는 뜻입니다. 큐브 합계와 원천 라인 합계는 기간 × 측정값 45개 조합에서 모두 일치하고 차이는 0건입니다.

도입하면 달라지는 것

• 예치 현황 보고 준비 — 은행별 · 유형별 · 통화별 표를 따로 만들던 일이 한 화면의 축 전환으로 끝납니다.
• 월말 회의 — "어느 숫자가 맞는가" 대신 "계획 외 예치가 왜 생겼는가"를 이야기합니다.
• 마감 이후 — 사유가 행에 남아 다음 달에도 같은 설명을 반복하지 않습니다.
• 자리를 비운 날 — 감시 규칙이 지연 예치 비중과 기말 미이행 잔액을 대신 점검해 대기함에 올립니다.

이런 회사에 맞습니다

입찰 · 계약이행 · 하자 · 임차 · 거래 담보 · 통관 예치 등 여러 유형의 보증금과 예치금을 다수 법인과 여러 은행에서 운용하고, 외화 예치가 섞여 있으며, 자금 · 회계 · 재무가 같은 숫자를 서로 다른 표로 따로 관리하는 조직에 맞습니다. 자금 담당은 은행 · 만기 · 지연, 회계는 처리 단계 · 이견 보류, 재무와 경영은 계획 대비 차이와 집중도를 봅니다.

실행 화면

아래 화면은 모두 검증용 샘플 데이터(2026년 1월~9월)로 실제 앱을 열어 찍은 것입니다. 화면마다 무엇을 보는지, 무엇을 누르면 무엇이 일어나는지, 숫자를 어떻게 읽는지를 함께 적었습니다.

사용 방법

1. 조회 조건 — 법인(선택) · 기간 부터/까지(필수) · 비교 기준을 정합니다. 기본은 전체 법인, 2026년 01월~09월, 예치 계획과 비교입니다.
2. 조회 — 조회조건 영역 오른쪽 끝의 조회 버튼을 누르거나 Enter 키를 누릅니다. 조회 뒤 조건 영역은 한 줄 요약으로 접힙니다.
3. 요약 카드 — 순예치액 · 최대 보증금 유형 비중 · 증액 예치 비율 · 지연 예치 비중 · 계획 대비 차이를 확인합니다.
4. 보는 사람 탭 — 경영 → 재무 → 자금 → 회계 순서로 바꿔 봅니다. 다시 조회하지 않습니다.
5. 축 옮기기 — 차원 보관함의 칩을 눌러 행 축으로 보내고, 축의 칩을 눌러 열로 보내거나 순서를 바꿉니다. 열 축은 두 단계까지입니다.
6. 값 필터 · 측정값 — 값을 여러 개 골라 범위를 좁히고 측정값과 계산항목을 고릅니다.
7. 칸 클릭 — 숫자 칸을 누르면 원천 라인 팝업이 열립니다. 팝업의 CSV 로 내려받습니다.
8. 계획 차이 — 스위치를 켜고 행을 선택하면 일곱 요인 폭포 차트가 열립니다. 변동 사유 버튼으로 사유를 적습니다.
9. 해설 · 에이전트 · 보기 저장 · CSV — 맨 위 단추 줄에서 각각 엽니다. CSV 는 현재 표를 그대로 내려받습니다.

무엇으로 만들었나

앱의 기본 정보는 다음과 같습니다.

처음 열었을 때 — 조회조건과 빈 화면

처음 열면 조회 조건이 맨 위에 펼쳐져 있고 표와 차트는 비어 있습니다. 조건을 정하고 조회를 누르면 요약 카드 · 피벗 · 차트가 한 번에 채워집니다.

법인 · 기간(부터/까지) · 비교 기준을 정하고 조회 버튼을 누르거나 Enter 키를 누릅니다. 기본값은 전체 법인 · 2026년 01월~09월 · 예치 계획과 비교입니다.

행은 보증금 유형 › 지급 은행, 열은 분기가 기본입니다. 표는 합계 행부터 펼쳐지고 합계 행의 화살표로 단계별로 내려갑니다. 금액 단위는 억원이 기본이며 오른쪽 선택 상자에서 원 · 천원 · 백만원 · 억원으로 바꿉니다.

보는 사람에 따라 — 경영 · 재무 · 자금 · 회계

같은 큐브를 질문이 다른 네 사람이 각자의 첫 화면으로 봅니다. 탭은 기본 축과 측정값만 바꾸며, 다시 조회하지 않습니다.

탭은 경영 → 재무 → 자금 → 회계 순서입니다. 탭을 바꿔도 다시 조회하지 않고 이미 받은 큐브로 즉시 다시 그립니다.

자금 담당자는 은행별로 약정일을 넘긴 예치가 얼마인지, 월말까지 예치하지 못한 요청 잔액이 얼마인지부터 봅니다.

대사가 끝나지 않은 단계가 어디에 얼마나 남았는지 확인합니다. 이견 보류 후 예치 건은 금액 이견을 거친 건입니다.

열 축에 측정값 칩이 들어가 있으면 분기마다 순예치액과 비중이 번갈아 나옵니다. 합계 행의 비중은 100%입니다.

축 전환과 범위 — 끌어다 놓고, 걸러 보기

피벗은 차원 칩을 눌러 보관함과 행 · 열 축 사이로 옮기며 만듭니다. 열 축은 두 단계까지이고, 값 필터로 범위를 좁힐 수 있으며, 한도를 넘으면 그리기 전에 안내가 나옵니다.

행 축과 열 축의 순서가 곧 피벗의 계층 순서입니다. 축을 바꿔도 서버에 다시 묻지 않고 이미 받은 큐브에서 즉시 다시 집계합니다.

외화 보증금은 원천 라인에 거래통화 금액과 환율을 따로 두고 있으며, 표의 금액은 모두 원화 환산액입니다. 통화 열은 같은 통화끼리 모은 원화 환산액을 보여 줍니다.

선택을 마치고 적용을 누르면 필터가 걸린 차원 개수가 단추 옆에 표시됩니다. 선택 지우기로 한 번에 비웁니다.

요약 카드의 숫자도 같은 범위를 따르므로 표의 합계와 어긋나지 않습니다.

열 조합이 너무 많아지면 표가 읽을 수 없게 되므로 열 단계는 두 단계, 열 조합은 36개까지로 제한합니다.

칸에서 원천 문서까지 — 드릴스루

표의 숫자를 누르면 그 칸을 이룬 원천 라인이 열립니다. 표의 값과 원천 합계가 같은지 그 자리에서 비교합니다.

2026년 2분기 칸은 928건이며 표의 값 918.23억원과 원천 합계 918.23억원이 일치합니다. 팝업의 CSV 단추로 라인을 내려받습니다.

내려가도 합계는 같습니다. 보기 전체에서 열 단계는 두 단계를 넘지 않습니다.

계산항목 — 큐브에 없는 비율을 그 자리에서

비율은 큐브에 들어 있지 않습니다. 건당 순예치액 · 증액 예치 비율 · 지연 예치 비중처럼 측정값끼리 계산한 행을 그 자리에서 만듭니다.

건당 순예치액은 순예치액을 예치 건수로 나눕니다. 비율 계산항목은 소계마다 분자와 분모를 각각 합한 뒤 나누므로 행 값의 평균이 아닙니다.

예치 계획 대비 차이 — 같은 표가 자금 회의 자료가 된다

스위치 하나로 같은 표가 계획 대비 차이 리포트가 됩니다. 기준을 넘는 칸만 붉게 표시하고, 일곱 요인으로 가른 폭포 차트와 변동 사유로 이어집니다.

금액 기준(백만원)과 비율 기준(%)을 모두 넘는 칸만 붉게 표시합니다. 전체 차이는 +83.19억원이고 계획 5,040.57억원 대비 +1.7%입니다.

임차보증금은 계획 2,739.65억원에서 실적 2,747.07억원으로 7.42억원 늘었고, 계획 외 예치 +90.55억원과 계획 예치 미발생 −96.03억원이 가장 큰 요인입니다. 계획 + 요인 합 − 실적 = 0 을 화면이 검산합니다.

저장한 사유는 표의 행 앞에 연필 표시로 나타나고, 해설에서는 이미 사유가 있는 행을 건너뜁니다. 사유는 최대 500자입니다.

AI 분석과 보고서

해설은 서비스가 계산한 숫자 위에 규칙으로 쓴 초안입니다. 근거 표를 펼쳐 쓴 숫자를 확인하고, PowerPoint 보고서로 내려받습니다.

묶는 기준과 보는 사람을 바꿔 다시 쓸 수 있고, 근거 표를 펼치면 해설에 쓴 숫자가 그대로 나옵니다. 사유가 적힌 행은 "사유 기재됨"으로 건너뜁니다.

외부 라이브러리 없이 브라우저가 파일을 만듭니다. 내려받으면 "보고서를 내려받았습니다" 안내가 뜹니다.

AI 에이전트 — 감시 규칙과 대기함

에이전트는 감시 규칙 4개를 하루 한 번 점검합니다. 걸린 항목은 받을 역할 관점의 보고로 대기함에 올라가고 활동 기록에 남습니다.

이번 실행은 규칙 4개 중 3건이 걸렸습니다. 같은 날 두 번째 실행은 서버가 막고 "오늘은 이미 실행했습니다(하루 한 번 제한)"를 알려 줍니다.

운영에서는 배치(SM36 또는 cron)로 같은 서비스 함수를 하루 한 번 부르는 방식으로 연결합니다. 연결 방법은 설명서와 블로그에 설명만 둡니다.

보기 저장과 복원

자주 쓰는 행 · 열 · 측정값 · 계획 차이 설정을 이름 붙여 저장하고, 기본 보기나 자동 조회 보기로 지정합니다.

저장할 때 아래에 "행 보증금 유형·지급 은행 / 열 분기 / 순예치액(원) / 계획 차이" 같은 내용 요약이 나와 무엇을 저장하는지 확인합니다.

기본 보기와 자동 조회 보기는 이름 옆 표시로 구분합니다.

좁은 화면에서

폭이 좁아지면 차트를 감추지 않고 표 아래로 내립니다.

단추 줄은 줄임 메뉴(점 세 개)로 접히고 차원 보관함 · 행 축 · 열 축도 위아래로 놓입니다.

화면 뒤에서 일어나는 일

여기부터는 목차에 올리지 않은 상세입니다. 위의 화면들이 어떤 규칙으로 그렇게 움직이는지를 자리별로 적었습니다.

1. 조회 한 번에 큐브(CubeSet)와 계획(PlanSet), 기간 요약(PeriodSet), 차원 값과 측정값 정의를 받아 브라우저에 둡니다.
2. 피벗 · 계산항목 · 계획 차이 · 값 필터는 모두 이 데이터 위에서 브라우저가 다시 집계합니다. 축을 바꿔도 서비스를 다시 부르지 않습니다.
3. 칸을 누를 때만 원천 라인(ItemSet)을 필터로 읽어 팝업에 보여 주고 표의 값과 합계를 비교합니다.
4. 일곱 요인 분해, 해설, 에이전트 실행은 서비스 펑션이 계산합니다. 숫자는 서비스에서 한 번 계산하고 화면은 받은 값을 보여 줍니다.
5. 사유 · 보기 · 대기함 · 활동 기록은 서비스에 저장되어 새로 고침 뒤에도 남습니다.

차이 판정과 화면 상태 규칙

조건이 맞으면 화면이 어떻게 바뀌고, 그때 무엇을 하면 되는지를 한 표로 모았습니다.

차이를 가르는 일곱 요인과 검산

계획 대비 차이는 아래 일곱 요인으로 가릅니다. 요인은 서로 겹치지 않게 정의되어 있어 합이 총차이와 같습니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

폭이 600px 보다 좁아지면 요약 카드가 두 줄이 되고 표와 차트가 위아래로 쌓입니다. 차트를 감추지 않고 표 아래로 내립니다. 단추 줄은 줄임 메뉴로 접히며 가로 스크롤이 생기지 않습니다.

파일 구성

앱 폴더/
├─ index.html · Component.js · manifest.json
├─ controller/ · view/ (대화창 7개) · model/ (피벗 엔진 · SVG 차트 · 보고서 · 보기)
├─ odata/<서비스>/  metadata.xml · service.js · calc.js · json/ (엔티티셋 14개)
├─ media/ 소개 영상 · 포스터 · 목차
└─ 설명서

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 두고, 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다.

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

T-code 별 연계 지점

맞닿은 표준 T-code 마다 두 화면의 숫자를 맞춰 보는 지점이 있습니다. 이 앱에서 표준으로는 원천 라인의 문서번호로 내려가고, 표준 화면의 값은 이 앱에서 같은 범위로 다시 집계해 비교합니다.

오가는 방법은 두 갈래입니다. 이 앱에서 표준으로 갈 때는 칸 → 원천 라인 → 문서번호로 전표 조회(FB03) 또는 계정 개별 항목(FBL3N)을 엽니다. 표준에서 이 앱으로 올 때는 계정 잔액(FS10N)의 기간별 값을 같은 법인 · 기간으로 이 앱의 누계 순예치액과 맞춰 보고, 어긋나면 값 필터와 단위부터 확인합니다.

표준에 남겨 둘 일은 다음과 같습니다. 그리고 운영 전환 때 기존 리포트를 없애야 하느냐는 질문에는 “없애지 않고 함께 둡니다”가 답입니다. 이 화면은 숫자를 맞춰 보는 상대가 필요하기 때문입니다.

• 계정 개별 항목 · 전표 · 계정 잔액 · 유동성 예측 화면 — 그대로 씁니다. 이 화면은 숫자를 맞춰 보는 상대입니다.
• 법정 · 공시 · 감사 대응 — 표준 화면에 둡니다. 이 화면은 분석과 점검용입니다.
• 세무 신고 — 회사와 세무 대리인 · 관세사가 표준 자료로 합니다.

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

분석 지표 정의

화면에 나오는 지표의 산식과 원천 데이터입니다. 고객사가 확정해야 하는 값은 확인 필요로 적었습니다.

감시 규칙의 판정 기준은 다음 네 가지입니다.

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

CDS 구성

운영 데이터로 옮길 때의 뷰 구성입니다. 화면이 읽는 엔티티셋 한 행이 큐브의 한 행이 되도록 나눴습니다. 표준 CDS 뷰 이름은 확인한 것만 쓰고, 나머지는 원천 테이블 기준으로 적었으며 고객사 환경에서 확인이 필요한 곳에는 주석을 달았습니다. 객체 이름은 기능을 뜻하는 영문으로 지었습니다.

뷰 레이어 구성

① 매핑 테이블 — 보증금 유형을 계정에 묶는다

이 화면의 첫 질문은 "어느 계정의 예치를 어떤 보증금 유형으로 볼 것인가" 입니다. 계정 목록을 쿼리마다 하드코딩하면 계정이 바뀔 때 뷰를 고쳐야 하므로, 기준 테이블 하나에 모아 둡니다. 보증금 유형 · 예치 기간 구분 · 지급 은행 해석 기준이 여기서 정해집니다.

@EndUserText.label : '보증금 유형 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zdep_map {
  key mandt     : mandt not null;
  key bukrs     : bukrs not null;
  key racct     : racct not null;      " 예치보증금 계정 (G/L)
  depkind       : abap.char(1);        " R 임차 · B 입찰·계약 · P 계약이행·하자 · T 거래 담보 · C 통관·관세
  term_rule     : abap.char(1);        " S 1년 이하 · M 1~3년 · L 3년 초과 · N 기간 미정
  bank_src      : abap.char(1);        " 지급 은행을 읽는 위치 — 확인 필요 (하우스 뱅크 / 계정 설명 / 별도 입력)
}

② 문서 라인 기본 뷰 — 원천 라인에 기준을 붙인다

ACDOCA 의 계정 라인에 매핑 테이블을 붙여 "예치 라인" 으로 만드는 가장 아래 뷰입니다. 이 화면의 원천 라인 팝업(ItemSet)과 요인 분해가 이 뷰의 라인을 그대로 씁니다. 거래통화 금액과 환율을 라인에 같이 남기는 것이 핵심입니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '예치 라인 (기본)'
@ObjectModel.usageType : { serviceQuality : #D, sizeCategory : #XL, dataClass : #TRANSACTIONAL }
define view entity ZI_DepositLine
  as select from acdoc as a
  inner join      zdep_map as m on  m.bukrs = a.rbukrs
                                and m.racct = a.racct
{
  key a.rldnr                         as Ledger,
  key a.rbukrs                        as CompanyCode,
  key a.gjahr                         as FiscalYear,
  key a.belnr                         as AccountingDocument,
  key a.docln                         as LedgerGLLineItem,
      a.budat                         as PostingDate,
      m.depkind                       as DepositKind,
      m.term_rule                     as TermClass,
      a.rwcur                         as TransactionCurrency,
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      a.wsl                           as AmountInTransactionCurrency,
      a.rhcur                         as CompanyCodeCurrency,
      @Semantics.amount.currencyCode : 'CompanyCodeCurrency'
      a.hsl                           as AmountInCompanyCodeCurrency,
      cast( case when a.wsl <> 0
                 then division( a.hsl, a.wsl, 8 )
                 else 0 end as abap.dec(13,8) ) as EffectiveRate   " 예치일 환율 — 원천 라인에 함께 남긴다
}

③ 차원 뷰 — 보증금 유형과 처리 단계의 이름을 붙인다

차원 뷰는 코드에 이름을 붙이고 정렬 순서를 정하는 일만 합니다. 화면의 차원 보관함 · 값 필터 · 막대 차트 라벨이 이 이름을 읽습니다. 값 목록(DimValueSet)에 라인 수를 같이 내려 주기 위해 코드와 이름을 한 뷰에 둡니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '보증금 유형 (차원)'
@ObjectModel.dataCategory : #VALUE_HELP
@Search.searchable : true
define view entity ZI_DepositKind
  as select from dd07t
{
  @ObjectModel.text.element : ['KindText']
  key cast( substring( domvalue_l, 1, 1 ) as abap.char(1) ) as DepositKind,
      @Semantics.text : true
      @Search.defaultSearchElement : true
      ddtext                                              as KindText
}
where domname    = 'ZDEP_KIND'      " 도메인 고정값으로 관리 — 확인 필요 (고객사 코드표 사용 가능)
  and ddlanguage = $session.system_language
  and as4local   = 'A'

④ 계획 뷰 — 같은 모양의 계획 행

계획 차이 모드는 실적과 계획이 같은 차원 모양이어야 성립합니다. 계획 원천은 고객사가 확정해야 하는 항목입니다(유동성 계획 항목을 쓸지, 별도 계획 입력 테이블을 쓸지). 여기서는 계획 입력 테이블을 가정한 형태로 보여 주며, 원천 확정 전까지는 "확인 필요" 입니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '예치 계획 (기본)'
define view entity ZI_DepositPlan
  as select from zdep_plan as p       " 계획 원천 — 확인 필요
{
  key p.version                       as PlanVersion,
  key p.bukrs                         as CompanyCode,
  key p.plan_doc                      as PlanDocument,
      p.plan_date                     as PlanDate,
      p.depkind                       as DepositKind,
      p.waers                         as TransactionCurrency,
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      p.plan_amount                   as PlanAmountInTransCurr,
      p.plan_rate                     as PlanRate,
      p.cut_amount                    as PlanCutAmount,
      p.incr_amount                   as PlanIncrAmount
}

⑤ 큐브 — 월 · 차원 칸으로 집계한다

큐브는 원천 라인을 월 · 법인 · 은행 · 보증금 유형 · 예치 기간 · 통화 · 예치일 대비 · 처리 단계 · 상계 구분의 칸으로 집계합니다. 화면의 CubeSet 한 행이 이 뷰의 한 행입니다. 순예치액 = 약정 예치액 + 증액 − 상계·감액 이며, 기말 미이행 잔액은 기간을 합쳐도 끝 기간만 쓰는 측정값입니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@Analytics.dataCategory : #CUBE
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '예치 큐브'
@ObjectModel.usageType : { serviceQuality : #D, sizeCategory : #XL, dataClass : #TRANSACTIONAL }
define view entity ZI_DepositCube
  as select from ZI_DepositLine as l
{
  key l.CompanyCode,
  key l.DepositKind,
  key l.TermClass,
  key l.TransactionCurrency,
  key cast( substring( cast( l.PostingDate as abap.char(8) ), 1, 6 ) as abap.char(6) ) as PostingPeriod,
      @DefaultAggregationOnly : true
      @Aggregation.default : #SUM
      @Semantics.amount.currencyCode : 'CompanyCodeCurrency'
      sum( l.AmountInCompanyCodeCurrency )                                    as NetDeposit,    " 순예치액
      @Aggregation.default : #SUM
      count( distinct l.AccountingDocument )                                  as DocumentCount, " 예치 건수
      l.CompanyCodeCurrency
}
group by l.CompanyCode, l.DepositKind, l.TermClass, l.TransactionCurrency,
         substring( cast( l.PostingDate as abap.char(8) ), 1, 6 ), l.CompanyCodeCurrency

⑥ 쿼리 — 필수 조회 조건과 기본 축

쿼리 뷰는 화면이 보는 입구입니다. 기간과 법인을 필수 필터로 두어 대용량에서 전체 집계가 한 번에 돌지 않게 하고, 행 · 열 기본 축을 정합니다. 화면의 "기본 축" 과 "보는 사람" 탭의 기본값이 여기 주석에 대응합니다.

@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : '예치 자금 분석 쿼리'
@OData.publish : false
define view entity ZC_DepositQuery
  as select from ZI_DepositCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @AnalyticsDetails.query.displayHierarchy : #ON
  @Consumption.filter : { selectionType : #SINGLE, multipleSelections : true, mandatory : false }
  DepositKind,

  @AnalyticsDetails.query.axis : #COLUMNS
  @Consumption.filter : { selectionType : #INTERVAL, mandatory : true }   " 기간은 필수
  PostingPeriod,

  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  CompanyCode,

  @AnalyticsDetails.query.axis : #COLUMNS
  @AnalyticsDetails.query.decimals : 2
  NetDeposit,
  DocumentCount
}

⑦ DCL — 법인 권한

법인별 조회 권한은 DCL 한 곳에서 겁니다. 화면에는 권한 로직이 없고, 서비스는 권한이 걸린 쿼리만 읽습니다. 권한 오브젝트와 필드 이름은 고객사 권한 설계에 따라 달라지므로 확인 필요 항목입니다.

@EndUserText.label : '예치 쿼리 권한'
@MappingRole : true
define role ZC_DepositQuery {
  grant select on ZC_DepositQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩 — 화면이 읽는 주소

화면은 OData V2 서비스 하나만 읽습니다. 운영에서는 서비스 정의에 쿼리를 노출하고 바인딩을 게시한 뒤, 앱의 데이터 소스 주소만 그 서비스로 바꿉니다. 화면 코드는 바뀌지 않습니다.

@EndUserText.label : '예치 자금 분석 서비스'
define service ZUI_DepositAnalysis {
  expose ZC_DepositQuery  as DepositQuery;
  expose ZI_DepositKind   as DepositKind;
}

" 서비스 바인딩: ZUI_DepositAnalysis_O2   바인딩 유형 OData V2 - UI
" 게시 후 앱 manifest 의 dataSources 주소를 게시된 서비스 주소로 바꾼다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 열한 가지는 코딩이 아니라 합의이고, 합의가 끝나면 기술 작업은 뷰를 만들고 서비스를 게시한 뒤 앱의 서비스 주소를 바꾸는 일입니다.

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

리포트에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 만드는 쪽에서 먼저 대사식을 세우고 전수로 돌린 결과입니다. 원천 라인은 정상 · 예치월 이동 · 계획 외 · 계획 미발생 · 미이행 다섯 종류가 섞여 있고, 모든 종류가 같은 대사에 들어갑니다. 위 “사례로 보는 효과”와 같은 숫자입니다.

의도적 예외는 없습니다. 화면 쪽은 따로 자동화로 돌려 축을 바꿔도 합계가 변하지 않는지, 칸의 값과 원천 합계가 같은지를 다시 잽니다.

운영 데이터로 갈 때

검증용 데이터는 원천 라인이 5천 건 남짓이지만 운영에서는 수천만 건이 될 수 있습니다. 그때 먼저 막히는 곳은 브라우저에 받는 큐브의 크기입니다.

자주 묻는 질문

도입 검토에서 자주 되돌아오는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영