SAP 은행 수수료 청구 점검 — 은행이 청구한 수수료를 약정표로 다시 계산해 청구서와 장부에 견주는 월마감

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

월마감 때 자금 담당이 부딪히는 질문은 늘 비슷합니다. 은행이 청구한 수수료가 약정대로 맞는가, 장부에는 청구 금액 그대로 반영됐는가, 은행이 보낸 청구서 총액과 우리 명세 합계는 같은가. 지금은 이 세 답이 은행 청구서 · 명세 화면 · 장부 라인 조회에 흩어져 있어서 한 번에 맞춰 보기 어렵고, 건당 금액이 작다 보니 “나중에 보자”고 넘어가기 쉽습니다.

이 앱은 은행이 청구한 수수료를 약정 수수료표(건당 정액 또는 금액 비례, 하한·상한)로 다시 계산하고, 그 값을 청구 금액과 장부 반영 금액에 견주어 차이를 건마다 보여 줍니다. 이어서 수수료 유형별 · 은행별로 묶어 합계가 서로 맞는지 대사합니다. 관련 기준서는 없고 대상 영역은 자금 회계(은행 수수료 청구 점검)입니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다.

은행 청구서는 약정과 맞는지 검산할 겨를이 없다

수수료 청구는 건당 수백 원에서 수만 원이라 한 건씩 보면 작지만, 월 수십~수천 건이 쌓이면 합계가 커지고 약정과 어긋난 건이 섞여 들어옵니다. 이 샘플에서는 타행 이체 100건에 건당 500원 약정이면 50,000원이어야 하는데 55,000원이 청구된 건이 있습니다. 청구서만 보면 건수와 금액이 그럴듯해 보여 지나가기 쉽습니다. 이 화면은 약정표로 다시 계산한 값(재계산)을 청구 금액 옆에 두고, 차이가 허용 오차를 넘으면 청구 과다(F01)로 표시합니다.

외화 송금 수수료는 비례 요율에 하한·상한이 붙어 눈으로 맞추기 어렵다

외화 송금 수수료는 송금액에 요율을 곱하되 건당 하한과 상한으로 묶습니다. 88,000 USD 를 보낸 건은 요율로 계산하면 훨씬 큰 값이지만 약정 상한 45,000원에 걸려야 합니다. 그런데 50,000원이 청구되었다면 상한 적용이 빠진 것입니다. 이런 계산은 송금액 · 환율 · 요율 · 하한 · 상한을 모두 알아야 하므로 사람이 눈으로 맞추기 어렵고, 이 화면은 상세 창에 계산 기준을 그대로 펼쳐 보여 줍니다.

청구는 맞는데 장부 금액이 다르면 다음 달에야 드러난다

은행 청구가 약정과 맞아도 장부에는 다른 금액이 기표될 수 있습니다. 예를 들어 인터넷뱅킹 이용료 30,000원이 청구되었는데 장부 반영은 0원인 경우입니다. 이 화면은 청구 금액과 장부 반영 금액의 차이를 따로 계산해 장부 불일치(F03)로 보여 주므로, 전표 금액을 마감 전에 확인할 수 있습니다.

같은 송금이 두 번 청구돼도 명세에서는 비슷해 보인다

같은 계좌에 송금번호와 금액이 같은 청구가 이미 있으면 중복 의심(F05)으로 가립니다. 상세 창은 같은 계좌의 이번 기간 청구를 아래에 이어 보여 주어, 두 건을 나란히 놓고 은행에 확인할 수 있게 합니다. 중복인지 아닌지의 판단은 은행과 회사가 하고, 화면은 후보를 모아 줍니다.

사용 방법

