수입 결제 환율 차이 점검 — 결제한 건마다 외환차손익을 다시 계산해 장부와 맞춰 보는 IAS 21 점검 화면

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

수입 담당자의 월말은 같은 질문으로 시작합니다. 이번 달에 결제한 대금에서 외환차손익이 얼마 났나, 그 숫자가 장부에 찍힌 숫자와 같나, 결제 환율은 은행 통지대로 맞게 들어갔나. 지금은 이 세 답이 공급업체 개별 항목 조회, 송장 환율 확인, 은행 통지서, 그리고 밤새 만든 엑셀에 흩어져 있습니다.

이 앱은 결제한 건마다 인식 원화(입고·송장 시점 환율)와 결제 원화(결제 시점 환율)를 외화 금액에서 다시 계산하고, 그 차이를 외환차손익으로 구해 장부 값과 견줍니다. 결제 환율이 기준 환율에서 벗어난 건도 함께 가려냅니다. 관련 기준서는 IAS 21 환율변동효과(K-IFRS 제1021호)이고, 외화 거래를 거래일 환율로 처음 인식하며 화폐성 항목을 결제할 때 생기는 환율 차이를 당기손익으로 인식한다는 요구사항이 이 화면의 출발점입니다. 화면은 분류 · 집계 · 대사를 돕는 점검 도구이며, 회계 처리의 최종 판단은 회사와 감사인이 합니다.

결제 환율 차이는 장부에 찍히고 나면 다시 계산해 볼 일이 드물다

대금을 지급하면 청산 전표에 외환차손익이 자동으로 찍힙니다. 문제는 그 뒤입니다. 인식 때 쓴 환율과 결제 때 쓴 환율, 외화 금액, 그리고 장부 외환차손익이 서로 맞는지 건별로 다시 곱해 보는 일은 표준 화면에 없습니다. 월평균 환율로 기표했거나, 부호가 반대로 찍혔거나, 외환차손익 전표가 빠진 건은 월말 합계에서 다른 건의 차이에 묻혀 지나갑니다.

이 앱은 결제 건마다 인식 원화 = 결제 외화 × 인식 환율, 결제 원화 = 결제 외화 × 결제 환율, 재계산 외환차손익 = 인식 원화 − 결제 원화를 원 미만 반올림으로 다시 구하고, 장부 값과의 차이를 장부 차이로 따로 둡니다. 외화 채무를 결제하면서 원화 부담이 줄면 이익(+), 늘면 손실(−)입니다.

결제 환율이 기준에서 벗어났는지는 아무도 안 본다

외환차손익이 장부와 맞아도 결제에 쓴 환율 자체가 이상할 수 있습니다. 은행 통지 환율과 결제 방식(신용장 · 사후 송금 · 전신환)별 적용 기준이 다르기 때문입니다. 이 앱은 결제일의 기준 환율과 결제 환율의 차이를 결제 ÷ 기준 − 1로 구해, 정해 둔 비율(이 자료에서는 1.00%, 가정값)을 넘으면 주의로 표시합니다. 원인을 단정하지 않고 확인이 필요한 곳을 알려 주는 표시입니다.

한 선하증권이 나뉘어 결제되면 어디까지 결제됐는지가 흐려진다

수입 대금은 선하증권 한 건이 여러 차수로 결제되기도 하고, 아직 결제되지 않은 채 남기도 합니다. 선하증권별 탭은 송장 외화, 결제 외화, 미결제 외화를 한 줄에 놓고 송장 외화 = 결제 외화 + 미결제 외화가 맞는지를 보여 줍니다. 일부 결제된 건과 미결제 건이 구분되어 보이므로 기말에 “남은 외화 채무”를 이야기할 때 출발점이 됩니다.

사용 방법

