SAP 영업부문 공시 금액 조정표 점검 — 보고부문 합계에서 재무제표 금액까지, 빠진 조정 항목이 없는지 한 화면에서

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

영업부문 공시를 준비하는 회계팀이 해마다 같은 자리에서 막힙니다. 보고부문 금액을 다 더했는데 재무제표 금액과 맞지 않습니다. IFRS 8(K-IFRS 제1108호)은 보고부문 수익 · 손익 · 자산 · 부채의 합계를 기업 금액으로 조정하는 표를 요구하고, 모든 중요한 조정 항목을 별도로 식별하고 설명하도록 합니다. 그런데 부문 금액은 부문 보고 체계에서, 기업 금액은 원장에서, 조정 항목은 공시 초안에서 따로 오기 때문에 세 곳이 어긋난 채로 마감 막바지에야 드러나는 일이 많습니다.

지금은 표준 원장 조회 화면에서 세그먼트별 라인을 내려받고, 엑셀에서 비보고 사업과 부문간 상계를 빼고 미배분을 얹어 조정표를 손으로 맞춥니다. 조정 항목 한 줄이 초안에 옮겨 적히는 사이에 부호가 바뀌거나, 금액이 작아 보여 다른 항목에 합산되는 일을 잡아낼 도구가 따로 없습니다.

이 앱은 그 자리를 메웁니다. 조정표 네 항목을 다시 계산하고, 조정 항목을 원장 집계와 공시 초안 금액으로 맞대어 보고, 금액이 큰데 합산된 항목을 짚어 줍니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 점검 관점을 더해 확장합니다. 회계 처리와 공시의 최종 판단은 회사와 감사인이 하며, 화면은 판단을 돕는 도구입니다.

세 곳의 숫자가 따로 오면 마지막 날에야 어긋남이 보인다

부문 금액 · 원장 금액 · 초안 금액이 서로 다른 시스템과 담당자에게서 오면, 합계가 맞지 않을 때 어느 쪽이 틀렸는지를 가리는 데 시간이 듭니다. 이 앱은 세 곳을 같은 화면에 올리고 보고부문 합계 + 조정 합계 = 조정 후 금액, 조정 후 금액 − 재무제표 금액 = 차이를 항목마다 계산합니다. 차이가 0 이 아니면 R01 이 붙고, 그 위에서 어느 조정 항목이 빠졌거나 부호가 달라졌는지를 조정 항목 명세에서 좁혀 갑니다.

초안에 옮겨 적은 금액은 원장 집계와 따로 놀 수 있다

조정 항목은 원장에서 집계한 금액과 공시 초안에 적힌 금액이 두 개입니다. 초안은 손으로 옮겨 적는 값이라 한 자리 오타나 부호 반전이 생기기 쉽습니다. 항목마다 두 금액의 차이를 계산해 0 이 아니면 R02 로 표시하므로, 초안을 고치기 전에 어느 줄이 원장과 다른지부터 보입니다.

금액이 큰데 다른 항목에 합산돼 있으면 별도 식별 요구를 놓친다

조정 항목이 재무제표 금액의 1% 이상이면 중요 항목으로 보고, 공시 초안에 별도 행으로 식별돼 있지 않고 합산돼 있으면 R03 을 붙입니다. 1% 는 이 화면의 점검용 가정이며 실제 중요성 기준은 회사가 정합니다. 반대로 금액이 작아 합산돼 있어도 점검 대상이 아닌 항목은 정상으로 둡니다.

점검 도구는 점검 필요라고만 말하고 원인을 단정하지 않는다

공시 숫자가 다른 이유는 오타일 수도, 기준 해석일 수도, 원장 반영 시점 차이일 수도 있습니다. 화면이 오류라고 단정하면 담당자가 방어적이 되므로 결과는 점검 필요 · 확인 필요로만 적고, 각 코드 옆에 사용자가 할 조치(원장 집계와 비교 · 별도 행으로 식별할지 검토 등)를 한 줄로 붙였습니다.

사용 방법

