IFRS 18 경영진 정의 성과측정치(MPM) 조정항목 세효과 점검 — 법인세 효과와 비지배지분 효과를 다시 계산해 장부와 맞춰 보는 공시 준비 화면

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

IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 경영진이 외부에 알리는 성과 지표, 곧 경영진 정의 성과측정치(Management-defined Performance Measures, 이하 MPM)를 재무제표 주석에서 설명하도록 요구합니다. 조정 영업이익이나 조정 EBITDA 처럼 회사가 보고서 첫 장에 쓰던 숫자가 이제는 대응하는 재무제표 소계에서 출발하는 조정표로 공시 대상이 됩니다. 조정표의 조정항목마다 법인세 효과와 비지배지분 효과를 따로 밝히는 것이 요구사항의 한 축입니다. 시행은 2027-01-01 이후 개시하는 회계연도부터이며 조기적용이 허용됩니다.

결산을 맡은 팀이 매달 부딪히는 질문은 단순합니다. 조정항목에 붙은 세효과 숫자가 정말 그 항목의 세율로 나온 숫자인가, 비지배지분이 있는 법인의 조정은 지분율을 반영했는가, 두 효과를 합쳐 한 줄로 공시하지는 않았는가. 지금은 표준 화면에서 계정 잔액을 뽑고 엑셀에서 세율을 곱해 보며 답을 찾습니다. 항목이 스무 개만 넘어가도 어느 줄이 어긋났는지 찾는 데 하루가 갑니다.

이 앱은 그 자리를 메웁니다. 조정표의 항목마다 세효과와 비지배지분 효과를 적용 세율과 지분율로 다시 계산해 장부 금액과 나란히 놓고, 차이가 허용 범위를 넘는 줄에는 이유가 붙은 점검 코드를 답니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다.

조정표가 맞는지와 세효과가 맞는지는 서로 다른 질문이다

조정표는 소계 금액에 조정항목의 세전 금액을 더해 MPM 금액을 만듭니다. 이 덧셈이 맞는지는 대사 한 줄로 끝납니다. 그러나 세효과는 다릅니다. 세전 금액에 어떤 세율을 곱했는지, 세무상 인정되지 않는 항목에까지 세효과를 잡지는 않았는지는 항목을 하나씩 열어 봐야 알 수 있습니다. 이 앱은 두 질문을 한 화면의 다른 탭으로 나눠 답합니다. 첫 탭은 조정표의 덧셈을, 둘째 탭은 항목별 재계산을 보여 줍니다.

합쳐서 공시한 두 효과는 나중에 분리하기 어렵다

세효과와 비지배지분 효과를 한 숫자로 합쳐 장부에 두면, 공시 직전에 둘을 가르는 일이 가장 큰 수작업이 됩니다. 이 앱은 항목마다 구분 공시 여부를 컬럼으로 두고, 구분하지 않은 줄은 점검 필요로 올립니다. 결산 중에 발견하면 계정 매핑을 고치면 되지만, 공시 초안이 나온 뒤에 발견하면 주석 전체를 다시 쓰게 됩니다.

세율이 하나가 아닌 항목은 사람이 확인해야 한다

개별 세무조정 근거를 쓴 항목은 법정세율로 다시 계산할 수 없습니다. 이런 항목을 오류로 몰면 현업이 화면을 믿지 않게 됩니다. 그래서 이 앱은 해당 줄을 점검 필요가 아니라 확인 필요로 따로 세우고, 근거 자료를 회사가 확인하도록 안내합니다. 기계가 판정할 수 있는 것과 사람이 판단해야 하는 것을 섞지 않는 것이 이 판정 규칙의 출발점입니다.

사용 방법

