SAP 영업활동 현금흐름 직접법·간접법 대사 점검 — IFRS 18(K-IFRS 제1118호)에 따라 개정되는 IAS 7 기준, 영업손익에서 출발하는 간접법과 현금거래로 모은 직접법을 맞추고 이자·배당 분류 차이와 전환 영향을 가려 보는 결산 화면

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

IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 2027-01-01 이후 개시하는 회계연도부터 적용되고(조기적용 허용, 비교기간 재작성), 함께 개정되는 IAS 7 현금흐름표(K-IFRS 제1007호)는 두 가지를 바꿉니다. 간접법의 출발점이 당기순이익에서 영업손익(손익계산서 영업 범주 소계)으로 바뀌고, 주된 사업활동이 특정되지 않은 일반 회사는 이자 지급·배당 지급을 재무활동, 이자 수취·배당 수취를 투자활동으로 분류해야 합니다(종전의 정책 선택 폐지). 이 화면은 그 기준으로 영업활동 현금흐름을 직접법과 간접법으로 각각 산출해 같은지 맞춰 보고, 영업활동에 남아 있는 이자·배당 거래를 분류 차이로 가려 내며, 같은 자료로 종전 IAS 7 기준 금액과의 차이(전환 영향)까지 보여 줍니다. 예금 계정 라인은 CDS 로 상대 계정까지 최대 2단계 추적해, 활동 분류의 근거를 전표 라인 단위로 남깁니다. 화면은 분류·집계·대사를 돕는 점검 도구이며 최종 판단은 회사와 감사인이 합니다. 주된 사업이 금융(은행 등)인 회사의 다른 분류는 적용 범위 밖이며 확인 필요입니다.

핵심 포인트 7가지

사례로 보는 효과

같은 기간, 두 가지 원인 — 설비 대금과 이자 지급 — 검증용 샘플에서 회사 1000 · 8월은 간접법 200,400,000원, 직접법 170,400,000원으로 30,000,000원 차이가 났고 원인은 영업활동으로 처리된 설비 대금(활동 혼입)이었습니다. 회사 2000 · 8월은 3,100,000원 차이가 났는데, 이자 지급 1건이 기타 영업 지급으로 남아 있던 IFRS 18 이자·배당 분류 차이(R05)였습니다. 두 회사 6개 기간의 종전 IAS 7 영업CF 합계는 721,300,000원, IFRS 18 영업CF 합계는 735,100,000원으로 전환 영향은 +13,800,000원입니다.

도입하면 달라지는 것

• IFRS 18 기준 현금흐름표를 직접법과 간접법 두 방향에서 맞춰 보고 결산을 닫습니다
• 예금 전표마다 최종 상대 계정과 거래처를 근거로 남깁니다
• 영업활동에 남은 이자 · 배당 거래를 결산 전에 찾아 옮깁니다
• 종전 기준 대비 전환 영향을 비교기간 재작성 자료로 씁니다
• 차이의 원인이 구성 · 원인 단위로 남아 감사 대응 자료가 됩니다

이런 회사에 맞습니다

IFRS 18 도입을 준비하는 상장사 · 해외 모회사 보고 법인의 결산팀, 이자 · 배당을 영업활동으로 분류해 온 회사, 현금흐름표의 활동 분류를 감사 전에 스스로 점검하려는 재무팀에 맞습니다. 주된 사업이 금융인 회사는 적용 범위 밖입니다.

사용 방법

1. 회계연도를 넣습니다(필수). 기간 · 회사 · 활동 구분 · 직접법 구성 · 거래처 · 전기일 · 점검 코드 · 점검 결과는 필요할 때만 고르며, 비워 두면 그 조건은 걸리지 않습니다.
2. 조회 버튼은 조회조건 영역 입력 칸의 맨 오른쪽에 있습니다. 입력 칸에서 Enter 키를 눌러도 조회되며, 처음 열면 한 번 자동으로 조회합니다.
3. 요약에서 점검한 회사·기간 · 간접법과 직접법 영업활동 현금흐름 합계 · 방법 간 차이 절댓값 · 일치하지 않는 회사·기간 · 종전 IAS 7 영업CF 와 전환 영향 · 점검·확인 현금거래 · 정합성 대사 차이를 먼저 봅니다.
4. 탭은 방법 간 대사 → 직접법 구성별 차이 → 간접법 조정표 → 현금거래 명세 → 대사 결과 순서로 넘깁니다.
5. 방법 간 대사에서 행을 누르면 그 회사·기간의 두 방법 금액과 구성별 차이가 상세 창으로 열립니다.
6. CSV 내려받기를 누르면 지금 보는 탭의 조회 결과가 UTF-8 CSV 로 내려옵니다.

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