1. 조회조건 입력 — 기준 연월(6자리, 필수)을 확인합니다. 조정표 항목 · 조정 유형 · 점검 코드 · 점검 결과는 선택이며 비워 두면 전체입니다.
2. 조회 — 조회조건 줄 맨 오른쪽의 조회 버튼을 누르거나 입력 칸에서 Enter 를 누릅니다. 화면을 처음 열면 기본 기준 연월로 자동 조회됩니다.
3. 요약 확인 — 조정표 항목 수 · 조정 항목 수 · 조정 후 금액이 재무제표 금액과 다른 항목 · 초안 금액이 다른 조정 항목 · 별도 식별 누락 중요 항목 · 점검 필요 항목 · 정합성 대사 차이 건수를 봅니다.
4. 탭 이동 — 조정표 → 조정 항목 명세 → 부문 명세 → 조정 유형별 집계 → 대사 결과 순서로 확인합니다.
5. 행 클릭 상세 — 조정표 탭의 행을 누르면 보고부문 합계에서 재무제표 금액에 이르는 조정 항목이 창으로 열립니다.
6. CSV 내려받기 — 현재 탭의 조회 결과를 CSV(UTF-8)로 내려받아 검토 자료로 씁니다.

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

점검 화면이 틀린 숫자를 보여 주면 점검의 의미가 없으므로, 만든 쪽에서 먼저 대사식을 세워 검증용 샘플 데이터 전수에 돌렸습니다. 두 기준 연월(202412 · 202312)을 합산한 결과입니다.

01~06 정합성 대사와 10 외부수익 대사의 차이는 0건입니다. 07~09 의 차이는 점검 화면의 동작을 확인하려고 202412 에 의도적으로 넣은 예외 3건과 같은 대상입니다 — R01 1건(부채: 조정 후 금액이 재무제표 금액보다 8,650,000,000원 적음) · R02 1건(세전계속사업이익: 본사 공통 관리비 초안 금액이 원장 집계와 180,000,000원 다름) · R03 1건(자산: 이연법인세자산 미배분이 중요 항목인데 초안에 합산). 정합성 대사 차이와 분리해 기록했습니다. 202312 는 예외 없이 모두 정상이고, 금액이 작아 합산돼 있어도 점검 대상이 아닌 항목을 일부러 포함해 중요 항목 기준 판정을 확인합니다.

화면 쪽은 렌더링된 상태에서 요약 숫자 7개가 검증 결과와 같은지(조정표 항목 4 · 조정 항목 19 · 조정 후 금액 ≠ 재무제표 금액 1 · 초안 금액이 다른 조정 항목 1 · 별도 식별 누락 중요 항목 1 · 점검 필요 3 · 정합성 대사 차이 0)를 대조했습니다. 기준 연월을 202312 로 바꾸면 점검 필요가 0 으로 내려가는 것도 확인했습니다.

무엇으로 만들었나

실행 화면

아래 화면은 모두 같은 검증용 샘플 데이터에서 캡처했습니다. 가상 회사 · 가상 사업부문으로 만든 자료이며 실제 고객사의 부문 구분과 금액을 쓰지 않았습니다. 숫자는 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때와 점검 필요만 골라 볼 때

조회조건 줄, 요약 숫자 칸, 탭, 조정표가 한 화면에 세로로 쌓입니다. 점검 결과 조건으로 확인이 필요한 항목만 남길 수 있습니다.

화면을 열면 기본 기준 연월로 자동 조회됩니다. 맨 위 요약 숫자는 점검 필요가 몇 건인지, 정합성 대사 차이가 0인지를 먼저 보여 줍니다. 표 한 줄이 한 항목이며, 보고부문 합계 + 조정 합계 = 조정 후 금액이 재무제표 금액과 같은지가 왼쪽에서 오른쪽으로 읽힙니다. 조회 버튼은 조회조건 줄 맨 오른쪽에 있고 입력 칸에서 Enter 를 눌러도 같은 조회가 됩니다.

점검 필요는 원인을 단정하지 않습니다. 원장 집계와 공시 초안이 다르거나, 금액이 큰데 합산돼 있다는 신호일 뿐이며 어느 쪽이 맞는지는 사람이 원장을 보고 정합니다. 조건을 비워 두면 전체이고, 초기화 버튼은 기본 기준 연월로 되돌립니다.

조정 항목을 하나씩 들여다볼 때

조정표의 숫자가 어디서 왔는지는 조정 항목 명세와 부문 명세, 그리고 유형별 집계에서 확인합니다.