1. 조회조건 입력 — 통화, 결제 방식, 점검 상태, 선하증권 번호(앞부분), 결제일(부터·까지)을 고릅니다. 모두 선택 사항이며 필수 조건은 없습니다.
2. 조회 — 조건 영역 오른쪽 끝의 조회 버튼을 누르거나 선하증권 번호 · 날짜 칸에서 Enter 키를 누릅니다. 처음 열 때도 한 번 자동 조회합니다.
3. 요약 확인 — 결제 건수, 인식 원화, 결제 원화, 순 외환차손익, 이익 합계, 손실 합계, 점검 필요 건을 먼저 봅니다.
4. 탭 이동 — 결제 건 명세 → 통화별 → 월별 → 선하증권별 진행 → 대사 결과 순서로 같은 숫자를 다른 축에서 확인합니다.
5. 행 클릭 — 결제 건 명세와 선하증권별 행은 결제 차수 상세를 열고, 통화별 · 월별 행은 그 조건을 채워 결제 건 명세로 이동합니다.
6. 내보내기 — 화면 아래쪽 버튼으로 현재 탭의 내용을 UTF-8 CSV 로 내려받습니다.

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

화면이 보여 주는 합계가 서로 맞는지 대사식 여덟 가지를 전수로 돌렸습니다. 아래는 검증용 샘플 데이터(결제 40건 · 통화 4종)에 대한 결과입니다.

점검 대상으로 일부러 넣은 예외는 대사 차이 건수와 분리해서 기록했습니다. 장부 차이 7건(부호 반대 · 미기표 · 월평균 환율 기표 등)과 결제 환율 이탈 5건이며, 허용 오차 이내의 미세한 차이 3건은 정상으로 판정합니다. 이 7건과 5건이 화면에서 점검 필요 · 주의로 잡히는지가 판정 규칙의 검증입니다.

무엇으로 만들었나

실행 화면

실제로 돌아가는 화면 8종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 보는 자리이고 무엇을 누르면 무엇이 일어나는지를 아래에 적었습니다. 모든 화면은 검증용 샘플 데이터(가상 거래처 · 가상 선하증권 번호)이고, 환율과 허용 기준은 실제 고시값이 아닌 가정값입니다. 숫자는 한 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

조건부터 명세까지 한 화면에 놓입니다. 처음 보는 사람도 요약 수치에서 시작해 아래로 내려가면 됩니다.

화면을 열면 한 번 자동으로 조회합니다. 위쪽 요약에서 결제 건수 · 인식 원화 · 결제 원화 · 순 외환차손익을 먼저 읽고, 이익은 +, 손실은 −로 봅니다. 이 자료에서는 결제 40건의 순 외환차손익이 66,705,261원입니다. 조건은 모두 선택이라 비워 두면 전체가 조회됩니다.

점검할 건만 골라 보기

전체 40건을 다 읽지 않아도, 점검 상태를 좁히면 장부와 어긋난 건만 남습니다.

재계산 외환차손익은 인식 원화에서 결제 원화를 뺀 값이고, 장부 차이는 거기서 장부 값을 뺀 값입니다. 허용 오차(1,000원, 가정값)를 넘으면 점검 필요가 됩니다. 이 자료에는 의도적으로 넣은 장부 차이 7건이 여기에 걸립니다. 결제 환율이 기준 환율에서 벗어난 건은 주의로 따로 표시합니다.

통화별 · 월별로 같은 숫자를 다른 축에서

같은 순 외환차손익이 통화로 나뉘고 달로 나뉩니다. 어느 축에서 더해도 66,705,261원으로 돌아와야 합니다.

통화가 다른 외화 금액은 더하지 않고 통화별로만 보여 주며, 합계는 원화로만 냅니다. 이 자료에서는 달러 19건 35,065,748원, 유로 8건 7,687,811원, 엔 7건 15,452,967원, 위안 6건 8,498,735원이고 네 줄을 더하면 66,705,261원입니다. 행을 누르면 그 통화로 결제 건 명세가 열립니다.

월별 탭은 2026년 3월부터 9월까지를 최근 달이 위로 오게 보여 줍니다. 이익 합계와 손실 합계를 따로 두어 순액 한 줄에 가려지는 움직임을 볼 수 있습니다. 행을 누르면 그 달과 통화가 조건에 채워지고 결제 건 명세로 이동합니다.