1. 회계연도와 기간(월)을 확인하고 필요하면 회사·은행·계좌·수수료 유형·청구일·점검 코드·점검 결과를 고릅니다. 처음 열면 2026년 09월이 채워져 자동으로 한 번 조회됩니다.
2. 조회 버튼(조회조건 영역의 오른쪽 끝)을 누르거나 입력란에서 Enter 를 누릅니다.
3. 위쪽 요약에서 청구 건수 · 청구 금액 합계 · 청구 과다 건수와 금액 · 장부 불일치 · 확인 필요 · 점검 필요 · 대사 차이를 먼저 봅니다.
4. 청구 명세 → 유형별 점검 → 은행별 대사 → 약정 수수료표 → 대사 결과 순으로 탭을 옮겨 봅니다.
5. 청구 명세의 행을 누르면 재계산 · 청구 · 장부 금액과 같은 계좌의 다른 청구가 상세 창에 열립니다.
6. CSV 내려받기 로 지금 보는 탭을 파일로 받아 은행에 확인할 자료로 씁니다.

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

수수료 점검에서 가장 비싼 질문은 “이 합계 맞아?” 입니다. 그래서 대사식을 먼저 세우고 샘플 데이터 전체에 돌렸습니다. 검증용 파일을 화면과 별개 코드로 다시 계산해 서비스 결과와 견준 값입니다.

대사식 9건 · 검사 87건이 모두 차이 0 입니다. 점검 화면이 보여 주려고 일부러 넣은 예외는 대사 차이와 섞이지 않도록 따로 세었습니다.

화면 쪽은 별도로 브라우저 자동화로 확인했습니다 — 조회·초기화·Enter 조회, 날짜 조건, 탭별 건수, 행 클릭 상세, CSV 내려받기, 좁은 화면 배치와 오류 안내를 실제로 돌려 보았습니다.

무엇으로 만들었나

실행 화면

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

처음 열었을 때

조회조건 · 요약 · 탭이 한 화면에 세로로 쌓입니다. 연 직후 자동으로 한 번 조회되어 빈 화면 없이 이번 달 청구가 바로 보입니다.

2026년 09월이 채워진 채 한 번 자동 조회됩니다. 위쪽 요약 줄에서 점검한 청구 건수(34건), 청구 금액 합계(1,300,286원), 청구 과다 건수와 금액(5건 · 33,980원), 장부 불일치·확인 필요·점검 필요 건수, 정합성 대사 차이 건수(0건)를 먼저 읽습니다. 표의 한 줄이 은행이 청구한 수수료 한 건이며, 재계산·청구·장부 금액이 나란히 놓입니다.

점검 필요만 추려 보기, 그리고 유형·은행 단위로

건마다 보는 화면에서 약정과 다른 청구만 추린 뒤, 같은 차이가 어느 유형과 은행에서 났는지 묶어서 봅니다.

조회조건에서 점검 결과를 점검 필요로 두고 조회 버튼을 누르면 해당 청구 10건만 남습니다. 청구 과다(F01) 5건, 장부 불일치(F03) 3건, 중복 의심(F05) 2건이 여기에 모입니다. 입력란에서 Enter 를 눌러도 같은 조회가 됩니다. 초기화를 누르면 기본값으로 돌아갑니다.

유형마다 재계산 합계, 청구 합계, 둘의 차이, 장부 반영 합계가 한 줄에 놓입니다. 예를 들어 회사 1000 의 타행 이체 수수료는 재계산 145,850원에 청구 150,850원으로 5,000원 차이가 보입니다. 유형 행의 점검 코드(T00·T01·T03)는 그 안의 청구 중 가장 무거운 판정을 따릅니다.

은행마다 재계산 합계·청구 합계·명세에 없는 항목·청구서 총액이 놓입니다. 가상은행B 는 청구서 총액 105,950원이 명세 합계 101,550원보다 4,400원 크고, 이 차이는 명세에 올라오지 않은 항목입니다. 이런 은행은 확인 필요로 표시되어 은행에 항목 내역을 요청하는 출발점이 됩니다.

약정표와 한 건의 상세 — 재계산의 근거

재계산이 어떤 약정 행을 썼는지, 한 건이 어떻게 계산되었는지를 끝까지 따라가는 화면입니다.