1. 조회조건 입력 — 회계연도는 필수(4자리, 예: 2026)입니다. 회사 · 경영진 성과측정치 · 조정 유형 · 공시 기준일 구간 · 조정항목 이름 일부 · 점검 코드 · 점검 결과는 선택이며 “전체”로 두면 그 조건은 조회에 쓰이지 않습니다.
2. 조회 — 조건 칸들의 가장 오른쪽에 있는 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 화면을 처음 열 때는 자동으로 한 번 조회합니다.
3. 요약 지표 확인 — 점검한 조정항목 수, 점검 필요 항목 수, 확인 필요 항목 수, 세효과 차이 합계, 비지배지분 효과 차이 합계, 정합성 대사 차이 건수 여섯 가지를 먼저 봅니다.
4. 탭 이동 — MPM 조정표 → 조정항목별 점검 → 조정 유형별 합계 → 대사 결과 순서로 봅니다. 탭 제목에 현재 조건의 건수가 붙습니다.
5. 행 클릭 상세 — 조정항목별 점검 탭에서 행을 누르면 점검 사유와 재계산 기준, 같은 조정표 항목들의 비교가 팝업으로 열립니다.
6. 내려받기 — 현재 탭의 조회 결과를 CSV(UTF-8)로 저장해 결산 점검표나 감사인 요청 자료에 붙입니다.

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

점검 화면이 틀린 숫자를 보여 주면 점검 자체가 의미를 잃습니다. 그래서 화면에 올리기 전에 대사식을 세워 검증용 샘플 데이터 전수에 돌렸습니다.

이 숫자는 정합성 검사이고, 화면에서 점검 필요로 표시되는 건수와는 다른 이야기입니다. 점검 화면을 보여 주려고 일부러 어긋나게 만든 항목이 샘플에 들어 있습니다.

정합성 차이 0건과 점검 필요 8건은 서로 다른 층의 숫자입니다. 앞은 “화면이 계산을 제대로 했다”이고, 뒤는 “화면이 계산한 결과 장부가 의심스러운 줄이 이만큼 있다”입니다.

무엇으로 만들었나

앱 정보

실행 화면

실제 화면 5종입니다. 순서는 사용 순서를 따랐습니다. 처음 연 화면에서 시작해 항목별 점검, 상세 팝업, 유형별 합계, 대사 결과로 이어집니다. 화면 속 금액은 검증용 샘플 데이터이며 실제 회사의 숫자가 아닙니다.

처음 열었을 때 — 조정표와 요약 지표

화면을 열면 2026 회계연도로 자동 조회됩니다. 맨 위 조회조건, 그 아래 요약 지표 여섯 칸, 아래에 탭 네 개가 놓입니다.

첫 탭은 MPM 별 조정표입니다. 한 줄이 ‘조정 영업이익’ 같은 성과측정치 하나이고, 대응하는 IFRS 소계 금액에 조정 세전 합계를 더한 값이 MPM 금액입니다. 세효과와 비지배지분 효과는 장부 금액과 재계산 금액이 나란히 있습니다. 맨 오른쪽 대사 차이가 0 이 아니면 조정표 덧셈 자체가 어긋난 것이므로 가장 먼저 봅니다. 요약 지표의 점검 필요 항목 수는 별도 함수 호출로 센 값입니다. 기본값은 회계연도 2026, 나머지 조건은 전체입니다.

항목 하나하나를 다시 계산한다 — 조정항목별 점검

이 앱의 중심 탭입니다. 조정항목 한 줄마다 세전 금액, 적용 세율, 세효과 장부 · 재계산 · 차이, 비지배 지분율, 비지배지분 효과 장부 · 재계산 · 차이, 구분 공시 여부, 점검 결과가 나옵니다.

차이 컬럼이 1,000원을 넘는 줄은 점검 코드와 함께 색이 붙습니다. 코드 A01 은 세효과, A02 는 비지배지분 효과, A03 은 구분 공시, A04 는 세무상 불인정 항목에 세효과가 잡힌 경우입니다. 개별 근거 항목은 A09 확인 필요로 따로 표시됩니다. 숫자를 읽을 때는 재계산 열이 ‘세전 × 세율’ 이라는 단순 방식이라는 점을 기억해야 하며, 두 열이 다르다는 것은 틀렸다는 뜻이 아니라 사유를 확인하라는 뜻입니다.

한 줄을 열어 이유를 본다 — 조정항목 상세

