SAP 외화 평가·결제 마감 통합 관리 — 결산 영역의 외화 평가 · 결제 청산 · 유동성 재분류를 만들고 승인하고 대사까지

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

기말 결산을 맡은 분들이 늘 받는 질문은 비슷합니다. 외화 미결 항목은 모두 기말 환율로 평가했는가, 결제로 정리된 건의 실현손익은 얼마이고 앞서 인식한 평가손익은 되돌렸는가, 만기가 1년 안으로 들어온 장기 외화 차입금은 유동성으로 옮겼는가, 그리고 장부 숫자와 보조원장 숫자가 맞는가. 지금은 F.05 · FAGL_FC_VAL 로 평가를 돌리고, F-44 · F-53 으로 정리하고, FBL3N · FBL5N · FAGLB03 에서 잔액을 옮겨 와 엑셀로 맞춘 뒤, 승인은 메일로 받는 경우가 많습니다. 표준 화면 하나하나는 잘 동작하지만 결과가 여러 화면과 파일에 흩어져 있어, 마감 일정 안에 “어디까지 끝났고 무엇이 남았는가”를 한눈에 보기 어렵습니다.

이 앱은 그 자리를 이어 붙입니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 처리 · 승인 · 대사 · 분석 관점을 더해 확장합니다. 관련 기준서는 IAS 21 환율변동효과(K-IFRS 제1021호)와 IFRS 9 금융상품(K-IFRS 제1109호)의 외화 항목 처리 관점이며, 어디까지나 점검의 관점으로만 쓰고 회계 처리의 결론은 회사와 감사인이 정합니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 숫자를 맞춰 보는 두 가지 장면

검증용 샘플 데이터(가상의 3개 회사 · 4개 통화 · 2026년 7~10월)에서 실제로 나온 숫자입니다. 환율과 금액은 시연용 가정값입니다.

첫째, 대사. 2026-09 기간의 최신 대사에서 R1(보조원장 잔액과 총계정 잔액) 검사 21건 중 차이 3건(최대 3,400,000원), R2(장부환율과 고시환율) 16건 중 3건, R3(평가손익 누계와 평가 문서) 16건 중 2건, R4(결제 외화금액과 청산 문서) 4건 중 2건이 나왔습니다. 모두 점검용으로 일부러 넣어 둔 예외 11건에 해당하며, 열림 7 · 조치 중 1 · 보류 1 · 수용 1 · 해소 1 로 나뉘어 표에 올라옵니다. 엑셀에서 옮겨 적어 맞추던 작업이, 어느 규칙에서 몇 건이 나왔는지 읽는 일로 바뀝니다.

둘째, 차이 분석. 2026-09 조정 금액은 계획 대비 총차이가 186,105,930원이었고, 워터폴은 이를 결제·정리, 평가, 대사·조정 세 단계의 라인 수 효과와 평균 금액 효과 여섯 요인으로 가릅니다. 가장 큰 요인은 결제·정리의 라인 수 효과(+404,949,932원)이고 평균 금액 효과(−342,755,573원)가 반대 방향으로 작용합니다. 여섯 요인의 합 186,105,930원은 총차이와 같고, 화면이 그 등식을 매번 보여 줍니다. 원인을 단정하는 화면이 아니라, 차이가 어느 단계에서 났는지 점검할 자리를 좁혀 주는 화면입니다.

도입하면 달라지는 것

• 마감 일정 — 결산 과업 51건의 진행률과 기한 경과 건이 홈 화면 카드로 보여, 일정 회의가 “어디까지 했나”를 묻는 자리에서 “무엇을 먼저 풀까”를 정하는 자리로 바뀝니다.
• 승인 — 메일 대신 문서 안에서 검토 요청 · 승인 · 전기가 이어지고, 같은 사람이 작성과 승인을 겸하지 못하게 화면이 막습니다.
• 대사 — 평가 문서를 전기한 뒤 규칙 4종을 버튼 한 번으로 돌리고, 차이 항목은 조정 · 보류 · 수용으로 이유와 함께 남깁니다.
• 사람이 바뀌어도 — 담당자가 바뀌어도 감사 로그와 문서 이력이 남아 인수인계가 짧아집니다.

이런 회사에 맞습니다

수출입이나 해외 차입으로 외화 채권 · 채무 · 예금 · 차입금을 가진 제조 · 유통 · 서비스 기업 가운데, 월 결산마다 외화 평가와 결제 정리를 SAP 표준 T-code 로 돌리면서 엑셀 대사와 메일 승인에 시간을 쓰는 곳입니다. 법인이나 사업장이 여럿이고 통화가 서너 가지 이상이며, 처리 담당 · 승인자 · 관리자가 나뉘어 있어 직무 분리가 필요한 재무 · 회계 · 자금 조직에 특히 맞습니다.

실행 화면

실제 브라우저에서 앱을 조작해 찍은 화면 중 대표 28종을 사용 순서대로 싣습니다(설명서에는 50종이 실려 있습니다). 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 보는 자리이고 누르면 무엇이 일어나는지를 아래에 적었습니다. 사례의 숫자는 모두 같은 가상 샘플 데이터에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

사용 방법