약정 행은 건당 정액(단가)이거나 금액 비례(요율과 건당 하한·상한)입니다. 유효기간이 청구일을 덮지 못하는 약정은 확인 필요로 보입니다. 이 표의 숫자는 검증용 가정값이며, 실제 적용 때는 회사가 은행과 정한 약정으로 바꿉니다.

청구 명세에서 행을 누르면 계산 기준(건수·거래 금액·적용 약정), 재계산과 청구와 장부 금액, 차이와 허용 오차, 확인할 제안이 한 창에 나옵니다. 아래에는 같은 계좌의 다른 청구가 이어져 중복 여부를 바로 비교할 수 있습니다. 예시의 88,000 USD 송금은 비례 요율로 계산하면 상한(45,000원)에 걸려 45,000원이어야 하는데 50,000원이 청구되었습니다.

대사 결과와 좁은 화면

합계가 서로 맞는지 건수와 차이로 확인하고, 같은 화면을 좁은 폭에서도 씁니다.

정합성 대사식 9건의 좌변·우변·검사 건수·차이 건수가 나옵니다. 아래쪽에 점검 화면이 보여 주려고 넣은 예외(청구 과다·과소·장부 불일치·약정 없음·중복 의심)가 따로 놓여 대사 차이와 섞이지 않습니다. 이 탭의 결과는 CSV 로 내려받아 은행에 확인할 자료로 쓸 수 있습니다.

화면 폭이 줄면 조회조건과 요약 지표가 여러 줄로 나뉘어 쌓이고, 표는 열을 숨기지 않고 가로로 밀어 보게 합니다. 탭과 조회 버튼의 위치는 그대로라 넓은 화면에서 익힌 순서로 쓸 수 있습니다. 열이 많은 청구 명세는 가로 공간이 넓은 화면에서 읽는 편이 편합니다.

화면 뒤에서 일어나는 일

서비스는 청구 한 줄마다 아래 순서로 판정합니다. 한 건에 여러 조건이 겹쳐도 점검 코드는 가장 앞선 하나만 붙습니다(우선순위 F04 > F05 > F01·F02 > F03).

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

폭이 줄면 조회조건과 요약 지표가 여러 줄로 나뉘어 쌓이고, 표는 열을 숨기지 않고 가로로 밀어 봅니다. 탭 순서와 조회 버튼의 자리는 그대로여서 같은 순서로 쓸 수 있습니다.

파일 구성

index.html · Component.js · manifest.json
controller/ (BaseController · Main.controller)   view/ (Main.view · DetailDialog.fragment)
model/ (formatter · ErrorHandler)   css/   i18n/
odata/ (서비스 정의 · 서비스 로직 · 샘플 데이터)
media/ (소개 영상 · 첫 장면)

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다. 은행 명세를 올리고 후처리하고 장부 라인을 확인하는 일은 모두 표준에 두고, 그 결과를 약정과 견주는 자리만 이어 붙였습니다.

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

T-code 별 연계 지점

법정 · 감사 · 세무 신고에 쓰는 보고서와 정정 전표는 표준에 그대로 둡니다. 따라서 운영 전환 때 기존 리포트를 없애지 않고, 한두 달 두 화면의 합계를 맞춰 본 뒤 쓰임새를 나눕니다.

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

S/4HANA 에서는 CDS 뷰 위에 분석 쿼리를 두고 Fiori 분석 앱이나 Analysis for Office 로 읽는 구성이 흔합니다. 이 화면의 서비스도 같은 CDS 뷰 위에 놓이는 것을 전제로 하며, 약정 재계산과 점검 판정을 뷰에서 계산해 다른 도구에서도 같은 숫자를 읽을 수 있게 합니다. 구체적인 표준 분석 앱 이름은 고객 환경에서 확인한 뒤에 연결합니다.

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

분석 지표 정의표

관련 기준서는 없으며 대상 영역은 자금 회계입니다. 이 화면은 점검 도구이며 최종 판단은 회사와 감사인이 합니다.

CDS 구성 — 약정 재계산에서 서비스까지