표의 행을 누르면 팝업이 열려 점검 사유 문장, 재계산에 쓴 세율과 지분율, 같은 MPM 조정표에 속한 다른 항목들과의 비교를 보여 줍니다. 한 항목만 이상한지 같은 조정표의 항목이 모두 비슷하게 어긋나는지를 여기서 구분합니다. 모두 비슷하게 어긋나면 개별 항목이 아니라 세율 설정이 원인일 가능성이 큽니다. 팝업은 닫기 버튼, 바깥 클릭, ESC 로 닫습니다.

유형으로 묶어 본다 — 조정 유형별 합계

조정 유형은 구조조정 비용, 손상차손, 소송 충당금, 감가상각비 · 상각비, 외화환산손익, 공정가치 평가손익, 주식보상비용, 처분손익 여덟 가지입니다. 한 유형에서 점검 필요가 몰려 있으면 그 유형의 세율 설정이나 불인정 처리 기준을 먼저 의심합니다. 합계는 항목별 점검 탭의 합과 같아야 하며, 이 일치는 대사 R03 으로 검사합니다.

마지막으로 대사를 확인한다

R01 ~ R03 은 정합성 대사로 차이가 0 이어야 하는 검사이고, R04 ~ R06 은 점검 대상 건수를 보여 주는 참고 대사입니다. 둘을 섞으면 ‘차이가 있다’는 말이 계산 오류인지 점검 대상인지 구분되지 않기 때문에 일부러 분리했습니다. 정합성 대사에서 차이가 나오면 판정 결과를 믿기 전에 데이터 연결부터 확인합니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 입력된 조건을 필터로 바꿔 서비스에 보냅니다. 서비스는 네 가지 데이터 묶음을 각각 조건에 맞게 돌려주고, 조정항목 탭에서는 정렬과 스크롤에 따라 필요한 만큼만 다시 받아 옵니다. 점검 필요 항목 수는 서비스가 제공하는 함수를 한 번 호출해 가져옵니다. 화면은 받은 값을 보여 주기만 하고 판정을 다시 하지 않으므로, 같은 서비스에 붙는 다른 화면이나 배치도 같은 판정 결과를 얻습니다.

점검 판정 규칙 — 조건에서 사용자 조치까지

판정 순서는 A09 → A04 → A01 → A02 → A03 입니다. 앞 조건에 걸리면 뒤 조건은 보지 않습니다. 허용 범위 1,000원은 반올림 차이를 넘기려는 값이며 회사 기준으로 바꿀 수 있습니다.

산출 · 대사 순서

1. MPM 금액 = 대응 IFRS 소계 금액 + Σ 조정항목 세전 금액 (대사 R01, 차이 0)
2. 세효과 재계산 = 세전 금액 × 적용 세율 (세무상 인정 항목만, 불인정이면 0)
3. 비지배지분 효과 재계산 = (세전 금액 − 세효과 재계산) × 비지배 지분율
4. 지배기업 귀속 순영향 = 세전 − 세효과 장부 − 비지배지분 효과 장부 (대사 R02, 차이 0)
5. 조정 유형별 세전 합계 = 조정항목별 세전 합계 (대사 R03, 차이 0)
6. 참고 대사 R04 ~ R06 — 세효과 차이 건수 · 비지배지분 효과 차이 건수 · 구분 공시 건수. 점검 대상 건수이며 정합성 차이와 분리합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

창 폭이 줄어들면 조회조건 칸이 한 줄에 하나씩 쌓이고, 요약 지표는 두 칸씩 두 줄로 내려옵니다. 표는 앞 두 열을 고정한 채 가로로 밀어 볼 수 있으므로 열을 숨기지 않습니다. 기능은 줄어들지 않고 배치만 달라집니다. 휴대폰에서는 결산 회의 자리에서 한 줄을 열어 사유를 확인하는 정도의 용도로 쓰는 것을 권합니다.

파일 구성

앱 폴더
├─ 시작 파일 · 설명서 · 구성 파일(Component · manifest)
├─ controller/   화면 제어 (공통 제어 + 메인 제어)
├─ view/         메인 화면 + 조정항목 상세 팝업
├─ model/        표시 형식 · 오류 처리
├─ css/ · i18n/  스타일 · 화면 문구
├─ odata/        서비스 구현 · 데이터 묶음
└─ media/        소개 영상 · 대표 이미지

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 점검 관점을 더해 확장합니다. 이 절은 어디까지가 표준이고 어디서부터가 이 앱인지, 두 화면의 숫자를 어디서 맞춰 보는지를 정리합니다.

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

