SAP 환전·송금 환율 스프레드 점검 — 은행에 더 낸 원화를 기준 환율로 다시 계산해 허용 범위·은행 통지·장부와 견주는 자금 화면

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

외화를 사거나 팔 때, 해외로 송금할 때 자금 담당이 마주치는 질문은 늘 비슷합니다. 은행이 적용한 환율이 그날의 기준 환율과 얼마나 벌어졌는가, 그 차이가 회사가 은행과 정한 허용 범위 안인가, 은행 통지서의 원화 금액과 장부의 원화 금액은 같은가. 지금은 이 세 답이 은행 통지서, 환율 표, 장부 라인 조회에 흩어져 있어서 한 번에 맞춰 보기 어렵습니다. 한 건씩 보면 환율 차이는 소수점 둘째 자리 이하의 일이라 “원래 그 정도”로 넘어가기 쉽지만, 금액이 큰 거래가 쌓이면 은행에 더 낸 원화가 합계로 드러납니다.

이 앱은 외화 금액에 적용 환율을 곱한 원화와 기준 환율을 곱한 원화를 거래마다 다시 구하고, 둘의 차이를 스프레드 비용(은행에 더 낸 원화)으로 보여 줍니다. 그 비용을 기준 원화로 나눈 스프레드(%)가 회사가 정한 허용 퍼센트를 넘으면 점검 필요로 표시하고, 은행 통지 원화와 장부 원화가 어긋난 거래도 함께 가립니다. 관련 기준서는 없고 대상 영역은 자금(외화 환전·송금)입니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다.

환율 차이는 작아 보여도 거래 금액이 크면 합계가 커진다

이 샘플의 한 해외 송금 거래는 160,649.51 EUR 를 적용 환율 1,541.42 로 보냈는데 같은 날 기준 환율은 1,530.22 입니다. 환율 차이는 1% 도 되지 않지만 원화로는 약 180만 원이고, 회사가 정한 허용(0.50%)을 넘은 부분만 해도 57만 원입니다. 건별 통지서만 보면 환율 숫자가 그럴듯해 보이므로, 기준 환율과 나란히 놓고 퍼센트로 바꿔 보아야 차이가 보입니다.

허용 스프레드는 통화와 거래 유형마다 다르다

외화를 살 때와 팔 때, 송금할 때의 허용 범위는 같지 않고 통화마다도 다릅니다. 이 화면은 통화·거래 유형별 허용 퍼센트를 정책표로 두고, 거래마다 그 값을 찾아 견줍니다. 정책표에 없는 통화나 거래 유형은 허용 여부를 판단할 수 없으므로 확인 필요로 남깁니다. 허용 값 자체는 회사가 은행과 협의해 정하는 값입니다.

은행 통지 금액과 장부 금액이 다르면 마감 뒤에야 드러난다

은행이 알려 준 원화 금액이 외화 금액 × 적용 환율과 다르거나, 장부에 기표된 원화가 은행 통지와 다르면 환율 문제와는 별개의 확인 대상입니다. 이 화면은 두 차이를 허용 오차(1원)를 넘는 경우에만 따로 가려 점검 필요와 확인 필요로 표시하므로, 전표 금액이나 통지서 환율을 마감 전에 확인할 수 있습니다.

기준 환율의 선택에 따라 결론이 달라질 수 있다

어떤 환율 유형을 어떤 날짜 기준으로 쓸지는 회사 정책으로 정할 일입니다. 샘플은 같은 날의 기준 환율(가정값)을 쓰지만, 실제 적용 때는 환율 표(OB08 에서 유지하는 값)와 환산 시점을 회사가 정해 연결해야 합니다. 이 화면은 그 선택을 대신하지 않으며, 선택한 기준에 따라 스프레드가 얼마로 보이는지를 보여 줍니다.

사용 방법

