SAP 충당부채 전입·환입 손익 범주 점검 — IFRS 18 에서 충당부채 손익이 맞는 범주에 놓였는지 관련 활동으로 다시 구해 장부와 견주는 화면

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

결산이 가까워지면 감사인이 묻는 질문이 있습니다. 이 충당부채 전입은 손익계산서 어느 범주에 들어갔나, 나중에 환입한 금액은 처음 전입한 범주로 돌아갔나. IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 손익계산서의 수익과 비용을 영업 · 투자 · 재무 · 법인세 · 중단영업 범주로 나눠 보이게 하는데, 충당부채의 전입과 환입은 그 경계에 자주 걸립니다. 같은 소송충당부채라도 영업활동에서 생긴 것이면 영업범주, 투자자산 처분과 이어진 약정이면 투자범주, 중단영업으로 분류된 사업의 것이면 중단영업 범주가 점검의 기준입니다. 이 글은 그 점검을 건마다 다시 구해 장부와 견주는 OpenUI5 화면을 소개합니다.

지금은 이 답이 계정 한 줄에 들어 있습니다. 전입 비용 계정이 어느 손익 범주로 모이는지는 계정 매핑이 정하고, 그 계정에 쌓인 금액이 실제로 어떤 충당부채의 전입인지, 환입이 어느 전입에서 나왔는지는 원장 조회 화면과 전표 화면을 오가며 엑셀로 맞춥니다. 이 앱은 그 자리를 메웁니다. 전입 · 환입 건마다 관련 활동(영업활동 · 투자자산 처분 관련 · 중단영업 사업)으로 범주를 다시 구해 장부에 놓인 범주와 나란히 보이고, 환입은 최초 전입을 기록한 범주와도 견주며, 어긋난 건에는 점검 코드와 해야 할 일을 문장으로 붙입니다.

범주는 계정만으로 정해지지 않는다

전입 비용 계정 하나가 영업범주로 매핑되어 있으면, 그 계정으로 들어온 금액은 모두 영업범주에 모입니다. 그런데 투자자산 처분 약정에서 난 보증충당부채나 중단영업으로 분류된 사업의 철수충당부채도 같은 계정으로 기표될 수 있습니다. 반대로 영업활동에서 생긴 소송충당부채의 전입이 재무비용 계정으로 기표되는 일도 있습니다. 장부는 계정을 따라가지만 충당부채의 성격은 다른 곳에 있습니다. 이 앱은 계정이 아니라 충당부채 쪽의 사실(관련 활동)에서 범주를 다시 구해 장부와 견줍니다.

환입은 처음 전입한 범주를 따라가야 한다

전입 때 투자범주에 놓았던 충당부채가 환입될 때 영업범주로 기록되면, 한쪽 범주에는 비용만 남고 다른 쪽에는 이익만 남습니다. 그래서 환입 건에는 장부 범주 · 재계산 범주 외에 최초 전입 범주를 함께 보이고, 환입이 최초 전입과 다른 범주에 기록되면 별도 코드(P03)로 잡습니다. 환입 금액은 마이너스로 표시되므로 전입과 환입을 한 표에서 더해도 순 손익이 그대로 나옵니다.

어긋난 건은 코드와 문장으로 말해 주어야 움직인다

숫자만 다르다고 알려 주면 현업은 왜 다른지를 다시 추적해야 합니다. 그래서 어긋난 유형을 점검 코드로 나눴습니다. 영업활동 관련 충당부채가 투자범주에 놓인 건(P01), 재무범주에 놓인 건(P02), 환입이 최초 전입과 다른 범주에 기록된 건(P03), 중단영업 사업 관련인데 중단영업 범주에 놓이지 않은 건(P04), 투자자산 처분 관련 약정인데 투자범주에 놓이지 않은 건(P05)은 점검 필요, 관련 활동이 등록되지 않아 판단 기준이 없는 건(P09)은 확인 필요입니다. 확인 필요 건은 범주를 짐작해 채우지 않고 판정 보류로 따로 모읍니다. 건마다 ‘무엇을 확인하라’ 는 조치 문장이 붙어 있어 담당자가 바로 움직일 수 있습니다.

범주를 옮기면 얼마가 움직이는지가 먼저 궁금하다