샘플 화면은 서비스 로직이 계산하지만, 운영에서는 같은 계산을 CDS 뷰에 둡니다. 아래는 그 구성의 스케치입니다. 표준 CDS 뷰 이름은 확인된 것만 쓰고, 명세·장부 원천은 테이블 기준으로 적었으며 원천 필드는 도입 때 “확인 필요”입니다.

뷰 레이어 구성

① 약정 수수료표 — 재계산의 유일한 기준

약정이 어디에 저장되는지가 곧 재계산의 신뢰도입니다. 은행 · 수수료 유형 · 유효 시작일을 키로 두어 약정이 바뀌어도 과거 청구를 그때의 약정으로 다시 계산할 수 있게 했습니다. 건당 정액과 금액 비례(요율 · 하한 · 상한)를 한 표에 담습니다.

// ─────────────────────────────────────────────────────────────
// ZBFEE_TARIFF — 은행 수수료 약정표 (고객 테이블)
// 역할 : 재계산의 유일한 기준. 은행·수수료 유형·유효기간마다 한 행.
// 이렇게 나눈 이유 : 약정이 바뀌면 코드가 아니라 이 표의 행만 바꾸게 하려는 것.
//   유효 종료일을 닫고 새 행을 여는 방식이라 과거 청구도 그때의 약정으로 다시 계산된다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '은행 수수료 약정표'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zbfee_tariff {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key bank_code  : abap.char(4) not null;
  key fee_type   : abap.char(2) not null;
  key valid_from : abap.dats not null;
  valid_to       : abap.dats;
  fee_mode       : abap.char(1);        // F 건당 정액 · P 금액 비례
  fee_waers      : waers;
  @Semantics.amount.currencyCode : 'zbfee_tariff.fee_waers'
  unit_fee       : abap.curr(15,2);
  rate_pct       : abap.dec(9,4);       // 0.1000 = 0.10 %
  @Semantics.amount.currencyCode : 'zbfee_tariff.fee_waers'
  min_fee        : abap.curr(15,2);
  @Semantics.amount.currencyCode : 'zbfee_tariff.fee_waers'
  max_fee        : abap.curr(15,2);
}

② 수수료 유형과 계정 매핑 — 회계팀이 관리하는 표

장부 라인에서 어떤 계정이 어떤 수수료 유형인지를 정하는 표입니다. 허용 오차도 여기에 두어 은행의 반올림 방식에 따라 유형마다 조정할 수 있습니다. 정하지 않으면 장부 금액을 청구와 연결하지 못합니다.

// ─────────────────────────────────────────────────────────────
// ZBFEE_TYPEMAP — 수수료 유형 ↔ 수수료 계정(G/L) 매핑 (고객 테이블)
// 역할 : 장부 라인에서 어떤 계정이 어떤 수수료 유형인지 한 곳에서 정한다.
// 이렇게 나눈 이유 : 계정이 새로 생겨도 한 행만 추가하면 되고, 뷰는 고치지 않는다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '수수료 유형-계정 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zbfee_typemap {
  key client   : abap.clnt not null;
  key bukrs    : bukrs not null;
  key fee_type : abap.char(2) not null;
  type_name    : abap.char(40);
  glaccount    : abap.char(10);         // 수수료 비용 계정
  tol_krw      : abap.dec(9,2);         // 허용 오차 (원화)
  tol_fx       : abap.dec(9,2);         // 허용 오차 (외화 단위)
}

③ 약정 행 뷰 — 통화 의미를 붙여 노출

큐브가 테이블을 직접 읽지 않고 이 뷰만 보게 합니다. 금액 필드에 통화 의미를 붙여 두면 이후 원화 환산이나 합산에서 통화가 다른 금액이 섞이는 일을 막을 수 있습니다.

