SAP ACDOCA 다차원 분석 리포트 — 축을 끌어다 놓아 바꾸고, 셀에서 전표 라인까지 내려간다

손익을 볼 때 질문은 늘 한 번에 끝나지 않습니다. 계정별로 보다가 "이 적자는 어느 사업부에서 나왔나" 싶으면 이익센터를 넣어 보고, 다시 "수출인가 내국인가"로 세그먼트를 끼워 넣습니다. 축을 바꿀 때마다 다른 리포트를 열어야 하면 그 흐름이 끊깁니다. SAP 다차원 리포트(Multi-dimensional Report)가 축을 끌어다 놓게 만든 이유입니다.

ACDOCA 유니버설 저널 위에 큐브를 올리고, 행 축과 열 축을 끌어다 놓아 바꾸며, 셀을 누르면 그 금액을 만든 전표 라인까지 내려가는 화면을 OpenUI5 로 구현했습니다. 축을 바꾸는 동안 서비스는 다시 부르지 않습니다 — 큐브를 한 번 받아 브라우저에서 다시 묶습니다. 실제 구동 화면 8종과 검증 결과를 함께 공개합니다.

실제 화면 10종 둘러보기

사용 방법

1. 회사코드·회계연도·원장·회계기간 범위를 넣고 조회합니다. 회계기간은 시작과 끝을 범위로 받습니다. 입력 필드에서 Enter 키를 눌러도 같은 조회가 실행됩니다.
2. 요약 줄에서 큐브 행 수와 전표 라인 수, 매출·매출원가·매출총이익률·판관비·영업이익률·영업외손익을 먼저 확인합니다.
3. 레이아웃 보드에서 차원을 끌어다 놓아 행 축과 열 축을 바꿉니다. 끌기가 번거로우면 차원을 눌러 다음 칸으로 보낼 수도 있습니다. 같은 칸에서 위아래로 끌면 묶는 순서가 바뀝니다.
4. 행↔열 바꾸기로 두 축을 통째로 교환하고, 초기화로 기본 배치로 돌아옵니다.
5. 측정값을 표시금액 · 원장금액 · 그룹통화 · 수량 중에서 고릅니다. 구성비는 같은 단계 형제 합을 분모로 삼아 다시 계산됩니다.
6. 피벗의 셀을 누르면 그 금액을 만든 전표 라인이 드릴스루 다이얼로그로 열립니다. 행 라벨을 누르면 그 행 전체 기간이 대상입니다.
7. 표 맨 아래 계산항목 세 행에서 매출총이익 · 영업이익 · 법인세비용차감전순이익을 열마다 확인합니다. 산식은 계산항목 탭에서 봅니다.
8. 조회조건·요약·레이아웃 영역은 각각 접을 수 있고, 머리 영역 접기로 세 개를 한꺼번에 접습니다. 표를 넓게 볼 때 씁니다.
9. CSV 내려받기(UTF-8 BOM)로 현재 탭의 결과를 저장합니다. 드릴스루 다이얼로그에서도 내려받을 수 있습니다.

피벗이 만들어지는 여섯 단계

피벗은 여섯 단계로 만들어집니다. 축을 바꾸면 2단계부터 다시 돕니다 — 1단계는 다시 하지 않습니다.

1. 큐브 받기 — CubeSet?$filter=Bukrs eq … and Poper ge … and Poper le …. 조회할 때 한 번만 부릅니다.
2. 행 묶기 — 행 축 차원을 순서대로 적용해 트리를 만듭니다. 1단계 값으로 묶고, 그 안에서 2단계 값으로 다시 묶습니다(최대 3단계).
3. 열 만들기 — 열 축 차원의 값 조합을 뽑아 열을 세웁니다. 2단계면 머리글이 두 줄이 되고 1단계 값이 하위 열을 묶습니다. 마지막에 합계열을 붙입니다.
4. 칸 채우기 — 행 묶음 × 열 조합마다 측정값을 더합니다. 칸 = Σ(그 행 묶음에 속하고 그 열 조합에 해당하는 큐브 행의 측정값)
5. 구성비 — 구성비 = |행 금액| ÷ Σ|같은 단계 형제 행 금액|. 절댓값을 쓰는 이유는 원장금액을 고르면 차변·대변이 섞여 분모가 0 에 가까워질 수 있기 때문입니다.
6. 합계행 — 1단계 형제들의 합입니다. 합계행은 드릴스루 대상이 아닙니다.

차원을 아무리 조합해도 나오지 않는 숫자가 있습니다. 매출총이익이나 영업이익은 어떤 계정에도 전기되지 않고 계정그룹 합계를 더하고 빼야 나오기 때문입니다. 그래서 총계 아래에 계산항목 세 행을 따로 붙였습니다.