범주가 다르다는 사실보다 “옮기면 영업이익이 얼마나 달라지나” 가 보고 라인의 관심사입니다. 요약의 범주 이동 필요 금액은 장부 범주와 재계산 범주가 다른 건의 금액을 모은 값입니다. 검증용 샘플 데이터에서는 30건 가운데 7건이 점검 필요이고 이동 필요 금액은 1,568.0백만 원입니다.

합계가 맞는지는 화면이 매번 말해야 한다

점검 화면의 숫자가 틀리면 점검 자체가 신뢰를 잃습니다. 전입 · 환입 건에서 충당부채로, 충당부채에서 종류로 올라가는 모든 합계에 대사식을 걸어 두었고, 결과는 별도 탭과 요약의 대사 차이 건수로 항상 보입니다.

사용 방법

1. 조회조건을 입력합니다. 회계연도(4자리)만 필수이고 회사 · 충당부채 종류 · 장부 범주 · 기록일 · 충당부채명 · 점검 코드 · 점검 결과는 선택입니다. 화면을 열면 회계연도 기준으로 자동 조회됩니다.
2. 조회 버튼 또는 Enter 키로 조회합니다. 조회 버튼은 조회조건 영역 안 입력칸들의 가장 오른쪽에 있습니다.
3. 요약에서 점검한 건수 · 점검 필요 · 확인 필요 · 이동 필요 금액 · 영업범주 장부 손익 · 대사 차이 건수를 먼저 봅니다.
4. 탭을 충당부채별 범주 판정 → 전입 · 환입 건별 점검 → 종류별 합계 → 대사 결과 순서로 옮겨 가며 봅니다.
5. 건별 점검 탭에서 행을 누르면 상세가 열려 점검 근거와 같은 충당부채의 건별 비교가 나옵니다.
6. CSV 내려받기 버튼으로 지금 보는 탭을 UTF-8 파일로 내려받아 감사 협의 자료에 붙입니다.

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

검증용 샘플 데이터(회사 2곳 · 전입 · 환입 건 30 · 충당부채 13 · 종류 9행)에 대해 대사식을 전수로 돌렸습니다. 정합성 대사 6식과 참고 대사 1식 모두 차이 0입니다.

점검 화면이므로 의도적으로 넣은 예외 건은 대사 차이와 분리해 기록합니다. 점검 필요 7건(P01 2건 · P02 1건 · P03 1건 · P04 1건 · P05 2건)과 확인 필요 1건(P09)이며, 이 건수는 대사 차이 건수 0과 별개입니다. 그 밖에 서비스 계약(조회 · 단건 · 날짜 조건 · 함수 호출)과 샘플 데이터 참조 분리도 확인했고 모두 통과했습니다.

무엇으로 만들었나

앱 정보

실행 화면

처음 열었을 때

화면을 열면 회계연도 2026 기준으로 자동 조회됩니다. 맨 위 요약은 점검한 전입 · 환입 건수 30, 점검 필요 항목 7, 확인 필요 항목 1, 범주 이동 필요 금액 1,568.0백만 원, 영업범주로 놓인 장부 손익 3,048.0백만 원, 정합성 대사 차이 0건 순서입니다. 점검 필요 항목만 서비스의 건수 함수가 세고 나머지는 조회된 건에서 계산합니다. 아래 표는 충당부채 하나가 한 줄이며, 장부 범주 금액과 재계산 범주 금액이 나란히 놓여 어긋난 충당부채가 눈에 띕니다.

건마다 놓인 범주를 비교한다

충당부채 단위로 훑어 본 뒤에는 전입 · 환입 건 단위로 내려갑니다. 건별 점검 탭에서는 같은 충당부채의 전입과 환입이 번호 순서대로 이어집니다.

건별 점검 탭은 전입과 환입을 건 단위로 보여 줍니다. 전입은 플러스, 환입은 마이너스로 표시되고 구분 열의 전입 · 환입으로 구별합니다. 장부 범주 · 최초 전입 범주 · 재계산 범주가 한 줄에 놓여, 예를 들어 영업활동 관련 소송충당부채의 전입이 재무범주에 놓인 건이나 환입이 최초 전입과 다른 범주로 기록된 건이 점검 필요로 표시됩니다. 조회조건의 점검 결과를 점검 필요로 두면 7건만 남습니다.

행을 눌러 근거를 읽고, 종류로 올려 본다