1. 회사 · 기간 고르기 — 화면 위쪽 머리말에서 회사 코드(1000 · 2000 · 3000)와 기간을 고르면 모든 탭이 같은 범위로 바뀝니다. 기간은 필수이고 회사는 비워 두면 전체입니다.
2. 조회 — 홈 · 기준정보 · 문서 · 대사 화면은 머리말의 회사 · 기간을 바꾸는 순간 자동으로 다시 조회됩니다. 분석 화면은 조건 영역 오른쪽 끝의 조회 버튼을 누르거나 조건 입력칸에서 Enter 키를 누르면 조회되며, 레이아웃을 ‘기본 + 자동 조회’로 저장하면 열릴 때 바로 조회됩니다.
3. 홈에서 요약 확인 — 카드(결산 진행률 · 기한 경과 과업 · 승인 대기 · 반려 문서 · 전기 대기 · 미해결 예외 · 보류 예외 · 안 읽은 보고)와 내 할 일 목록을 봅니다. 할 일 행을 누르면 해당 문서나 예외로 이동합니다.
4. 탭 이동 — 홈 → 기준정보 → 문서 처리 → 일괄 실행 → 대사 · 예외 → 결산 분석 → 영역 간 연계 → 이력 · 감사 · 권한 순으로 업무가 이어집니다.
5. 행 · 셀 눌러 상세 — 문서 행은 상세 창(분개 · 상태 이력 · 연계 문서)을, 분석 피벗의 칸은 근거 전표 명세(드릴스루)를 엽니다. 흐름도 노드는 연계 문서 상세로 이동합니다.
6. 처리 — 문서는 작성 → 검토 요청 → 승인 → 전기(필요하면 역처리) 순입니다. 일괄 실행은 모의 실행으로 건수 · 합계를 보고 실행합니다. 대사는 대사 실행 후 예외 행에서 조정 · 보류 · 수용을 고릅니다.
7. 내보내기와 올리기 — 표 위의 엑셀 내보내기는 xlsx 를 만들고, 분석 화면은 CSV 와 PPT 보고서 버튼이 있습니다. 기준정보와 문서는 xlsx 올리기 후 미리보기에서 정상 행만 반영합니다.

자동으로 불러오는 시점은 두 곳입니다. 앱을 열 때 홈의 할 일과 점검 에이전트(하루 1회)가 불러오고, 나머지 화면은 머리말의 회사 · 기간을 바꿀 때 조회됩니다. 분석 화면만은 조건을 여러 개 만지는 일이 많아 조회 버튼을 따로 두었습니다.

무엇으로 만들었나

앱 정보

처음 열었을 때 — 오늘 무엇을 해야 하는지가 먼저 보인다

앱을 열면 지금 할 일부터 보이도록 홈을 두었습니다. 마감 일정 · 승인 대기 · 예외 건수가 카드로 요약됩니다.

앱을 열면 가장 먼저 보이는 화면입니다. 카드의 숫자는 머리말에서 고른 회사 · 기간 기준이며, 아래 단계별 진행 막대(사전점검 · 결제·정리 · 평가 · 대사·조정 · 마감·보고)와 ‘내 할 일’ 목록이 이어집니다. 할 일 행을 누르면 해당 문서나 예외로 곧바로 이동합니다. 샘플 기준으로 과업 51건 중 15건이 완료되어 29% 로 표시됩니다.

기준정보 관리 — 대상 항목과 변경 이력

평가와 청산의 출발점은 외화 미결 항목입니다. 기준정보는 조회와 수정 · 업로드가 한 화면에서 이어지고 변경은 모두 로그에 남습니다.

기준정보는 계정 · 결산 과업 · 환율 · 외화 미결 항목 · 결산 일정 탭으로 나뉩니다. 이 화면은 미결 항목 탭이고 구분 필터로 채권 · 채무 · 예금 · 차입금 · 그룹 내 거래를 좁힙니다. 신규 · 일괄 업로드 · 엑셀 내보내기 버튼이 오른쪽 위에 있으며, 행마다 수정 · 이력 · 삭제 아이콘이 있어 변경은 모두 감사 로그에 남습니다. 중지된 항목은 평가 누계가 0 으로 보입니다.

문서 처리와 승인 — 작성자와 승인자는 같을 수 없다

문서는 임시저장에서 시작해 검토 요청 · 승인 · 전기 순서로만 진행되고, 필요하면 역처리로 되돌립니다. 각 단계는 역할에 따라 버튼이 달리 보입니다.

위쪽 파란 안내줄에 상태 흐름(작성중 → 검토중 → 승인됨 → 전기됨 → 역처리됨)과 직무 분리 규칙이 적혀 있습니다. 검색어 · 상태 · 유형 필터와 ‘내가 작성한 것만’ 체크로 목록을 좁히고, 행을 누르면 상세 창이 열립니다. 승인 단계 칸의 1/1 · 2/2 는 필요한 승인 수 가운데 받은 수입니다.

유형을 외화 평가로 고르면 해당 회사 · 기간의 외화 미결 항목이 처리 대상 목록에 뜹니다. 금액을 비워 두면 대상 기준 평가손익이 자동으로 들어갑니다. 저장하면 상태는 작성중이고, 이 단계에서는 장부에 아무것도 반영되지 않습니다.

상세 창 위쪽에 상태 · 금액 · 회사와 기간 · 승인 단계 · 작성과 승인 사용자가 나란히 보입니다. 분개 탭은 차변과 대변 합계가 같을 때만 ‘일치’로 표시되고, 검토 요청을 누르면 아래에 확인 메시지가 뜹니다. 차변과 대변이 맞지 않으면 요청 자체가 거절됩니다.

노란 안내줄에 ‘작성자는 자기 문서를 승인 · 반려할 수 없습니다’가 표시됩니다. 사용자를 승인 권한이 있는 다른 사람으로 바꾸면 승인할 수 있습니다. 5천만 원 이상은 서로 다른 2인의 승인이 필요하도록 두었고, 이 기준 금액은 시연용 가정값입니다.