1. 회계연도와 기간(월)을 확인하고 필요하면 회사·은행·통화·거래 유형·거래일·점검 코드·점검 결과를 고릅니다. 처음 열면 2026년 09월이 채워져 자동으로 한 번 조회됩니다. 비워 두면 “전체”입니다.
2. 조회 버튼(조회조건 영역의 오른쪽 끝, 초기화 옆)을 누르거나 입력란에서 Enter 를 누릅니다.
3. 위쪽 요약에서 점검한 거래 건 · 기준 원화 합계 · 스프레드 비용 합계 · 허용 초과 건과 금액 · 확인 필요 · 점검 필요 · 정합성 대사 차이를 먼저 봅니다.
4. 거래 명세 → 은행·통화 집계 → 허용 스프레드 정책 → 기준 환율 → 대사 결과 순서로 탭을 옮겨 봅니다.
5. 거래 명세의 행을 누르면 환율 · 스프레드 · 원화 금액과 같은 은행·통화의 다른 거래가 상세 창에 열립니다.
6. CSV 내려받기 로 지금 보는 탭을 UTF-8(BOM) 파일로 받아 은행에 확인할 자료로 씁니다.

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

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

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

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

무엇으로 만들었나

실행 화면

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

처음 열었을 때와 점검 필요 거래만 보기

조회 조건을 넣어 요약부터 읽고, 약정과 다른 거래만 추려 봅니다.

2026년 09월이 채워진 채 한 번 자동 조회됩니다. 위쪽 요약 줄에서 점검한 거래 건수(92건), 기준 원화 합계(4,769,646,473원), 스프레드 비용 합계(+15,327,517원), 허용 초과 건수와 금액(16건 · 1,982,431원), 확인 필요 4건 · 점검 필요 18건, 정합성 대사 차이 건수(0건)를 먼저 읽습니다. 표에는 거래마다 외화 금액, 적용 환율, 기준 환율, 스프레드(%)와 허용(%)이 한 줄에 놓입니다.

조회조건에서 점검 결과를 점검 필요로 두고 조회 버튼을 누르면 해당 거래 18건만 남습니다. 허용 스프레드를 넘은 거래(S01) 16건과 은행 통지 금액이 다시 구한 원화와 다른 거래(S02) 2건이 모입니다. 입력란에서 Enter 를 눌러도 같은 조회가 되고, 초기화를 누르면 기본값으로 돌아갑니다.

은행·통화 집계와 허용 스프레드 정책

같은 차이가 어느 은행·통화에서 났는지 묶어 보고, 판정의 기준이 되는 허용 값을 확인합니다.

은행·통화마다 거래 건수, 외화 합계, 기준 원화, 스프레드 비용, 평균·최대 스프레드, 허용 초과 건수가 한 줄에 놓입니다. 예를 들어 가상은행A 의 USD 는 11건에서 스프레드 비용이 +2,331,270원이고 허용을 넘은 거래가 3건(178,183원) 있어 점검 필요로 표시됩니다. 정책표에 없는 통화(GBP)가 섞인 행은 확인 필요입니다.

통화와 거래 유형(외화 매수 · 외화 매도 · 해외 송금)마다 허용 스프레드(%)와 유효기간이 한 줄씩 있습니다. 이 값은 회사가 거래 은행과 협의해 정하는 값이며 화면의 숫자는 검증용 가정값입니다. 일부러 GBP 정책을 비워 두어, 정책이 없는 거래가 확인 필요로 남는 모습을 볼 수 있게 했습니다.

대사 결과와 한 거래의 상세

합계가 서로 맞는지 건수와 차이로 확인하고, 한 거래의 계산을 끝까지 따라갑니다.

통화별 은행 통지 원화 대사와 장부 원화 대사, 그리고 스프레드 비용·집계 합계·건수에 관한 정합성 대사식이 좌변·우변·검사 건수·차이 건수와 함께 나옵니다. 점검 화면이 보여 주려고 일부러 넣은 예외(통지 금액 차이 · 장부 금액 차이)는 차이 건수로 따로 드러나고, 정합성 대사식의 차이는 0건입니다.

환율(적용 · 기준 · 외화 금액), 스프레드(퍼센트 · 비용 · 허용 · 허용 초과), 원화 금액(재계산 · 은행 통지 · 장부), 차이와 허용 오차, 확인할 제안이 한 창에 나옵니다. 아래에는 같은 은행·같은 통화의 이번 기간 거래가 이어져 한 거래가 평소 수준과 얼마나 다른지 바로 견줄 수 있습니다. 예시의 JPY 거래는 스프레드 +0.7971% 로 허용 0.60% 를 넘어 점검 필요입니다.

화면 뒤에서 일어나는 일

서비스는 거래 한 줄마다 아래 순서로 계산하고 판정합니다. 한 거래에 여러 조건이 겹쳐도 점검 코드는 가장 앞선 하나만 붙습니다(우선순위 S04 > S02 > S03 > S01).