행을 누르면 상세 창이 열립니다. 위쪽에는 충당부채명, 종류, 관련 활동, 구분, 장부 · 최초 전입 · 재계산 범주, 이동 필요 금액과 점검 코드, 점검 내용 문장이 나오고 아래쪽에는 같은 충당부채의 다른 전입 · 환입이 건별로 비교됩니다. 담당자는 이 한 창에서 ‘무엇이 왜 어긋났고 무엇을 확인해야 하는지’ 를 읽습니다.

종류별 합계 탭은 품질보증 · 소송 · 구조조정 · 손실부담계약 · 처분 관련 보증으로 묶어 장부 범주 금액과 재계산 범주 금액을 나란히 보여 줍니다. 종류마다 장부와 재계산이 갈리는 지점이 보이고, 관련 활동이 없는 충당부채의 금액은 판정 보류로 따로 모입니다.

합계가 맞는지 대사 결과로 확인한다

대사 결과 탭은 좌변과 우변, 검사 건수, 차이 건수, 최대 차이를 식마다 적습니다. 정합성 대사 6식은 모두 차이 0이어야 하고, 참고 대사 1식은 점검 필요 건수가 충당부채별 합계와 같은지 확인합니다. 의도적으로 넣은 예외 건은 대사 차이가 아니라 점검 결과로 따로 셉니다.

화면 뒤에서 일어나는 일

화면이 만드는 숫자는 서비스 쪽 한 곳에서 정해집니다. 아래는 판정 규칙, 산출 순서, 조회조건과 결과 컬럼입니다. 화면은 조회조건을 표준 필터 조건으로 보내고 돌아온 행을 표시할 뿐입니다.

범주 판정 규칙 — 판정 조건 → 결과 상태 → 사용자 조치

산출과 대사 순서

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

창이 좁아지면 조회조건이 여러 줄로 접히고 요약 지표는 두 줄로 나뉩니다. 표는 가로로 스크롤되며, 행을 누르면 열리는 상세 창도 화면 폭에 맞춰 줄어듭니다. 휴대폰에서 점검 필요 건만 골라 확인하는 용도로 충분히 쓸 수 있습니다.

파일 구성

앱 폴더
├─ index.html · readme.html · Component.js · manifest.json
├─ view/        Main.view.xml · DetailDialog.fragment.xml
├─ controller/  BaseController.js · Main.controller.js
├─ model/       formatter.js · ErrorHandler.js
├─ css/ · i18n/
├─ odata/       서비스 정의(metadata.xml) · 서비스 로직(service.js) · 샘플 데이터(json)
└─ media/       소개 영상 · 포스터

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 충당부채 전입 · 환입을 전기하는 일, 손익 계정의 금액을 보는 일, 전표 원문을 여는 일은 표준 화면이 그대로 합니다. 이 앱이 더하는 것은 그 결과를 관련 활동 관점으로 다시 모아 장부 범주와 견주는 자리입니다.

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

T-code 별 연계 지점

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

이 앱의 서비스는 원장 전표에서 충당부채 계정의 라인만 골라 건으로 만들고, 그 위에 관련 활동 · 계정 매핑 · 최초 전입 연결을 얹어 재계산 범주를 구하는 구조입니다. S/4HANA 에서는 원장 전표 테이블(ACDOCA)을 읽는 CDS 뷰 위에 같은 구조를 세우고, 화면은 서비스 주소만 바꿔 같은 화면으로 운영 데이터를 봅니다. 뷰 구성은 다음 절에 코드와 함께 공개합니다.

요구사항 매핑표

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

CDS 구성

뷰 레이어 구성

① 충당부채 관련 활동 입력 테이블

비어 있는 충당부채가 있으면 모두 ‘관련 활동 미등록(P09)’ 으로 떨어져 판정이 보류됩니다. 회사가 충당부채 검토 때 이미 정리하는 정보이므로 회계팀이 직접 유지하도록 SM30 뷰를 함께 만드는 것이 보통입니다. 중단영업 분류의 효력 시작일도 여기에 둡니다.

" ───────────────────────────────────────────────────────────────
" ZPRVC_RELACT  충당부채 관련 활동 입력 (회계팀이 SM30 으로 유지)
" 하는 일    : 충당부채마다 관련 활동(영업활동 / 투자자산 처분 관련 / 중단영업 사업)을 등록한다
" 이렇게 나눈 이유 : 관련 활동은 SAP 표준에 없는 사실이라 회사가 입력해야 하고,
"                   판단 근거를 감사인이 거슬러 볼 수 있도록 변경 이력을 남긴다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '충당부채 관련 활동'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zprvc_relact {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;
  key provno   : abap.char(10) not null;  " 충당부채 번호
  provtype     : abap.char(3);            " WTY LIT RST ONR IND
  relact       : abap.char(4);            " OPR INV DISC (빈 값 = 미등록)
  valid_from   : abap.dats;               " 효력 시작일 (중단영업 분류일 등)
  changed_by   : syuname;
  changed_at   : timestamp;
}