검증용 샘플 데이터(가상 회사 두 곳, 2026년 7~9월, 회사·기간 6건 · 현금거래 140건)에 대사식과 판정 규칙을 전수로 다시 돌린 결과입니다.

검사 건수 합계 1,623건, 차이 0건입니다. 판정이 일부러 걸리도록 넣은 예외(활동 혼입 1 · 미분류 입금 1 · 구성 이동 1 · 잔여 차이 1 · IFRS 18 이자·배당 분류 차이 1)는 대사 차이와 따로 셉니다.

무엇으로 만들었나

실행 화면

실제로 돌아가는 화면 8종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있습니다. 숫자는 모두 같은 검증용 샘플 데이터에서 나와 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

회계연도 2026 이 기본값이라 열자마자 두 회사의 7~9월 대사 결과가 IFRS 18 기준으로 보입니다.

회사·기간마다 간접법 영업CF · 직접법 영업CF · 방법 간 차이 옆에 종전 IAS 7 영업CF 와 전환 영향이 나란히 있습니다. 요약의 종전 IAS 7 영업CF 721.3 백만원과 IFRS 18 간접법 735.1 백만원의 차이 +13.8 백만원이 이자 지급을 재무로, 이자·배당 수취를 투자로 옮긴 영향입니다. 6개 기간 중 5곳이 정상이 아니며, 2000·8월은 IFRS 18 이자·배당 분류 차이(R05)입니다.

차이를 구성으로 나누기

두 방법이 같은지만 보면 원인을 모릅니다. 직접법 구성마다 손익과 운전자본에서 다시 구한 금액과 견줍니다.

기타 영업 지급에서 −3,100,000원 차이가 나고, 전액이 이자·배당 분류 열(K04)로 들어갑니다. 재무활동으로 분류해야 하는 이자 지급 1건이 영업에 남은 것이라 직접법만 작아지고 영업손익에서 출발한 간접법은 그대로입니다. 직접법 구성은 이제 고객 수취 · 공급자 지급 · 종업원 지급 · 기타 영업 지급 · 법인세 납부 다섯 개입니다.

간접법을 한 줄씩

간접법 조정표는 IFRS 18 공시 초안의 순서 그대로입니다.

영업손익 183,500,000원에서 감가상각비와 무형자산상각비를 더하고, 매출채권 · 재고자산 · 선급비용 증가는 빼고 매입채무 · 미지급급여 증가는 더한 뒤 법인세 납부를 뺍니다. 당기순이익에서 출발할 때 필요하던 이자·법인세 손익 제거 줄이 없어졌습니다. 모두 더하면 간접법 영업활동 현금흐름 200,400,000원입니다.

원인 거래 찾기

차이의 원인은 결국 현금거래 한 건입니다.

이자 지급은 재무, 예금 이자 수취는 투자로 분류되어 있고, 2000·8월 이자 지급 3,100,000원 1건만 활동 구분이 영업, 직접법 구성이 기타 영업 지급으로 남아 있습니다. 점검 코드 T04(IFRS 18 이자·배당 분류 차이)로 표시되며, 이 한 건이 2000·8월의 방법 간 차이 전부입니다.

예금 계정에서 상대 계정까지

예금 계정에 전기된 라인을 CDS 규칙대로 상대 계정까지 따라갑니다.

공급자 세 곳에 한 번에 지급한 268,100,000원은 같은 전표의 매입채무 3라인에 |금액| 비례로 나뉘고(L1), 276,200,000원 입금은 입금 정리계정을 거쳐 2단계(L2)로 추적됩니다. 배분 금액의 합은 언제나 예금 라인 금액과 같고, 반올림 차이가 나면 금액이 가장 큰 라인에 몰아 반올림 조정 열에 남깁니다. 표준 상대계정(GKONT)과 배분 결과 계정이 같은지도 함께 보여 줍니다.

입금 정리계정(10109100)에 들어간 276,200,000원을 반제 전표 1500000001 에서 따라가 고객 두 곳에 165,700,000원과 110,500,000원으로 나눴습니다. 추적한 활동이 전표에 기록된 활동과 다르면 T02 · T04 로 연결되고, 정리 계정이 아직 반제되지 않으면 L8, 반제 전표에도 정리 계정만 있으면 L9 로 남깁니다.

숫자를 스스로 맞춰 본다

대사 결과 탭은 서비스가 계산한 대사식 15종입니다.