판정은 “점검 필요”와 “확인 필요”로만 표시하며 원인을 단정하지 않습니다. 환율 차이가 허용을 넘었다는 사실과, 그것이 부당한 거래라는 결론은 다릅니다.

조회조건

결과 컬럼

파일 구성

index.html · readme.html · Component.js · manifest.json
controller/  BaseController.js · Main.controller.js
view/        Main.view.xml · DetailDialog.fragment.xml
model/       formatter.js · ErrorHandler.js
css/ i18n/   style.css · i18n_ko.properties
odata/fxspread_srv/  metadata.xml · service.js · json/(엔티티셋별 데이터)
media/       intro.mp4 · intro_poster.jpg
test/        검증 전용 (샘플 데이터 화면)

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다. 은행 통지를 처리하고 장부 라인을 확인하고 환율을 유지하는 일은 모두 표준에 두고, 그 결과를 기준 환율·허용 값과 견주는 자리만 이어 붙였습니다.

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

T-code 별 연계 지점

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

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

S/4HANA 에서는 CDS 뷰 위에 분석 쿼리를 두고 Fiori 분석 앱이나 Analysis for Office 로 읽는 구성이 흔합니다. 이 화면의 서비스도 같은 CDS 뷰 위에 놓이는 것을 전제로 하며, 재계산과 허용 판정을 뷰에서 계산해 화면 · 내려받기 · 대사가 같은 숫자를 읽도록 합니다. 아래 CDS 구성은 그 스케치입니다.

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

분석 지표 정의표

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

CDS 구성 — 기준 환율에서 서비스까지

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

뷰 레이어 구성

① 허용 스프레드 정책표 — 판정의 유일한 기준

허용 퍼센트가 어디에 저장되는지가 곧 판정의 신뢰도입니다. 회사 · 통화 · 거래 유형 · 유효 시작일을 키로 두어 정책이 바뀌어도 과거 거래를 그때의 값으로 다시 판정할 수 있게 했습니다.

// ─────────────────────────────────────────────────────────────
// FxSpreadPolicy — 허용 스프레드 정책표 (고객 테이블)
// 역할 : 통화·거래 유형별로 회사가 은행과 협의해 정한 허용 퍼센트를 둔다.
// 이렇게 나눈 이유 : 허용 값이 바뀌어도 뷰·화면 코드를 고치지 않으려고.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '환전·송금 허용 스프레드'
@AbapCatalog.tableCategory : #TRANSPARENT
define table fxspread_policy {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key waers      : waers not null;
  key trtype     : abap.char(1) not null;   // B 외화 매수 · S 외화 매도 · R 해외 송금
  key valid_from : abap.dats not null;
  valid_to       : abap.dats;
  max_pct        : abap.dec(9,4);           // 허용 스프레드(%) — 회사 정책으로 확정
}

② 거래 한 줄 뷰 — 장부와 기준 환율을 한 행에

외화 금액·장부 원화의 원천(전표 라인)과 기준 환율의 원천(환율 테이블)을 한 행에 모읍니다. 환율 유형과 적용일 기준은 회사 정책으로 정하는 항목이라 도입 때 확인합니다.

// ─────────────────────────────────────────────────────────────
// FxTradeBase — 환전·송금 거래 한 줄 (전표 라인 + 기준 환율)
// 역할 : 외화 금액과 장부 원화, 같은 날 기준 환율을 한 행에 모은다.
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '환전·송금 거래 기준 원화'
define view entity FxTradeBase as select from acdoca
  association [0..1] to tcurr as _Rate on  _Rate.kurst = 'M'      // 환율 유형 — 확인 필요
                                       and _Rate.fcurr = acdoca.rwcur
                                       and _Rate.tcurr = acdoca.rhcur
{
  key rbukrs as Bukrs, key gjahr as Gjahr, key belnr as DocNo, key docln as DocItem,
  budat as TrDate, rwcur as Waers,
  @Semantics.amount.currencyCode : 'Waers'     wsl as FcAmt,
  rhcur as LocalCurr,
  @Semantics.amount.currencyCode : 'LocalCurr' hsl as BookKrw,
  _Rate
}

③ 스프레드·판정 큐브 — 숫자가 만들어지는 유일한 자리

