수입 결제 환차손익 다차원 분석 — 결제 환율 영향을 축으로 쪼개고 예정 대비 차이를 여섯 요인으로 가르다

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

수입 대금을 외화로 결제하고 나면 두 가지 질문이 남습니다. 인식할 때 환율과 결제할 때 환율이 달라 생긴 차이가 얼마이고, 그것이 어느 공급사 · 통화 · 결제 조건에서 났는가, 그리고 예정했던 결제 원화와 견주면 왜 이만큼 달라졌는가입니다. IAS 21 환율변동효과(K-IFRS 제1021호)가 다루는 외화 거래의 환율 차이를 점검하는 자금 · 회계 담당자에게 결제 시점의 환율 차이는 분류하고 집계해 두어야 하는 대상입니다.

지금 방식은 대개 표준 화면에서 공급업체 개별 항목과 전표를 건별로 열어 엑셀에 옮기고, 은행 · 헷지 자료와 맞춘 뒤, 예정 금액과 다시 비교하는 순서입니다. 축을 하나 바꾸려면 집계를 처음부터 새로 해야 하고, 합계가 달라지면 어느 쪽이 맞는지부터 가려야 합니다. 이 화면은 결제 품목 라인 단위 큐브를 한 번 읽어 와서 브라우저에서 축을 다시 묶고, 칸에서 결제 라인까지 내려가며, 예정 대비 차이를 요인으로 나눕니다. 모든 숫자는 라인 합계와 대사해 두었습니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(가상 공급사 12곳 · 결제월 2026.04~2026.09 · 가정 환율)에서 예정 결제 원화는 500.85억원, 실적은 600.21억원으로 +99.36억원(+19.8%) 차이가 발생했습니다. 합계 숫자만 보면 "왜 늘었는가"에서 멈추지만, 여섯 요인으로 가르면 어디를 점검할지가 갈립니다. 아래 표의 여섯 요인은 예정에서 실적까지 하나씩 실적 값을 대입해 가며 계산한 값이고, 합은 총차이와 같습니다.

가장 큰 몫은 미계획 결제(+96.75억원)로, 계획 외 결제 491라인에서 차이가 발생했습니다. 환율 요인(인식 환율 + 결제 환율)의 합은 +23.98억원이고, 수량 요인은 이월 181라인이 포함되어 −25.14억원으로 나옵니다. 표시값은 소수 둘째 자리에서 반올림했기 때문에 억원 환산 열을 더하면 총차이와 0.02억원 어긋나 보이지만, 원 단위 합은 +9,935,854,542원으로 총차이와 같습니다. 이 사례에서 요인 하나만 보고 원인을 단정하지 않고, 미계획 결제 라인과 이월 라인에 사유를 남겨 점검이 필요한 항목으로 넘기는 흐름입니다.

환율 영향만 따로 보면 결제 원화에서 인식 원화를 뺀 5.28억원이고, 이는 외환차손 6.27억원에서 외환차익 0.99억원을 뺀 값과 같습니다. 외환차손을 헷지 구분으로 나누면 미적용 3.66억원 · 부분 적용 2.15억원 · 선물환 적용 0.45억원이어서, 헷지를 적용하지 않은 결제를 먼저 점검할 수 있습니다. 인식 원화 593.02억원, 결제 원화 600.21억원, 수수료 1.91억원은 같은 라인에서 나온 합계입니다.

도입하면 달라지는 것

• 마감 전 준비 — 공급사별 · 통화별 환율 영향, 라인 확인, 요인분해가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 회의의 주제 — "어느 숫자가 맞는가" 대신 "어느 요인을 점검할 것인가"를 이야기합니다.
• 다음 기간으로 이어지는 기록 — 변동 사유와 레이아웃이 남아 같은 설명을 되풀이하지 않습니다.
• 놓치지 않는 점검 — 화면을 열지 않아도 감시 규칙에 걸린 항목이 역할별 대기함에 올라옵니다.
• 역할별 시각 — CFO · 구매 책임자 · 물류 책임자 · 자금 책임자가 같은 큐브를 자기 기준 축으로 읽습니다.

이런 회사에 맞습니다

원재료나 설비 부품을 해외에서 수입해 USD · EUR · JPY · CNY 같은 여러 통화로 결제하고, 신용장 유산스나 송금(TT) 등 결제 조건이 섞여 있으며, 선물환 같은 헷지를 일부 결제에만 적용하는 제조 · 유통 회사에 맞습니다. 공급사가 열 곳 안팎 이상이고 월마다 결제 환율 차이를 엑셀로 집계하는 자금팀 · 회계팀, 그리고 예정 대비 결제 원화 차이를 구매 · 물류 · 자금이 함께 읽어야 하는 조직에 특히 쓸모가 있습니다.

실행 화면

사용 방법