영업손익이 매출에서 영업 범주 비용을 뺀 값과 같은지(③), 영업손익에 투자·재무 범주와 법인세를 반영하면 당기순이익이 되는지(④), 종전 IAS 7 영업CF 에 이자·배당 이동분을 반영하면 IFRS 18 영업CF 가 되는지(⑫), 전표별 배분 합계가 예금 라인 금액과 같은지(⑬), 추적 기준 구성이 직접법 구성과 설명분까지 맞는지(⑮)까지 봅니다. 검증용 샘플에서는 모두 차이 0 입니다.

회사·기간 하나를 끝까지

방법 간 대사 행을 누르면 판단 재료가 한 창에 모입니다.

머리에는 직접법 영업활동 현금흐름과 점검 결과, 그 아래에 간접법 금액과 차이, 종전 기준 금액과 전환 영향, 이자 지급 · 이자 수취 · 배당 수취가 붙습니다. 아래 표에서 차이가 난 구성과 원인 문장을 바로 읽을 수 있습니다.

업무 점검 — IFRS 18 기준 현금흐름 분류 점검표

결산 담당자가 IFRS 18 에 따라 개정되는 IAS 7 기준으로 현금흐름표를 닫기 전에 확인할 항목을, 이 화면의 어디서 보는지와 검증용 샘플 결과로 정리했습니다. 주된 사업이 금융인 회사의 분류는 적용 범위 밖이며 확인 필요입니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 대사 · 구성 · 조정표 · 거래 · 대사 결과 다섯 엔티티셋을 각각 조건과 함께 부르고, 요약의 차이 절댓값 · 불일치 회사·기간 수 · 전환 영향은 서비스 함수로 받습니다. 두 방법의 산출과 판정은 서비스 쪽 데이터에 이미 계산되어 있습니다.

1. 간접법 영업CF = 영업손익(영업 범주 소계) + 비현금 항목 ± 운전자본 증감 − 법인세 납부
2. 직접법 영업CF = 영업활동으로 분류된 현금거래를 5개 구성으로 모은 합계 — 이자 지급·배당 지급은 재무, 이자·배당 수취는 투자
3. 구성별 유도액 — 고객 수취 = 매출 − 매출채권 증가, 공급자 지급 = −(매출원가 + 재고자산 증가 − 매입채무 증가), 종업원 지급 = −(급여 − 미지급급여 증가), 기타 영업 지급 = −(판관비 + 선급비용 증가), 법인세 = 납부액
4. Σ 유도액 = 간접법 영업CF (두 방법이 같은 숫자로 만나는 자리)
5. 구성별 차이 = 직접 − 유도 = 미분류 거래 + 활동 혼입 + 구성 이동 + 이자·배당 분류 + 잔여
6. 방법 간 차이 = 직접법 − 간접법 = Σ 구성별 차이 → 판정 R00 ~ R05
7. 전환 영향 = IFRS 18 영업CF − 종전 IAS 7 영업CF = 이자 지급 − 이자 수취 − 배당 수취 (부호 그대로)
8. 기초현금 + 영업(직접) + 투자 + 재무 + 미분류 = 기말현금

방법 간 판정 — 조건과 조치

구성 · 거래 판정 — 조건과 조치

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건은 폭에 맞춰 줄을 바꿔 쌓이고, 조회 버튼은 언제나 입력 칸 묶음의 맨 끝에 붙습니다. 표는 회사 · 기간 두 열을 고정한 채 가로로 넘기며, 상세 창은 휴대폰 폭에서 화면 전체를 씁니다.

파일 구성

앱 폴더/
├─ index.html · manifest.json · Component.js
├─ controller/   BaseController · Main.controller
├─ view/         Main.view.xml · DetailDialog.fragment.xml
├─ model/        formatter · ErrorHandler
├─ css/ · i18n/
├─ odata/        서비스 정의 · 서비스 로직 · 엔티티셋별 데이터
└─ media/        소개 영상

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 표준에서 만든 현금흐름표를 없애지 않고, 같은 원장 데이터로 IFRS 18 기준 두 방법을 다시 구해 맞춰 보고 이자 · 배당 분류를 점검하는 자리를 더합니다.

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

T-code 별 연계 지점

운영으로 옮길 때 기존 현금흐름표 작성 절차를 없앨 필요는 없습니다. 법정 공시와 감사 대응은 표준과 기존 절차에 두고, 이 화면은 결산 마감 전 검증 단계로 씁니다.

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

현금 계정 거래 큐브와 간접법 조정 큐브를 분석 쿼리로 만들어 두면 표준 Fiori 분석 앱과 Analysis for Office 가 같은 숫자를 띄웁니다. 재무제표 표준 보고서 위에 IFRS 18 기준 두 방법의 대사와 이자 · 배당 분류 점검, 전환 영향을 얹는 자리입니다.

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

요구사항 매핑표