식은 화면에 박아 두지 않습니다. 서비스의 CalcSet 카탈로그가 +G1-G2-G3+G4R-G4E 같은 계정그룹 토큰으로 들고 있고, 화면은 그 토큰을 읽어 행을 만듭니다. 항목을 늘리려면 카탈로그에 한 줄을 더하면 되고 화면 코드는 그대로입니다.

계산항목은 열마다 따로 계산합니다. 1월 열의 영업이익은 1월 큐브 행만 모아 식을 적용한 값이고, 합계열은 조회 범위 전체입니다. 그래서 월별 값을 더하면 합계열과 같습니다. 행 축을 무엇으로 바꾸든 조회 범위 전체가 대상이라 값이 변하지 않으며, 금액 측정값에서만 뜻이 있어 수량을 고르면 값을 비웁니다. 드릴스루 대상도 아닙니다 — 전표 한 장에 대응하는 금액이 아니라 여러 계정그룹을 더하고 뺀 결과이기 때문입니다.

표시금액과 원장금액의 관계는 이렇습니다. 큐브는 저장된 표시금액을 더하지 않고 원장금액에서 다시 만듭니다.

축을 바꿀 때와 전표로 내려갈 때

축을 바꾸는 일과 전표로 내려가는 일은 서로 다른 경로를 씁니다.

드릴스루 조건은 and 로만 이어집니다. 셀이 속한 행 경로의 차원값과 열 조합의 차원값을 모두 eq 로 걸고, 기간은 Poper ge·Poper le 범위로 겁니다. 분기·반기 열은 전표에 그 필드가 없으므로 해당 기간 범위로 바꿔 겁니다.

ItemSet?$filter=Bukrs eq '1000' and Gjahr eq '2026' and Rldnr eq '0L'
              and Racct eq '400100' and Poper ge '003' and Poper le '003'
       &$orderby=Poper,Belnr,Docln

조회조건

결과 컬럼

차원 10종과 측정값 4종은 다음과 같습니다.

SAP 표준 기능 매핑

S/4HANA 에서는 CDS 뷰로 만든 분석 쿼리를 Fiori 의 다차원 리포트로 띄우고, Query Browser · View Browser 에서 그 뷰를 찾아 씁니다. 환경별로 제공 범위가 달라 구체적인 앱 ID 는 확인 필요로 남겼습니다.

참고 CDS 뷰

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: 'ACDOCA 손익 다차원 큐브 (스케치)'
@Analytics.dataCategory: #CUBE
define view entity C_PnlMultiDimCube
  as select from I_JournalEntryItem as Jei
  association [0..1] to I_GLAccountInChartOfAccounts as _Acct
    on  _Acct.ChartOfAccounts = Jei.ChartOfAccounts
    and _Acct.GLAccount       = Jei.GLAccount
{
  key Jei.CompanyCode                      as Bukrs,
  key Jei.FiscalYear                       as Gjahr,
  key Jei.Ledger                           as Rldnr,
  key Jei.FiscalPeriod                      as Poper,
  key Jei.GLAccount                        as Racct,
  key Jei.ProfitCenter                     as Prctr,
  key Jei.CostCenter                       as Kostl,
  key Jei.Segment                          as Segment,
  key Jei.FunctionalArea                   as Rfarea,
  key Jei.Plant                            as Werks,
      // 파생 시간 차원 — 전표에는 없다
      concat('Q', cast( division(cast(Jei.FiscalPeriod as abap.int4) + 2, 3, 0)
                        as abap.char(1) ))  as Quarter,
      case when cast(Jei.FiscalPeriod as abap.int4) <= 6 then 'H1' else 'H2' end as Half,
      // 측정값
      @DefaultAggregation: #SUM
      sum( Jei.AmountInCompanyCodeCurrency ) as Hsl,
      @DefaultAggregation: #SUM
      sum( case when _Acct.GLAccountType = 'N'            // 수익 계정은 부호를 뒤집는다
                then Jei.AmountInCompanyCodeCurrency * -1
                else Jei.AmountInCompanyCodeCurrency end ) as Dsl,
      @DefaultAggregation: #SUM
      sum( Jei.AmountInGlobalCurrency )      as Ksl,
      @DefaultAggregation: #SUM
      sum( Jei.Quantity )                    as Msl,
      @DefaultAggregation: #SUM
      count( * )                             as ItemCnt
}
group by Jei.CompanyCode, Jei.FiscalYear, Jei.Ledger, Jei.FiscalPeriod,
         Jei.GLAccount, Jei.ProfitCenter, Jei.CostCenter, Jei.Segment,
         Jei.FunctionalArea, Jei.Plant, _Acct.GLAccountType