선하증권에서 결제 차수까지

선하증권 한 건이 얼마나 결제됐고 얼마가 남았는지, 그리고 한 차수 안에서 재계산과 장부가 어떻게 다른지 봅니다.

수입 대금은 선하증권(B/L) 한 건이 여러 번에 나뉘어 결제되기도 합니다. 이 탭은 송장 외화 = 결제 외화 + 미결제 외화가 맞는지를 한 줄에서 보게 합니다. 이 자료는 선하증권 40건이 결제 완료 28 · 일부 결제 5 · 미결제 7로 나뉩니다. 선하증권 단위 상태는 소속 결제 건 가운데 가장 높은 상태를 씁니다.

결제 건 명세나 선하증권별 행을 누르면 그 선하증권의 결제 차수가 열립니다. 인식 환율과 결제 환율, 인식 원화와 결제 원화, 재계산 외환차손익과 장부 외환차손익, 그리고 둘의 차이가 한 표에 모입니다. 차이가 난 차수는 어느 값이 어긋났는지 여기서 먼저 봅니다.

대사 결과 — 화면이 스스로 검산한 표

합계끼리 맞는지를 일곱 가지 식으로 확인한 결과입니다.

화면이 보여 주는 합계끼리 서로 맞는지를 스스로 검산한 결과입니다. 집계 쪽 대사식은 차이가 모두 0이고, 장부 대사의 7건과 결제 환율 이탈의 5건은 점검 대상으로 따로 셉니다. 대사 차이 건수와 점검 대상 건수를 섞지 않는 것이 이 탭의 약속입니다.

좁은 화면에서 달라지는 것

휴대폰 폭에서도 같은 순서로 읽힙니다.

휴대폰 폭에서는 조건이 위로 쌓이고 표는 가로로 밀어서 봅니다. 조회 버튼과 탭은 같은 자리에 있어 데스크톱과 같은 순서로 쓰면 됩니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 다섯 묶음(결제 건 · 통화별 · 월별 · 선하증권별 · 대사)을 서비스에 요청하고, 조건은 모두 서버 필터로만 보냅니다. “전체”를 고르면 필터를 만들지 않습니다. 결제일의 시작과 끝은 하나의 AND 조건으로 묶어 보냅니다 — 두 조건을 따로 보내면 같은 칸의 조건끼리 OR 로 묶여 모든 날짜가 통과하기 때문입니다. 정렬은 화면이 정렬 기준으로 요청합니다.

판정 규칙 — 조건, 결과 상태, 사용자 조치

판정은 결제 건마다 아래 순서로 하고, 첫 번째로 해당하는 규칙의 상태를 씁니다.

선하증권 단위 상태는 소속 결제 건 가운데 가장 높은 상태를 씁니다(점검 필요 > 주의 > 정상). 허용 오차와 이탈 비율은 이 자료에서 둔 가정값이며, 운영에서는 회사 기준으로 정합니다.

산출 · 대사 순서

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

폭이 좁아지면 조건 칸이 위로 쌓이고 요약 수치가 두 줄로 접힙니다. 표는 가로로 밀어서 보며, 탭 순서와 조회 버튼의 위치는 바뀌지 않습니다. 같은 사람이 책상에서 쓰던 순서 그대로 이동 중에도 쓸 수 있도록 했습니다.

파일 구성

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/
odata/        메타데이터 · 서비스 로직 · 샘플 응답
media/        소개 영상 · 대표 이미지

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 그래서 아래 표는 “무엇을 대체하는가”가 아니라 “표준 화면의 숫자와 이 화면의 숫자를 어디서 맞춰 보는가”를 중심으로 적었습니다.

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

외화 미결제 잔액의 기말 평가처럼 이 화면이 다루지 않는 일도 있습니다. 이 앱은 결제가 일어난 건의 환율 차이를 보는 도구이므로, 기말 평가는 표준의 외화 평가 기능(FAGL_FCV)에 그대로 둡니다.

T-code 별 연계 지점