CDS 구성

검증 화면은 회사 · 기간 6건을 서비스 데이터로 들고 있지만, 운영에서는 현금 계정 라인과 손익 · 운전자본 집계를 CDS 로 내립니다. 코드는 스케치이며 표준 필드명은 릴리스에 따라 다르므로 주석에 확인할 자리를 적었습니다.

뷰 레이어 구성

① 계정 매핑 테이블

두 방법의 모든 숫자가 이 표에서 갈립니다. 계정마다 현금 계정인지, 상대계정이라면 어느 활동 · 어느 직접법 구성인지, 손익 · 운전자본 계정이라면 간접법의 어느 구분인지를 적습니다. 운영 전환에서 가장 먼저 합의할 항목입니다.

" ────────────────────────────────────────────────────────────────
"  ZCF_ACCTMAP — 계정 → 현금흐름 분류 매핑 (투명 테이블)
"  역할 : 현금 계정 여부 · 활동(OP/INV/FIN) · 직접법 구성 · 간접법 구분
"  나눈 이유 : IFRS 18 손익 범주와 이자·배당 활동 분류를 코드가 아니라 표로 관리한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '현금흐름 계정 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcf_acctmap {
  key mandt     : mandt not null;
  key ktopl     : ktopl not null;
  key saknr     : saknr not null;
  is_cash       : abap.char(1);       " X = 현금및현금성자산 계정
  activity      : abap.char(3);       " OP · INV · FIN (상대계정일 때)
  direct_cat    : abap.char(2);       " 10 수취 · 20 공급자 · 30 종업원 · 40 기타 · 70 법인세 (이자·배당은 투자·재무)
  pl_category   : abap.char(3);       " IFRS 18 손익 범주 OPR 영업 · INV 투자 · FIN 재무 · TAX 법인세
  ind_section   : abap.char(2);       " OP 영업손익 · NC 비현금 · WC 운전자본 · TX 법인세
  wc_sign       : abap.char(1);       " + 부채성(증가 가산) · - 자산성(증가 차감)
}

② 계정 차원 뷰

계정 마스터에 매핑을 붙인 한 행입니다. 거래 큐브와 조정 큐브가 같은 정의를 봅니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfAccount — 계정 차원 (SKA1 + 매핑)
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '현금흐름 — 계정 차원'
@Analytics.dataCategory: #DIMENSION
define view entity ZI_CfAccount
  as select from ska1 as s
    left outer join zcf_acctmap as m on m.ktopl = s.ktopl and m.saknr = s.saknr
{
  key s.ktopl        as ChartOfAccounts,
  key s.saknr        as GLAccount,
      m.is_cash      as IsCash,
      m.activity     as Activity,
      m.direct_cat   as DirectCat,
      m.pl_category  as PlCategory,
      m.ind_section  as IndSection,
      m.wc_sign      as WcSign
}

③ 현금 계정 거래 큐브

현금 계정 라인마다 같은 전표의 상대 라인 계정을 붙여 활동과 직접법 구성을 정합니다. 상대 라인이 여러 개인 전표의 배분 규칙은 운영에서 정해야 합니다(확인 필요).

" ────────────────────────────────────────────────────────────────
"  ZI_CfCashLine — 현금 계정 라인 + 상대계정 분류
"  주의 : 상대 라인이 여럿인 전표의 금액 배분은 확인 필요
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '현금흐름 — 현금 계정 거래'
@Analytics.dataCategory: #CUBE
define view entity ZI_CfCashLine
  as select from acdoca as c
    inner join ZI_CfAccount as ca on ca.GLAccount = c.racct and ca.IsCash = 'X'
    inner join acdoca as o on  o.rldnr  = c.rldnr  and o.rbukrs = c.rbukrs
                           and o.gjahr  = c.gjahr  and o.belnr  = c.belnr
                           and o.docln <> c.docln
    left outer join ZI_CfAccount as oa on oa.GLAccount = o.racct
{
  key c.rbukrs  as CompanyCode,
  key c.gjahr   as FiscalYear,
  key c.belnr   as DocNo,
  key c.docln   as DocLine,
      c.poper   as Period,
      c.budat   as PostDate,
      @Semantics.amount.currencyCode: 'Currency'
      c.hsl     as Amount,
      c.rhcur   as Currency,
      coalesce( oa.Activity, 'UNK' ) as Activity,
      oa.DirectCat                   as DirectCat
}
where c.rldnr = '0L' 

④ 간접법 조정 큐브

