비화폐성 정부보조금 인식·이연수익 점검 — 무상으로 받은 자산의 인식금액·감가상각·이연수익을 다시 계산해 원장과 맞춰 보는 화면

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

정부나 지자체, 공공기관에서 설비·건물·토지·소프트웨어를 무상으로 넘겨받는 회사의 결산에는 늘 같은 질문이 따라옵니다. 이 자산을 얼마로 인식했나, 같은 금액으로 보조금(이연수익)을 세웠나, 감가상각이 돌 때 수익 인식도 같은 속도로 돌고 있나. 이 세 답은 자산 마스터 · 감가상각 실행 결과 · 전표에 흩어져 있어, 결산 때마다 엑셀에서 다시 모아야 합니다. 이 앱은 세 답을 한 화면에서 다시 계산해 원장과 맞대고, 어긋난 건에만 점검 사유를 붙여 줍니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 6건이 가려낸 격차

기준 연월 202412 의 샘플(가상 자료) 32건을 다시 계산하면 재계산 인식금액 합계는 16,647,005,000원, 자산 장부금액은 14,010,555,625원, 이연수익 잔액은 12,527,111,180원입니다. 원장은 자산 장부금액이 재계산보다 785,727,885원 적고, 이연수익 잔액은 2,172,356,217원 적습니다. 전체 합계만 보면 “원장이 조금 적다”로 끝날 수 있는 숫자인데, 건별로 내리면 6건에서 모두 나온 차이입니다.

다섯 코드의 차이를 더하면 자산 쪽은 785,727,885원, 이연수익 쪽은 2,172,356,217원으로 전체 차이와 1원도 어긋나지 않습니다. 합계가 맞는다는 것은 이 6건 말고는 원장과 재계산이 같다는 뜻이고, 점검 대상이 6건으로 줄어든다는 뜻입니다. 이 숫자는 어디까지나 검증용으로 만든 가상 자료입니다. 실제 환경에서 같은 모습이 나온다면 원인은 평가 자료일 수도, 원장 설정일 수도, 정책 해석일 수도 있으므로 점검 필요로만 읽고 회사와 감사인이 판단합니다.

도입하면 달라지는 것

• 결산 점검 준비 — 인식금액 · 감가상각 · 이연수익 · 원장 대조가 한 화면에서 나오므로 건별 엑셀 취합이 줄어듭니다.
• 점검의 초점 — ‘전부 다시 본다’가 아니라 ‘어긋난 건과 그 이유 코드를 본다’로 바뀝니다.
• 감사 대응 — 연도별 재계산 줄과 대사식이 화면에 있어, 금액이 어떻게 나왔는지 같은 자리에서 보여 줄 수 있습니다.
• 정책 일관성 — 정책(공정가치·명목금액)과 원장 인식 방식이 다른 건이 정책별 집계에서 먼저 보입니다.

이런 회사에 맞습니다

국가·지자체·공공기관으로부터 설비 · 건물 · 토지 · 소프트웨어를 무상으로 이전받아 회계처리하는 제조·연구·공공 서비스 회사, 자산 마스터와 이연수익 계정을 따로 점검하느라 결산 때 시간이 드는 자산회계·재무회계 팀, 그리고 감사인에게 인식 근거를 매번 다시 만들어 설명해야 하는 조직에 맞습니다. 현금으로 받는 보조금(비화폐성이 아닌 보조금)이나 수익 관련 보조금은 이 화면의 범위 밖입니다.

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

점검 도구에서 가장 비싼 질문은 “이 도구가 만든 숫자는 맞나” 입니다. 그래서 화면이 만든 숫자끼리의 산식을 먼저 세워 전수로 돌렸습니다. 아래는 기준 연월 202412 의 결과입니다.

앞의 여섯 식은 화면이 만든 숫자끼리의 검산이라 모두 0건이어야 하고 실제로 0건입니다. 뒤의 세 식은 원장과 맞대는 점검이라 0이 아닌 것이 정상이며, 이 샘플에서는 의도적으로 넣은 예외 여섯 건이 이 세 줄에 나타납니다. 화면 쪽은 이와 별도로 브라우저 자동화로 돌려 확인했습니다 — 조회 → 점검 필요만 보기 → 정책별 · 유형별 탭 → 대사 탭 → 행 상세 순서로 열어 보며 조회 건수(25건 · 15건 · 32건)와 요약 숫자가 서로 맞는지 매번 다시 잽니다.