승인자 역할은 승인 · 반려(사유 필수)만 보이고, 전기는 처리자 · 관리자에게 열리도록 안내가 바뀝니다. 승인 직후에도 아직 장부에 반영되지 않았다는 점을 상태 칸으로 구분해 읽습니다.

전기는 확인 창을 한 번 거치며, 열린 기간에서만 가능합니다. 상태 이력 탭의 건수(여기서는 4건)가 요청 · 승인 · 전기마다 하나씩 늘어 순서대로 쌓입니다. 전기된 뒤에는 안내줄이 ‘역처리는 승인자 · 관리자만 할 수 있습니다’로 바뀝니다. 마감된 기간이면 처리 버튼이 비활성으로 보입니다.

역처리는 승인자 · 관리자에게만 보입니다. 역처리된 문서는 더 이상 처리할 수 없다는 안내가 뜨고, 연결 문서 탭에 역분개 문서 번호가 나타납니다. 이 문서는 대사 R3의 평가 문서 합계에서 역처리 분이 함께 계산됩니다.

일괄 실행 — 시뮬레이션 합계와 실행 결과가 같다

결제 청산(SETL) · 외화 평가(FXEV) · 유동성 재분류(RCLS)는 모의 실행으로 먼저 보고, 실행하면 같은 합계의 문서가 만들어집니다.

처리 종류(결제 청산 · 외화 평가 · 유동성 재분류) · 회사 · 기간을 정하고 모의 실행을 누르면 저장 없이 대상과 금액을 미리 보여 줍니다. 대상마다 통화 · 금액 · 평가손익과 산식(결제 외화금액 × 결제환율과 장부환율의 차이 등)이 한 줄로 적혀 있어, 실행 전에 숫자가 어떻게 만들어지는지 읽을 수 있습니다.

아래 알림에 ‘문서 4건을 만들었습니다’가 뜨고, 실행 이력 표 맨 위에 새 실행 번호가 올라옵니다. 모의 실행 합계와 실행 이력의 합계가 같다는 것이 이 화면에서 확인할 핵심입니다.

일괄 처리의 단위는 대상(미결 항목)이며, 이미 문서가 만들어진 대상은 같은 기간에 새로 만들지 않고 건너뜁니다. 재실행을 안심하고 눌러도 되도록 둔 장치입니다. 실행 이력은 지난달과 지지난달 기록까지 이어서 보입니다.

대상별 결과 표에는 만들어진 청산 문서 번호가 링크로 붙어 있어 곧바로 문서 상세로 갈 수 있습니다. 일부 대상이 건너뛰어졌다면 이력 표 상태 칸에 ‘일부 건너뜀’으로 표시되고, 로그 탭에서 사유를 읽습니다.

대사와 예외 조치 — 차이는 이유와 함께 남긴다

대사 규칙 R1~R4를 돌려 차이 항목을 예외로 올리고, 조정 · 보류 · 수용으로 조치한 뒤 재대사로 해소를 확인합니다.

2026-09 기준 R1 점검 21 · 차이 3 · 최대 3,400,000원, R2 16 · 3, R3 16 · 2, R4 4 · 2 입니다. 통화가 다른 금액은 합치지 않고 통화별로 맞춥니다. 오른쪽 위 대사 실행 버튼으로 다시 돌릴 수 있으며, 아래 예외 목록 11건이 같은 화면에 이어집니다.

예외마다 좌측값과 우측값, 차이, 상태(미해결 · 조치 중 · 보류 · 허용 종결 · 해소)가 보입니다. 조정은 R1 · R3 예외에만 열리고, R2 · R4 예외는 보류 또는 수용으로 처리합니다. 수용(화면에는 ‘허용 종결’로 표시)과 보류에는 사유를 적습니다. 홈 카드의 ‘미해결 예외’가 이 표의 미해결 건수입니다.

R1 차이 건수가 3건에서 2건으로 줄고, 외화예금 행의 상태가 해소로 바뀐 것이 보입니다. 조정 문서(ADJ) 번호가 사유 칸에 링크로 남아 어떤 문서로 정리했는지 따라갈 수 있습니다.

분석 — 칸을 누르면 근거 문서까지, 합계는 요인으로 갈라진다

피벗 · 드릴스루 · 계획 대비 차이 · 워터폴은 모두 같은 분석 큐브에서 나옵니다. 큐브는 근거 라인 합과 항상 일치해야 하며 검산 결과가 화면 아래에 나옵니다.

조회 조건은 접어 둘 수 있고, 요약 카드는 조정 금액 23,957,242,230원(계획 대비 +3,475,955,078), 지연 일수 156.7일, 전표 라인 612건을 보여 줍니다. 비교 기준을 계획으로 두면 칸마다 실적 · 기준 · 차이 · 증감이 붙고, 금액과 비율 기준을 모두 넘는 칸만 색을 입혀 작은 흔들림은 눈에 띄지 않게 합니다. 행 축과 열 축에는 차원을 끌어다 놓아 구성을 바꾸며, 위에 CSV와 PPT 보고서 버튼이 있습니다.

창 제목에 단계와 건수(예: P3 · 191건)가 보이고 전표 · 기간 · 회사 · 계정 · 유형 · 조정 금액 · 손익 영향 · 지연 일수가 이어집니다. 명세 합계가 눌렀던 칸의 금액과 같은지 확인하는 것이 읽는 방법이며, 전표 번호를 누르면 문서 상세로 이동합니다.

사유는 필수이고, 저장하면 조회 범위와 행 경로를 키로 남아 축을 바꾸거나 다시 조회해도 같은 행에 따라옵니다. 숫자만 보고 지나치지 않고 ‘왜’를 같은 자리에 적어 두려는 장치이며, 입력한 사유는 감사 로그에도 쌓입니다.