기존 리포트를 없애야 하나요? 아닙니다. 법정 · 감사 · 세무 신고 대응은 표준 화면과 기존 보고서에 그대로 둡니다. 이 앱은 그 숫자를 결제 건 단위로 다시 계산해 맞춰 보는 점검 도구이므로, 운영 전환 뒤에도 기존 리포트와 함께 두고 월마감 점검에 쓰는 것이 일반적입니다.

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

S/4HANA 에는 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 도구가 이미 있습니다. 이 앱은 그 위에 놓이는 경쟁 도구가 아니라 수입 결제 환율 차이라는 한 가지 점검 목적에 맞춘 화면입니다. 같은 CDS 큐브를 Analysis for Office 로 열어 임의의 축으로 보는 일과, 이 화면처럼 판정 규칙과 대사식을 정해 두고 매달 같은 방식으로 점검하는 일은 서로 다른 용도입니다. 어떤 표준 Fiori 앱이 어느 범위까지 같은 화면을 제공하는지는 릴리스와 구성에 따라 달라 이 글에서는 앱 이름을 단정하지 않았습니다 — 확인 필요.

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

요구사항 매핑표 — IAS 21 환율변동효과(K-IFRS 제1021호)

기준서의 시행 시기와 경과규정은 이 글에서 확인된 사실로 적지 않았습니다. 문단 번호와 세부 요건은 원문을 확인한 뒤 회사의 회계 정책에 맞춰 반영하시기 바랍니다.

CDS 구성 — 코드와 운영 작업

아래 CDS · DDIC 코드는 이 화면이 읽는 데이터를 S/4HANA 에서 어떻게 구성하는지 보이는 구성 스케치입니다. 표준 CDS 뷰 이름과 청산 회계연도 필드명, 외환차손익 전표 라인을 가려내는 조건은 릴리스와 구성에 따라 달라 코드 주석에 “확인 필요”로 표시했습니다. 확인하지 못한 표준 뷰는 쓰지 않고 원천 테이블 기준으로 적었습니다.

뷰 레이어 구성

① 기준 테이블 — 회사 기준을 데이터로 남긴다

허용 오차와 이탈 비율은 회사마다 다르고 시간이 지나며 바뀝니다. 코드에 상수로 넣으면 바꿀 때마다 이송이 필요하므로 작은 커스터마이징 테이블로 둡니다. 판정 결과가 달라지는 지점이 여기 하나뿐이어야 “왜 이 건이 점검 필요냐”에 한 곳에서 답할 수 있습니다.

@EndUserText.label : '수입 결제 환율 점검 기준'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zimpfx_chgkey {
  key client       : abap.clnt not null;
  key company_code : bukrs not null;
  key rate_type    : kurst not null;       " 결제 환율 점검에 쓰는 환율 유형
  tolerance_krw    : abap.dec(13,0);       " 장부 차이 허용 오차(원) — 샘플 1,000원은 가정값
  rate_dev_pct     : abap.dec(5,2);        " 환율 이탈 비율(%) — 샘플 1.00 은 가정값
}

② 기준 환율 차원 — 결제일에 맞는 환율을 한 곳에서

환율표는 유효 시작일 구조라 결제일에 해당하는 행을 고르는 일이 까다롭습니다. 이 일을 큐브에서 반복하지 않고 차원 뷰 한 곳에 모읍니다. 환율 유형이 다르면 같은 날에도 값이 다르므로 환율 유형이 키에 들어갑니다.