1. 조회조건을 넣습니다. 회사코드(필수)와 시작 · 종료 결제월을 고릅니다. 차원 값을 비워 두면 전체 범위입니다.
2. 조회 버튼을 누르거나 Enter를 칩니다. 큐브가 한 번 읽혀 오고 차트와 피벗이 함께 그려집니다.
3. 임원 요약에서 전체 모양을 확인합니다. 역할(CFO · 구매 · 물류 · 자금)을 바꾸면 표시 항목과 행 축이 그 역할에 맞게 바뀝니다.
4. 탭과 축을 옮깁니다. 차원 칩을 끌어 행 축(최대 3) · 열 축(최대 2)에 놓으면 서버를 다시 부르지 않고 바로 다시 묶입니다. 막대와 요인 워터폴을 전환합니다.
5. 칸이나 행을 눌러 상세를 엽니다. 칸은 결제 품목 라인으로, 차이 모드의 행은 변동 사유 입력으로 이어집니다.
6. 내보냅니다. 피벗과 라인은 CSV로, 분석 결과는 AI 분석 창의 PPTX 보고서로 내려받습니다.

무엇으로 만들었나

화면은 UI5 표준 컨트롤 위에 얹었고, 데이터는 OData V2 모델이 매니페스트에 선언된 서비스를 상대 경로로 읽어 옵니다. 서비스 경로는 화면 코드에 적지 않으며, 연결에 실패하면 빈 화면이나 콘솔 오류 대신 오류 처리기가 사용자 메시지를 띄웁니다.

처음 열었을 때 — 조회 전 틀에서 피벗과 차트까지

화면 맨 위에는 조회 조건, 그 아래 분석 축 보드, 임원 요약, 차트와 피벗이 세로로 쌓여 있습니다. 조회를 누르기 전에는 틀만 보이고, 누르는 순간 큐브가 한 번 읽혀 모든 영역이 채워집니다.

조회 조건에는 회사코드 1000과 결제월 2026.04~2026.09가 기본값으로 들어 있고, 차원 값은 "전체"입니다. 분석 축은 행에 공급사와 통화, 열에 결제월이 놓여 있습니다. 임원 요약은 아직 "해당 없음"이므로 조회 버튼을 눌러야 숫자가 나옵니다.

결제 원화 금액 60,021.0백만원 아래에 예정 50,085.1과 차이 +9,935.9가 함께 보입니다. 환율 영향(결제−인식)은 528.0백만원, 외환차손은 626.8백만원, 환율 영향률은 0.89%입니다. 금액 단위는 위쪽 선택값(백만원)을 따릅니다.

"사용 가능" 영역에는 아직 쓰지 않은 차원이 칩으로 놓여 있고, 행 축은 최대 3개 · 열 축은 최대 2개까지 받습니다. 칩을 끌어 놓거나 칩의 화살표 버튼을 누르면 이동합니다. 끌기가 어려운 환경을 위해 같은 일을 버튼으로도 할 수 있습니다.

행 축은 공급사 › 통화 › 환헷지 구분, 열 축은 결제월 › 결제 소요 구간으로 바뀌었습니다. 이때 서버로 나가는 요청은 없고, 이미 읽은 큐브를 브라우저에서 다시 묶습니다. 총합은 바뀌기 전과 같습니다.

패널 제목을 누르면 조건 · 축 영역이 접히고 접힌 줄에는 현재 설정이 한 줄로 요약됩니다. 피벗을 오래 읽을 때 쓰는 모양이며, 접힌 상태는 레이아웃에 함께 저장됩니다. 다시 펼치려면 줄 앞의 화살표를 누릅니다.

경영 요약 — 같은 큐브를 역할 네 가지로 읽는다

임원 요약은 역할을 바꾸면 기준 차원과 표시 항목이 함께 바뀝니다. 같은 6개월 · 같은 합계 위에서 CFO는 통화, 구매 책임자는 공급사, 물류 책임자는 결제 소요 구간, 자금 책임자는 헷지 구분을 먼저 봅니다.

CFO 역할은 결제 원화 · 환율 영향 · 외환차손 · 환율 영향률 네 지표를 통화별로 읽습니다. 통화별 예정 초과 상위는 EUR 19,196.2(+3,566.8), CNY 17,026.0(+2,688.9), USD 15,738.2(+2,392.3), JPY 8,060.6(+1,287.8)백만원 순입니다. 아래 피벗은 같은 통화를 결제월별로 펼친 것입니다.

구매 책임자 역할은 결제 원화에 인식 원화와 수수료율(0.32%)을 함께 놓습니다. 공급사별 예정 초과 상위는 V04 함부르크 기계부품(+1,650.3), V11 밀라노 설비부품(+1,174.8), V07 시애틀 특수소재(+1,148.2)백만원입니다. 단가 협상이나 공급사 점검의 우선순위를 정할 때 보는 화면입니다.

물류 책임자 역할은 환율 영향 528.0 · 외환차손 626.8 · 결제 수수료 191.2백만원과 차손 비중 86.38%를 봅니다. 결제 소요 구간 B3(31~60일)가 +202.2로 가장 크고 B4(61~90일) +123.4가 뒤를 잇습니다. 구간이 길수록 인식과 결제 사이의 환율 차이를 점검할 대상이 되는지 확인하는 용도입니다.

자금 책임자 역할은 외환차손 626.8 · 외환차익 98.8 · 순 환율 영향 528.0백만원과 환율 영향률 0.89%를 놓습니다. 헷지 구분별 외환차손은 미적용 366.4, 부분 적용 215.1, 선물환 적용 45.3백만원이며 합은 626.8로 같습니다. 헷지를 적용하지 않은 결제의 차손을 먼저 점검할 수 있습니다.

축 전환과 범위 — 끌어다 놓아도 총합은 그대로