// ─────────────────────────────────────────────────────────────
// ZI_BankFeeTariff — 약정 행 (기준 뷰)
// 역할 : 약정표를 표준 통화 의미(@Semantics)를 붙여 노출한다.
// 이렇게 나눈 이유 : 큐브가 약정표 테이블을 직접 읽지 않고 이 뷰만 보게 해서
//   약정표의 저장 구조가 바뀌어도 위쪽 뷰는 그대로 둔다.
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '약정 수수료표'
define view entity ZI_BankFeeTariff
  as select from zbfee_tariff
{
  key bukrs      as CompanyCode,
  key bank_code  as BankCode,
  key fee_type   as FeeType,
  key valid_from as ValidFrom,
      valid_to   as ValidTo,
      fee_mode   as FeeMode,
      fee_waers  as FeeCurrency,
      @Semantics.amount.currencyCode : 'FeeCurrency'
      unit_fee   as UnitFee,
      rate_pct   as RatePct,
      @Semantics.amount.currencyCode : 'FeeCurrency'
      min_fee    as MinFee,
      @Semantics.amount.currencyCode : 'FeeCurrency'
      max_fee    as MaxFee
}

④ 청구 한 줄 뷰 — 명세와 장부를 한 행에

청구 금액의 원천(은행 명세)과 장부 반영 금액의 원천(수수료 계정 라인)을 한 행에 모읍니다. 필드 이름은 고객의 명세 형식에 따라 달라지므로 도입 때 정하는 항목입니다.

// ─────────────────────────────────────────────────────────────
// ZI_BankFeeLine — 은행 청구 한 줄 (명세 + 장부 반영 금액)
// 역할 : 은행 명세의 수수료 항목 한 줄과 그 줄에 대응하는 장부 라인 금액을 한 행에 둔다.
// 이렇게 나눈 이유 : 청구 금액과 장부 금액의 원천이 달라 한 곳에서 합쳐야
//   "청구는 맞는데 장부가 다르다"를 뷰에서 계산할 수 있다.
// 원천 필드 : 명세 형식에 따라 달라지므로 도입 때 확인 필요 (스케치)
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행 수수료 청구 한 줄'
define view entity ZI_BankFeeLine
  as select from febep as s
    inner join   febko as k on  k.kukey = s.kukey
    left outer join zbfee_typemap as m
                    on  m.bukrs = k.bukrs and m.fee_type = s.zz_fee_type   // 확장 필드(확인 필요)
{
  key k.bukrs                       as CompanyCode,
  key s.kukey                       as StatementKey,
  key s.esnum                       as StatementItem,
      k.hbkid                       as HouseBank,
      k.hktid                       as AccountId,
      s.zz_fee_type                 as FeeType,
      s.vb1ok                       as StatementDate,            // 명세 일자(확인 필요)
      s.kwaers                      as FeeCurrency,
      @Semantics.amount.currencyCode : 'FeeCurrency'
      s.kwbtr                       as BilledFee,
      s.zz_qty                      as Quantity,                 // 건수(확인 필요)
      s.zz_txn_amt                  as TxnAmount,                // 거래 금액(확인 필요)
      @Semantics.amount.currencyCode : 'FeeCurrency'
      s.zz_book_fee                 as BookedFee                 // 장부 반영(장부 라인에서 채움)
}

⑤ 재계산·판정 큐브 — 숫자가 만들어지는 유일한 자리

정액과 비례의 계산, 하한·상한 적용, 약정 없음 판정이 여기서 결정됩니다. 화면 · 내려받기 · 대사가 모두 이 뷰의 값을 읽으므로 운영에서 가장 먼저 검증해야 하는 뷰입니다.