사용 방법

1. 기준 연월(6자리, 기본 202412)을 확인하고 조회를 누릅니다. 기준 연월 입력칸에서 Enter 를 눌러도 조회됩니다. 필요하면 자산 유형 · 인식 정책 · 수취일 기간 · 점검 코드 · 점검 결과를 골라 범위를 좁힙니다. ‘전체’는 그 조건을 서버로 보내지 않습니다.
2. 위쪽 요약에서 원장−재계산 자산 차이와 이연수익 차이, 점검 필요 건수를 먼저 봅니다.
3. 점검 결과를 점검 필요로 두면 판정에 걸린 건만 남습니다. 건별 점검 코드(A01~A05)와 점검 내용을 읽습니다.
4. 탭을 인식 정책별 집계 → 자산 유형별 집계 → 대사 결과 순서로 넘기며 차이가 어느 단면에 몰려 있는지 봅니다.
5. 궁금한 행을 눌러 상세 팝업에서 회계연도별 감가상각 · 수익 인식 · 이연수익 잔액 줄을 확인합니다.
6. 필요하면 지금 보고 있는 탭을 CSV로 내려받아 점검 의견을 덧붙입니다. 원인 확인은 AS03 · AW01N · AFAB · FAGLL03 같은 표준 거래에서 합니다.

실행 화면

실제로 돌아가는 화면 7종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 가상 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다.

처음 열었을 때

조회조건 한 줄 아래에 요약 숫자가, 그 아래에 탭 네 개가 놓입니다. 탭 머리의 숫자는 건수입니다.

화면이 열리면 한 번 자동으로 조회합니다. 조회조건은 기준 연월(필수)·자산 유형·인식 정책·수취일 기간·점검 코드·점검 결과 여섯 칸이고, 조회 버튼은 맨 오른쪽에 있습니다. 요약에서 먼저 볼 숫자는 두 개입니다 — 원장−재계산 자산 차이(−785,727,885원)와 원장−재계산 이연수익 차이(−2,172,356,217원). 둘 다 0이 아니면 아래 점검 필요 건수가 왜 0이 아닌지 바로 이어서 봅니다.

점검 필요 건만 걸러 보기

결산에서 실제로 시간을 쓰는 곳은 ‘어긋난 건’입니다. 점검 결과 한 칸만 바꾸면 그 건들만 남습니다.

전체 32건 가운데 건별 판정에 걸린 6건만 모은 모습입니다. 한 건에는 가장 먼저 걸린 코드 하나만 붙습니다. 이 화면은 어느 쪽이 옳다고 말하지 않습니다 — 재계산과 원장이 다르다는 사실과, 그 차이가 어느 입력에서 비롯됐을 가능성이 큰지만 적고 최종 판단은 회사와 감사인에게 남깁니다.

집계로 단면을 나눠 보기

건별 목록에서 원인을 찾기 전에, 인식 정책과 자산 유형 두 단면으로 차이가 어디에 몰려 있는지 먼저 봅니다. 집계 합계는 명세 합계와 같아야 합니다.

명목금액 방식은 건당 1,000원으로 인식하므로 금액이 작습니다(샘플 기준 5건 합계 5,000원). 그래도 이 줄이 따로 있어야 하는 이유는, 같은 회사 안에서 정책이 섞여 있을 때 원장이 어느 정책으로 기록됐는지를 정책 단위로 맞춰 볼 수 있기 때문입니다. 공정가치 방식 줄의 이연수익 잔액 차이가 이번 샘플의 점검 필요 6건과 맞물립니다.

감가상각 자산은 보조금 수익 인식 기간과 감가상각 기간이 같아서 수익 인식과 감가상각이 서로 상쇄되고 순손익 효과 누계가 0 입니다. 토지만 감가상각이 없어 누적 수익 인식액이 그대로 양수(1,483,444,445원)로 남습니다. 유형별로 보면 토지·건물·기계장치 줄에 점검 필요가 몰려 있고 설비·장비와 소프트웨어는 원장과 재계산이 같습니다.