결제·정리 · 평가 · 대사·조정 각각의 라인 수 효과와 평균 금액 효과를 막대로 그립니다. 표에는 요인 금액 · 비중 · 설명이 있고, 맨 아래 초록 줄이 ‘요인 합계 186,105,930원 = 전체 차이 186,105,930원 — 일치’를 알려 줍니다. 원인을 단정하지 않고 점검할 단계를 좁히는 용도입니다.

영역 간 연계 — 재무 문서가 영업 · 구매 · 자금으로 이어진다

평가와 청산 문서가 영업(SD) · 구매(MM) · 자금(TR) 문서와 어떻게 이어지는지 흐름도 하나로 봅니다.

청산 문서는 영업 매출 연계 문서(SDX)나 구매 연계 문서(MMX)로, 평가 문서는 자금 반영 문서(TRP)로 이어집니다. 위쪽 영역 필터로 한 영역만 좁혀 보고, 위쪽 안내줄에는 재무 문서를 역처리하면 따라 생긴 연계 문서도 함께 되돌려진다는 설명이 있습니다.

연계 문서는 원본 청산 문서와 대상 번호를 함께 보여 줍니다. 분개 항목은 비어 있고(재무 분개는 원본 문서에 있음) 상태 · 금액 · 승인 단계 · 이력 · 연계 문서 탭은 일반 문서와 같은 모양이라 영역이 달라도 읽는 방법이 같습니다.

AI 분석과 에이전트 — 숫자는 서비스가 계산하고 문장은 그 숫자를 읽는다

해설은 규칙 기반으로 먼저 나오고, 점검 에이전트는 하루 한 번 규칙을 돌려 결과를 역할별 보고로 올립니다.

금액과 비율은 서비스가 큐브에서 계산해 근거 표로 넘기고, 해설은 그 숫자를 문장으로 옮깁니다. 근거 표를 펼치면 같은 숫자를 그대로 볼 수 있고, 슬라이드(PPTX)로 내려받아 보고 자료에 붙일 수도 있습니다.

규칙마다 임계값과 받을 역할이 정해져 있고, 걸리면 현재 건수와 함께 확인이 필요하다는 문장이 보고로 쌓입니다. 하루에 한 번만 돌고, 아래 활동 기록 표에 호출 주체와 결과가 남습니다. 확인 버튼으로 읽음 처리합니다.

이력 · 감사 · 역할 — 승인 버튼은 승인자에게만 보인다

모든 처리가 감사 로그에 남고, 역할에 따라 버튼이 켜지고 꺼집니다.

탭은 감사 로그 · 상태 이력 · 사용자 · 권한 · 에이전트 규칙입니다. 상태 변경은 ‘DRAFT → REVIEW’처럼 이전 → 이후로, 대사 실행은 규칙별 차이 건수로 적힙니다. 직무 분리에서 막힌 시도도 같은 목록에 남습니다.

같은 화면이라도 조회자(U01)에게는 처리 버튼이 막히고, 처리자(U02 · U03)는 작성과 실행, 승인자(U04 · U05)는 승인과 반려, 관리자(U06)는 전부 쓸 수 있습니다. 운영에서는 이 역할이 SAP 권한 객체로 옮겨 갑니다.

레이아웃과 좁은 화면

분석 구성은 이름을 붙여 저장하고, 좁은 화면에서는 배치가 바뀝니다.

행 · 열 · 필터로 쓸 차원 9종이 위쪽에 놓여 있고, 구성한 배치를 이름 붙여 저장합니다. 기본 + 자동 조회로 저장하면 다음에 열 때 바로 그 배치로 조회됩니다.

표는 가로로 밀어 보고, 오른쪽에 있던 차트는 구분 손잡이 아래로 내려옵니다. 같은 분석을 휴대폰에서도 확인할 수 있게 한 대응입니다.

화면 뒤에서 일어나는 일

화면은 조건을 모아 서비스에 필터로 보내고, 받은 데이터를 표와 카드에 그립니다. 값이 비어 있는 조건은 보내지 않습니다. 문서 상태를 바꾸는 버튼은 화면이 상태를 직접 고치지 않고 서비스의 함수(검토 요청 · 승인 · 반려 · 전기 · 역처리)를 부릅니다. 서비스가 허용된 전이인지, 역할이 맞는지, 작성자와 승인자가 같지 않은지를 판단해 결과와 이력을 남깁니다. 분석 피벗은 받은 데이터를 화면에서 다시 배열해 재조회 없이 축을 바꾸고, 드릴스루와 요인 분해는 서비스에 다시 물어 합계를 검산합니다. 서비스에 닿지 못하면 메시지 처리기가 안내 창을 띄웁니다.

판정 규칙 — 평가 · 청산 · 재분류가 만들어지는 조건

평가손익 = 외화 금액 × (기말 고시환율 − 장부환율) ÷ 환율 단위. 외화 채무는 부호를 반대로 합니다. 이 앱은 분류 · 집계 · 대사를 돕는 도구이며 회계 판단을 확정하지 않습니다.

처리 단계와 대사식

통화가 다른 금액은 합산하지 않고 통화별로 대사합니다. 분석 큐브는 근거 라인 합과 항상 일치해야 하며, 검산 결과가 분석 화면 아래에 표로 나옵니다.

조회조건

모든 조건은 서비스에 $filter 조건으로 전달되고, 정렬은 $orderby, 건수 제한은 $top, 전체 건수는 $inlinecount 로 받습니다.

결과 컬럼

좁은 화면에서 달라지는 것