// ─────────────────────────────────────────────────────────────
// ZI_BankFeeRecalc — 재계산·판정 (큐브)
// 역할 : 청구 한 줄에 약정을 붙여 재계산 금액을 구하고, 청구·장부와의 차이와
//        점검 코드(F00~F04)를 계산한다. 같은 계좌 중복(F05)은 위 쿼리에서 윈도로 잡는다.
// 이렇게 나눈 이유 : 판정을 뷰 한 곳에서만 계산해 화면·CSV·대사가 같은 숫자를 쓰게 한다.
//   금액 비례는 clamp(거래 금액 × 요율, 하한, 상한), 정액은 단가 × 건수.
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수수료 재계산·판정'
define view entity ZI_BankFeeRecalc
  as select from ZI_BankFeeLine   as l
    left outer join ZI_BankFeeTariff as t
      on  t.CompanyCode = l.CompanyCode
      and t.BankCode    = l.HouseBank
      and t.FeeType     = l.FeeType
      and t.ValidFrom  <= l.StatementDate
      and ( t.ValidTo >= l.StatementDate or t.ValidTo = '00000000' )
{
  key l.CompanyCode, key l.StatementKey, key l.StatementItem,
      l.FeeType, l.FeeCurrency, l.StatementDate,
      @Semantics.amount.currencyCode : 'FeeCurrency'
      l.BilledFee,
      @Semantics.amount.currencyCode : 'FeeCurrency'
      l.BookedFee,
      @Semantics.amount.currencyCode : 'FeeCurrency'
      case t.FeeMode
        when 'F' then cast( t.UnitFee * l.Quantity as abap.curr(15,2) )
        when 'P' then cast(
             case when l.TxnAmount * t.RatePct / 100 < t.MinFee then t.MinFee
                  when l.TxnAmount * t.RatePct / 100 > t.MaxFee then t.MaxFee
                  else l.TxnAmount * t.RatePct / 100 end * l.Quantity
             as abap.curr(15,2) )
        else cast( 0 as abap.curr(15,2) ) end         as ExpectedFee,
      case when t.FeeMode is null then 'F04'          // 약정 없음(미등록·유효기간 밖)
           else 'CALC' end                            as PreCode
}

⑥ 청구 조회 쿼리 — 화면 컬럼과 필터 규칙

회사코드는 필수 단일 선택, 청구일은 범위로 거는 식의 조회 규칙을 한 곳에 둡니다. 차이와 점검 코드를 여기서 계산해 화면이 별도 계산을 하지 않게 합니다.