대사 — 화면이 만든 숫자와 원장

대사 탭은 아홉 줄입니다. 여섯 줄은 산식 검증, 세 줄은 장부 점검입니다.

대사는 두 갈래입니다. 앞의 여섯 식은 화면이 만든 숫자끼리의 산식 검증(인식금액 = 정책 기준금액, 자산 장부금액 = 인식금액 − 누적 감가상각 등)이라 늘 0이어야 합니다. 뒤의 세 식은 원장과 재계산을 맞대는 장부 점검이라 0이 아닐 수 있고, 0이 아닌 것이 곧 이 화면이 찾아 주는 대상입니다.

건별 상세

합계에서 건으로, 건에서 연도별 줄로 내려갑니다.

숫자가 왜 그렇게 나왔는지는 상세에서 확인합니다. 기말 경과 개월로 회계연도마다 다시 계산한 줄이 나오고, 당기분은 전기말 누계와의 차이입니다. 감사 대응에서 ‘이 금액이 어떻게 나왔느냐’는 질문이 오면 이 팝업을 열어 설명하면 됩니다.

화면이 좁아졌을 때

노트북 반 화면이나 태블릿에서도 같은 조회·같은 숫자입니다. 표는 가로로 넘기면 되고, 요약은 세로로 쌓입니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 자산 마스터 관리, 감가상각 실행, 전표 전기는 모두 표준 거래가 맡고, 이 앱은 그 결과를 다시 계산한 값과 맞대어 보는 읽기 전용 화면입니다.

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 점검 방식을 없애야 하느냐” 는 질문이 꼭 나오는데, 대부분은 없애지 않고 둡니다 — 대사와 감사 대응의 최종 근거는 표준 거래가 맡는 편이 안전합니다.

기준서 요구사항과 화면의 대응

아래는 기준서의 요구사항을 이 화면의 어느 기능이 점검하는지 짝지은 표입니다. 기준서 문단번호는 원문과 대조해 확인한 뒤에만 적을 수 있어 이 글에는 적지 않았습니다 — 문단번호는 원문 확인 필요입니다.

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

S/4HANA 에서는 CDS 뷰로 만든 쿼리를 표준 Fiori 앱이 그대로 띄워 줍니다. 이 앱을 올리기 전에 표준 자산회계 Fiori 앱과 앞으로 겹치는 자리를 먼저 확인하는 편이 좋습니다. 표준 앱은 자산 단위의 조회와 실행이 강하고, 이 앱은 정책 · 보조금 · 원장을 한 줄에서 다시 계산해 맞대는 점검이 강합니다. 겹치는 부분은 표준을 쓰고, 이 앱은 표준에 없는 ‘보조금 이연수익과 자산의 동시 재계산’ 자리에 둡니다. 아래 CDS 구성은 그 자리를 운영 환경으로 옮길 때의 뼈대입니다.

CDS 구성

이 사례의 화면은 서비스가 내려 주는 JSON 을 그대로 받아 보여 줍니다. 데모라서 되는 일이고, 운영 데이터에서는 재계산을 DB 쪽으로 내립니다. 운영으로 올릴 때 가장 먼저 하는 일이 정책 매핑을 정하고 재계산 · 원장 집계 · 판정을 CDS 로 내리는 것입니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스·환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다. 이 화면의 판정 규칙(점검 코드 다섯 가지)은 회사의 정책을 대신 정하지 않으며, 판정 결과도 ‘점검 필요’ · ‘확인 필요’ 로만 내보냅니다.

뷰 레이어 구성

① 정책 · 내용연수 매핑 테이블

점검의 모든 숫자가 이 표에서 갈립니다. 어느 자산 유형이 어느 인식 정책을 쓰고, 수익 인식 기간이 얼마인지를 정하는 자리라 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 정책 선택 자체는 회사와 감사인이 정하며, 이 표는 그 결정을 담는 그릇일 뿐입니다.