표 오른쪽의 차이 열이 0 이 아닌 줄과 별도 식별 열이 아니오인 줄이 점검 대상입니다. 금액이 재무제표 금액의 1% 이상이면 중요 항목으로 표시하는데, 이 기준은 점검용 가정이며 실제 중요성 기준은 회사가 정합니다. 조정 유형(부문간 거래 상계 · 비보고 사업 · 미배분 · 회계정책 차이)으로 좁혀 볼 수도 있습니다.

부문 총수익은 외부수익에 부문간 수익을 더한 값입니다. 조정표의 보고부문 합계는 여기서 보고부문으로 구분한 사업만 더한 것이고, 비보고 사업은 합계에서 빠져 조정 항목으로 되돌아옵니다. 이 탭은 기준 연월만 조건으로 받습니다.

공시 설명에서 가장 자주 받는 질문이 어떤 성격의 조정이 큰가입니다. 이 탭은 같은 조정 항목 명세를 유형으로 묶었을 뿐이라 합계가 명세와 같아야 하며, 그 일치를 대사 06 이 확인합니다.

한 항목의 조정 과정을 따라갈 때

조정표의 행을 누르면 보고부문 합계에서 재무제표 금액까지의 길이 한 창에 모입니다.

상세 창 맨 위에는 항목의 점검 코드와 한 줄 설명이 있고, 아래 표는 조정 항목을 금액 순서가 아니라 번호 순서로 보여 줍니다. 별도 행으로 식별되지 않은 중요 항목은 여기서 눈에 띄게 표시되므로, 공시 초안을 고칠 때 어느 줄을 따로 적어야 하는지가 바로 보입니다. ESC 로 닫습니다.

숫자가 맞는지 스스로 점검할 때

마지막 탭은 화면이 스스로 하는 검산입니다.

01~06 은 화면이 스스로 계산한 값끼리 맞는지 보는 정합성 대사이고, 07~10 은 재무제표 금액 · 공시 초안과 맞는지 보는 장부 점검 대사입니다. 둘을 분리해 둔 이유는 의도적 점검 사항이 정합성 오류처럼 읽히지 않게 하기 위해서입니다. 이 탭도 기준 연월만 받습니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 조회조건을 필터 객체로 만들어 서비스에 보내고, 서비스가 다섯 가지 조회 단위(조정표 · 조정 항목 · 부문 · 조정 유형별 · 대사)를 돌려줍니다. 점검 코드와 조정 후 금액은 화면이 아니라 서비스에서 계산됩니다. 화면은 받은 값을 표에 바인딩하고, 행을 누르면 같은 서비스의 단건과 조정 항목을 다시 읽어 상세 창을 채웁니다.

점검 코드 판정 규칙

조정표 항목 한 건에는 점검 코드가 하나만 붙습니다. 아래 순서대로 먼저 해당하는 코드를 씁니다. 조정 항목에는 R02 · R03 만 같은 기준으로 붙습니다. 결과는 점검 필요 · 확인 필요로만 표기하고 원인은 단정하지 않습니다.

중요 항목 기준(재무제표 금액의 1%)은 이 화면의 점검용 가정입니다. 실제 중요성 기준은 회사가 정하며 확인 필요입니다.

조정 후 금액 산출과 대사 순서

조회조건

"전체"는 코드값으로 보내지 않고 해당 조건을 필터에서 뺍니다. 부문 명세 · 대사 결과 탭에는 기준 연월만 적용됩니다.

결과 컬럼

좁은 화면에서 달라지는 것

조회조건 칸은 줄바꿈되어 세로로 쌓이고 표는 가로로 스크롤됩니다. 요약 숫자 칸은 두 줄로 접힙니다. 휴대폰에서는 점검 필요만 골라 확인하는 용도가 맞고, 대사 결과와 조정 항목 명세는 넓은 화면에서 보시는 편이 낫습니다.

파일 구성

index.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/        서비스 정의(metadata) · 서비스 로직 · 엔티티셋별 샘플 json
media/        소개 영상 · 포스터

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 아래는 표준으로 이미 되는 일과 이 화면이 이어 붙이는 일을 나눠 적은 것입니다.

표준으로 되는 것과 이 화면이 더하는 것

T-code 별 연계 지점