열 축을 두 단계로 쌓거나 차원 값을 골라 범위를 좁혀도 서버를 다시 부르지 않습니다. 어떤 배치든 총합은 같아야 하며, 이를 검증용 샘플 데이터에서 축 배치 6종으로 확인했습니다.

열 축에 결제월과 환헷지 구분을 함께 놓으면 헤더가 "결제월 · 구분" 조합으로 늘어납니다. 칸이 많아지는 만큼 가로로 길어지므로 열 개수에는 상한이 있습니다. 행 수와 원천 라인 읽는 단위는 피벗 아래 선택값에서 바꿉니다.

결제월 · 분기 · 공급사 · 결제 조건 · 결제 은행 · 환헷지 구분 · 통화 · 인코텀즈 · 자재그룹 등 차원마다 값을 고를 수 있고, 비워 두면 전체입니다. 적용을 누르면 범위가 좁혀져 다시 조회됩니다. 선택 해제로 한 번에 비웁니다.

조회 조건 줄에 "2개 차원 선택"처럼 현재 범위가 요약됩니다. 공급사 · 통화 행만 남아 차트와 피벗이 같은 범위로 줄어듭니다. 범위를 좁혀도 위쪽 검산 줄은 같은 방식으로 요인 합과 총차이를 비교합니다.

칸에서 결제 라인까지 — 드릴스루

피벗의 칸을 누르면 그 금액을 만든 결제 품목 라인이 열립니다. 라인은 한 번에 정해진 단위(기본 500건)로 읽고, 모두 읽으면 칸의 값과 라인의 합이 같은지 화면이 알려 줍니다.

V04 함부르크 기계부품 · EUR · 결제월 2026.04 칸의 값은 989.2백만원이고, 읽은 라인의 합도 989.2로 "칸의 값과 결제 라인 합이 같습니다"가 표시됩니다. 31 / 31건을 모두 읽은 상태입니다. 표에는 결제 문서 · 품목 · 헷지 · 소요 구간 · 인식일 · 결제일 · 수량 · 환율이 함께 나옵니다.

V07 시애틀 특수소재 · 결제월 2026.08 칸의 값 1,464.3과 읽은 라인의 합 1,464.3이 같고, 46 / 46건을 모두 읽었습니다. 라인이 읽는 단위보다 많으면 일부만 먼저 읽고 "아직 일부만 읽음"으로 표시해 대사가 끝나지 않았음을 알립니다. CSV 버튼으로 읽은 라인을 내려받을 수 있습니다.

검산 패널은 인식 원화 · 결제 원화 · 환율 영향 · 수수료 · 외환차익 · 외환차손의 큐브 합계와 라인 합계를 비교하고 차이 열이 모두 0입니다. 아래에는 결제월 2026.04~2026.09의 라인 수 · 결제 문서 수 · 인식 · 결제 · 환율 영향 · 수수료가 월별로 나옵니다. 월별 합은 위 합계와 같습니다.

계산항목 — 환율 영향률과 순 환율 영향

계산항목은 서비스가 식을 내려 주고 화면이 칸마다 같은 식을 적용합니다. 환율 영향률(%)은 환율 영향을 인식 원화로 나눈 값, 외환차손 비중(%)은 차손이 차손과 차익 합에서 차지하는 비율, 수수료율(%)은 수수료를 결제 원화로 나눈 값입니다. 물대 결제액(수수료 제외)은 결제 원화에서 수수료를 뺀 값이고, 순 환율 영향은 차손에서 차익을 뺀 값입니다.

환율 영향률은 결제월별 퍼센트로 표시되고 막대 차트도 같은 값을 그립니다. 값이 클수록 인식 대비 결제 환율의 영향이 큰 칸이며, 점검 대상을 고르는 기준으로 씁니다. 임계값을 넘는 칸은 AI 에이전트 규칙에서도 같은 식으로 판정됩니다.

통화별로 선물환 적용 · 미적용 · 부분 적용 열과 합계가 나란히 놓입니다. 합계 열은 세 구분의 합과 같으며, 칸마다 차손에서 차익을 뺀 값이 적혀 있습니다. 같은 식을 바꾸지 않고 열 축만 바꿔 다른 관점으로 읽는 예입니다.

예정 대비 차이 — 같은 표가 요인 분해 보고서가 된다

비교를 "예정 대비 차이"로 바꾸면 칸마다 예정 · 실적 · 차이 · 차이율이 붙고, 차트는 막대에서 요인 워터폴로 바뀝니다. 예정은 구매오더 조건에서 읽은 결제 원화이고, 요인은 수량 → 외화 단가 → 인식 환율 → 결제 환율 → 결제 수수료 → 미계획 결제 순서로 실적 값을 하나씩 대입해 계산합니다.

피벗이 예정 대비 차이 값으로 바뀌고 차트에는 예정에서 실적까지의 워터폴이 그려집니다. 붉은색은 환율 영향(차손)이나 비용을 늘린 요인, 초록은 줄인 요인입니다. 행의 사유 버튼을 누르면 그 행의 변동 사유를 적는 창이 열립니다.

대상 행 V04 함부르크 기계부품의 예정 대비 차이 +1,650.3(+22.8%)가 보이고, 주된 요인은 "결제 환율"로 골라 두었습니다. 사유는 500자까지 적고 저장하며, 조회 범위와 행 경로에 묶여 남으므로 축을 바꿔도 같은 행에서 다시 나옵니다. 사유를 지우는 버튼도 있습니다.