" ────────────────────────────────────────────────────────────────
"  zgrant_policy — 자산 유형 → 인식 정책 · 기간 매핑 (투명 테이블)
"  코드에 박지 않는 이유 : 정책이 바뀌었을 때 개발자를 부르지 않고
"  회계팀이 SM30 뷰에서 직접 고칠 수 있어야 한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '비화폐성 보조금 정책 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " SM30 뷰를 함께 만들어 둔다
define table zgrant_policy {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;         " 회사코드
  key asset_type : abap.char(1) not null;  " L 토지 · B 건물 · M 기계장치 · E 설비·장비 · S 소프트웨어
  key valid_from : abap.dats not null;
  valid_to       : abap.dats;
  policy         : abap.char(1);           " F 공정가치 방식 · N 명목금액 방식 (회사가 정한다)
  nominal_amt    : abap.dec(18,0);         " N 방식일 때 명목금액 (샘플은 1,000원)
  oblig_months   : abap.int4;              " 비상각 자산의 수익 인식 기간 — 이행 조건 확인 필요
}

② 자산 기준 뷰

수취일과 내용연수를 읽는 뷰입니다. 수취일을 자산의 자본화일로 볼지, 별도로 관리하는 수취일 필드를 쓸지는 환경마다 다르므로 주석의 확인 필요 자리를 먼저 정합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_GrantAsset — 보조금 대상 자산 기준 (한 자산 한 행)
"  표준 뷰 이름·필드는 릴리스마다 다르다 → View Browser(F2170)로 확인
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label                : '보조금 대상 자산'
define view entity ZI_GrantAsset
  as select from I_FixedAsset as Asset            " 확인 필요: 자산 마스터 표준 CDS 뷰
  association [0..1] to zgrant_policy as _Policy
    on  _Policy.bukrs      = Asset.CompanyCode
    and _Policy.asset_type = $projection.AssetType
{
  key Asset.CompanyCode                 as CompanyCode,
  key Asset.MasterFixedAsset            as MasterFixedAsset,
  key Asset.FixedAsset                  as FixedAsset,

      Asset.AssetClass                  as AssetClass,
      Asset.AssetCapitalizationDate     as GrantDate,        " 확인 필요: 수취일 필드를 따로 쓰는지

      " 자산 클래스 → 유형 코드는 회사 체계에 맞춰 매핑한다(여기서는 자리표시)
      cast( 'M' as abap.char(1) )       as AssetType,

      " 감가상각 조건(내용연수)을 읽어 개월로 환산한다. 토지는 0.   확인 필요: 평가 영역 · 상각 키
      cast( 0 as abap.int4 )            as LifeMonths,

      _Policy.policy                    as Policy,
      _Policy.nominal_amt               as NominalAmt,
      _Policy.oblig_months              as ObligMonths
}

③ 재계산 뷰

화면의 산식이 이 뷰 하나에 있습니다. 경과 개월은 기준 연월과 수취 연월의 정수 월 차이이고, 감가상각과 수익 인식은 정액법 월할입니다. 평가 자료(수취일 공정가치)는 표준 필드에 없는 경우가 많아 FairValue 는 자리표시로 두었습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_GrantRecalc — 정책에 따른 인식금액과 월할 재계산
"  기준 연월은 파라미터로 받는다(p_period = 6자리 연월, 예 202412).
"  경과 개월 = (기준 연 − 수취 연) × 12 + (기준 월 − 수취 월)
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label                : '보조금 재계산'
define view entity ZI_GrantRecalc
  with parameters
    p_period : abap.char(6)
  as select from ZI_GrantAsset as A
{
  key A.CompanyCode,
  key A.MasterFixedAsset,
  key A.FixedAsset,
      A.AssetType,
      A.Policy,

      " 정책 기준금액 : F 방식 = 수취일 공정가치, N 방식 = 명목금액
      case A.Policy
        when 'F' then cast( 0 as abap.dec(18,0) )     " 확인 필요: 수취일 평가 자료와 조인해 채운다
        else          A.NominalAmt
      end                                               as BasisAmt,

      ( cast( left( $parameters.p_period, 4 ) as abap.int4 )
          - cast( left( cast( A.GrantDate as abap.char(8) ), 4 ) as abap.int4 ) ) * 12
      + ( cast( substring( $parameters.p_period, 5, 2 ) as abap.int4 )
          - cast( substring( cast( A.GrantDate as abap.char(8) ), 5, 2 ) as abap.int4 ) )
                                                        as ElapsedMonths,

      A.NominalAmt,
      A.LifeMonths,
      A.ObligMonths
}