② 전입 · 환입 계정 → 장부 범주 매핑 테이블

장부 범주는 계정 매핑의 결과입니다. 이 매핑을 데이터로 꺼내 두면 점검 필요 건이 나왔을 때 ‘충당부채의 관련 활동이 틀렸나, 계정 매핑이 틀렸나’ 를 가릴 수 있습니다.

" ───────────────────────────────────────────────────────────────
" ZPRVC_ACCTMAP  전입·환입 손익 계정 → 장부 범주 매핑
" 하는 일    : 전입·환입을 기표하는 손익 계정이 손익계산서 어느 범주에 모이는지
" 이렇게 나눈 이유 : '장부 범주' 는 계정 매핑의 결과다. 비교의 한쪽을
"                   코드에 박으면 계정 체계가 바뀔 때마다 이송이 필요하다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '충당부채 손익 계정-장부 범주 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zprvc_acctmap {
  key mandt    : mandt not null;
  key ktopl    : ktopl not null;
  key racct    : racct not null;          " 손익 계정
  bookedcat    : abap.char(4) not null;   " OPR INV FIN DISC
}

③ 환입 → 최초 전입 연결 뷰

환입이 처음 전입한 범주로 돌아갔는지를 보려면 환입 전표가 어느 전입 전표를 가리키는지 알아야 합니다. 연결 방식(참조 필드 · 충당부채 번호 · 전표 연결)은 회사마다 달라 확인이 필요한 부분이고, 이 뷰가 그 차이를 흡수합니다.

" ───────────────────────────────────────────────────────────────
" ZI_ProvOrigin  환입 → 최초 전입 연결
" 하는 일    : 환입 라인마다 최초 전입 라인의 장부 범주(OrigCat)를 붙인다
" 이렇게 나눈 이유 : 연결 방식이 회사마다 달라 한 뷰에 가둔다.
"                   연결을 못 찾으면 OrigCat 을 장부 범주 그대로 두어 P03 이 거짓으로 뜨지 않게 한다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '환입의 최초 전입 연결'
define view entity ZI_ProvOrigin
  as select from ZI_ProvEvent as r
    left outer join ZI_ProvEvent as o
      on  o.CompanyCode = r.CompanyCode
      and o.ProvNo      = r.ProvNo
      and o.EvtType     = 'C'
      and o.EvtNo       = r.OrigEvtNo
{
  key r.CompanyCode, key r.FiscalYear, key r.ProvNo, key r.EvtNo,
      coalesce( o.BookedCat, r.BookedCat ) as OrigCat
}

④ 전입 · 환입 건 뷰 — 모든 합계의 최소 단위

원장 전표에서 충당부채 손익 계정의 라인만 골라 건으로 만듭니다. 전입은 양수, 환입은 음수로 두어 전입과 환입을 그냥 더하면 순 손익이 됩니다. 성능 때문에 계정 조건을 뷰에 박아 두는 곳이기도 합니다.

" ───────────────────────────────────────────────────────────────
" ZI_ProvEvent  전입·환입 건 (Basic)
" 하는 일    : 원장 전표의 충당부채 손익 계정 라인을 건 단위로 읽는다
" 이렇게 나눈 이유 : 건 단위가 모든 합계(충당부채·종류)의 최소 단위다.
"                   금액 부호(전입 +, 환입 -)를 여기서 정해 이후 모든 합계가 단순 합이 된다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '충당부채 전입·환입 건'
define view entity ZI_ProvEvent
  as select from acdoca as a
    inner join zprvc_acctmap as m
      on  m.ktopl = a.ktopl
      and m.racct = a.racct
    inner join zprvc_relact as p
      on  p.bukrs  = a.rbukrs
      and p.provno = a.zuonr           " 충당부채 번호 (할당 필드 — 회사별 확인 필요)
{
  key a.rbukrs  as CompanyCode,
  key a.gjahr   as FiscalYear,
  key a.belnr   as DocNo,
  key a.docln   as DocLine,
      p.provno  as ProvNo,
      p.provtype as ProvType,
      p.relact  as RelAct,
      m.bookedcat as BookedCat,
      a.budat   as PostingDate,
      @Semantics.amount.currencyCode : 'Currency'
      a.hsl     as EvtAmt,               " 전입 +, 환입 -
      a.rhcur   as Currency,
      case when a.hsl >= 0 then 'C' else 'R' end as EvtType
}
where a.rldnr = '0L'