원천은 유니버설 저널(ACDOCA)과 계정 마스터(SKA1 · SKAT)입니다. 뷰 이름과 조건은 스케치이며, 계정유형으로 수익을 가르는 방식과 그룹통화 필드는 SAP 환경별로 달라 확인 필요로 남겼습니다. 데이터가 커지면 이 뷰에서 집계 수준을 올리고 화면은 묶기와 표시만 맡는 편이 빠릅니다.

OpenUI5 구성

파일 구성

데이터 파일은 전표 라인 하나뿐입니다. 큐브·기간 요약·차원 카탈로그·측정값·조회 요약은 모두 전표에서 나오는 값이라 각각 파일로 떠 두면 전표가 바뀔 때 다섯 군데가 어긋날 수 있습니다. 그래서 요청 시점에 더해서 만듭니다. 전표 라인 수는 파일 한 개의 업로드 한도(50MB)에 맞춰 최대로 잡아 55,946행입니다.

검증 결과

검증용 샘플 데이터는 전장부품 제조 한 회사를 가정해 2026년 1~9월, 회사코드 1000, 선도원장 0L 기준으로 만들었습니다. 전표 18,649장 · 라인 55,946행이고, 9개월 누계로 매출 108,230,770,000원, 매출총이익률 23.08%, 영업이익률 5.52% 수준입니다.

집계가 맞는지는 같은 계산을 다른 언어로 한 번 더 해서 맞춰 봤습니다. 전표 55,946행을 파이썬으로 따로 더해 자바스크립트 집계 결과와 행 단위로 대조했고, 금액 5종(원장금액·표시금액·그룹통화·수량·건수) 모두 불일치 0건이었습니다. 합계는 원장금액 −4,935,503,000 · 표시금액 211,851,671,000 · 그룹통화 −3,655,928.54 · 수량 752,956 · 건수 55,946 으로 같았고, 큐브 ID 연번과 순서까지 동일했습니다.

화면에서는 셀 금액과 전표 합계가 맞는지 세 경로로 확인했습니다. 제품매출 3월 셀 9,202,220,000 → 전표 473행 합계 같은 금액, 상품매출 전기간 14,028,400,000 → 2,826행, 매출 합계열 108,230,770,000 → 9,660행이 모두 일치했습니다. 축을 바꿔도 전체 합계가 변하지 않는지, 구성비가 0~100% 안에 있고 한 단계 합이 100% 인지, 열 조합·행 단계 상한에서 안내가 뜨는지도 함께 확인했습니다.

계산항목 세 행은 금액과 비율을 파이썬으로 다시 계산해 대조했고 불일치 0건이었습니다. 월별 9개 열의 합이 합계열과 1원도 다르지 않았고, 수량 측정값에서는 값이 비었으며, 계산항목 행을 눌러도 드릴스루가 열리지 않는 것까지 확인했습니다. 덧붙여 세전이익 4,935,503,000원이 손익 전표 원장금액 합계의 부호를 뒤집은 값과 같다는 것도 대사식으로 넣었습니다 — 표시금액으로 쌓아 올린 손익 단계가 원장과 맞물린다는 확인입니다.

응답 시간은 샘플 데이터 기준 조회 후 피벗 렌더 377ms, 축 변경 후 재집계 93ms, 전표 전체 55,946행 적재 3,186ms 였습니다. 집계 자체는 서버에서 540ms, 브라우저에서 57ms 이고 그 뒤로는 캐시에서 꺼냅니다. 7월 영업이익이 적자로 나오는 것은 점검 화면의 동작을 보이기 위해 상여금 전기 월을 1·4·7월로 둔 결과이며 대사 차이와는 무관합니다.

자주 묻는 질문

다차원 리포트에서 큐브는 왜 따로 두나요?