기준 원화, 스프레드 비용, 허용 초과, 점검 코드가 여기서 결정됩니다. 화면 · 내려받기 · 대사가 모두 이 뷰의 값을 읽으므로 운영에서 가장 먼저 검증해야 하는 뷰입니다.

// ─────────────────────────────────────────────────────────────
// FxSpreadCube — 스프레드·판정 (큐브)
// 역할 : 거래마다 기준 원화·스프레드 비용·허용 초과를 구하고 점검 코드를 붙인다.
// 이렇게 나눈 이유 : 판정을 뷰 한 곳에서만 계산해 화면·CSV·대사가 같은 숫자를 쓰게 한다.
// ─────────────────────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@EndUserText.label : '환전·송금 스프레드 판정'
define view entity FxSpreadCube as select from FxTradeBase as t
  left outer join fxspread_policy as p
    on  p.bukrs = t.Bukrs and p.waers = t.Waers
    and p.valid_from <= t.TrDate and ( p.valid_to >= t.TrDate or p.valid_to = '00000000' )
{
  key t.Bukrs, key t.Gjahr, key t.DocNo, key t.DocItem,
  t.TrDate, t.Waers, t.FcAmt, t.BookKrw,
  p.max_pct as MaxPct,
  // 기준 원화 = 외화 금액 × 기준 환율, 스프레드 비용 = 방향부호 × (재계산 − 기준)
  cast( 0 as abap.dec(18,0) ) as SpreadKrw,        // 적용 환율은 은행 통지 자료에서 받는다 — 확인 필요
  case when p.max_pct is null then 'S04'            // 정책 없음 → 확인 필요
       else 'CALC' end        as PreCode
}

④ 거래 조회 쿼리 — 화면 컬럼과 필터 규칙

회계연도 · 기간은 필수, 회사 · 은행 · 통화 · 거래 유형은 선택으로 두는 조회 규칙을 한 곳에 둡니다. 스프레드(%)와 점검 코드를 여기서 계산해 화면이 별도 계산을 하지 않게 합니다.

// ─────────────────────────────────────────────────────────────
// FxSpreadQuery — 화면용 조회 쿼리 (Consumption)
// 역할 : 거래 명세 탭이 읽는 한 줄. 스프레드(%)와 점검 코드를 여기서 계산한다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '환전·송금 거래 조회'
define view entity FxSpreadQuery as select from FxSpreadCube
{
  key Bukrs, key Gjahr, key DocNo, key DocItem, TrDate, Waers, FcAmt, BookKrw, MaxPct, SpreadKrw,
  // 스프레드(%) = 스프레드 비용 ÷ 기준 원화 × 100 — 기준 원화가 0 이면 비워 둔다
  cast( 0 as abap.dec(9,4) ) as SpreadPct,
  PreCode as CheckCode
}

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

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

// ─────────────────────────────────────────────────────────────
// FxSpreadQuery — 접근 제어 (DCL)
// 역할 : 회사코드 권한이 없는 회사의 거래는 합계로도 보이지 않게 한다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '환전·송금 거래 권한'
@MappingRole : true
define role FxSpreadQueryRole {
  grant select on FxSpreadQuery
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

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

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

// ─────────────────────────────────────────────────────────────
// FxSpreadCheck — 서비스 정의와 바인딩 (OData V2)
// 역할 : 화면이 읽는 뷰를 서비스로 노출한다.
// 이렇게 나눈 이유 : 노출 목록이 곧 계약이므로 한 파일에 모아 두고,
//   바인딩을 게시한 뒤 앱 설정의 서비스 주소만 바꿔 운영에 연결한다.
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '환전·송금 스프레드 점검 서비스'
define service FxSpreadCheck {
  expose FxSpreadQuery   as TradeSet;
  expose FxSpreadPairs   as PairSet;
  expose FxSpreadPolicy  as PolicySet;
}
// Service Binding : 유형 OData V2 - UI, 게시 후 서비스 활성화

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

월 거래 건수가 수만 건을 넘으면 조회조건(회사 · 기간)을 필수로 두고 거래 명세를 페이지 단위로 읽는 것이 기본입니다. 은행·통화 집계는 뷰에서 미리 묶어 응답 시간을 일정하게 유지하고, 기준 환율은 환율일별로 한 번만 가져오도록 조인을 설계합니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

데이터와 표준 연계

도입과 운영