⑤ 범주 재계산 큐브 — 판정 규칙이 사는 곳

재계산 범주와 점검 코드를 결정하는 가장 중요한 뷰입니다. 판정 순서(미등록 → 중단영업 → 투자자산 처분 관련 → 영업활동)가 곧 규칙이므로 순서를 바꾸면 결과가 바뀝니다. 이 뷰만 고치면 모든 화면의 숫자가 함께 바뀌므로 변경 이송은 반드시 대사 결과와 함께 검토합니다.

" ───────────────────────────────────────────────────────────────
" ZC_ProvCategory  범주 재계산 큐브 (Cube)
" 하는 일    : 재계산 범주(ExpectCat)와 점검 코드(CheckCode)를 건마다 결정하고 금액을 집계한다
" 이렇게 나눈 이유 : 판정 규칙이 한 곳에 있어야 규칙을 바꿀 때 모든 화면의 숫자가 함께 바뀐다.
"                   판정 순서는 '관련 활동 미등록 → 중단영업 → 투자자산 처분 관련 → 영업활동' 으로 고정한다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '충당부채 범주 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZC_ProvCategory
  as select from ZI_ProvEvent as e
    association [0..1] to ZI_ProvOrigin as _Origin
      on  _Origin.CompanyCode = e.CompanyCode
      and _Origin.ProvNo      = e.ProvNo
{
  key e.CompanyCode, key e.FiscalYear, key e.DocNo, key e.DocLine,
      e.ProvNo, e.ProvType, e.RelAct, e.BookedCat, e.EvtType,
      _Origin.OrigCat,
      case e.RelAct
        when ''     then 'NONE'
        when 'DISC' then 'DISC'
        when 'INV'  then 'INV'
        else             'OPR'
      end as ExpectCat,
      case
        when e.RelAct = ''                                              then 'P09'
        when e.RelAct = 'DISC' and e.BookedCat <> 'DISC'                then 'P04'
        when e.RelAct = 'INV'  and e.BookedCat <> 'INV'                 then 'P05'
        when e.RelAct = 'OPR'  and e.BookedCat = 'INV'                  then 'P01'
        when e.RelAct = 'OPR'  and e.BookedCat = 'FIN'                  then 'P02'
        when e.EvtType = 'R'   and _Origin.OrigCat <> e.BookedCat       then 'P03'
        else 'P00'
      end as CheckCode,
      @Semantics.amount.currencyCode : 'Currency'
      e.EvtAmt,
      e.Currency,
      _Origin
}

⑥ 충당부채 · 종류 집계 뷰

건에서 충당부채로, 충당부채에서 종류로 올라가는 합계입니다. 장부 4범주 금액과 재계산 4범주 금액, 판정 보류 금액을 같은 모양으로 모아 대사식(R04 · R05)이 그대로 성립하게 만듭니다.

" ───────────────────────────────────────────────────────────────
" ZC_ProvSummary  충당부채별 집계 (Cube 위의 집계)
" 하는 일    : 건 → 충당부채 단위 합계. 장부 4범주·재계산 4범주·판정 보류·이동 필요 금액
" 이렇게 나눈 이유 : 같은 합이 건·충당부채·종류 어느 단위에서도 같아야 대사가 성립한다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '충당부채별 범주 판정'
define view entity ZC_ProvSummary
  as select from ZC_ProvCategory
{
  key CompanyCode, key FiscalYear, key ProvNo,
      max( ProvType ) as ProvType,
      sum( EvtAmt )   as NetAmt,
      sum( case when BookedCat = 'OPR' then EvtAmt else 0 end ) as LedgerOpr,
      sum( case when BookedCat = 'INV' then EvtAmt else 0 end ) as LedgerInv,
      sum( case when BookedCat = 'FIN' then EvtAmt else 0 end ) as LedgerFin,
      sum( case when BookedCat = 'DISC' then EvtAmt else 0 end ) as LedgerDisc,
      sum( case when ExpectCat = 'NONE' then EvtAmt else 0 end ) as HoldAmt,
      sum( case when ExpectCat <> 'NONE' and ExpectCat <> BookedCat
                then EvtAmt else 0 end ) as MoveAmt,
      sum( case when CheckCode in ('P01','P02','P03','P04','P05')
                then 1 else 0 end ) as FlagCnt
}
group by CompanyCode, FiscalYear, ProvNo