분해 범위가 공급사 하나로 좁혀져 예정 7,248.8에서 실적 8,899.1까지 수량 −461.9 · 외화 단가 +62.7 · 인식 환율 +400.9 · 결제 환율 +34.7 · 수수료 +10.0 · 미계획 결제 +1,604.0 순으로 이어집니다. 범위를 좁혀도 "검산: 요인 합 − 총차이 = 0원"이 그대로 나옵니다. "전체 범위로" 버튼을 누르면 전체 분해로 돌아갑니다. 단위는 백만원입니다.

여섯 요인의 합은 +9,935.9백만원으로 총차이와 같고, 미계획 결제 막대가 가장 큽니다. 수량 막대는 초록으로 내려가는데, 이월 라인 181건이 수량 0으로 들어갔기 때문입니다. 요인 하나만 보고 원인을 단정하지 않고, 해당 행에 사유를 남겨 점검이 필요한 항목으로 넘깁니다.

AI 분석과 보고서

AI 분석은 지금 조회한 범위를 읽어 요약과 점검 대상을 문장으로 써 줍니다. 기본은 외부 AI 서비스를 부르지 않는 규칙 기반 해설이며, 숫자는 서비스가 계산한 값만 그대로 문장에 옮깁니다. 외부 모델 연결은 기본적으로 꺼져 있습니다.

요약은 결제 문서 1640건 · 원천 라인 3189건의 결제 원화 600.21억원이 예정 500.85억원 대비 +99.36억원(+19.8%) 차이가 발생했다고 쓰고, 환율 요인 +23.98억원과 헷지 미적용 외환차손 3.66억원을 함께 밝힙니다. 점검 대상은 차이가 큰 자재그룹과 공급사 순이며 "사유 확인이 필요합니다"로 끝납니다.

버튼을 누르면 "보고서 AI_Report_20261013.pptx(을) 만들었습니다" 메시지가 뜨고 파일이 내려받아집니다. 표와 차트, 요약 문장이 같은 범위의 숫자로 채워집니다. 파일은 서버에 남기지 않습니다.

AI 에이전트 — 규칙이 곧 점검 대상

에이전트는 감시 규칙 5개를 정해 두고 하루 한 번 점검합니다. 규칙마다 임계값과 받을 역할이 붙어 있고, 걸린 항목은 그 역할의 대기함으로 올라옵니다. 하루 한 번 실행 제한은 서비스가 판정하고, 실행 결과는 기록으로 남습니다.

공급사 환율 영향률 상한 초과(1%) · 통화별 환율 요인 임계(1억원) · 헷지 미적용 외환차손(6천만원) · 결제 원화 예정 대비 초과(12%) · 장기 결제 구간 환율 노출(4천만원)입니다. 임계값을 고치고 저장하면 다음 실행부터 반영됩니다. 열어 둔 동안 한 시간마다 실행하는 스위치는 기본이 꺼짐입니다.

지금 실행하기를 누르면 규칙을 판정하고 걸린 항목을 보고로 올립니다. 대기함 탭의 배지 숫자는 4건이며, 하단에는 "오늘은 이미 실행해서 한도에 걸렸습니다. 하루 한 번 제한"이라는 안내가 있습니다. 같은 날 다시 눌러도 새 보고는 올라가지 않습니다.

레이아웃 저장과 복원

축 · 조회 조건 · 표시 항목 · 표시 행 수 · 접힘 상태를 이름을 붙여 저장하고 불러옵니다. 기본 레이아웃으로 지정해 두고 "열 때 자동 조회"를 켜면, 열자마자 조회된 상태로 시작합니다.

예시 이름은 "헷지별 결제 점검"입니다. 두 체크박스는 기본 레이아웃으로 쓸지, 열 때 자동으로 조회할지를 정합니다. 저장 전에는 "저장된 레이아웃이 없습니다"라고 보입니다.

목록 줄에는 "기본 · 열 때 자동 조회" 표시와 저장 시각이 보입니다. 별표는 기본 레이아웃 지정, 화살표는 적용, 휴지통은 삭제입니다. 저장이 끝나면 "레이아웃을 저장했습니다" 안내가 뜹니다.

행 축 공급사 › 환헷지 구분, 차이 모드 요인 워터폴, 접힌 머리 영역이 저장한 대로 복원되었습니다. 열 때 자동 조회 덕에 조회 버튼을 누르지 않아도 피벗이 채워져 있습니다. 검증에서 복원 뒤 칸 수 · 행 축 · 사유 · 레이아웃 수가 모두 이어지는 것을 확인했습니다.

좁은 화면과 한계

휴대폰 폭에서는 열 폭과 패널이 접히고 대화 상자는 화면 전체로 열립니다. 큐브가 클 때를 위한 상한도 있어, 상한을 넘으면 화면이 안내 메시지로 범위를 줄이도록 알려 줍니다.

조건 · 축 · 임원 요약이 접힌 줄로 보이고 조회 버튼은 오른쪽에 그대로 남습니다. 피벗의 행 이름 열은 좁아져 말줄임표로 줄어들지만 값 열은 가로 스크롤 없이 읽힙니다. 상단 버튼 세 개는 아이콘 중심으로 줄어듭니다.