운영 전환 시 기존 리포트를 없애야 하는가. 없애지 않습니다. 법정 · 감사 대응에 쓰는 표준 리포트와 조정표 양식은 그대로 두고, 이 화면은 마감 전에 두 곳을 맞춰 보는 점검 용도로 함께 씁니다. 공시 숫자를 만드는 일은 이 화면이 하지 않습니다.

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

S/4HANA 에서는 CDS 뷰 위에 분석 쿼리를 올려 Fiori 분석 앱이나 Analysis for Office 로 같은 집계를 열 수 있습니다. 이 앱의 서비스가 하는 일은 그 CDS 집계와 점검 코드 판정입니다. 그래서 운영에서는 아래 CDS 구성처럼 집계를 DB 로 내리고 점검 코드만 쿼리 위에 얹으면, 같은 숫자를 표준 분석 앱에서도 열 수 있습니다. 표준 CDS 뷰 이름은 릴리스마다 다르므로 View Browser(F2170)로 실제 이름을 확인해야 하며, 확인하지 못한 뷰는 확인 필요로 두었습니다.

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

기준서 요구사항 매핑

CDS 구성

이 사례의 화면은 검증용 샘플 데이터를 서비스가 읽어 돌려줍니다. 데모라서 되는 일이고, 운영 데이터에서는 집계를 CDS 로 내리는 것이 첫 작업입니다. 아래는 그때 만드는 객체를 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스와 환경에 따라 다르므로 그대로 붙여 넣기 전에 View Browser(F2170)로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다.

뷰 레이어 구성

① 부문 · 조정 유형 매핑 테이블

조정표의 모든 분류가 이 표에서 갈립니다. 어느 세그먼트가 보고부문이고, 어느 계정이 부문간 상계 · 미배분 · 회계정책 차이인지를 정하는 자리라 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 부문 체계가 바뀌어도 과거 기간의 조정표가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZSEGR_ADJMAP — 세그먼트 · 계정 → 조정 분류 매핑 (투명 테이블)
"  한 행이 "이 계정(또는 세그먼트)은 조정표의 어느 칸인가" 를 말한다.
"  코드에 박지 않는 이유 : 부문 체계와 계정은 해마다 바뀌고,
"  바뀔 때마다 개발자를 부르게 만들면 점검 화면이 금방 낡는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '영업부문 조정 분류 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " 유지보수 뷰를 함께 만들어 둔다
define table zsegr_adjmap {
  key mandt      : mandt not null;
  key ktopl      : ktopl not null;        " 계정과목표
  key saknr      : saknr not null;        " 계정
  key valid_from : abap.dats not null;    " 유효 시작일
  valid_to       : abap.dats;
  measure_id     : abap.char(3);          " REV 수익 · PRF 세전계속사업이익 · AST 자산 · LIA 부채
  adj_type       : abap.char(4);          " ELIM 부문간 상계 · UNRP 비보고 · UNAL 미배분 · POLC 회계정책 차이
  adj_no         : abap.numc(3);          " 조정 항목 번호 — 화면 정렬 순서
  adj_name       : abap.char(40);
  is_segment_acc : abap.char(1);          " X = 보고부문 금액 집계 대상 계정
}

② 조정 항목 차원 뷰

조정표 항목(수익 · 세전계속사업이익 · 자산 · 부채)과 조정 유형의 이름과 정렬 순서가 여기서 결정됩니다. 매핑을 읽는 join 을 이 뷰에 한 번만 두면, 아래 큐브와 쿼리가 같은 분류를 보게 되어 화면 사이에 분류가 어긋날 자리가 없습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_SegAdjDim — 조정 항목 차원
"  계정 한 행에 조정표 항목 · 조정 유형 · 번호가 붙는다.
"  차원 뷰를 따로 두는 이유 : 큐브에서 join 을 한 번만 걸고,
"  값 도움말과 텍스트가 이 뷰 하나를 보게 하기 위해서다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '조정 항목 차원'
@Analytics.dataCategory              : #DIMENSION
@ObjectModel.representativeKey       : 'GLAccount'
define view entity ZI_SegAdjDim
  as select from zsegr_adjmap as Map
{
  key Map.ktopl                                  as ChartOfAccounts,
  key Map.saknr                                  as GLAccount,
  key Map.valid_from                             as ValidFrom,
      Map.valid_to                               as ValidTo,

      @EndUserText.label : '조정표 항목'
      Map.measure_id                             as Measure,

      @EndUserText.label : '조정 유형'
      Map.adj_type                               as AdjType,

      @EndUserText.label : '조정 유형명'
      case Map.adj_type
        when 'ELIM' then cast( '부문간 거래 상계'    as abap.char(30) )
        when 'UNRP' then cast( '비보고 사업'         as abap.char(30) )
        when 'UNAL' then cast( '미배분 항목'         as abap.char(30) )
        when 'POLC' then cast( '회계정책 · 측정 차이' as abap.char(30) )
        else             cast( '미분류'             as abap.char(30) )
      end                                        as AdjTypeName,

      Map.adj_no                                 as AdjNo,
      Map.adj_name                               as AdjName,
      Map.is_segment_acc                         as IsSegmentAccount
}