IFRS 18 영업 범주 손익 계정만 출발점(영업손익)으로 모으고, 운전자본 계정은 기말 − 기초 증감을 냅니다. 투자 · 재무 범주 손익(이자 · 배당수익, 이자비용)은 간접법에 들어오지 않습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfIndirect — 간접법 조정 항목 (영업손익 · 비현금 · 운전자본)
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '현금흐름 — 간접법 조정'
@Analytics.dataCategory: #CUBE
define view entity ZI_CfIndirect
  as select from acdoca as a
    inner join ZI_CfAccount as m on m.GLAccount = a.racct
{
  key a.rbukrs        as CompanyCode,
  key a.gjahr         as FiscalYear,
  key a.poper         as Period,
  key m.IndSection    as Section,
      // 손익 계정은 기간 금액(부호 반전), 운전자본은 증감 × 부호
      sum( case when m.IndSection = 'WC' and m.WcSign = '-' then - a.hsl
                when m.IndSection = 'WC'                    then   a.hsl
                else - a.hsl end )   as Amount
}
where a.rldnr = '0L'
  and ( m.IndSection <> 'OP' or m.PlCategory = 'OPR' )   // 출발점은 영업 범주만
group by a.rbukrs, a.gjahr, a.poper, m.IndSection

⑤ 분석 쿼리

회사 · 기간별 두 방법을 나란히 두는 쿼리입니다. 직접법은 영업활동 현금거래 합계, 간접법은 조정 큐브 합계입니다.

" ────────────────────────────────────────────────────────────────
"  ZC_CfDualQuery — 두 방법 대사 쿼리
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '영업활동 현금흐름 직접법·간접법 대사'
@Analytics.query: true
define transient view entity ZC_CfDualQuery
  provider contract analytical_query
  as projection on ZI_CfCashLine
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  @AnalyticsDetails.query.axis: #ROWS
  CompanyCode,
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  FiscalYear,
  @AnalyticsDetails.query.axis: #ROWS
  Period,
  @AnalyticsDetails.query.axis: #COLUMNS
  Activity,
  Amount
}

⑥ 권한(DCL)

회사코드 권한을 거래 큐브에 겁니다.