④ 원장 집계 뷰

원장 쪽 숫자를 계산 뷰와 같은 키로 맞추는 뷰입니다. 자산 계정과 이연수익 계정의 범위는 회사마다 달라 매핑 테이블로 정하고, 이 스케치에서는 계정 범위를 주석으로만 표시했습니다. 차변은 양수, 대변은 음수로 들어 있는 원장 부호를 그대로 두고 표시용 부호는 위쪽 뷰에서 정합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_GrantLedger — 자산 단위 원장 잔액 (자산 계정 · 이연수익 계정)
"  ACDOCA 의 HSL 은 차변 +, 대변 − 이다. 부호는 여기서 바꾸지 않는다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '보조금 원장 잔액'
define view entity ZI_GrantLedger
  as select from acdoca as L
{
  key L.rbukrs                                      as CompanyCode,
  key L.anln1                                       as MasterFixedAsset,
  key L.anln2                                       as FixedAsset,

      @Semantics.amount.currencyCode : 'Currency'
      sum( case when L.racct between '0000150000' and '0000159999'     " 확인 필요: 자산 계정 범위
                then L.hsl else 0 end )             as LedgerCarry,

      @Semantics.amount.currencyCode : 'Currency'
      sum( case when L.racct between '0000260000' and '0000269999'     " 확인 필요: 이연수익 계정 범위
                then L.hsl else 0 end )             as LedgerDeferRaw,

      L.rhcur                                       as Currency
}
where L.rldnr = '0L'                                " 선도 원장
group by L.rbukrs, L.anln1, L.anln2, L.rhcur

⑤ 판정 뷰

재계산과 원장을 한 줄에서 빼고 점검 코드를 붙입니다. 코드는 가장 먼저 걸린 하나만 적고, 결과 상태는 ‘점검 필요’ · ‘확인 필요’ 로만 내보냅니다. 아래는 토지 상각 계상(A03)과 일시 수익 처리(A02)만 풀어 쓴 스케치이며, 나머지 코드는 원장의 인식 방식 · 기간 · 금액 필드(확인 필요)를 끌어와 같은 방식으로 조건만 바꿔 더합니다. 임계값은 코드에 박지 않고 파라미터나 매핑 테이블로 두는 편이 좋습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_GrantCheck — 재계산 − 원장 차이와 점검 코드
"  판정 순서 : A01 정책 불일치 → A02 일시 수익 → A03 토지 상각
"             → A04 기간 불일치 → A05 금액 불일치 (먼저 걸린 하나만)
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '보조금 점검 판정'
define view entity ZC_GrantCheck
  with parameters p_period : abap.char(6)
  as select from ZI_GrantRecalc( p_period : $parameters.p_period ) as R
  left outer join ZI_GrantLedger as L
    on  L.CompanyCode      = R.CompanyCode
    and L.MasterFixedAsset = R.MasterFixedAsset
    and L.FixedAsset       = R.FixedAsset
{
  key R.CompanyCode,
  key R.MasterFixedAsset,
  key R.FixedAsset,
      R.AssetType,
      R.Policy,
      R.BasisAmt,

      " 재계산 자산 장부금액 = 인식금액 − 누적 감가상각 (정액법 월할, 토지는 상각 없음)
      case
        when R.LifeMonths = 0                    then R.BasisAmt
        when R.ElapsedMonths >= R.LifeMonths     then cast( 0 as abap.dec(18,0) )
        else cast( R.BasisAmt
                   - division( R.BasisAmt * R.ElapsedMonths, R.LifeMonths, 0 )
                   as abap.dec(18,0) )
      end                                        as CarryCalc,

      L.LedgerCarry,
      L.LedgerDeferRaw * -1                      as LedgerDefer,   " 이연수익은 대변(−)이라 부호를 바꿔 읽는다

      case
        when L.LedgerCarry is null               then cast( 'I00' as abap.char(3) )
        " A02 : 수취 시점에 일시 수익으로 처리되어 이연수익 잔액이 0
        when L.LedgerDeferRaw = 0 and R.ElapsedMonths < R.ObligMonths
                                                 then cast( 'A02' as abap.char(3) )
        " A03 : 내용연수가 없는 토지인데 원장 자산 금액이 인식금액과 다름(상각 계상 의심)
        when R.AssetType = 'L' and L.LedgerCarry <> R.BasisAmt
                                                 then cast( 'A03' as abap.char(3) )
        else cast( 'I00' as abap.char(3) )
      end                                        as CheckCode
      " 결과 상태(점검 필요 · 확인 필요) 텍스트는 코드에서 파생하는 별도 뷰에서 붙인다
}

