SAP 환율관리 — 은행 고시환율을 하루 한 번 안전하게 올리기
은행이 아침에 고시한 환율 파일을 기준일부터 맞춰 보고, 이미 올린 날이면 지우고 다시 올릴지 확인한 뒤 TCURR에 반영하는 화면입니다.
환율은 하루에 한 번만 제대로 올리면 되는 데이터입니다. 그런데 이 단순한 작업이 틀어지면 그날 만든 외화 전표가 전부 잘못됩니다.
실수는 대개 둘 중 하나입니다. 어제 파일을 오늘 날짜로 올리거나, 이미 올린 날에 다시 올려 값이 겹치는 것입니다. 그래서 이 화면은 업로드 버튼을 누르면 바로 넣지 않고 세 단계를 거칩니다. 파일 안의 기준일이 조회 일자와 같은지 보고, 그날 환율이 이미 있는지 확인하고, 지우고 다시 올릴지 담당자에게 물어본 뒤에야 TCURR에 반영합니다.
SAP 표준 구조를 그대로 이어받은 부분
- 환율 저장 —
TCURR구조 그대로 (GDATU · KURST · FCURR · TCURR · UKURS) - 통화 명칭 —
TCURT에서 조회 - 일자 변환 —
CONVERSION_EXIT_INVDT_INPUT으로 TCURR 역순 일자 형식 변환 - 등록 처리 —
BAPI_EXCHRATE_CREATEMULTIPLE호출 후BAPI_TRANSACTION_COMMIT
| 항목 | 내용 |
|---|---|
| 업무 영역 | 재무회계(FI) · 환율 마스터 |
| Namespace | zui5.exrate |
| 셸 구조 | 조회조건 영역(우측 조회·업로드) + 통화별 환율 목록 |
| 화면 수 | 조회·업로드 화면 1개 |
| 데이터 | 통화 8종 × 환율 6종 = TCURR 48라인 |
| 성격 | 조회·등록형(CRU) — 등록은 표준 BAPI 가 수행 |
| UI 테마 | sap_horizon 단일 적용 |
실제 화면 9종 둘러보기
일자를 정해 조회하면 등록 여부가 보입니다 → 파일을 고르면 기준일이 대조되고 → 업로드가 3단계 점검을 거쳐 반영합니다.
아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.
조작 방법
- Date 를 확인합니다. 기본값은 오늘이며, 이 일자가 조회와 업로드의 기준이 됩니다.
- 등록된 환율이 없으면 통화 레이아웃만 나옵니다. 등록여부 칸으로 무엇이 비었는지 확인합니다.
- 파일 선택으로 은행 고시 파일을 고릅니다. 파일 기준일이 바로 표시되어 일치 여부를 알 수 있습니다.
- 업로드를 누르면 기준일 점검 → 중복 확인 → 등록 순으로 진행됩니다.
- 이미 올린 날이면 삭제 후 재업로드 여부를 묻습니다. 아니오를 고르면 아무것도 바뀌지 않습니다.
- 등록이 끝나면 화면이 자동으로 다시 조회됩니다. CSV 다운로드로 그날 환율을 내려받을 수 있습니다.
환율 6종과 산출 관계
은행이 고시하는 여섯 항목이 SAP 환율종류와 1:1로 대응합니다.
업로드 3단계 점검
1) 기준일 점검
엑셀 B4 의 기준일 = 조회 일자 ?
다르면 → "Exchange Rate Date Error" 출력 후 중단
2) 당일 환율 등록 여부
TCURR 에 그 일자 데이터가 한 건이라도 있으면
→ "Already upload Exchange Rate. Do you want to Delete and re-Upload ?"
Yes → 해당 일자 환율 삭제 후 3) 진행
No → 작업 취소
3) 업로드
통화명(A열) 파싱 → 6종 환율을 TCURR 에 등록
KURST : M · CB · CS · TTB · TTS · EXD
FCURR : 업로드 통화 TCURR : KRW
GDATU : 입력된 일자 UKURS : 업로드 환율
BAPI_EXCHRATE_CREATEMULTIPLE → BAPI_TRANSACTION_COMMIT → 화면 Refresh| 항목 | 산식 · 규칙 |
|---|---|
매매기준율 M | 은행 고시 기준율. 나머지 환율의 중심 |
현찰사실때 CB | 기준율보다 높음 — 현찰 매도 스프레드 반영 |
현찰파실때 CS | 기준율보다 낮음 |
전신환매입 TTB | 기준율보다 낮으나 현찰보다 폭이 좁음 |
전신환매도 TTS | 기준율보다 높으나 현찰보다 폭이 좁음 |
미화환산율 EXD | 해당 통화 기준율 ÷ USD 기준율. USD 는 1 |
환산단위 FFACT | JPY 는 100단위, 그 외는 1단위 |
삭제 후 재등록으로 처리하는 이유
부분 갱신을 하면 파일에 없는 통화의 이전 값이 남습니다. 은행이 어떤 통화를 빼고 고시한 날, 그 통화만 어제 값으로 남아 있으면 전표 환산이 조용히 틀어집니다. 그 일자를 통째로 지우고 파일 내용으로 다시 채우면 화면에 보이는 값과 저장된 값이 항상 같습니다.
업로드 3단계
업로드 버튼을 누르면 바로 넣지 않고 세 단계를 차례로 거칩니다.
| 단계 | 점검 내용 | 결과 | 막아 주는 실수 |
|---|---|---|---|
| 1. 기준일 점검 | 엑셀 B4 와 조회 일자 비교 | 불일치 시 중단 | 어제 파일을 오늘로 올리는 실수를 막음 |
| 2. 중복 확인 | TCURR 에 해당 일자 데이터 존재 여부 | 있으면 재업로드 여부 확인 | 값이 겹쳐 쌓이는 것을 막음 |
| 3. 등록 | 통화명 파싱 후 6종 환율 생성 | BAPI 호출 후 COMMIT | 등록 후 화면 자동 갱신 |
세 단계를 모두 지나야 TCURR 이 바뀌므로, 잘못 올려 전표 환산이 틀어지는 일이 없습니다.
조회조건
| 필드 | 필수 | 설명 |
|---|---|---|
| Date | 필수 | 기본값 오늘. 이 일자로 TCURR 을 조회하고 업로드 기준이 됨 |
| 업로드 파일 | 선택 | 은행 고시환율 엑셀. 선택 시 기준일을 읽어 표시 |
| 오늘 | 보조 | 조회 일자를 오늘로 되돌림 |
결과 컬럼
| 컬럼 | 의미 · 표시 |
|---|---|
| 통화코드 · 통화명 | TCURT 의 통화와 명칭 |
| 환산단위 | JPY 100단위처럼 1이 아닌 경우만 표시 |
| 매매기준율 (M) | 고시 기준율. 강조 표시 |
| 현찰사실때 · 현찰파실때 | 현찰 거래 환율 |
| 전신환매입 · 전신환매도 | 송금 거래 환율 |
| 미화환산율 (EXD) | USD 대비 환산율, 소수 4자리 |
| 현찰 스프레드 | 현찰 사실 때 − 파실 때 (계산값) |
| 등록여부 | 해당 일자에 환율이 들어와 있는지 |
보조 기능
| 컬럼 | 의미 · 표시 |
|---|---|
| 파일 기준일 | 선택한 파일의 기준일과 일치 여부를 색으로 표시 |
| 업로드 상태 | 파일 선택 전 / 업로드 대기 / 업로드 완료 |
| CSV | 조회한 일자의 통화별 환율을 그대로 내려받기 |
SAP 표준 기능 매핑
환율 등록은 표준 BAPI 가 수행합니다. 이 화면은 그 앞에서 점검하고 결과를 보여 줍니다.
| 표준 | 역할 | 이 화면에서의 확장 |
|---|---|---|
TCURR | 환율 테이블 | 일자 × 환율종류 × 통화 단위로 저장 |
TCURT | 통화 명칭 | 통화코드 옆에 명칭 표시 |
BAPI_EXCHRATE_CREATEMULTIPLE | 환율 일괄 등록 | 통화 × 환율종수 만큼 한 번에 전달 |
OB08 관점 | 환율 수기 유지보수 | 건수가 적거나 예외 건은 표준 화면에서 |
CONVERSION_EXIT_INVDT_INPUT | 일자 변환 | TCURR 의 역순 일자 형식으로 변환 |
| 외화 전표 · 평가 | 환산 기준 | 이 화면에서 올린 환율을 참조 |
운영 데이터 소스 매핑
| 항목 | SAP 원천 | 비고 |
|---|---|---|
| 환율 | TCURR | GDATU · KURST · FCURR · TCURR · UKURS · FFACT |
| 통화 명칭 | TCURT | 통화코드별 텍스트 |
| 기준일 | 엑셀 B4 | 조회 일자와 대조하는 값 |
| 환율종류 | M · CB · CS · TTB · TTS · EXD | 은행 고시 항목과 1:1 대응 |
| 권한 | FI 재무팀 권한 | 사양서 권한 점검 요구사항 |
도입 시 확인이 필요한 부분
은행마다 고시 항목명과 엑셀 레이아웃이 다릅니다. 기준일 셀 위치와 통화명 파싱 규칙을 은행별로 설정에 두면 거래 은행이 바뀌어도 프로그램을 고치지 않아도 됩니다. 환산단위(TCURF)가 등록되지 않은 통화는 환율이 100배 어긋나므로 통화 추가 시 함께 확인해야 합니다.
참고 CDS 뷰
등록된 환율을 조회할 때는 통화 명칭과 환산단위를 붙인 뷰가 편합니다.
@AbapCatalog.sqlViewName: 'ZCEXRATE'
@EndUserText.label: '일자별 고시환율 (Z)'
define view Z_C_EXCHANGE_RATE
as select from tcurr as Rate
left outer join tcurt as CurrText on Rate.fcurr = CurrText.waers
and CurrText.spras = $session.system_language
left outer join tcurf as Factor on Rate.kurst = Factor.kurst
and Rate.fcurr = Factor.fcurr
and Rate.tcurr = Factor.tcurr
{
key Rate.kurst as RateType,
key Rate.fcurr as FromCurrency,
key Rate.tcurr as ToCurrency,
key Rate.gdatu as ValidFromInverted,
CurrText.ltext as CurrencyName,
Rate.ukurs as ExchangeRate,
Factor.ffact as FromFactor,
Factor.tfact as ToFactor,
// 환산단위를 반영한 실제 환율
Rate.ukurs / Factor.ffact * Factor.tfact as EffectiveRate
}등록된 환율을 조회하거나 전표 환산값과 대조할 때 쓰는 참고용 설계입니다. GDATU 는 역순 일자이므로 조회 시 변환이 필요합니다.
OpenUI5 구성
| 기능 | 사용 컨트롤 |
|---|---|
| 화면 골격 | sap.m.Page + 조회조건 영역 · 환율 목록 |
| 조회조건 | sap.m.DatePicker · sap.m.Input — 우측 끝에 조회·업로드 |
| 환율 목록 | sap.ui.table.Table — 통화코드·통화명 2컬럼 고정 |
| 기준일 표시 | sap.m.ObjectStatus — 일치 초록 · 불일치 빨강 |
| 미등록 표시 | RowSettings.highlight + 등록여부 컬럼 |
| 확인 흐름 | MessageBox.confirm — 재업로드는 Yes/No 버튼 |
| CSV | Blob + UTF-8 BOM |
기준일을 파일 선택 단계에서 보여 주는 이유
업로드를 누른 뒤에 에러가 나오면 이미 한 번 헛걸음한 셈입니다. 파일을 고르는 즉시 안의 기준일을 읽어 조회 일자와 맞는지 색으로 표시하면, 업로드를 누르기 전에 파일을 다시 받을지 날짜를 바꿀지 판단할 수 있습니다.
파일 구성
| 경로 | 역할 |
|---|---|
manifest.json | 앱 디스크립터 — 앱 ID(zui5.exrate) · ko 로케일 · sap_horizon |
Component.js | 조회조건 모델 · 결과 모델 초기화 |
view/Main.view.xml | 조회화면 + 통화별 환율 목록 |
controller/Main.controller.js | 조회 · 파일 선택 · 3단계 점검 · 업로드 · CSV |
model/ModelMock.js | TCURR 시뮬레이션 · 기준일 점검 · 삭제 · 등록 |
model/formatter.js | 환율 · 환산단위 · 일자 · 스프레드 · 등록여부 포맷터 |
i18n/i18n_ko.properties | ko 로케일 리소스 — 사양서 메시지 원문 포함 |
localdata/exrate.json | 환율 시뮬레이션 데이터와 업로드 파일 샘플 |
검증 결과
화면 구성에 쓴 데이터는 전일 등록 환율과 당일 고시 파일입니다.
| 데이터 | 규모 | 구성 |
|---|---|---|
| 환율 마스터 | TCURR 48라인 | 통화 8종 × 환율 6종 |
| 통화 | 8종 | USD · EUR · JPY · CNY · GBP · HKD · SGD · AUD |
| 업로드 파일 | 2종 | 기준일이 맞는 파일과 어긋난 파일 |
| 검증 항목 | 결과 |
|---|---|
| 환율 종류 6종 (M·CB·CS·TTB·TTS·EXD) | 통과 |
| TCURR 라인 = 통화 × 환율종류 · 목표통화 KRW | 통과 |
| 환산단위가 통화 마스터와 일치 · JPY 는 100단위 | 통과 |
| 업로드 통화가 마스터에 존재 · 6종 환율 보유 | 통과 |
| 현찰 사실 때 > 매매기준율 > 현찰 파실 때 | 통과 |
| 전신환 매도 > 매매기준율 > 전신환 매입 | 통과 |
| 전신환 스프레드가 현찰 스프레드보다 좁음 | 통과 |
| 미화환산율 = 매매기준율 ÷ USD 기준율 · USD 는 1 | 통과 |
| 업로드 파일 2종의 기준일이 당일·전일 | 통과 |
| 화면 렌더링 — 미등록 → 등록 → 일자오류 → 업로드 → 재업로드 | 9/9 |
환율 값은 모두 검증용 데이터입니다.
자주 묻는 질문
환율이 없는 날에 왜 빈 화면이 아니라 통화 목록이 나오나요?
사양서에 레이아웃만 표시하도록 돼 있고, 실제로도 그 편이 낫습니다. 빈 화면이면 조회가 잘못됐는지 환율이 없는 건지 구분이 안 됩니다. 통화 목록이 나오면서 등록여부가 전부 미등록으로 보이면 '올려야 하는 날'이라는 것이 바로 드러납니다.
기준일을 왜 파일 안에서 읽나요?
파일명은 바뀔 수 있지만 파일 안의 기준일은 은행이 찍은 값입니다. 어제 받은 파일을 오늘 이름으로 바꿔 올려도 안의 기준일은 어제이므로 걸립니다. 사양서가 B4 셀을 지정한 것도 같은 이유입니다.
이미 올린 날을 다시 올리면 덮어쓰나요?
덮어쓰지 않고 먼저 물어봅니다. 예를 고르면 그 일자 환율을 전부 지우고 새로 넣습니다. 부분 갱신이 아니라 삭제 후 재등록이라 이전 값이 남아 섞이는 일이 없습니다. 아니오를 고르면 아무것도 건드리지 않습니다.
환율 여섯 종류를 다 넣는 이유는?
쓰는 곳이 다르기 때문입니다. 전표 환산에는 매매기준율을, 외화 송금에는 전신환 매도·매입을, 현금 출납에는 현찰 환율을 씁니다. 미화환산율은 통화 간 비교나 달러 기준 보고에 쓰입니다. 은행 고시 항목과 SAP 환율종류를 1:1로 맞춰 둔 구조입니다.
SAP 표준 기능과 어떻게 이어지나요?
환율 등록은 BAPI_EXCHRATE_CREATEMULTIPLE 이 수행하고 데이터는 TCURR 표준 구조에 그대로 남습니다. 표준 유지보수 화면(OB08)과 같은 테이블을 쓰므로 여기서 올린 환율이 외화 전표 환산과 기말 평가에 그대로 반영됩니다.