T-code 별 연계 지점

오가는 방법은 두 갈래입니다. 이 앱에서 시작할 때는 점검 필요 줄의 계정을 확인한 뒤 위 T-code 에서 원천을 열고, 표준 화면에서 시작할 때는 이상한 계정을 찾은 뒤 이 앱의 조정항목별 점검 탭에서 그 계정이 속한 항목의 세효과 재계산을 봅니다. 법정 보고와 감사 대응에 쓰는 원장 조회는 표준 화면에 그대로 남겨 둡니다. 따라서 운영 전환 때 기존 리포트를 없앨 필요는 없습니다.

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

표준 CDS 분석 쿼리와 Fiori 분석 앱은 계정 잔액과 손익을 다차원으로 보는 데 강합니다. 이 앱은 그 위에서 조정항목이라는 공시 단위로 다시 묶고, 항목마다 재계산을 붙이는 쪽을 맡습니다. 표준 분석 앱에서 숫자의 흐름을 보고, 이 앱에서 공시 조정표의 줄 단위 타당성을 점검하는 식으로 나눠 쓰는 것이 자연스럽습니다. Analysis for Office 로 이 앱이 쓰는 서비스를 읽어 엑셀 양식에 채우는 방식도 가능하지만, 이 문서에서는 다루지 않습니다.

요구사항 매핑표

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

CDS 구성 — 코드와 운영 작업

아래 코드는 이 화면이 쓰는 데이터를 S/4HANA 의 ACDOCA 위에 CDS 로 올릴 때의 스케치입니다. 객체 이름은 기능을 뜻하는 영문으로 지었습니다. 표준 CDS 뷰 이름은 확인한 것만 쓰고, 확인하지 못한 자리는 원천 테이블 기준으로 썼습니다. 실제 시스템의 릴리스에 맞춘 검증은 구현 단계에서 거쳐야 합니다.

뷰 레이어 구성

① 매핑 테이블 — 계정과 조정항목을 잇는 기준

이 앱의 모든 숫자는 어느 계정이 어느 조정항목에 속하는지에서 출발합니다. 코드가 아니라 테이블에 두어야 회계팀이 직접 관리할 수 있고, 계정이 새로 생겨도 개발 없이 반영됩니다. 매핑이 빠진 계정은 조정항목에 들어가지 않으므로 합계가 어긋나는 것으로 곧바로 드러납니다.

" ───────────────────────────────────────────────────────────────
" ZMPM_ADJMAP · MPM 조정항목 계정 매핑
" 역할 : 원장 계정을 조정항목 · 조정 유형 · 성과측정치에 연결한다.
" 이렇게 나눈 이유 : 매핑은 회사 정책이라 코드에 넣지 않고 회계팀이 관리한다.
" ───────────────────────────────────────────────────────────────
@EndUserText.label : 'MPM 조정항목 계정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zmpm_adjmap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key mpm_code   : abap.char(3) not null;   " 성과측정치 코드
  key adj_no     : abap.numc(2) not null;   " 조정항목 번호
  racct          : racct;                   " 조정 대상 계정
  adj_type       : abap.char(4);            " 조정 유형 (RSTR · IMPR · DISP …)
  sign_rule      : abap.char(1);            " 부호 규칙
  deduct_flag    : abap.char(1);            " 세무상 인정 여부 (Y/N)
  tax_basis      : abap.char(4);            " STAT 법정 / IND 개별 근거
  sep_flag       : abap.char(1);            " 구분 공시 여부 (Y/N)
}

② 설정 테이블과 차원 뷰 — 세율과 지분율