좁은 화면에서는 차트와 피벗이 세로로 쌓입니다. 요인 워터폴도 같은 요인 막대를 작은 글자로 보여 주고, 검산 줄은 접힌 패널로 맨 아래에 있습니다. 가로 폭을 넘는 요소는 만들지 않았습니다.

노란 안내 줄에 "열이 84개라 앞의 36개만 보여 줍니다. 열 축을 줄이거나 차원 값을 골라 주세요"가 뜹니다. 열은 최대 36개, 행 노드는 최대 1,500개까지 그리며, 상한 때문에 합계가 달라지지는 않고 보이는 칸만 줄어듭니다. 범위를 줄이면 안내가 사라집니다.

화면 뒤에서 일어나는 일

한 번의 조회에서 서비스는 큐브(결제 라인 단위 집계)와 예정 · 계산항목 · 차원 값을 돌려주고, 화면은 이를 칸 단위로 묶어 둔 뒤 축 배치에 맞게 다시 합산합니다. 같은 값이 여러 곳(임원 요약 · 피벗 · 차트 · 검산)에서 쓰이지만 계산은 한 번만 합니다.

1. 읽기 — 회사코드 · 결제월 범위 · 차원 값 필터로 큐브와 예정을 읽습니다. 큐브는 차원 조합 × 측정값 6개의 긴 형태(9,816행)이고, 예정은 9,360행입니다.
2. 묶기 — 긴 형태를 차원 조합 1,636개 칸으로 묶습니다. 이후 축을 바꾸는 일은 이 칸을 다시 합산하는 일입니다.
3. 계산항목 적용 — 서비스가 준 식을 칸마다 적용해 비율과 순 환율 영향을 만듭니다.
4. 그리기 — 행 축 노드를 트리로 만들고 열 축을 헤더로 펼친 뒤 차트를 같은 값으로 그립니다.
5. 검산 — 큐브 합계와 결제 라인 합계, 요인 합과 총차이를 화면 안에서 비교해 보여 줍니다.

축 전환 — 브라우저 재집계

요인분해 — 순차 대입과 검산

요인분해는 예정(t0)에서 시작해 수량 → 외화 단가 → 인식 환율 → 결제 환율 → 결제 수수료 → 미계획 결제 순으로 실적 값을 하나씩 대입합니다. 각 단계에서 바뀐 결제 원화가 그 요인의 몫이 되고, 마지막 단계에서 실적이 되므로 요인 합 = 총차이가 구조적으로 성립합니다. 화면은 이 등식을 "검산: 요인 합 − 총차이 = 0원"으로 매번 보여 주며, 0이 아니면 그 자체가 점검 신호입니다.

드릴스루 — 칸과 라인 대사

감시 규칙 — 판정과 대기함

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

• 행 이름 열이 좁아지고(9rem) 값 열은 그대로 읽히도록 가로 스크롤 안에서 움직입니다.
• 차원 값 선택 같은 대화 상자가 화면 전체로 열립니다.
• 차트와 피벗이 가로로 나란히 놓이지 않고 위아래로 쌓이며, 차트 폭 손잡이는 숨겨집니다.
• 임원 요약 지표는 두 개씩 줄바꿈되어 가로 넘침이 생기지 않습니다.

파일 구성

앱 폴더
├─ Component.js · manifest.json · index.html     앱 진입, 모델 선언(서비스 상대 경로)
├─ view/Main.view.xml                             화면 한 장(조회 조건 · 축 보드 · 임원 요약 · 차트와 피벗)
│   └─ fragment/                                 AI 분석 · 에이전트 · 레이아웃 · 변동 사유 · 라인 보기 대화 상자
├─ controller/                                    Main 컨트롤러 · 기본 컨트롤러
├─ model/                                         큐브 재집계 · SVG 차트 · 서식 · 레이아웃 직렬화 · PPTX 보고서 · 오류 처리
├─ i18n/                                          화면 문구(한국어)
└─ css/                                           화면 보조 스타일(sap_horizon 의미 색 사용)

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 결제를 실행하고 전표를 만드는 일, 법정 · 감사 · 세무 신고에 쓰는 숫자를 확정하는 일은 계속 표준 화면에서 합니다. 이 화면은 그 결과를 같은 필드로 읽어 여러 축으로 묶고 대사합니다.

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

T-code 별 연계 지점

기존 리포트를 없애야 하나요? 아니요. 운영 전환 뒤에도 표준 T-code와 기존 리포트는 법정 · 감사 · 세무 신고 대응과 문서 단위 확인에 그대로 둡니다. 이 화면은 처음 몇 기간 동안 두 숫자를 나란히 놓고 맞춰 보는 용도로 쓰다가, 대사 체계가 자리 잡으면 월 단위 분석과 점검의 입구가 됩니다.

기준서 요구사항과 화면의 대응 — IAS 21 환율변동효과(K-IFRS 제1021호)

기준서의 요구사항은 명칭 수준으로만 적습니다. 이 화면은 분류 · 집계 · 대사를 돕는 조회 · 점검 도구이며, 요구사항을 어떻게 적용하는지의 판단은 회사와 감사인이 합니다.

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