폭이 줄어들면 왼쪽 메뉴는 햄버거 버튼 뒤로 접히고, 머리말의 회사 · 기간 · 사용자는 상단에 작게 남습니다. 분석 화면은 요약 카드가 두 줄로 쌓이고, 오른쪽에 있던 차트는 표 아래로 내려옵니다. 표는 가로로 밀어 보며, 조작 순서와 버튼 이름은 넓은 화면과 같습니다.

파일 구성

index.html            앱 진입점
readme.html           설명서(화면 50종 · 판정 규칙 · 검증 결과)
manifest.json         앱 설정과 서비스 선언
Component.js
controller/ view/ fragment/ model/ css/ i18n/
odata/<서비스 이름>/   서비스 로직 · 판정 코어 · 데이터 집합별 샘플 데이터
media/                소개 영상 · 포스터 · 재생 지점

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 · 처리 관점을 더해 확장합니다. 이 절은 어디까지가 표준이고 어디서부터가 이 앱인지, 두 화면의 숫자를 어디서 맞춰 보는지를 정리합니다.

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

T-code 별 연계 지점

운영 전환 시 기존 리포트를 없애야 하나요? 없애지 않습니다. 법정 · 감사 · 세무 대응에 쓰는 표준 화면과 리포트는 그대로 두고, 이 앱은 결산 중 처리 · 승인 · 대사 · 분석을 한 곳에서 하는 자리로 씁니다. 처음에는 두 화면 숫자를 같이 놓고 R1~R4 차이가 0으로 맞는지 확인하다가, 팀이 믿을 수 있다고 판단하는 시점에 표준 쪽 사용 빈도를 정하시면 됩니다.

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

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 도구가 있어, 총계정 잔액이나 개별 항목을 분석하는 용도는 이미 표준에서 다룹니다. 이 앱의 분석 화면은 그 자리를 대신하지 않고, 외화 결산 문서(평가 · 청산 · 재분류 · 조정)와 대사 결과라는 결산 업무 단위로 큐브를 따로 두어 ‘평가 · 정리 금액이 계획 대비 어느 단계에서 벌어졌는가’를 보는 관점을 더합니다. 운영 시에는 큐브를 표준 CDS 뷰 위에 얹고, 표준 분석 앱에서 보던 필터 값과 같은 조건으로 대조하면 됩니다. 특정 표준 Fiori 앱 이름과 표준 CDS 뷰 이름은 시스템마다 달라 확인이 필요하므로, 4장에서는 원천 테이블 기준으로 적었습니다.

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

요구사항 매핑표

CDS 구성 — 최대한 자세히

아래는 운영 시스템에서 같은 구성을 만들 때의 스케치입니다. 기준 → 차원 → 큐브 → 쿼리 → 권한 순으로 뷰를 쌓고, 상태가 있는 문서는 RAP 비즈니스 오브젝트로 둡니다. 원천은 표준 테이블(BKPF · BSEG · ACDOCA · TCURR · BSIS · BSID · BSIK · T001)이며, 표준 CDS 뷰 이름은 시스템마다 확인이 필요해 테이블 기준으로 적었습니다.

뷰 레이어 구성

① 기준 테이블 — 평가 계정 매핑 · 문서 머리글

어느 계정을 평가 대상으로 보고, 평가이익 · 평가손실 · 재분류 상대 계정이 어디인지는 회사마다 다릅니다. 이 값을 코드에 박아 두면 계정과목표가 바뀔 때마다 뷰를 고쳐 이송해야 하므로, 회사코드별 기준 테이블로 둡니다. 문서 머리글 테이블은 이 앱이 소유하는 데이터(문서 유형 · 상태 · 승인 이력)를 담습니다.

"──────────────────────────────────────────────────────────────────────
" ZFXC_ACCTMAP · ZFXC_DOCHDR : 기준(매핑) 테이블
" 하는 일  : 평가 대상 계정과 상대 계정을 짝짓고, 외화 결산 문서 머리글을 담는다.
" 나눈 이유: 계정을 코드에 박지 않는다. 문서 상태와 승인 정보는 앱이 소유한다.
"──────────────────────────────────────────────────────────────────────
@EndUserText.label : '외화 평가 계정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zfxc_acctmap {
  key mandt   : mandt not null;
  key bukrs   : bukrs not null;
  key saknr   : saknr not null;
  item_kind   : abap.char(2);     " AR 채권 · AP 채무 · BK 예금 · LN 차입금 · IC 그룹 내
  gain_acct   : saknr;            " 평가이익 계정
  loss_acct   : saknr;            " 평가손실 계정
  recl_acct   : saknr;            " 유동성 재분류 상대 계정
  valid_from  : datum;
}

@EndUserText.label : '외화 결산 문서 머리글'
@AbapCatalog.enhancement.category : #EXTENSIBLE_ANY
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zfxc_dochdr {
  key mandt        : mandt not null;
  key doc_no       : abap.char(16) not null;   " FXR-26-000121 형식
  key fiscal_year  : gjahr not null;
  doc_type         : abap.char(3);             " FXR 평가 · FXS 청산 · RCL 재분류 · ADJ 조정
  bukrs            : bukrs;
  period           : abap.char(7);             " 2026-09
  status           : abap.char(1);             " D 작성중 · R 검토중 · A 승인됨 · P 전기됨 · V 역처리됨 · J 반려
  @Semantics.amount.currencyCode : 'zfxc_dochdr.local_cur'
  amount_local     : abap.curr(15,2);
  local_cur        : waers;
  created_by       : syuname;
  approved_by      : syuname;
  last_changed_at  : timestampl;
}

② ZI_FxRateMap — 고시환율과 환율 단위