세율과 지분율은 연도마다 바뀌는 값이고 관리하는 부서도 다릅니다. 매핑과 섞어 두면 세무팀이 세율을 고치려고 회계팀의 매핑 테이블을 열게 됩니다. 그래서 둘을 나눴습니다. 차원 뷰는 이 설정을 회사 · 연도 단위로 읽어 큐브가 association 으로 붙일 수 있게 합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: 'MPM 세율 · 지분율 (차원)'
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #S, dataClass: #CUSTOMIZING }
define view entity ZI_MpmTaxRate
  as select from zmpm_taxrate
{
  key bukrs        as CompanyCode,
  key gjahr        as FiscalYear,
  key tax_basis    as TaxBasis,
      stat_rate    as StatutoryRate,     " 법정세율 (%)
      nci_ratio    as NciRatio           " 비지배 지분율 (%)
}

③ 기본 뷰 — 계정 합계를 조정항목 단위로

세전 금액은 이 뷰에서만 계산합니다. 이후 뷰는 모두 이 값을 받아 쓰므로 세전 금액이 두 가지로 갈라질 일이 없습니다. 원장금액은 부호가 있는 값 그대로 합하고, 보여 줄 때의 부호는 매핑의 부호 규칙으로 바로잡습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: 'MPM 조정항목 기준'
define view entity ZI_MpmAdjustment
  as select from acdoca as j
    inner join   zmpm_adjmap as m
      on  m.bukrs = j.rbukrs
      and m.racct = j.racct
{
  key j.rbukrs      as CompanyCode,
  key j.gjahr       as FiscalYear,
  key m.mpm_code    as MpmCode,
  key m.adj_no      as AdjNo,
      m.adj_type    as AdjType,
      m.deduct_flag as DeductFlag,
      m.tax_basis   as TaxBasis,
      m.sep_flag    as SepFlag,
      @Semantics.currencyCode: true
      j.rhcur       as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      sum( case m.sign_rule when '-' then j.hsl * -1 else j.hsl end ) as PreTaxAmount
}
where j.rldnr = '0L'                       " 선도원장 — 원장 선택은 운영에서 확정
group by j.rbukrs, j.gjahr, m.mpm_code, m.adj_no,
         m.adj_type, m.deduct_flag, m.tax_basis, m.sep_flag, j.rhcur

④ 큐브 — 장부와 재계산을 나란히

세효과 계정과 비지배지분 효과 계정의 합계를 장부 금액으로 가져오고, 같은 줄에서 세율과 지분율을 곱한 재계산 금액을 만듭니다. 재계산 식이 이 뷰 한 곳에만 있으므로 화면과 배치가 서로 다른 값을 낼 수 없습니다. 세무상 불인정 항목은 재계산이 0 입니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: 'MPM 조정항목 세효과 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_MpmAdjCube
  as select from ZI_MpmAdjustment as a
    association [0..1] to ZI_MpmTaxRate as _Rate
      on  _Rate.CompanyCode = a.CompanyCode
      and _Rate.FiscalYear  = a.FiscalYear
      and _Rate.TaxBasis    = a.TaxBasis
    association [0..1] to ZI_MpmBookedEffect as _Booked
      on  _Booked.CompanyCode = a.CompanyCode
      and _Booked.FiscalYear  = a.FiscalYear
      and _Booked.MpmCode     = a.MpmCode
      and _Booked.AdjNo       = a.AdjNo
{
  key a.CompanyCode, key a.FiscalYear, key a.MpmCode, key a.AdjNo,
      a.AdjType, a.DeductFlag, a.SepFlag, a.Currency,
      @DefaultAggregation: #SUM
      a.PreTaxAmount,
      _Rate.StatutoryRate,
      _Rate.NciRatio,
      @DefaultAggregation: #SUM
      _Booked.TaxBooked,
      @DefaultAggregation: #SUM
      _Booked.NciBooked,
      @DefaultAggregation: #SUM
      case a.DeductFlag
        when 'Y' then cast( a.PreTaxAmount * _Rate.StatutoryRate / 100 as abap.curr(18,0) )
        else cast( 0 as abap.curr(18,0) )
      end as TaxExpected,
      @DefaultAggregation: #SUM
      case a.DeductFlag
        when 'Y' then cast( ( a.PreTaxAmount - a.PreTaxAmount * _Rate.StatutoryRate / 100 )
                            * _Rate.NciRatio / 100 as abap.curr(18,0) )
        else cast( a.PreTaxAmount * _Rate.NciRatio / 100 as abap.curr(18,0) )
      end as NciExpected
}