// ─────────────────────────────────────────────────────────────
// ZC_BankFeeCharge — 화면용 조회 쿼리 (Consumption)
// 역할 : 청구 명세 탭이 읽는 한 줄. 차이·판정을 계산해 화면 컬럼으로 노출한다.
// 이렇게 나눈 이유 : 화면 컬럼·필터·정렬 규칙(@UI·@Consumption)을 한 곳에 모아
//   서비스와 화면이 같은 정의를 쓰게 한다. 원화 환산은 청구일 환율로 한다.
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수수료 청구 점검'
@Metadata.allowExtensions : true
define view entity ZC_BankFeeCharge
  as select from ZI_BankFeeRecalc
{
  @Consumption.filter : { selectionType : #SINGLE, mandatory : true }
  key CompanyCode,
  key StatementKey,
  key StatementItem,
      @Consumption.filter.selectionType : #RANGE
      StatementDate,
      @UI.lineItem : [{ position : 10 }]
      FeeType,
      @UI.lineItem : [{ position : 20 }]
      FeeCurrency,
      @UI.lineItem : [{ position : 30 }]
      ExpectedFee,
      @UI.lineItem : [{ position : 40 }]
      BilledFee,
      @UI.lineItem : [{ position : 50 }]
      BilledFee - ExpectedFee                       as FeeDiff,
      @UI.lineItem : [{ position : 60 }]
      BookedFee - BilledFee                         as BookDiff,
      @UI.lineItem : [{ position : 70, criticality : 'Criticality' }]
      case when ExpectedFee = 0 and PreCode = 'F04' then 'F04'
           when BilledFee - ExpectedFee >  1 then 'F01'
           when BilledFee - ExpectedFee < -1 then 'F02'
           when BookedFee <> BilledFee       then 'F03'
           else 'F00' end                           as CheckCode
}

⑦ 은행별 대사 — 청구서 총액과 명세 합계

은행이 보낸 청구서 총액은 명세와 다른 원천이라 별도 뷰로 비교합니다. 차이는 명세에 올라오지 않은 항목이며, 확인 필요로 올려 은행에 항목 내역을 요청하는 출발점이 됩니다.

// ─────────────────────────────────────────────────────────────
// ZI_BankFeeBankRecon — 은행별 청구서 총액 대사
// 역할 : 은행 청구서 총액(은행 문서)과 명세 합계를 비교해 명세 외 항목을 드러낸다.
// 이렇게 나눈 이유 : 청구서 총액은 명세와 다른 원천이라 별도 뷰로 두고,
//   차이가 있으면 B01(확인 필요)·B02(점검 필요)로 올린다.
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '은행별 청구서 대사'
define view entity ZI_BankFeeBankRecon
  as select from ZI_BankFeeRecalc as r
    left outer join zbfee_stmt_total as s            // 은행 청구서 총액(고객 테이블)
      on s.bukrs = r.CompanyCode and s.bank_code = r.StatementKey
{
  key r.CompanyCode,
  key s.bank_code                                    as BankCode,
      sum( r.BilledFee )                             as StatementSum,
      max( s.stmt_total )                            as InvoiceTotal,
      max( s.stmt_total ) - sum( r.BilledFee )       as OutsideStatement
}
group by r.CompanyCode, s.bank_code

⑧ 접근 제어 — 회사코드 권한

집계 뷰까지 같은 권한을 상속해야 합계로 다른 회사의 금액이 드러나지 않습니다. 드릴다운에만 권한을 걸면 뺄셈으로 새어 나갈 수 있어 집계 단계에 겁니다.

// ─────────────────────────────────────────────────────────────
// ZC_BankFeeCharge — 접근 제어 (DCL)
// 역할 : 회사코드 권한이 없는 회사의 청구는 합계로도 보이지 않게 한다.
// 이렇게 나눈 이유 : 집계 뷰까지 같은 규칙을 상속해야 합계로 새는 일이 없다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '수수료 청구 점검 권한'
@MappingRole : true
define role ZC_BankFeeCharge {
  grant select on ZC_BankFeeCharge
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑨ 서비스 정의와 바인딩 — 화면이 읽는 계약

노출 목록이 곧 화면과의 계약입니다. 바인딩을 게시한 뒤 서비스를 활성화하고, 앱 설정의 서비스 주소만 운영 주소로 바꿉니다.

// ─────────────────────────────────────────────────────────────
// ZUI_BankFeeCheck — 서비스 정의와 바인딩 (OData V2)
// 역할 : 화면이 읽는 뷰를 서비스로 노출한다.
// 이렇게 나눈 이유 : 노출 목록이 곧 계약이므로 한 파일에 모아 두고,
//   바인딩을 게시한 뒤 앱 설정의 서비스 주소만 바꿔 운영에 연결한다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '수수료 청구 점검 서비스'
define service ZUI_BankFeeCheck {
  expose ZC_BankFeeCharge     as ChargeSet;
  expose ZI_BankFeeBankRecon  as BankSet;
  expose ZI_BankFeeTariff     as TariffSet;
}
// Service Binding : 유형 OData V2 - UI, 게시 후 서비스 활성화

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 여덟 가지는 코딩이 아니라 합의이며, 합의가 끝나면 기술 작업은 뷰를 만들고 서비스를 게시하는 일로 줄어듭니다.

운영 데이터로 갈 때

월 청구 건수가 수만 건을 넘으면 조회조건(회사 · 기간)을 필수로 두고 청구 명세를 페이지 단위로 읽는 것이 기본입니다. 유형별 · 은행별 집계는 뷰에서 미리 묶어 응답 시간을 일정하게 유지하고, 약정 조인은 약정 행이 적으므로 인덱스 없이도 부담이 작습니다. 응답 시간 기준은 고객 환경에서 정한 뒤 시험으로 확인합니다.

자주 묻는 질문

숫자와 산식 · 화면과 조작 · 데이터와 표준 연계 · 도입과 운영 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

데이터와 표준 연계

도입과 운영