환율은 ‘1 외화당 원화’가 아니라 환율 단위(JPY 100 등)를 반영해야 같은 기준으로 비교됩니다. 이 뷰가 단위를 한 번만 풀어 두면 평가 · 청산 · 대사 R2 가 모두 같은 환율을 읽습니다. TCURR 의 날짜는 뒤집힌 형식(GDATU)으로 저장되므로 변환 지점을 여기에 모아 둡니다.

"──────────────────────────────────────────────────────────────────────
" ZI_FxRateMap : 차원 — 고시환율(환율 단위 반영)
" 하는 일  : 환율표(TCURR)를 읽어 외화 1 단위당 환율(RatePerUnit)을 계산한다.
" 나눈 이유: 환율 단위 처리를 한 곳에 두어 평가 · 청산 · 대사가 같은 환율을 쓴다.
"──────────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '고시환율(환율 단위 반영)'
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #S, dataClass: #CUSTOMIZING }
define view entity ZI_FxRateMap
  as select from tcurr
{
  key kurst                    as RateType,
  key fcurr                    as FromCurrency,
  key tcurr                    as ToCurrency,
  key gdatu                    as InvertedValidFrom,      // 뒤집힌 날짜 형식
      ffact                    as FromFactor,
      tfact                    as ToFactor,
      ukurs                    as ExchangeRate,
      division( cast( ukurs as abap.dec(15,5) ) * cast( tfact as abap.dec(15,5) ),
                cast( ffact as abap.dec(15,5) ), 5 )   as RatePerUnit
}

③ ZI_FxOpenItem — 외화 미결 항목

평가와 청산의 대상은 총계정(BSIS), 고객(BSID), 공급업체(BSIK) 미결 항목에 흩어져 있습니다. 세 원천을 같은 모양으로 맞춰 합쳐 두면 일괄 처리와 대사 R1 이 계정 유형을 가리지 않고 한 뷰만 읽습니다. 매핑 테이블과 맞물려 외화 계정만 남기며, 로컬 통화와 문서 통화가 같은 항목은 대상에서 뺍니다.

"──────────────────────────────────────────────────────────────────────
" ZI_FxOpenItem : 차원 — 외화 미결 항목(총계정 · 고객 · 공급업체)
" 하는 일  : BSIS · BSID · BSIK 를 같은 컬럼 구성으로 합치고, 매핑된 외화 계정만 남긴다.
" 나눈 이유: 평가 · 청산 · 대사 R1 이 계정 유형을 가리지 않고 같은 뷰를 읽게 한다.
"──────────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '외화 미결 항목'
define view entity ZI_FxOpenItem
  as select from bsis as i
    inner join zfxc_acctmap as m on  m.bukrs = i.bukrs
                                 and m.saknr = i.hkont
    inner join t001         as c on  c.bukrs = i.bukrs
{
  key i.bukrs                  as CompanyCode,
  key i.belnr                  as AccountingDocument,
  key i.gjahr                  as FiscalYear,
  key i.buzei                  as AccountingDocumentItem,
      cast( 'G' as abap.char(1) ) as LedgerSource,
      i.hkont                  as GLAccount,
      m.item_kind              as ItemKind,
      i.waers                  as TransactionCurrency,
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      i.wrbtr                  as AmountInTransactionCurrency,
      c.waers                  as CompanyCodeCurrency,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      i.dmbtr                  as AmountInCompanyCodeCurrency
}
where i.waers <> c.waers
union all
select from bsid as i
    inner join zfxc_acctmap as m on  m.bukrs = i.bukrs
                                 and m.saknr = i.hkont
    inner join t001         as c on  c.bukrs = i.bukrs
{
  key i.bukrs, key i.belnr, key i.gjahr, key i.buzei,
      cast( 'D' as abap.char(1) ), i.hkont, m.item_kind,
      i.waers, i.wrbtr, c.waers, i.dmbtr
}
where i.waers <> c.waers
union all
select from bsik as i
    inner join zfxc_acctmap as m on  m.bukrs = i.bukrs
                                 and m.saknr = i.hkont
    inner join t001         as c on  c.bukrs = i.bukrs
{
  key i.bukrs, key i.belnr, key i.gjahr, key i.buzei,
      cast( 'K' as abap.char(1) ), i.hkont, m.item_kind,
      i.waers, i.wrbtr, c.waers, i.dmbtr
}
where i.waers <> c.waers

④ ZI_FxCloseCube — 분석 큐브

분석 화면의 모든 숫자는 이 큐브에서 나옵니다. 금액은 통화 코드와 함께 집계해야 통화가 다른 값이 섞이지 않고, 문서 유형(평가 · 청산 · 재분류 · 조정)은 전표 참조에서 읽어 한 가지 기준으로 분류합니다. 큐브 합계가 근거 라인 합과 같아야 하므로, 운영에서는 이 뷰와 근거 라인 뷰의 합계를 검산하는 확인 쿼리를 함께 둡니다(샘플에서는 45건 모두 차이 0).