⑤ 쿼리 — 점검 코드를 판정한다

판정 순서 A09 → A04 → A01 → A02 → A03 과 허용 범위가 이 뷰 한 곳에 있습니다. 화면은 판정을 다시 하지 않고 이 뷰의 결과 컬럼을 보여 주기만 합니다. 허용 범위를 회사 기준으로 바꿀 때는 이 뷰의 상수 하나를 바꾸거나 설정 테이블에서 읽도록 확장합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: 'MPM 세효과 점검 쿼리'
@Analytics.query: true
@VDM.viewType: #CONSUMPTION
define view entity ZC_MpmTaxCheck
  as select from ZI_MpmAdjCube
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key CompanyCode,
  @Consumption.filter.mandatory: true
  key FiscalYear,
  key MpmCode,
  key AdjNo,
      AdjType,
      PreTaxAmount,
      StatutoryRate,
      TaxBooked,
      TaxExpected,
      TaxBooked - TaxExpected as TaxDiff,
      NciBooked,
      NciExpected,
      NciBooked - NciExpected as NciDiff,
      SepFlag,
      case
        when TaxBasis = 'IND'                                              then 'A09'
        when DeductFlag = 'N' and abs( TaxBooked ) > 1000                  then 'A04'
        when abs( TaxBooked - TaxExpected ) > 1000                         then 'A01'
        when abs( NciBooked - NciExpected ) > 1000                         then 'A02'
        when SepFlag = 'N'                                                 then 'A03'
        else 'A00'
      end as CheckCode
}

⑥ 권한 — 회사코드 단위로 자른다

합계 화면에서는 보이지 않던 남의 회사 숫자가 줄 단위 점검 화면에서는 그대로 드러납니다. 그래서 권한은 조회 서비스의 가장 아래, 이 뷰에 겁니다. 화면 쪽 필터는 편의일 뿐 보안 수단이 아닙니다.

@EndUserText.label: 'MPM 세효과 점검 — 회사코드 권한'
@MappingRole: true
define role ZC_MpmTaxCheck {
  grant select on ZC_MpmTaxCheck
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의 — 화면이 바라보는 문

마지막 층은 서비스입니다. 서비스 정의에서 노출할 뷰를 정하고, 서비스 바인딩에서 OData V2 로 게시합니다. 점검 필요 건수를 세는 함수는 RAP 의 정적 함수로 두거나, 쿼리 뷰의 집계로 대신할 수 있습니다.

@EndUserText.label: 'MPM 세효과 점검 서비스'
define service ZUI_MpmTaxCheck {
  expose ZC_MpmTaxCheck as AdjustmentCheck;
  expose ZI_MpmAdjCube  as AdjustmentCube;
}
" 서비스 바인딩 : OData V2 - UI 로 만들어 게시한다.
" 게시 뒤 게이트웨이의 서비스 유지 화면(/IWFND/MAINT_SERVICE)에서 활성화 여부를 확인한다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 일곱 가지는 코딩이 아니라 합의입니다.

운영 데이터로 갈 때

운영 원장의 전표는 수천만 건이 될 수 있습니다. 이 앱이 보는 것은 전표가 아니라 조정 대상 계정의 합계이므로, 집계는 반드시 데이터베이스 쪽(큐브 뷰)에서 끝내야 합니다. 화면이 전표를 받아 합산하는 구조로 가면 응답이 느려집니다. 회계연도를 필수 조건으로 두고, 매핑된 계정에 해당하는 전표만 읽도록 조인 순서를 확인하며, 원장 · 회사코드 · 계정으로 이어지는 접근 경로가 쓰이는지 실행 계획으로 점검합니다. 응답 시간 기준은 회사가 정해야 하지만, 월 마감 시점의 첫 조회가 수 초 안에 끝나는 것을 목표로 잡는 것이 일반적입니다.

자주 묻는 질문

도입을 검토할 때 자주 나오는 질문을 네 묶음으로 모았습니다.

숫자와 산식

화면과 조작

표준 T-code 와 데이터

도입과 운영