③ 원장 집계 큐브 — 세그먼트 금액과 조정 항목 금액

화면이 들고 묶던 일을 DB 로 내립니다. 표준 분개 항목 뷰의 세그먼트 · 계정 · 금액을 기간 단위로 집계하고, 매핑을 join 해 보고부문 금액과 조정 항목 원장 집계 금액을 한 뷰에서 만듭니다. 이 큐브의 합계가 조정표의 보고부문 합계와 조정 합계가 되므로, 대사 02 · 03 이 이 뷰를 기준으로 돌아갑니다.

" ────────────────────────────────────────────────────────────────
"  ZI_SegLedgerCube — 세그먼트 · 조정 항목 원장 집계 큐브
"  원천 : 표준 분개 항목 뷰(I_JournalEntryItem — ACDOCA 기반)
"  확인 필요 : 릴리스에 따라 세그먼트 필드(Segment)와 원장 필드(Ledger) 이름이
"             다를 수 있다. View Browser(F2170)로 실제 필드를 확인한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '영업부문 원장 집계 큐브'
@Analytics.dataCategory              : #CUBE
define view entity ZI_SegLedgerCube
  as select from I_JournalEntryItem as Item
  inner join      ZI_SegAdjDim      as Dim
    on  Dim.ChartOfAccounts = Item.ChartOfAccounts
    and Dim.GLAccount       = Item.GLAccount
    and Item.PostingDate   >= Dim.ValidFrom
    and Item.PostingDate   <= Dim.ValidTo
{
  key Item.CompanyCode                                     as CompanyCode,
  key Item.FiscalYear                                      as FiscalYear,
  key Item.FiscalPeriod                                    as FiscalPeriod,
  key Item.Segment                                         as SegId,
  key Dim.Measure                                          as Measure,
  key Dim.AdjType                                          as AdjType,
  key Dim.AdjNo                                            as AdjNo,

      @Semantics.currencyCode : true
      Item.CompanyCodeCurrency                             as Currency,

      @Semantics.amount.currencyCode : 'Currency'
      @Aggregation.default : #SUM
      sum( Item.AmountInCompanyCodeCurrency )              as Amount,

      @Aggregation.default : #SUM
      count( * )                                           as LineCount
}
where Item.Ledger = '0L'                  " 리딩 원장 — 운영 원장 구성에 맞춰 확인
group by Item.CompanyCode, Item.FiscalYear, Item.FiscalPeriod, Item.Segment,
         Dim.Measure, Dim.AdjType, Dim.AdjNo, Item.CompanyCodeCurrency

④ 공시 초안 입력 테이블과 뷰

표준에는 공시 초안이라는 개념이 없어 이 값은 입력으로 받아야 합니다. 초안을 파일로 올릴지, 입력 화면을 둘지, 공시 관리 도구에서 받을지는 회사가 정합니다. 어느 쪽이든 키를 원장 집계 큐브와 같은 모양으로 맞춰 두어야 두 금액이 항목마다 나란히 놓입니다.

" ────────────────────────────────────────────────────────────────
"  ZSEGR_DRAFT — 공시 초안 조정 금액 (입력 테이블)
"  원장 집계 큐브와 같은 키 모양으로 둔다. 키가 어긋나면 초안 금액이
"  원장 집계 옆에 붙지 않고 따로 뜬다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '영업부문 공시 초안 조정 금액'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
define table zsegr_draft {
  key mandt       : mandt not null;
  key bukrs       : bukrs not null;
  key gjahr       : gjahr not null;
  key poper       : poper not null;
  key adj_no      : abap.numc(3) not null;
  waers           : waers;
  @Semantics.amount.currencyCode : 'zsegr_draft.waers'
  draft_amount    : abap.curr(23,2);       " 초안에 적힌 조정 금액
  is_separate     : abap.char(1);          " X = 초안에 별도 행으로 식별됨
}