⑦ 분석 쿼리 — 화면이 부르는 조건과 열

화면이 쓰는 조건과 열을 선언하는 곳입니다. 회계연도를 필수 파라미터로 받아 조건 없는 전체 조회를 막고, 점검 코드와 점검 결과는 화면의 선택 조건으로 열어 둡니다.

" ───────────────────────────────────────────────────────────────
" ZQ_ProvCategory  충당부채 범주 점검 쿼리 (Consumption)
" 하는 일    : 화면의 조회조건과 결과 열을 선언한다
" 이렇게 나눈 이유 : 필수 필터를 쿼리에 박아 두면 회계연도 없는 전체 스캔이 서비스 단계에서 막힌다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '충당부채 범주 점검'
@Analytics.query : true
define view entity ZQ_ProvCategory
  with parameters
    P_FiscalYear : gjahr
  as select from ZC_ProvCategory
{
  key CompanyCode, key FiscalYear, key DocNo, key DocLine,
      @AnalyticsDetails.query.axis : #ROWS
      ProvNo, ProvType, RelAct, BookedCat, OrigCat, ExpectCat, CheckCode,
      @AnalyticsDetails.query.axis : #COLUMNS
      EvtAmt
}
where FiscalYear = $parameters.P_FiscalYear

⑧ 권한 DCL — 집계 단계에 건다

권한을 드릴스루에만 걸면 합계로 다른 회사 숫자가 샙니다. 집계 쿼리 단계에서 회사코드 단위 권한을 걸어, 권한 없는 회사의 건이 합계에 들어오지 않게 합니다.

" ───────────────────────────────────────────────────────────────
" ZC_ProvCategory  DCL — 회사코드 단위 권한
" 하는 일    : 회사코드 권한 객체(F_BKPF_BUK)로 읽을 수 있는 회사의 건만 남긴다
" 이렇게 나눈 이유 : 집계 단계에 걸어야 권한 없는 회사 숫자가 합계로 새지 않는다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '충당부채 범주 큐브 권한'
@MappingRole : true
define role ZC_ProvCategory {
  grant select on ZC_ProvCategory
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑨ 서비스 정의 — 화면이 보는 하나의 창

화면은 서비스 주소만 알면 됩니다. 네 갈래 조회(건 · 충당부채 · 종류 · 대사)를 한 서비스로 노출하고, 점검 필요 건수를 세는 함수는 서비스 구현 쪽에 둡니다.

" ───────────────────────────────────────────────────────────────
" ZUI_PROVCAT  서비스 정의 (OData V2 바인딩으로 게시)
" 하는 일    : 건·충당부채·종류·대사 네 조회를 하나의 서비스로 노출한다
" 이렇게 나눈 이유 : 화면이 보는 단위와 서비스의 조회 단위를 맞추면 같은 조건이 모든 탭에 쓰인다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '충당부채 범주 점검 서비스'
define service ZUI_PROVCAT {
  expose ZQ_ProvCategory as EvtSet;
  expose ZC_ProvSummary  as PrvSet;
  expose ZC_ProvTypeSum  as TypSet;
  expose ZC_ProvRecon    as ReconSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코딩이 아니라 합의입니다.

운영 데이터로 갈 때

전입 · 환입 건은 충당부채 수에 비례해 늘 뿐이어서 전표 수천만 건의 원장이라도 충당부채 손익 계정으로 걸러낸 뒤의 건수는 많지 않습니다. 문제는 걸러내기 전의 스캔입니다. 그래서 (1) 손익 계정으로 먼저 좁히는 조건을 뷰에 박아 두고, (2) 회계연도를 필수 파라미터로 받으며, (3) 원장의 계정 · 전기일 · 회사코드 조합에 맞는 인덱스를 확인합니다. 목표는 조회 한 번이 몇 초 안에 끝나는 것이고, 응답이 느려지면 먼저 쿼리의 필수 필터와 인덱스를 봅니다. 집계는 서비스 쪽에서 하되 건 단위 조회는 페이징으로 나눠 받습니다.

자주 묻는 질문

숫자와 판정

화면과 조작

표준 T-code 와 데이터

도입과 운영