S/4HANA의 분석은 CDS 큐브와 분석 쿼리를 중심으로, 그 위에 Fiori 분석 앱과 Analysis for Office 같은 도구를 얹는 구조입니다. 이 화면이 읽는 데이터도 같은 층(큐브 → 쿼리 → 서비스)으로 만들 수 있게 CDS 구성을 아래 절에 코드로 실었습니다. 표준 분석 도구는 정해진 쿼리를 열고 필터링하는 데 강하고, 이 화면은 한 번 읽은 큐브를 브라우저에서 축을 끌어 다시 묶고 칸에서 라인까지 내려가며 요인분해와 변동 사유 · 에이전트를 한 화면에 묶는 쪽에 있습니다. 둘은 같은 큐브를 바라보므로 쓰임에 따라 나란히 둘 수 있습니다. 구체적인 Fiori 앱 이름은 확인하지 못한 것은 적지 않았습니다.

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

CDS 구성

아래는 운영 데이터로 갈 때의 구성 스케치입니다. 이름은 기능을 뜻하는 영문으로 짓고, 기준 → 차원 → 큐브 → 쿼리 → 권한 → 서비스 순서로 나눕니다. 코드는 구조를 보여 주기 위한 것이며 실제 환경의 문서 구조와 환율 설정에 맞춰 확인이 필요합니다.

뷰 레이어 구성

① ZIMPFX_MAP — 기준 매핑 테이블

결제 소요일수를 "15일 이내 · 16~30일 · 31~60일 · 61~90일 · 91일 이상" 같은 구간으로, 헷지 구분 코드를 "선물환 적용 · 부분 적용 · 미적용"으로 바꾸는 규칙입니다. 구간 경계가 운영 중에 바뀌어도 뷰를 고치지 않고 이 테이블만 고치면 됩니다.

" ──────────────────────────────────────────────────────────
" ZIMPFX_MAP — 분석 기준 매핑
" 역할 : 소요 구간(BAND) · 헷지 구분(HEDG) 코드를 축 값으로 변환
" 이렇게 나눈 이유 : 구간 경계와 헷지 코드 이름을 현업이 직접 유지하도록
" ──────────────────────────────────────────────────────────
@EndUserText.label : '수입 결제 환차손익 분석 기준 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zimpfx_map {
  key client   : abap.clnt not null;
  key map_type : abap.char(4) not null;    " BAND : 소요 구간 / HEDG : 헷지 구분
  key map_code : abap.char(10) not null;   " B1~B5 / NONE · PART · FWD
  day_from     : abap.int4;                " 구간 시작일수 (BAND 에서만 사용)
  day_to       : abap.int4;                " 구간 종료일수
  label        : abap.char(40);            " 화면에 보이는 이름
}

② ZI_ImportPayVendor — 공급사 차원

차원은 값과 이름을 한 곳에서 내려 주는 뷰입니다. 이 뷰가 있으면 화면의 "차원 값 선택" 대화 상자와 피벗 행 이름이 같은 텍스트를 씁니다.

" ──────────────────────────────────────────────────────────
" ZI_ImportPayVendor — 공급사 차원
" 역할 : 공급사 코드 + 이름 + 국가
" 이렇게 나눈 이유 : 큐브가 이름까지 들고 다니면 행 수가 늘어난다
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '공급사 차원'
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'Supplier'
define view entity ZI_ImportPayVendor
  as select from lfa1
{
      @ObjectModel.text.element: [ 'SupplierName' ]
  key lifnr as Supplier,
      @Semantics.text: true
      name1 as SupplierName,
      land1 as Country
}

③ ZI_ImportPayFxLine — 결제 품목 라인

이 뷰에서 "라인식"의 재료가 정해집니다. 송장 인식 라인의 원화 금액, 결제(청산) 라인의 원화 금액, 수수료를 한 행에 두어 결제 원화 − 수수료 − 인식 원화 = 환율 영향을 라인마다 대사할 수 있게 합니다. 검증용 샘플 데이터에서 3,189건 모두 차이 0으로 맞춘 식이 바로 이것입니다. 청산 연결 조건과 수수료 원천은 운영 문서 구조에 맞춰 확정이 필요합니다.

" ──────────────────────────────────────────────────────────
" ZI_ImportPayFxLine — 수입 결제 품목 라인
" 역할 : 인식 라인(inv) + 결제 라인(pay) → 라인 단위 환율 영향
" 이렇게 나눈 이유 : 라인식 대사의 기준을 큐브와 분리해 두면
"                    큐브 합계가 틀릴 때 라인에서 바로 원인을 찾는다
" 주의 : 청산 연결 조건은 운영 데이터 구조에서 확인 필요
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 결제 품목 라인'
define view entity ZI_ImportPayFxLine
  as select from acdoca as inv
    inner join   acdoca as pay
      on  pay.rbukrs = inv.rbukrs
      and pay.belnr  = inv.augbl
      and pay.lifnr  = inv.lifnr
  association [0..1] to ZI_ImportPayVendor as _Supplier
    on $projection.Supplier = _Supplier.Supplier
{
  key inv.rbukrs                              as CompanyCode,
  key inv.belnr                               as InvoiceDocument,
  key inv.docln                               as InvoiceItem,
      pay.belnr                               as PaymentDocument,
      inv.lifnr                               as Supplier,
      inv.rwcur                               as TransCurrency,
      inv.budat                               as RecognitionDate,
      pay.budat                               as PaymentDate,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      inv.hsl                                 as BookAmtLC,      " 인식 원화
      @Semantics.amount.currencyCode: 'LocalCurrency'
      pay.hsl                                 as PayAmtLC,       " 결제 원화
      @Semantics.amount.currencyCode: 'LocalCurrency'
      cast( 0 as abap.curr( 23, 2 ) )         as FeeAmtLC,       " 수수료 : 수수료 라인 연결 후 채움(확인 필요)
      inv.rhcur                               as LocalCurrency,
      _Supplier
}