전표 라인을 그대로 묶으면 축을 바꿀 때마다 수만 행을 다시 훑어야 합니다. 같은 계정·이익센터·원가센터·세그먼트·기능영역·플랜트·기간 조합의 전표를 미리 한 행으로 더해 두면, 축을 바꾸는 일은 그 행들을 다시 묶는 일이 됩니다. 이 사례에서는 전표 55,946행이 차원 조합 685행으로 줄었습니다(81.7:1). 실제 SAP 에서는 이 묶기를 CDS 뷰(@Analytics.dataCategory: #CUBE)가 맡습니다.

계산항목은 차원과 무엇이 다릅니까?

차원은 전표에 들어 있는 값이라 그 값으로 묶으면 행이 나옵니다. 계정·이익센터·세그먼트가 그렇습니다. 반면 매출총이익이나 영업이익은 어떤 계정에도 전기되지 않습니다. 매출 계정그룹 합계에서 매출원가 계정그룹 합계를 빼야 나오는 값이라, 차원을 아무리 조합해도 행으로 나오지 않습니다. 그래서 총계 아래에 따로 붙이고 왼쪽 표시줄로 구분했습니다. 식은 서비스의 CalcSet 카탈로그가 들고 있어서, 항목을 늘릴 때 화면 코드를 고치지 않습니다.

영업외손익 행 금액과 계산항목의 영업외 금액이 다릅니다.

표시금액은 수익 계정의 부호를 뒤집어 모두 양수로 만듭니다. 그래서 영업외손익 그룹 행은 이자수익과 이자비용을 둘 다 양수로 더한 값이 됩니다. 반면 계산항목의 +G4R-G4E 는 수익을 더하고 비용을 빼므로 상계한 순액(-1,033,797,000원)이 나옵니다. 손익 단계를 읽을 때는 계산항목 쪽을 보시면 됩니다.

표시금액과 원장금액은 무엇이 다릅니까?

ACDOCA 의 HSL 은 차변이 양수, 대변이 음수입니다. 매출은 대변이라 원장에 음수로 들어 있어 리포트에 그대로 쓰면 매출이 마이너스로 보입니다. 그래서 수익 계정만 부호를 뒤집은 값을 표시금액으로 함께 두었습니다. 원장과 대사할 때는 원장금액을 고르면 저장된 값 그대로 나옵니다. 표시금액은 저장된 값을 더하는 것이 아니라 원장금액과 계정유형에서 다시 계산합니다 — 부호 규칙이 한 곳에만 있어야 어긋날 여지가 없습니다.

행 축을 세 개, 열 축을 두 개로 제한한 이유가 있습니까?

열 축은 조합 수가 곱으로 늘어 머리글이 먼저 무너집니다. 회계기간 9개에 세그먼트 3개를 겹치면 27열이고, 여기에 하나를 더 올리면 100열을 넘깁니다. 그래서 열 축은 2단계, 열 조합은 36개로 막고 넘으면 안내만 띄웁니다. 행 축은 트리로 접히므로 3단계까지 둘 수 있게 했습니다.

분기·반기로도 볼 수 있는데 전표에는 그 필드가 없지 않습니까?

없습니다. 회계기간에서 만들어 큐브에 붙인 파생 차원입니다. 그래서 열 축에는 올릴 수 있지만, 셀에서 전표로 내려갈 때는 전표에 그 필드가 없으므로 회계기간 범위(Poper ge · le)로 바꿔 겁니다.

셀 금액과 전표 합계가 정말 같습니까?

같습니다. 큐브가 전표 라인을 더해 만든 값이기 때문입니다. 제품매출 3월 셀 9,202,220,000원을 누르면 전표 473행이 열리고 그 합계가 같은 금액입니다. 매출 합계열 108,230,770,000원은 전표 9,660행과 맞물립니다. 설명서의 검증 결과에 세 가지 경로를 모두 적어 두었습니다.

전표가 수만 건인데 조회할 때마다 다 받아 오나요?

아닙니다. 전표 라인 전체를 JSON 으로 내리면 48MB 입니다. 조회할 때는 500행만 $top 으로 받고, 전체 건수는 $inlinecount=allpages 로 숫자만 함께 받습니다. 표시 행 수는 500 / 2,000 / 전체 중에서 고를 수 있습니다. 큐브는 685행뿐이라 전체를 받아도 가볍고, 축을 바꿀 때 서비스를 다시 부르지 않습니다.

행이 아주 많아지면 느려지지 않습니까?

느려집니다. 이 화면은 큐브 전체를 브라우저가 들고 묶기 때문에 큐브 행이 수만 건을 넘으면 축을 바꿀 때 눈에 띄게 걸립니다. 그때는 조회 기간을 좁히거나, CDS 뷰에서 미리 집계 수준을 올리거나, 묶기를 서비스 쪽으로 옮겨 $apply=groupby(...) 를 쓰는 OData V4 로 바꾸는 방법이 있습니다.

조회조건에 or 를 쓰지 않은 이유가 있습니까?

OData 구현마다 and 와 or 가 섞인 괄호 조건의 해석이 갈립니다. 범위 비교로 풀 수 있는 조건은 ge · le 로 바꿔 and 만 쓰도록 맞췄습니다. 분기·반기 열의 드릴스루도 그래서 기간 범위로 바뀝니다.

#ACDOCA #다차원 분석 리포트 #Multi-dimensional Report #유니버설 저널 #큐브 #드릴스루 #계산항목 #Drag and Drop #TreeTable #OpenUI5