" ─── ZI_ImpFxBase ────────────────────────────────────────────
" 역할 : 결제일의 기준 환율을 환율 유형별로 내려 주는 차원 뷰
" 나눈 이유 : 환율표(TCURR)는 '유효 시작일' 구조라 결제일에 맞는 행을
"            찾는 일을 큐브에서 반복하면 느리고 틀리기 쉽습니다.
"            기준 환율 조회를 이 뷰 한 곳에 모읍니다.  (확인 필요 : 릴리스별 필드명)
@EndUserText.label: '결제일 기준 환율'
@ObjectModel.usageType: { serviceQuality: #B, sizeCategory: #L, dataClass: #CUSTOMIZING }
define view entity ZI_ImpFxBase
  as select from tcurr as r
{
  key r.kurst as RateType,
  key r.fcurr as Currency,
  key r.tcurr as LocalCurrency,
  key r.gdatu as ValidFromInverted,        // 역일자 형식 — 변환은 큐브 쪽에서
      r.ukurs as BaseRate
}

③ 송장 인식 환율 — 인식과 결제를 갈라 둔다

인식 환율은 송장 전표에서, 결제 환율은 청산 전표에서 옵니다. 한 뷰에서 섞으면 숫자가 어긋났을 때 어느 쪽 문제인지 추적할 수 없으므로 출처별로 뷰를 갈라 둡니다.

" ─── ZI_ImpInvoiceRecog ──────────────────────────────────────
" 역할 : 송장 전표의 인식 시점 환율과 원화 금액
" 나눈 이유 : '인식'과 '결제'를 같은 뷰에서 섞으면 어느 환율이 어디서
"            왔는지 추적이 안 됩니다. 인식은 송장, 결제는 청산 전표로 갈라 둡니다.
@EndUserText.label: '송장 인식 환율'
define view entity ZI_ImpInvoiceRecog
  as select from bkpf as h
    inner join   rseg as i on i.belnr = h.belnr and i.gjahr = h.gjahr
{
  key h.bukrs   as CompanyCode,
  key h.belnr   as InvoiceDoc,
  key h.gjahr   as FiscalYear,
      h.waers   as Currency,
      h.kursf   as RecogRate,              // 송장 전표 환율
      h.budat   as RecogDate
}

④ 큐브 — 환율 곱셈과 반올림을 한 곳에서

인식 원화 · 결제 원화 · 재계산 외환차손익의 계산 규칙이 한 곳에서만 정의되어야 화면과 대사, 내보내기가 같은 값을 씁니다. 통화는 금액의 짝으로 반드시 함께 올립니다. 통화가 다른 행끼리 더하면 의미가 없기 때문입니다.

" ─── ZI_ImpPayFxDiff ─────────────────────────────────────────
" 역할 : 청산(결제) 항목 한 줄 = 결제 차수 한 건. 외화에서 인식 원화 · 결제 원화
"        · 재계산 외환차손익을 다시 계산하고 장부 외환차손익과 견줍니다.
" 나눈 이유 : 환율 곱셈과 반올림 규칙을 한 곳에서만 정의해, 화면 · 대사 · 내보내기가
"            같은 값을 쓰게 합니다.  통화는 반드시 함께 올려 통화가 다른 행을 더하지 않습니다.
@EndUserText.label: '수입 결제 외환차손익 점검'
@Analytics.dataCategory: #CUBE
@ObjectModel.usageType: { serviceQuality: #C, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZI_ImpPayFxDiff
  as select from acdoca as clr
  association [0..1] to ZI_ImpFxBase        as _base  on  _base.Currency = clr.rwcur
  association [0..1] to ZI_ImpInvoiceRecog  as _recog on  _recog.CompanyCode = clr.rbukrs
{
  key clr.rbukrs as CompanyCode,
  key clr.belnr  as ClearingDoc,
  key clr.docln  as ClearingItem,
      clr.rwcur  as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      clr.wsl    as FcAmt,                 // 거래 통화 금액
      _recog.RecogRate,
      _base.BaseRate,
      // 인식 원화 · 결제 원화는 외화 × 환율, 원 미만 반올림
      @Semantics.amount.currencyCode: 'LocalCurrency'
      cast( round( clr.wsl * _recog.RecogRate, 0 ) as abap.curr(23,0) ) as KrwRecog,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      clr.hsl    as FxDiffBook,            // 외환차손익 전표 라인의 현지 통화 금액 (확인 필요)
      clr.rhcur  as LocalCurrency
}

⑤ 분석 쿼리 — 무엇으로 자를지는 쿼리가 맡는다

큐브가 ‘무엇을 계산하나’를 맡는다면 쿼리는 ‘무엇으로 자르고 어떻게 더하나’를 맡습니다. 조회조건의 필터 가능 항목이 여기서 정해집니다.

" ─── ZC_ImpPayFxDiffQuery ────────────────────────────────────
" 역할 : 화면이 부르는 조회 단위. 필터 가능한 항목과 집계 방식을 여기서 정합니다.
" 나눈 이유 : 큐브는 '무엇을 계산하나', 쿼리는 '무엇으로 자르나'를 맡습니다.
@EndUserText.label: '수입 결제 환율 차이 점검 쿼리'
@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
define view entity ZC_ImpPayFxDiffQuery
  as select from ZI_ImpPayFxDiff
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true }
  key Currency,
  @AnalyticsDetails.query.axis: #ROWS
  key ClearingDoc,
  @AnalyticsDetails.query.axis: #COLUMNS
  @Aggregation.default: #SUM
  FcAmt,
  @AnalyticsDetails.query.axis: #COLUMNS
  @Aggregation.default: #SUM
  KrwRecog,
  @AnalyticsDetails.query.axis: #COLUMNS
  @Aggregation.default: #SUM
  FxDiffBook
}