"──────────────────────────────────────────────────────────────────────
" ZI_FxCloseCube : 큐브 — 외화 결산 금액 · 건수
" 하는 일  : ACDOCA 라인을 회사 · 기간 · 계정 · 통화 · 문서 유형으로 집계한다.
" 나눈 이유: 집계를 한 곳에 두어 피벗 · 드릴스루 · 요인 분해가 같은 숫자를 읽는다.
"──────────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '외화 결산 큐브'
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZI_FxCloseCube
  as select from acdoca as a
  association [0..1] to ZI_FxRateMap as _Rate
    on  _Rate.FromCurrency = $projection.TransactionCurrency
    and _Rate.ToCurrency   = $projection.CompanyCodeCurrency
{
  key a.rbukrs                       as CompanyCode,
  key a.fiscyearper                  as FiscalYearPeriod,
  key a.racct                        as GLAccount,
  key a.rtcur                        as TransactionCurrency,
  key case substring( a.xblnr, 1, 3 )
        when 'FXR' then 'FXR'
        when 'FXS' then 'FXS'
        when 'RCL' then 'RCL'
        when 'ADJ' then 'ADJ'
        else 'ETC' end               as FxDocumentType,
      a.rhcur                        as CompanyCodeCurrency,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      @DefaultAggregation: #SUM
      sum( a.hsl )                   as AmountInCompanyCodeCurrency,
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      @DefaultAggregation: #SUM
      sum( a.tsl )                   as AmountInTransactionCurrency,
      @DefaultAggregation: #SUM
      count( * )                     as LineCount,
      _Rate
}
group by a.rbukrs, a.fiscyearper, a.racct, a.rtcur, a.rhcur,
         substring( a.xblnr, 1, 3 )

⑤ ZC_FxCloseQuery — 분석 쿼리

쿼리는 어떤 차원을 행 · 열 · 자유 축에 놓을지와 어느 필터를 필수로 둘지를 선언합니다. 기간을 필수 필터로 두면 큐브 전체가 한꺼번에 읽히는 일이 없고, 화면의 조회 버튼과 같은 약속(기간을 정한 뒤 조회)이 서비스 쪽에서도 지켜집니다.

"──────────────────────────────────────────────────────────────────────
" ZC_FxCloseQuery : 쿼리 — 행 · 열 · 필터 선언
" 하는 일  : 큐브를 분석 화면의 피벗 구성(행/열/자유 축)과 필수 필터로 노출한다.
" 나눈 이유: 화면이 아니라 서비스가 조회 범위(기간 필수)를 강제하게 한다.
"──────────────────────────────────────────────────────────────────────
@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '외화 결산 분석'
@UI.headerInfo: { typeName: '외화 결산', typeNamePlural: '외화 결산' }
define view entity ZC_FxCloseQuery
  as select from ZI_FxCloseCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @AnalyticsDetails.query.displayHierarchy: #OFF
  @UI.lineItem: [{ position: 10 }]
  FxDocumentType,

  @AnalyticsDetails.query.axis: #ROWS
  @UI.lineItem: [{ position: 20 }]
  GLAccount,

  @AnalyticsDetails.query.axis: #COLUMNS
  @Consumption.filter: { selectionType: #INTERVAL, multipleSelections: false, mandatory: true }
  FiscalYearPeriod,

  @AnalyticsDetails.query.axis: #FREE
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true }
  CompanyCode,

  @AnalyticsDetails.query.axis: #FREE
  TransactionCurrency,

  @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
  AmountInCompanyCodeCurrency,
  CompanyCodeCurrency,
  LineCount
}

⑥ ZR_FxSettlement — 결제 청산 문서(RAP 루트)

평가 · 청산 · 재분류 · 조정 문서는 상태를 가지고 이력이 남아야 하므로 읽기 전용 큐브가 아니라 RAP 루트 엔티티로 둡니다. 루트 뷰는 머리글 테이블을 읽고 라인을 composition 으로 묶습니다. 아래는 청산(FXS) 문서를 예로 든 스케치이며, 같은 구조를 문서 유형 값만 달리해 평가 · 재분류 · 조정에 씁니다.

"──────────────────────────────────────────────────────────────────────
" ZR_FxSettlement : RAP 루트 — 외화 결산 문서(청산 문서 예)
" 하는 일  : 머리글과 라인을 composition 으로 묶고 상태 · 승인자를 노출한다.
" 나눈 이유: 상태 전이와 직무 분리를 화면이 아니라 비즈니스 오브젝트에 둔다.
"──────────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '외화 결산 문서'
define root view entity ZR_FxSettlement
  as select from zfxc_dochdr
  composition [0..*] of ZR_FxSettlementItem as _Item
{
  key doc_no                  as DocumentNo,
  key fiscal_year             as FiscalYear,
      doc_type                as FxDocumentType,
      bukrs                   as CompanyCode,
      period                  as FiscalPeriod,
      status                  as DocumentStatus,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      amount_local            as AmountInCompanyCodeCurrency,
      local_cur               as CompanyCodeCurrency,
      created_by              as CreatedBy,
      approved_by             as ApprovedBy,
      @Semantics.systemDateTime.lastChangedAt: true
      last_changed_at         as LastChangedAt,
      _Item
}

"──────────────────────────────────────────────────────────────────────
" ZR_FxSettlement 동작 정의 : 액션 · 직무 분리 검증
" 하는 일  : 검토 요청 · 승인 · 반려 · 전기 · 역처리를 액션으로 두고, 승인 시 작성자와 승인자가 같은지 검사한다.
" 나눈 이유: 상태 전이 규칙(어느 상태에서 어느 액션이 되는가)을 한 곳에서 관리한다.
"──────────────────────────────────────────────────────────────────────
managed implementation in class zbp_r_fxsettlement unique;
strict ( 2 );