⑥ 정책별 · 유형별 집계 뷰

집계 합계가 명세 합계와 같아야 한다는 조건을 DB 에서도 한 번 더 확인하는 자리입니다. 같은 뷰를 정책 기준과 유형 기준으로 두 번 쓰지 말고, 집계 단위를 group by 한 줄로 바꿔 쓰는 편이 어긋날 여지가 적습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_GrantByPolicy — 인식 정책별 집계 (유형별은 group by 만 바꾼다)
"  집계 합계 = 명세 합계 라는 정합성 대사의 DB 쪽 확인 지점이다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '정책별 집계'
define view entity ZC_GrantByPolicy
  with parameters p_period : abap.char(6)
  as select from ZC_GrantCheck( p_period : $parameters.p_period ) as C
{
  key C.Policy,

      count(*)                                      as Cnt,
      sum( C.BasisAmt )                             as BasisAmt,
      sum( C.LedgerCarry )                          as LedgerCarry,
      sum( case when C.CheckCode <> 'I00' then 1 else 0 end ) as NeedCnt
}
group by C.Policy

⑦ 권한 (DCL)

" ────────────────────────────────────────────────────────────────
"  ZI_GrantCheck — 권한 (DCL)
"  집계 화면에서 권한을 상세에만 걸면, 권한 없는 사람이
"  전사 합계와 자기 몫의 차이를 빼서 남의 사업영역 숫자를 알아낸다.
"  그래서 판정 뷰를 읽는 자리에 건다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '보조금 점검 권한'
@MappingRole       : true
define role ZI_GrantCheck {
  grant select on ZC_GrantCheck
    where ( CompanyCode ) = aspect pfcg_auth ( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ OData 서비스 정의

" ────────────────────────────────────────────────────────────────
"  ZUI_GrantCheck — 서비스 정의 (바인딩은 OData V2 - UI)
"  화면이 부르는 엔티티셋 이름은 여기서 정한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '보조금 점검 서비스'
define service ZUI_GrantCheck {
  expose ZC_GrantCheck    as GrantSet;
  expose ZC_GrantByPolicy as MethodSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 왼쪽은 대부분 코딩이 아니라 합의입니다. 정책과 판단에 관한 항목은 회사와 감사인이 정하며, 이 앱은 정해진 내용을 입력으로 받아 점검할 뿐입니다.

운영 데이터로 갈 때 — 보조금 자산이 수천 건이면

이 사례는 보조금 32건(연도별 줄 190행)입니다. 운영에서는 건수가 늘어도 화면이 한 번에 받는 행 수를 통제하면 됩니다. 명세는 $top 과 $skip 으로 쪼개 받고, 총건수는 $inlinecount=allpages 로 숫자만 함께 받습니다. 집계 탭은 정책 · 유형 단위라 행 수가 몇 줄에 그칩니다.

한 가지 더. 이 화면은 읽기 전용이라 서버에 쓰기를 하지 않습니다. 보조금 건을 고치거나 전표를 다시 전기하는 일은 표준 거래에서 하고, 고친 뒤에는 같은 기준 연월로 다시 조회해 차이가 사라졌는지만 봅니다.

자주 묻는 질문

도입 상담과 데모에서 받는 질문을 네 묶음으로 나눠 적었습니다. 판단이 필요한 대목은 ‘확인 필요’ 로 남기고 결론을 내리지 않았습니다.

숫자와 산식

점검 코드와 판정

데이터와 연계

운영과 도입