④ ZI_ImportPayFxPlan — 예정 결제 원화

예정 대비 차이의 "예정"은 구매오더 조건에서 읽습니다. 구매오더 통화 금액을 예정 환율로 원화에 환산해 두면 실적과 같은 차원(공급사 · 통화 · 결제월)으로 비교됩니다. 예정 환율을 무엇으로 둘지는 운영 시점에 정할 일입니다.

" ──────────────────────────────────────────────────────────
" ZI_ImportPayFxPlan — 구매오더 조건 기반 예정 결제 원화
" 역할 : 구매오더 품목의 외화 금액을 예정 환율로 원화 환산
" 이렇게 나눈 이유 : 예정 환율 가정을 실적 계산과 섞지 않으려고
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 결제 예정'
define view entity ZI_ImportPayFxPlan
  as select from ekpo
    inner join   ekko on ekko.ebeln = ekpo.ebeln
{
  key ekpo.ebeln                                   as PurchaseOrder,
  key ekpo.ebelp                                   as PurchaseOrderItem,
      ekko.bukrs                                   as CompanyCode,
      ekko.lifnr                                   as Supplier,
      ekko.waers                                   as TransCurrency,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      currency_conversion(
        amount             => ekpo.netwr,
        source_currency    => ekko.waers,
        target_currency    => cast( 'KRW' as abap.cuky ),
        exchange_rate_date => ekko.bedat,
        exchange_rate_type => 'M',
        error_handling     => 'SET_TO_NULL' )      as PlanPayAmtLC,
      cast( 'KRW' as abap.cuky )                   as LocalCurrency
}

⑤ ZI_ImportPayFxCube — 큐브

환율 차이 계산이 한 번만 일어나는 곳입니다. 라인을 차원 조합으로 묶고 측정값(인식 · 결제 원화, 환율 영향, 수수료, 외환차익 · 외환차손)을 합산합니다. 외환차손과 외환차익은 환율 영향의 부호에 따라 갈라 합산하므로, 차손 − 차익 = 환율 영향이 항상 성립합니다.

" ──────────────────────────────────────────────────────────
" ZI_ImportPayFxCube — 수입 결제 환차손익 큐브
" 역할 : 결제 라인 → 차원 조합 × 측정값 6개
" 이렇게 나눈 이유 : 차손 · 차익 구분과 합산을 한 곳에서 해
"                    화면 · 보고서 · 에이전트가 같은 값을 쓰게 한다
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 결제 환차손익 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_ImportPayFxCube
  as select from ZI_ImportPayFxLine
{
      @ObjectModel.foreignKey.association: '_Supplier'
  key Supplier,
  key CompanyCode,
  key TransCurrency,
  key substring( PaymentDate, 1, 6 )           as PaymentMonth,
      @Semantics.currencyCode: true
      LocalCurrency,

      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'LocalCurrency'
      sum( BookAmtLC )                         as BookAmt,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'LocalCurrency'
      sum( PayAmtLC )                          as PayAmt,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'LocalCurrency'
      sum( PayAmtLC - FeeAmtLC - BookAmtLC )   as FxDiff,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'LocalCurrency'
      sum( FeeAmtLC )                          as FeeAmt,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'LocalCurrency'
      sum( case when ( PayAmtLC - FeeAmtLC - BookAmtLC ) > 0
                then ( PayAmtLC - FeeAmtLC - BookAmtLC ) else 0 end )
                                               as LossAmt,   " 외환차손
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'LocalCurrency'
      sum( case when ( PayAmtLC - FeeAmtLC - BookAmtLC ) < 0
                then 0 - ( PayAmtLC - FeeAmtLC - BookAmtLC ) else 0 end )
                                               as GainAmt,   " 외환차익
      _Supplier
}
group by Supplier, CompanyCode, TransCurrency,
         substring( PaymentDate, 1, 6 ), LocalCurrency

⑥ ZC_ImportPayFxQuery — 분석 쿼리

쿼리는 어떤 차원이 행과 열에 놓이는지, 어떤 필터가 필수인지, 어떤 계산항목을 같이 내려 줄지를 정합니다. 환율 영향률처럼 칸마다 같은 식으로 계산되는 값은 여기서 식으로 둡니다. 회사코드는 필수 필터로 둬 조회 범위가 무제한이 되지 않게 합니다.