define behavior for ZR_FxSettlement alias Settlement
persistent table zfxc_dochdr
lock master
authorization master ( instance )
etag master LastChangedAt
{
  create;
  update ( features : instance );
  field ( readonly ) DocumentNo, DocumentStatus, ApprovedBy, LastChangedAt;
  association _Item { create; }

  action ( features : instance ) submit  result [1] $self;      // 작성중 → 검토중
  action ( features : instance ) approve result [1] $self;      // 검토중 → 승인됨 (작성자 ≠ 승인자)
  action ( features : instance ) reject  parameter ZA_FxReason result [1] $self;
  action ( features : instance ) post    result [1] $self;      // 승인됨 → 전기됨 (열린 기간)
  action ( features : instance ) reverse parameter ZA_FxReason result [1] $self;

  validation checkSeparationOfDuty on save { field ApprovedBy; }
  validation checkBalanced         on save { create; update; }  // 차변 합 = 대변 합

  mapping for zfxc_dochdr
  {
    DocumentNo = doc_no;   FiscalYear = fiscal_year;   FxDocumentType = doc_type;
    CompanyCode = bukrs;   FiscalPeriod = period;      DocumentStatus = status;
    AmountInCompanyCodeCurrency = amount_local;        CompanyCodeCurrency = local_cur;
    CreatedBy = created_by; ApprovedBy = approved_by;  LastChangedAt = last_changed_at;
  }
}

⑦ 접근 제어 — DCL 역할

접근 제어는 큐브에 겁니다. 드릴스루나 근거 라인 뷰에만 걸면 전체 합계와 자기 몫의 차이로 다른 회사 숫자가 새어 나갈 수 있습니다. 큐브에 회사 코드 권한을 걸고 쿼리가 그 조건을 물려받게 하면, 어느 경로로 읽어도 같은 범위만 보입니다. 화면의 역할(조회자 · 처리자 · 승인자 · 관리자)은 운영에서 PFCG 역할과 권한 객체로 옮깁니다.

"──────────────────────────────────────────────────────────────────────
" ZI_FxCloseCube 접근 제어 : 회사 코드 단위
" 하는 일  : F_BKPF_BUK(회사 코드, 조회 활동)을 큐브에 건다. 쿼리는 이 조건을 상속한다.
" 나눈 이유: 집계 단계에서 걸러야 합계 차이로 다른 회사 숫자가 드러나지 않는다.
"──────────────────────────────────────────────────────────────────────
@EndUserText.label: '외화 결산 큐브 — 회사 코드 접근 제어'
@MappingRole: true
define role ZI_FxCloseCube {
  grant select on ZI_FxCloseCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

@EndUserText.label: '외화 결산 쿼리 — 큐브 조건 상속'
@MappingRole: true
define role ZC_FxCloseQuery {
  grant select on ZC_FxCloseQuery
    where inheriting conditions from entity ZI_FxCloseCube;
}

⑧ 서비스 정의와 바인딩

어느 뷰와 RAP 오브젝트를 OData 로 내보낼지는 서비스 정의 한 곳에서 정하고, 바인딩에서 프로토콜(OData V2 UI)을 고릅니다. 화면이 부르는 데이터 집합 이름과 함수 이름은 이 정의에서 별칭으로 정해지므로, 운영 전환 때 화면을 고치지 않으려면 별칭을 샘플과 맞추면 됩니다.

"──────────────────────────────────────────────────────────────────────
" ZSD_FxCloseService : 서비스 정의
" 하는 일  : 화면이 부를 뷰와 RAP 오브젝트의 이름(별칭)을 정한다.
" 나눈 이유: 게시 범위를 한 곳에서 관리하고, 화면 쪽 이름을 바꾸지 않아도 되게 한다.
"──────────────────────────────────────────────────────────────────────
@EndUserText.label: '외화 평가 · 결제 마감 서비스'
define service ZSD_FxCloseService {
  expose ZR_FxSettlement     as DocHeader;
  expose ZR_FxSettlementItem as DocItem;
  expose ZC_FxCloseQuery     as Cube;
  expose ZI_FxOpenItem       as Target;
  expose ZI_FxRateMap        as FxRate;
}

// 서비스 바인딩(ADT 에서 생성): 이름 ZUI_FxClose_O2 · 바인딩 유형 OData V2 - UI · 게시(Publish) 후
// /IWFND/MAINT_SERVICE 에서 활성화 상태를 확인한다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코드를 쓰기 전에 회사가 정해 두어야 하는 것들입니다.

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

결산 숫자에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 만드는 쪽에서 먼저 대사식을 세우고 전수로 돌린 결과입니다. 대사 R1~R4의 차이는 점검용으로 일부러 넣어 둔 예외 11건(R1 4 · R2 3 · R3 2 · R4 2)이며, 그 외 검산은 모두 차이 0입니다.

기능 검증은 실제 브라우저 조작으로 M1~M8 · P1~P10 · F1~F15 가 모두 통과했습니다. 샘플 데이터 규모는 외화 미결 항목 76건, 문서 264건(전기 240 · 역처리 4 · 검토 14 · 승인 5 · 반려 1), 분석 큐브 3,915건입니다.

운영 데이터로 갈 때

샘플은 수천 건이지만 운영에서는 총계정 라인(ACDOCA)이 수천만 건이 됩니다. 집계는 화면이나 서비스 로직이 아니라 데이터베이스(CDS 큐브)에서 하고, 분석 쿼리의 기간을 필수 필터로 두어 전체를 읽는 요청이 없게 합니다. 외화 미결 항목은 BSIS · BSID · BSIK 가 이미 미결만 담고 있어 규모가 작지만, 회사 코드 · 계정 · 통화에 맞춘 인덱스와 조회 기간 상한은 정해 두는 편이 좋습니다. 드릴스루는 집계가 아니라 조회이므로 건수를 먼저 세어 보고 상한을 넘으면 범위를 좁히라고 안내하며, 응답 시간 기준(예: 월말 동시 접속에서 몇 초 이내)은 운영 연결 단계에서 회사가 정합니다.

자주 묻는 질문

도입 상담과 데모에서 자주 나오는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영