" ── 위 테이블을 읽는 인터페이스 뷰 ─────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '공시 초안 조정 금액'
define view entity ZI_SegDraft
  as select from zsegr_draft
{
  key bukrs        as CompanyCode,
  key gjahr        as FiscalYear,
  key poper        as FiscalPeriod,
  key adj_no       as AdjNo,
      waers        as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      draft_amount as DraftAmount,
      is_separate  as IsSeparate
}

⑤ 점검 큐브 — 조정 후 금액 · 차이 · 점검 코드

점검 코드의 판정 순서(R01 → R02 → R03 → I00)가 코드로 굳는 자리입니다. 판정을 화면이 아니라 여기서 한 번만 정의하면 화면 · CSV · 분석 앱이 같은 결과를 봅니다. 중요성 기준 1% 는 조건식에 박지 않고 파라미터로 받아 회사 기준으로 바꿀 수 있게 했습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_SegAdjCheck — 조정 항목 단위 점검 (R02 · R03)
"  원장 집계 조정액과 초안 조정액을 항목마다 맞대고,
"  중요 항목(재무제표 금액 대비 비율 이상)이 별도 행인지 본다.
"  결과는 점검 필요 / 정상 두 값만 둔다 — 원인은 단정하지 않는다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '조정 항목 점검'
define view entity ZI_SegAdjCheck
  with parameters
    P_MaterialPct : abap.dec(5,2)         " 중요성 기준(%) — 점검용 가정, 회사가 정한다
  as select from ZI_SegLedgerCube as Led
  left outer join ZI_SegDraft     as Drf
    on  Drf.CompanyCode  = Led.CompanyCode
    and Drf.FiscalYear   = Led.FiscalYear
    and Drf.FiscalPeriod = Led.FiscalPeriod
    and Drf.AdjNo        = Led.AdjNo
{
  key Led.CompanyCode,
  key Led.FiscalYear,
  key Led.FiscalPeriod,
  key Led.Measure,
  key Led.AdjNo,
      Led.AdjType,
      Led.Currency,

      @Semantics.amount.currencyCode : 'Currency'
      Led.Amount                                         as LedgerAmount,
      @Semantics.amount.currencyCode : 'Currency'
      coalesce( Drf.DraftAmount, cast( 0 as abap.curr(23,2) ) ) as DraftAmount,
      @Semantics.amount.currencyCode : 'Currency'
      Led.Amount - coalesce( Drf.DraftAmount, cast( 0 as abap.curr(23,2) ) ) as AmountDiff,

      case when Led.Amount <> coalesce( Drf.DraftAmount, cast( 0 as abap.curr(23,2) ) )
           then cast( 'R02' as abap.char(3) )            " 초안과 원장 집계가 다르다
           when Drf.IsSeparate is initial
                and abs( Led.Amount ) * 100 >= $parameters.P_MaterialPct * Led.StatementAmount
           then cast( 'R03' as abap.char(3) )            " 중요한데 별도 행이 아니다
           else cast( 'I00' as abap.char(3) )
      end                                                as CheckCode
}

⑥ 분석 쿼리 — Consumption

화면의 조회조건과 결과 컬럼이 이 뷰의 선언으로 정해집니다. 필수 조건(기준 연월)과 선택 조건(조정표 항목 · 조정 유형 · 점검 코드 · 점검 결과)을 어노테이션으로 선언해 두면, 표준 Fiori 분석 앱과 Analysis for Office 가 같은 조건 칸으로 이 쿼리를 엽니다.