" ──────────────────────────────────────────────────────────
" ZC_ImportPayFxQuery — 분석 쿼리(Consumption)
" 역할 : 기본 축 · 필수 필터 · 계산항목 정의
" 이렇게 나눈 이유 : 큐브를 건드리지 않고 화면별 기본 배치를 바꾼다
" ──────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 결제 환차손익 분석'
@Analytics.query: true
define view entity ZC_ImportPayFxQuery
  as select from ZI_ImportPayFxCube
{
      @AnalyticsDetails.query.axis: #ROWS
      @AnalyticsDetails.query.display: #KEY_TEXT
  key Supplier,
      @AnalyticsDetails.query.axis: #ROWS
  key TransCurrency,
      @AnalyticsDetails.query.axis: #COLUMNS
  key PaymentMonth,
      @Consumption.filter: { mandatory: true, selectionType: #SINGLE, multipleSelections: false }
  key CompanyCode,

      @AnalyticsDetails.query.axis: #COLUMNS
      PayAmt,
      @AnalyticsDetails.query.axis: #COLUMNS
      FxDiff,
      LossAmt,
      GainAmt,
      FeeAmt,
      @AnalyticsDetails.query.formula: 'FxDiff / BookAmt * 100'
      @EndUserText.label: '환율 영향률(%)'
      @AnalyticsDetails.query.decimals: 2
      FxDiff as FxRatePct
}

⑦ ZC_ImportPayFxQuery — 권한(DCL)

권한은 집계 단계에 겁니다. 드릴스루 라인에만 권한을 걸면 합계에서 다른 조직의 숫자를 뺄셈으로 역산할 수 있기 때문입니다. 회사코드 단위에서 시작해 필요하면 공급사 단위로 좁힙니다.

" ──────────────────────────────────────────────────────────
" ZC_ImportPayFxQuery — 접근 제어(DCL)
" 역할 : 회사코드 단위 조회 권한(표시 활동 03)
" 이렇게 나눈 이유 : 쿼리 정의와 권한 정의를 따로 이송 · 변경한다
" ──────────────────────────────────────────────────────────
@EndUserText.label: '수입 결제 환차손익 분석 권한'
@MappingRole: true
define role ZC_ImportPayFxQuery {
  grant select on ZC_ImportPayFxQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ ZUI_ImportPayFx — 서비스 정의와 바인딩

서비스 정의는 쿼리와 차원을 OData로 노출합니다. 바인딩은 OData V2 UI 유형으로 게시하고 서비스를 활성화한 뒤, 앱 매니페스트의 서비스 주소를 이 서비스로 바꾸면 화면이 운영 데이터를 읽습니다.

" ──────────────────────────────────────────────────────────
" ZUI_ImportPayFx — 서비스 정의
" 역할 : 분석 쿼리와 공급사 차원 노출
" 이렇게 나눈 이유 : 화면은 서비스 주소만 알면 되고 뷰 구조를 몰라도 된다
" ──────────────────────────────────────────────────────────
@EndUserText.label: '수입 결제 환차손익 분석 서비스'
define service ZUI_ImportPayFx {
  expose ZC_ImportPayFxQuery as ImportPayFx;
  expose ZI_ImportPayVendor  as Supplier;
}

" 서비스 바인딩 : 바인딩 유형 'OData V2 - UI' 로 만들고 [게시]
" 서비스 활성화 : /IWFND/MAINT_SERVICE (또는 바인딩 게시)
" 화면 연결     : 앱 매니페스트의 서비스 주소를 위 서비스로 교체

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코드가 아니라 합의이고, 합의가 끝나야 위 뷰들이 같은 숫자를 냅니다.

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

검증용 샘플 데이터(가상 공급사 12곳 · 결제월 2026.04~2026.09 · 가정 환율 · 통화 USD · EUR · JPY · CNY · 회사코드 1000)로 대사식을 전수로 돌렸습니다. 원천 결제 품목 라인은 3,189건(결제 문서 1,640건 + 이월(미결제) 181건 라인), 큐브는 9,816행(칸 1,636개 조합 × 측정값 6), 예정은 9,360행입니다.

아래 두 가지는 의도적 예외입니다. 대사 차이로 세지 않고 따로 기록해 두었습니다.

같은 숫자를 도입 포인트의 사례(예정 대비 +99.36억원, 요인 합 − 총차이 = 0원)에서도 씁니다. 화면 쪽은 별도 자동 실행으로 축 배치 6종의 총합이 같은지, 칸의 값과 라인 합이 같은지를 다시 확인했습니다.

운영 데이터로 갈 때

결제 라인이 수천만 건으로 늘면 화면이 한 번에 읽는 큐브의 크기가 문제가 됩니다. 검증용 샘플 데이터에서는 큐브 9,816행을 한 번에 읽어 브라우저에서 다시 묶지만, 운영에서는 아래 순서로 범위를 줄입니다.

1. 집계 위치 — 라인 → 차원 조합 집계는 데이터베이스 안(CDS 큐브)에서 끝내고, 화면은 집계된 칸만 읽습니다.
2. 파라미터 필수화 — 회사코드와 결제월 범위를 필수로 두고, 기간 상한을 정합니다.
3. 인덱스와 파티션 — 결제일 · 회사코드 · 공급사 조합에 맞춰 접근 경로를 확인합니다. 구체적 방식은 데이터 규모를 보고 정합니다.
4. 화면 상한 — 열 36개 · 행 노드 1,500개 상한과 드릴스루 읽는 단위(500건)는 큐브가 커져도 브라우저가 느려지지 않게 하는 안전장치입니다.
5. 응답 시간 기준 — 조회 한 번의 목표 시간을 정하고, 넘으면 필수 필터를 더 요구하는 쪽으로 조정합니다. 수치는 운영 환경에서 측정한 뒤 정합니다.

자주 묻는 질문

숫자와 산식, 화면과 조작, 분석 기능, 도입과 운영 순서로 모았습니다. 숫자는 모두 검증용 샘플 데이터 기준입니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영