⑥ 권한(DCL) — 큐브를 읽는 자리에 건다

권한을 상세 조회에만 걸면 합계가 보이는 사람이 전체에서 자기 몫을 빼서 남의 숫자를 알아낼 수 있습니다. 그래서 큐브를 읽는 자리에서 회사코드 권한을 확인합니다.

" ─── 권한 (DCL) ──────────────────────────────────────────────
" 역할 : 회사코드 권한을 큐브를 읽는 자리에서 겁니다.
" 이렇게 나눈 이유 : 드릴스루에만 걸면 합계에서 자기 몫을 뺄셈해 남의 숫자를 알 수 있습니다.
@EndUserText.label: '수입 결제 외환차손익 권한'
@MappingRole: true
define role ZI_ImpPayFxDiff {
  grant select on ZI_ImpPayFxDiff
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 — 화면에는 주소만 건넨다

서비스 정의에서 노출할 엔티티셋을 정하고 바인딩으로 게시합니다. 게시한 뒤에는 앱 설정의 서비스 주소만 교체하면 되고 화면 코드는 바뀌지 않습니다.

" ─── 서비스 정의와 바인딩 ────────────────────────────────────
" 역할 : 화면이 부르는 엔티티셋을 한 서비스로 묶어 OData V2 로 게시합니다.
" 서비스 이름은 소문자로 맞추고, 게시 뒤 앱 설정의 서비스 주소만 교체합니다.
@EndUserText.label: '수입 결제 환율 차이 점검 서비스'
define service ZUI_ImpFxDiff {
  expose ZC_ImpPayFxDiffQuery as PaySet;
  expose ZI_ImpFxBase         as BaseSet;
}
" 서비스 바인딩 : 유형 OData V2 - UI, 게시 후 /IWFND/MAINT_SERVICE 에서 활성화 확인

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 운영 전환 전에 합의해 두면 첫 달 마감에서 막히지 않는 항목입니다.

운영 데이터로 갈 때

결제 건은 청산 전표 기준이라 전표 수에 비해 많지 않지만, 외환차손익 전표 라인을 찾는 단계와 환율표 조회가 무겁습니다. 집계는 가능하면 큐브 안에서 하고, 조회조건에 결제일 범위를 두어 한 번에 읽는 범위를 제한하는 편이 안전합니다. 환율표는 유효일 조회가 많으므로 기준 환율 차원 뷰를 캐시하거나 월 단위로 미리 구체화하는 방안을 성능 측정 뒤에 정합니다. 응답 시간 기준은 회사가 정해야 하며, 이 글은 수치를 약속하지 않습니다.

자주 묻는 질문

도입을 검토하시는 분들이 자주 물으시는 것을 숫자와 산식, 화면과 조작, 표준 T-code 와 데이터, 도입과 운영으로 나누어 답했습니다.

숫자와 산식

화면과 조작

표준 T-code 와 데이터

도입과 운영