" ────────────────────────────────────────────────────────────────
"  DCL — 회사코드 권한
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '현금흐름 거래 권한'
@MappingRole: true
define role ZI_CFCASHLINE {
  grant select on ZI_CfCashLine
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의

화면이 부르는 엔티티셋을 묶습니다. 운영 전환 시 서비스 바인딩을 게시하고 manifest 의 서비스 주소만 바꿉니다.

" ────────────────────────────────────────────────────────────────
"  ZUI_CFDUAL — Service Definition
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '현금흐름 직접법·간접법 대사 서비스'
define service ZUI_CFDUAL {
  expose ZI_CfCashLine as TxSet;
  expose ZI_CfIndirect as IndirectSet;
}

예금 계정 → 상대 계정 추적 — 데이터 흐름

예금 계정에 전기된 라인을 상대 계정까지 추적하는 뷰 5벌입니다. 종전에 확인 필요로 남겼던 "상대 라인이 여럿인 현금 전표의 배분 규칙" 은 아래 규칙으로 해소했고, 실제 회사 규칙 합의만 확인 필요로 남깁니다.

예금 계정 라인 (ZI_CFD_BankLine: ACDOCA 0L, T012K-HKONT / ZCFD_BANKACCT)
        │  같은 전표 · 부호 반대 · 비예금 라인
        ▼
1단계 상대 라인 (ZI_CFD_OffsetLine ← 분모 ZI_CFD_OffsetSum)
        │  배분 = 예금 HSL × |상대 HSL| ÷ Σ|상대 HSL|   (반올림 차이 → 최대 라인)
        ├── 상대가 은행 중간계정이 아님 ─────────────► L1 확정
        └── 상대가 은행 중간계정(ZCFD_BANKCLR)
                │  AUGBL · AUGDT 로 반제 전표
                ▼
        2단계 (ZI_CFD_ClearingTrace)
                ├── 반제 전표의 비중간계정 라인(D · K · S) ──► L2 확정 (같은 비례 배분)
                ├── 미반제(AUGBL 없음) ───────────────────► L8 미결
                └── 반제 전표에도 중간계정만 ─────────────► L9 추적 중단
        ▼
소비 뷰 (ZC_CFD_BankOffsetTrace) + ZCFD_ACCTMAP → IFRS 18 활동 · 직접법 구성 → 전표 판정(T02 · T04)과 대조

배분 규칙과 단계 코드

1. 분모 = 같은 전표에서 예금 라인과 부호가 반대인 비예금 라인의 |HSL| 합계 (같은 부호 라인 — 매입할인 등 — 은 빠짐)
2. 배분 금액 = 예금 라인 HSL × 상대 라인 |HSL| ÷ 분모, 원 단위 반올림
3. 반올림 차이(예금 라인 − Σ 배분)는 |HSL| 가 가장 큰 라인(같으면 앞 라인)에 더함 — 서비스 또는 AMDP 처리
4. 상대가 은행 중간계정이면 그 라인의 AUGBL · AUGDT 로 반제 전표를 찾아 중간계정이 아닌 라인에 같은 규칙으로 다시 배분(최대 2단계)
5. 표준 상대계정(GKONT · GKOAR)은 참고 열 — 배분 결과 계정과 같은지 플래그만 둠(결정 로직 · FINS_MIG_GKONT 확인 필요)
6. 이 규칙으로 종전 "상대 라인이 여럿인 현금 전표의 배분 규칙(확인 필요)" 을 해소했다 — 실제 회사 규칙 합의는 확인 필요

⑧ ZI_CFD_BankLine — 예금 계정 라인 (기본)

총계정원장 0L 원장에서 예금 계정에 전기된 라인만 고릅니다. 예금 계정 판별은 하우스뱅크 계정(T012K-HKONT)을 우선 쓰고, 그것으로 정할 수 없는 계정은 고객 매핑 테이블(ZCFD_BANKACCT)로 보충합니다. 실제 판별 기준(SKB1 의 은행 계정 표시 사용 여부 포함)은 확인 필요입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CFD_BankLine — 예금 계정 라인
"  원천  : ACDOCA (RLDNR = '0L')
"  판별  : T012K-HKONT(하우스뱅크 계정) 우선, ZCFD_BANKACCT(고객 매핑) 보충
"          SKB1 은행 계정 표시 사용 여부는 확인 필요
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '예금 계정 라인'
@Analytics.dataCategory: #FACT
@VDM.viewType: #BASIC
define view entity ZI_CFD_BankLine
  as select from acdoca as a
    left outer join t012k as h        on  h.bukrs = a.rbukrs
                                      and h.hkont = a.racct
    left outer join zcfd_bankacct as z on  z.bukrs = a.rbukrs
                                      and z.saknr = a.racct
{
  key a.rbukrs   as CompanyCode,
  key a.gjahr    as FiscalYear,
  key a.belnr    as DocNo,
  key a.docln    as DocLine,
      a.racct    as BankAccount,
      a.budat    as PostingDate,
      a.blart    as DocumentType,
      a.poper    as Period,
      @Semantics.amount.currencyCode: 'Currency'
      a.hsl      as Amount,
      a.rhcur    as Currency,
      a.augbl    as ClearingDoc,
      a.augdt    as ClearingDate,
      a.gkont    as GkontStd,      // 표준 상대계정 — 결정 로직 · FINS_MIG_GKONT 확인 필요
      a.gkoar    as GkoarStd,
      case when h.hkont is not null then 'H' else 'Z' end as BankSource   // H 하우스뱅크 · Z 고객 매핑
}
where a.rldnr = '0L'
  and ( h.hkont is not null or z.saknr is not null )

⑨ ZI_CFD_OffsetSum — 같은 전표 반대 부호 비예금 라인 합계 (보조 집계)

배분 분모입니다. 예금 라인과 부호가 반대인 비예금 라인의 |HSL| 를 전표별로 더합니다. 같은 부호 라인(매입할인 등)은 분모에서 빠집니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CFD_OffsetSum — 배분 분모(전표 · 부호별 비예금 라인 |HSL| 합계)
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '상대 라인 합계(배분 분모)'
define view entity ZI_CFD_OffsetSum
  as select from acdoca as o
    left outer join ZI_CFD_BankLine as b on  b.CompanyCode = o.rbukrs
                                         and b.FiscalYear  = o.gjahr
                                         and b.DocNo       = o.belnr
                                         and b.DocLine     = o.docln
{
  key o.rbukrs                                   as CompanyCode,
  key o.gjahr                                    as FiscalYear,
  key o.belnr                                    as DocNo,
  key case when o.hsl < 0 then 'H' else 'S' end  as Side,          // 상대 라인의 차대
      sum( abs( o.hsl ) )                        as OffsetAbsTotal
}
where o.rldnr = '0L'
  and b.DocLine is null                          // 비예금 라인만
group by o.rbukrs, o.gjahr, o.belnr, case when o.hsl < 0 then 'H' else 'S' end

⑩ ZI_CFD_OffsetLine — 같은 전표 1단계 상대 라인

예금 라인마다 같은 전표의 반대 부호 비예금 라인을 붙이고, 배분 금액 = 예금 라인 HSL × 상대 라인 |HSL| ÷ 분모로 구합니다. 표준 상대계정(GKONT · GKOAR)을 참고 열로 두고 배분 결과 계정과 같은지 플래그를 답니다. 표준 GKONT 결정 로직과 마이그레이션 여부(FINS_MIG_GKONT)는 확인 필요입니다. 반올림 차이는 CDS 에서 순위 함수를 쓰기 어려워 소비 뷰 아래 서비스(또는 AMDP)에서 금액이 가장 큰 라인에 몰아 줍니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CFD_OffsetLine — 1단계 상대 라인과 비례 배분
"  배분 : 예금 HSL × |상대 HSL| ÷ ZI_CFD_OffsetSum.OffsetAbsTotal
"  반올림 차이 : 서비스(AMDP 대안)에서 |상대 HSL| 최대 라인에 가산
"  GKONT/GKOAR : 표준 상대계정 — 결정 로직 · FINS_MIG_GKONT 는 확인 필요
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '예금 상대 라인(1단계)'
@Analytics.dataCategory: #FACT
define view entity ZI_CFD_OffsetLine
  as select from ZI_CFD_BankLine as b
    inner join acdoca as o            on  o.rldnr  = '0L'
                                      and o.rbukrs = b.CompanyCode
                                      and o.gjahr  = b.FiscalYear
                                      and o.belnr  = b.DocNo
                                      and o.docln <> b.DocLine
                                      and ( ( b.Amount > 0 and o.hsl < 0 ) or ( b.Amount < 0 and o.hsl > 0 ) )
    left outer join ZI_CFD_BankLine as ob on  ob.CompanyCode = o.rbukrs and ob.FiscalYear = o.gjahr
                                          and ob.DocNo = o.belnr and ob.DocLine = o.docln
    inner join ZI_CFD_OffsetSum as s  on  s.CompanyCode = b.CompanyCode
                                      and s.FiscalYear  = b.FiscalYear
                                      and s.DocNo       = b.DocNo
                                      and s.Side        = case when b.Amount > 0 then 'H' else 'S' end
  association [0..1] to zcfd_bankclr as _Mid on _Mid.saknr = o.racct   // 은행 중간계정 목록
{
  key b.CompanyCode,
  key b.FiscalYear,
  key b.DocNo,
  key b.DocLine,
  key o.docln                         as OffsetLine,
      b.BankAccount,
      b.Amount                        as BankAmount,
      b.Currency,
      o.racct                         as OffsetAccount,
      o.koart                         as OffsetAccountType,       // D 고객 · K 공급업체 · S 총계정 · A 자산
      o.kunnr                         as Customer,
      o.lifnr                         as Supplier,
      o.hsl                           as OffsetAmount,
      o.augbl                         as OffsetClearingDoc,
      o.augdt                         as OffsetClearingDate,
      cast( b.Amount as abap.dec(23,2) )
        * cast( abs( o.hsl ) as abap.dec(23,2) )
        / cast( s.OffsetAbsTotal as abap.dec(23,2) ) as AllocRaw,  // 반올림 전 배분
      b.GkontStd,
      b.GkoarStd,
      case when b.GkontStd = o.racct then 'X' else '' end as GkontMatch,
      case when _Mid.saknr is not null then 'X' else '' end as IsBankClearing,
      _Mid
}
where ob.DocLine is null

⑪ ZI_CFD_ClearingTrace — 반제 2단계 추적

1단계 상대가 은행 중간계정(정리 계정, 미결관리)이면 그 라인의 AUGBL · AUGDT 로 반제 전표를 찾고, 반제 전표 안의 중간계정이 아닌 라인(KOART D · K · S, KUNNR · LIFNR)을 최종 상대로 잡아 같은 방식으로 비례 배분합니다. 미반제는 L8, 반제 전표에도 중간계정만 있으면 L9(추적 중단)입니다. 단계는 최대 2단계입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CFD_ClearingTrace — 은행 중간계정 반제 전표 추적(2단계)
"  L2 반제 전표의 비중간계정 라인으로 확정 · L8 미반제 · L9 반제 후에도 중간계정
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '예금 상대 추적(2단계 · 반제)'
@Analytics.dataCategory: #FACT
define view entity ZI_CFD_ClearingTrace
  as select from ZI_CFD_OffsetLine as l
    left outer join acdoca as c       on  c.rldnr  = '0L'
                                      and c.rbukrs = l.CompanyCode
                                      and c.belnr  = l.OffsetClearingDoc
                                      and c.gjahr  = left( l.OffsetClearingDate, 4 )   // 반제 연도 — 회계연도 변형이 있으면 확인 필요
                                      and c.racct <> l.OffsetAccount
    left outer join zcfd_bankclr as m on  m.saknr = c.racct
{
  key l.CompanyCode,
  key l.FiscalYear,
  key l.DocNo,
  key l.DocLine,
  key l.OffsetLine,
  key coalesce( c.docln, '000000' )   as ClearLine,
      l.BankAmount,
      l.AllocRaw                      as MidAlloc,                 // 1단계에서 중간계정에 배분된 금액
      l.OffsetAccount                 as MidAccount,
      l.OffsetClearingDoc             as ClearingDoc,
      l.OffsetClearingDate            as ClearingDate,
      c.racct                         as FinalAccount,
      c.koart                         as FinalAccountType,
      c.kunnr                         as Customer,
      c.lifnr                         as Supplier,
      c.hsl                           as FinalAmount,
      case when l.OffsetClearingDoc = ''  then 'L8'
           when m.saknr is not null       then 'L9'
           else 'L2' end              as TraceLevel
}
where l.IsBankClearing = 'X' 

⑫ ZC_CFD_BankOffsetTrace — 소비 뷰 — 예금 라인 → 최종 상대

1단계 확정(L1)과 2단계 결과(L2 · L8 · L9)를 합쳐 예금 라인마다 최종 상대 계정 · 계정 유형 · 거래처 · 단계 · 배분 금액을 냅니다. 상대 계정은 매핑 테이블(ZCFD_ACCTMAP)로 IFRS 18 활동과 직접법 구성을 붙이고, 추적 활동이 전표에 기록된 활동과 다르면 현금거래 판정 T02 · T04 와 연결합니다.

" ────────────────────────────────────────────────────────────────
"  ZC_CFD_BankOffsetTrace — 소비 뷰(서비스 정의에서 TraceSet 으로 노출)
"  단계 : L1 1단계 확정 · L2 2단계 확정 · L8 미결 · L9 추적 중단
"  활동 : ZCFD_ACCTMAP — IFRS 18 에 따른 IAS 7 개정 기준(이자 지급 재무 · 이자·배당 수취 투자)
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '예금 → 상대 계정 추적'
@Analytics.dataCategory: #CUBE
@Metadata.allowExtensions: true
@UI.headerInfo: { typeName: '예금 상대 추적', typeNamePlural: '예금 상대 추적' }
define view entity ZC_CFD_BankOffsetTrace
  as select from ZI_CFD_OffsetLine as l
  association [0..1] to zcfd_acctmap as _Map on _Map.saknr = $projection.FinalAccount
{
      @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
      @UI.selectionField: [{ position: 10 }]
  key l.CompanyCode,
      @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key l.FiscalYear,
      @UI.lineItem: [{ position: 10 }]
  key l.DocNo,
  key l.DocLine,
  key l.OffsetLine,
      @UI.lineItem: [{ position: 20 }]
      'L1'                      as TraceLevel,
      l.BankAccount,
      @UI.lineItem: [{ position: 30 }]
      l.BankAmount,
      @UI.lineItem: [{ position: 40 }]
      l.OffsetAccount           as FinalAccount,
      l.OffsetAccountType       as FinalAccountType,
      coalesce( l.Customer, l.Supplier ) as Partner,
      @UI.lineItem: [{ position: 50 }]
      l.AllocRaw                as AllocAmount,     // 반올림 · 최대 라인 가산은 서비스에서
      l.GkontStd,
      l.GkontMatch,
      @UI.lineItem: [{ position: 60 }]
      _Map.activity             as TraceActivity,   // OP · INV · FIN
      _Map.direct_cat           as TraceCat,
      _Map
}
where l.IsBankClearing = ''
// 2단계 결과(L2 · L8 · L9)는 ZI_CFD_ClearingTrace 를 같은 모양으로 projection 해 union all 로 붙인다(구문 길이상 생략, 서비스에서 합침)

" Service Definition 에서 노출
" @EndUserText.label: '현금흐름 직접법·간접법 대사 서비스'
" define service ZUI_CFDUAL {
"   expose ZC_CFD_BankOffsetTrace as TraceSet;
" }

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

운영 데이터로 갈 때

직접법은 현금 계정 라인만 읽고 상대 라인은 같은 전표 안에서 찾으므로 전체 전표를 훑지 않습니다. 간접법은 영업 범주 손익 계정과 운전자본 계정의 기간 합계 · 잔액 증감만 쓰므로 집계 테이블을 읽으면 충분합니다. 회사 · 연도를 필수 조건으로 두고 기간 집계는 DB 에서 하며, 원인 거래만 상세로 내려가도록 나눕니다. 응답 시간 목표는 조회 2초 이내입니다.

자주 묻는 질문

도입 검토에서 나올 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

기준서와 판정

예금 상대 계정 추적

도입과 운영