" ────────────────────────────────────────────────────────────────
"  ZC_SegReconQuery — 조정표 점검 분석 쿼리
"  조회조건 · 기본 컬럼 · 정렬을 선언한다. 화면(OData)과 표준 분석 앱이
"  같은 선언을 읽는다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '영업부문 조정표 점검'
@Analytics.query                  : true
@Metadata.ignorePropagatedAnnotations : true
define view entity ZC_SegReconQuery
  with parameters
    P_MaterialPct : abap.dec(5,2)
  as select from ZI_SegAdjCheck( P_MaterialPct : $parameters.P_MaterialPct )
{
      @AnalyticsDetails.query.axis : #ROWS
      @Consumption.filter          : { selectionType : #SINGLE, mandatory : true }
  key FiscalPeriod,

      @AnalyticsDetails.query.axis : #ROWS
      @Consumption.filter          : { selectionType : #SINGLE, multipleSelections : false }
  key Measure,

      @AnalyticsDetails.query.axis : #ROWS
      @Consumption.filter          : { selectionType : #SINGLE }
  key AdjNo,

      @Consumption.filter          : { selectionType : #SINGLE }
      AdjType,
      @Consumption.filter          : { selectionType : #SINGLE }
      CheckCode,

      @Semantics.amount.currencyCode : 'Currency'
      @AnalyticsDetails.query.axis   : #COLUMNS
      LedgerAmount,
      @Semantics.amount.currencyCode : 'Currency'
      @AnalyticsDetails.query.axis   : #COLUMNS
      DraftAmount,
      @Semantics.amount.currencyCode : 'Currency'
      @AnalyticsDetails.query.axis   : #COLUMNS
      AmountDiff,
      Currency
}

⑦ 권한 (DCL)

집계 화면은 권한이 없어도 합계가 보이는 수가 있습니다. 세그먼트 권한이 없는 사람이 전사 합계는 볼 수 있고 상세만 막히면, 뺄셈으로 다른 부문의 숫자를 알아냅니다. 그래서 권한은 상세가 아니라 집계를 읽는 자리에 걸어야 합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_SegLedgerCube — 접근 제어 (DCL)
"  회사코드와 세그먼트 단위로 건다. 집계를 읽는 큐브에 걸어야
"  합계의 뺄셈으로 다른 부문 숫자가 새지 않는다.
"  확인 필요 : 세그먼트 권한 오브젝트는 회사의 권한 설계에 따른다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '영업부문 원장 집계 큐브 권한'
@MappingRole : true
define role ZI_SEGLEDGERCUBE {
  grant select on ZI_SegLedgerCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
      and ( SegId )       = aspect pfcg_auth( F_FAGL_SEG, FAGL_SEG, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

화면이 부르는 OData 서비스는 이 두 줄로 열립니다. 서비스 정의에 쿼리를 노출하고 OData V2 바인딩으로 게시한 뒤, 화면의 매니페스트에 적은 서비스 주소만 이 게시 주소로 바꾸면 화면 코드는 그대로 씁니다.

" ────────────────────────────────────────────────────────────────
"  Z_SegReconService — 서비스 정의 (OData V2 로 바인딩)
"  운영 전환 시 /IWFND/MAINT_SERVICE 로 활성화하거나 서비스 바인딩을 게시한 뒤,
"  화면의 manifest 데이터 소스 주소를 그 주소로 바꾼다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '영업부문 조정표 점검 서비스'
define service Z_SegReconService {
  expose ZC_SegReconQuery as SegReconQuery;
  expose ZI_SegLedgerCube as LedgerCube;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 코드를 쓰기 전에 합의해야 하는 항목입니다.

운영 데이터로 갈 때

영업부문 공시는 전표 수천만 건에서 세그먼트별로 집계해도 결과는 수백 행입니다. 그래서 집계를 DB 에서 끝내고 화면에는 집계 결과만 올려야 합니다. 기준 연월(회계연도 · 기간)과 회사코드는 파라미터 또는 필수 조건으로 받아 전체 기간 스캔을 막고, 세그먼트 · 계정 · 기간 컬럼에 대한 조회가 인덱스를 타는지 실행 계획으로 확인합니다. 응답 시간 기준은 회사가 정하되, 마감 중 반복 조회를 전제로 몇 초 안을 목표로 두는 편이 낫습니다. 이 화면은 월마감 점검용이라 실시간 합계보다 마감 시점 스냅샷이 더 중요할 수 있어, 필요하면 큐브 결과를 마감 시점에 저장해 두는 방식도 검토합니다.

자주 묻는 질문

도입 상담과 데모에서 나올 만한 질문을 네 묶음으로 나눠 적었습니다.

숫자와 점검 규칙

화면과 조작

표준 T-code 와 운영 연결

권한 · 성능 · 책임