생산 재공 평가·오더 정산 통합 관리 — 기말 재공 잔액부터 오더 정산·장기 재공 충당·대사까지 한 앱에서 끝내는 월마감

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

월마감 때 생산 영역이 받는 질문은 해마다 같습니다. 기말 재공 잔액이 얼마인가, 기술완료 오더를 모두 정산했는가, 오래 묵은 재공에 충당을 잡았는가. 지금 이 세 답은 오더 정보 조회, 재공품 계산, 오더 정산, 원가 라인 조회를 오가며 엑셀로 맞추고, 승인은 메일로 받는 식으로 흩어져 있는 경우가 많습니다. 이 앱은 그 세 답을 한 앱에 붙여, 처리하는 사람과 승인하는 사람, 확인하는 사람이 같은 숫자를 봅니다.

이 앱은 기준정보 관리, 문서 처리(작성 · 검토 · 승인 · 전기 · 역처리), 시뮬레이션 후 일괄 실행, 대사와 예외 조치, 큐브 분석, 영역 간 연계, 이력 · 감사 · 권한을 한 서비스 위에서 수행합니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 처리와 점검의 관점을 더해 확장합니다. 이 글의 숫자는 모두 샘플 데이터 기준이며, 점검 도구이므로 최종 판단은 회사와 감사인이 합니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 총차이 3.8% 의 가장 큰 몫은 시간당 원가

샘플 데이터 기준 2026-01 ~ 2026-10 범위에서 투입 원가는 898,880,557원이고 계획 865,771,862원보다 33,108,695원(3.8%) 많았습니다. 총차이만 보면 “원가가 좀 올랐다”로 끝나지만, 네 요인으로 가르자 가장 큰 몫이 시간당 원가(+16,230,553원)였고, 수율(+7,338,081원), 물량(+6,119,597원), 시간 원단위(+3,420,464원)가 뒤를 이었습니다. 네 요인의 합은 총차이와 정확히 같고 검산 값은 0 입니다. 원인은 이 화면이 단정하지 않고 “확인 필요”로 남기므로, 회의는 ‘어느 숫자가 맞나’ 대신 ‘시간당 원가가 왜 올랐나’로 시작합니다.

같은 범위에서 큐브 합계와 원천 원가 라인 합계는 측정값 8종 모두 차이가 0 이었고, 대사 규칙 4종은 샘플에 심어 둔 의도적 예외 10건을 정확히 찾아냈습니다(머리 금액 2건 · 정산 전표 2건 · 장부 재공 2건 · 기술완료 재공 4건).

도입하면 달라지는 것

• 처리 · 승인 · 전기 · 역처리를 한 앱에서 하고, 상태와 이력이 문서마다 남습니다.
• 시뮬레이션 합계를 확인한 뒤 같은 금액으로 정산 · 충당 문서를 만들어 실행 후 대조 작업이 줄어듭니다.
• 대사 예외가 담당자별 목록으로 올라와 마감 회의가 예외를 닫는 회의가 됩니다.
• 분석 숫자를 문서 라인까지 내려가 검산할 수 있어 숫자의 출처를 설명하는 시간이 줄어듭니다.
• 감사 로그와 역할 · 권한이 같은 앱에 있어 누가 언제 무엇을 했는지를 따로 모을 필요가 없습니다.

이런 회사에 맞습니다

생산오더 기준으로 재공을 평가하고 기술완료 오더를 정산하며, 월마감마다 장기 재공 충당 여부를 점검하는 제조 기업.

처리 건수가 많지 않아도 승인 단계(2단계)와 직무 분리를 시스템으로 남기고 싶은 생산 · 원가 · 재무 협업 조직. 사업장이 둘 이상이고 오더 정산 일정이 사업장마다 다른 경우에 특히 맞습니다.

SAP S/4HANA 를 쓰면서 재공 · 정산 대사를 엑셀로 하고 있는 원가 · 생산관리 팀.

이 앱은 업무 처리와 분류 · 집계 · 대사를 돕는 점검 도구입니다. 판정은 “점검 필요” · “확인 필요”로 표시하고, 최종 판단은 회사와 감사인이 합니다.

실행 화면

실제로 돌아가는 화면 44종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 어떻게 읽는지를 아래에 적었습니다. 숫자는 모두 같은 샘플 자료에서 나왔습니다.

사용 방법

1. 위쪽 조건 줄에서 사업장(선택)과 기간 시작 · 종료(필수, 2026-01 형식)를 고릅니다. 모든 화면이 같은 조건을 씁니다.
2. 오른쪽 위 파란 조회 버튼을 누르거나 입력 칸에서 Enter 를 누릅니다. 개요 화면은 열릴 때 한 번 조회합니다.
3. 개요 · 할 일의 카드(기말 재공 잔액 · 정산 대기 · 승인 대기 · 반려 · 미해결 예외 · 확정 문서)와 내 할 일을 확인합니다.
4. 왼쪽 메뉴 순서대로 기준정보 → 문서 처리 → 일괄 실행 → 대사 · 점검 → 분석 → 영역 간 연계 → 이력 · 감사 · 권한 탭으로 이동합니다.
5. 문서 목록의 행을 누르면 오른쪽에 상세(항목 · 상태 이력 · 연계 문서 · 감사 로그)가 열리고, 분석 피벗의 칸을 누르면 드릴스루 창이 열립니다.
6. 문서 목록 위 xlsx · CSV, 분석 화면의 CSV · PowerPoint 버튼으로 내려받습니다.

무엇으로 만들었나

처음 열었을 때 — 카드와 할 일

카드 숫자는 위 조회조건 범위 기준입니다. 샘플 데이터에서는 기말 재공 잔액 75.0백만원, 정산 대기 오더 7건, 승인 대기 문서 2건, 미해결 대사 예외 10건으로 읽힙니다. 사업장이나 기간을 바꾸고 조회하면 카드가 함께 바뀝니다.

기준정보 관리 — 오더 · 자재 · 충당 규칙

처리자 역할만 변경할 수 있고, 변경 내용은 이력에 남습니다. 자재의 사업장과 다른 오더는 만들 수 없습니다.

목표 수량은 0보다 커야 하고 자재와 사업장이 맞아야 합니다. 조회 전용 사용자에게는 생성 버튼이 보이지 않습니다.

규칙을 바꾸면 이후 일괄 실행의 충당 계산에 반영됩니다. 구간이 겹치거나 비면 저장을 거절합니다.

이력은 감사 로그와 같은 기록에서 읽으므로 두 화면이 어긋나지 않습니다.

문서 처리와 승인 — 승인 버튼은 승인자에게만 보인다

문서번호 · 오더 · 자재로 검색하고 구분 · 상태로 거릅니다. 목록 위 생성 · 업로드 · xlsx · CSV 버튼은 역할에 따라 보입니다.

차변 합계와 대변 합계가 같아야 전기할 수 있습니다. 상태에 맞는 버튼만 노출됩니다.

정산 문서는 기술완료 오더만, 평가 문서는 진행 오더만 고를 수 있습니다.

검증은 서비스가 판정하므로 업로드와 화면 입력이 같은 규칙을 씁니다.

기술완료 오더 7건 중 이미 정산이 진행 중인 오더를 다시 고르면 이 메시지가 뜹니다.

불량 행은 사유와 함께 나열되고, 전표일 형식이 틀린 행은 적용되지 않습니다.

현재 몇 단계가 끝났는지 보이고, 메모는 선택입니다.

숨기기만 하는 것이 아니라 서버도 같은 규칙으로 거절합니다.

반려된 문서는 처리자가 보완한 뒤 다시 검토를 요청합니다.

정산 문서는 전기와 함께 오더가 마감 상태로 바뀝니다.

원문서와 연결된 반대(차 · 대 바뀐) 문서가 만들어집니다.

정산 문서를 역처리하면 오더가 기술완료로 돌아오고 원가 라인도 되돌아갑니다.

이 경우 조정 문서로 처리하는 것이 순서입니다.

일괄 실행 — 시뮬레이션 합계와 실행 결과가 같다

사업장과 대상 기간을 넣고 시뮬레이션을 누르면 대상 목록과 합계가 나옵니다. 이 화면에서는 아무것도 저장되지 않습니다.

시뮬레이션을 하지 않으면 실행 버튼이 눌리지 않습니다.

실행으로 만든 문서의 합계는 시뮬레이션 합계와 같습니다.

이중 실행은 서버가 막고, 화면은 이유를 안내합니다.

대사와 예외 조치 — 차이를 사유와 함께 닫는다

머리 금액 2건, 정산 전표 2건, 장부 재공 2건, 기술완료 재공 4건이 예외로 올라옵니다. 예외는 모두 10건입니다.

조정은 자동 정정이 가능한 경우에만 허용됩니다.

해소된 예외는 다시 열 수 있고, 조치 이력은 감사 로그에 남습니다.

분석 — 피벗에서 문서 라인까지

기본은 재공을 오더 상태별로 봅니다. 모든 축이 같은 큐브에서 나오므로 어떤 배치에서도 총합이 같습니다.

큐브는 한 번 읽고 브라우저에서 다시 묶습니다. 총합은 바뀌지 않아야 합니다.

금액과 증감률을 둘 다 넘을 때만 색을 입힙니다.

워터폴의 끝값은 실적과 같고, 요인 합과 총차이의 검산은 0 입니다.

사유는 조회 범위와 행 경로에 묶여 다음 조회에도 따라옵니다.

맨 위에 칸 금액과 드릴스루 합계, 일치 표시가 나옵니다.

원가 집계 라인처럼 별도 문서가 없는 경우에는 이유를 안내합니다.

필터를 적용한 합계는 선택한 값들의 큐브 합과 같습니다.

역할을 고르면 그 역할이 먼저 보는 측정값과 축으로 시작합니다.

영역 간 연계 · AI · 이력 · 역할 · 좁은 화면

전기하면 원가 · 재무 쪽 연계 행이 만들어지고, 역처리하면 취소 행이 이어집니다.

금액과 비율은 서비스가 계산하고, 근거 표를 펼쳐 볼 수 있습니다. 원인은 단정하지 않고 확인 필요로 남깁니다.

하루 한 번 제한은 서버 기록으로 판정하고, 활동 기록이 남습니다.

사용자별 역할과 권한표가 함께 있어 누가 무엇을 할 수 있는지 확인합니다.

권한은 서비스가 판정하므로 화면을 우회해도 막힙니다.

필요한 역할이 없으면 이유를 안내합니다.

같은 이름은 거절됩니다.

메뉴는 접히고 카드는 세로로 쌓입니다.

행을 누르면 상세로 이동하고 뒤로 가기로 돌아옵니다.

축 조합 상한을 넘으면 안내가 뜹니다.

화면 뒤에서 일어나는 일

판정 규칙과 상태 전이는 서비스가 판정합니다. 화면은 결과와 허용된 동작만 보여 줍니다. 여기부터는 목차에 올리지 않은 상세입니다. 도입 검토에서 “그래서 이건 어떻게 되느냐”로 자주 되돌아오는 대목을 판정 조건 · 결과 · 사용자 조치로 적었습니다.

일괄 실행의 처리 단계

1. 사업장과 기간을 정하고 시뮬레이션을 누릅니다. 이때는 아무것도 저장하지 않습니다.
2. 대상 오더 · 경과 일수 · 구분별 금액과 합계, 그리고 조건 해시가 나옵니다.
3. 합계를 검토한 뒤 실행을 누르면 확인 창에 건수와 금액이 다시 나옵니다.
4. 서버는 같은 조건 해시일 때만 정산 · 충당 문서를 만들고, 실행 이력에 건수와 금액을 남깁니다.
5. 실행 합계가 시뮬레이션 합계와 같은지는 대사 화면에서 다시 확인합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

휴대폰처럼 좁은 화면에서는 왼쪽 메뉴가 접히고, 표 옆에 있던 차트는 표 아래로 내려갑니다. 표는 가로로 넘겨 보며, 같은 서비스와 같은 규칙을 쓰므로 숫자는 넓은 화면과 같습니다.

파일 구성

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 처리 흐름과 조회 · 검증 관점을 더해 확장합니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 화면을 없애야 하느냐”는 질문이 꼭 나오는데, 대부분은 없애지 않고 둡니다 — 정산 · 평가 실행과 감사 대응은 표준 거래가 맡는 편이 안전합니다. 아래 표의 오른쪽은 두 화면의 숫자를 맞춰 보는 지점입니다. 이 앱 결과에서 표준으로는 KOB1 · COOIS로 원천을 확인하고, 표준 화면의 값은 이 앱의 드릴스루와 대사 화면에서 다시 봅니다.

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

표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 정의된 쿼리를 읽는 데 강합니다. 이 앱은 같은 종류의 큐브와 분석 쿼리를 CDS 로 두되(#sec-cds 참조), 그 위에서 문서를 처리하고 승인하고 대사 예외를 닫는 흐름까지 한 서비스에 묶었다는 점이 다릅니다. 그래서 분석만 필요하면 CDS 쿼리를 표준 도구로 열고, 처리 흐름까지 필요하면 이 화면을 씁니다. 확인하지 못한 표준 Fiori 앱 이름은 적지 않았습니다. 확인 필요한 항목은 운영 환경의 View Browser(F2170)에서 실제 이름을 확인합니다.

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

분석 지표 정의

CDS 구성

화면이 읽는 숫자는 CDS 뷰에서 한 번만 정의합니다. 아래는 운영 환경에서 이 구성을 올릴 때의 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로 그대로 붙여 넣기 전에 View Browser(F2170)로 실제 이름을 확인해야 하며, 확인이 필요한 자리는 주석에 적었습니다.

뷰 레이어 구성

① 충당 규칙 테이블 — 경과 구간과 충당률을 코드 밖으로

이 테이블이 정하는 것: 경과 일수 구간과 충당률. 화면의 기준정보 “충당 규칙”이 이 테이블을 읽고 씁니다. 규칙을 코드에 박지 않고 테이블로 둔 이유는 감사인이 “몇 일부터 몇 퍼센트인가”를 물을 때 한 곳에서 답하고, 회계 정책이 바뀌면 이송 없이 데이터 변경으로 끝내기 위해서입니다.

" ───────────────────────────────────────────────────────────
"  ZWIP_AGERULE — 재공 충당 규칙(경과 구간)
"  역할    : 경과 일수 구간별 충당률. 일괄 실행의 충당 계산이 읽는다.
"  나눈 이유: 규칙을 뷰 안의 case 로 박으면 정책 변경이 곧 이송이 된다.
" ───────────────────────────────────────────────────────────
@EndUserText.label : '재공 충당 규칙'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zwip_agerule {
  key client  : abap.clnt not null;
  key bucket  : abap.char(1) not null;     " 1 / 2 / 3
  bucket_name : abap.char(30);             " 90일 이내 · 91~180일 · 181일 초과
  from_days   : abap.int4;
  to_days     : abap.int4;
  rate_pct    : abap.dec(5,2);             " 0 / 10 / 30
  active      : abap_boolean;
}

② 기준 뷰 — 오더와 자재

이 뷰가 정하는 것: 오더의 상태 · 수량 · 자재 연결. 큐브의 오더 차원이 모두 이 뷰를 거칩니다. 오더 상태를 코드값(REL · TECO · CLSD)으로 두고 이름은 화면에서 붙이는 이유는 언어와 표기를 뷰가 아니라 소비 쪽에서 정하기 위해서입니다.

" ───────────────────────────────────────────────────────────
"  ZI_WipOrder — 생산오더 기준
"  역할    : 오더 · 자재 · 사업장 · 상태 · 목표/입고 수량
"  나눈 이유: 큐브가 오더 마스터 테이블을 직접 읽으면 상태 판정이 뷰마다 달라진다.
"  확인 필요: 상태 판정(시스템 상태 JEST) 방식은 운영 환경에서 정한다.
" ───────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '재공 평가 — 생산오더 기준'
@ObjectModel.usageType.sizeCategory : #L
@ObjectModel.usageType.serviceQuality : #A
define view entity ZI_WipOrder
  as select from aufk
    inner join   afpo on afpo.aufnr = aufk.aufnr
{
  key aufk.aufnr         as OrderNo,
      aufk.werks         as Plant,
      aufk.auart         as OrderType,
      afpo.matnr         as Material,
      @Semantics.quantity.unitOfMeasure : 'Unit'
      afpo.psmng         as TargetQty,
      @Semantics.quantity.unitOfMeasure : 'Unit'
      afpo.wemng         as GrQty,
      afpo.meins         as Unit
}

③ 원천 라인 뷰 — 오더 원가 개별 라인

이 뷰가 정하는 것: 투입 · 입고 환산 · 정산 · 충당의 원천 금액 한 줄. 큐브 합계는 반드시 이 뷰의 합계와 같아야 하며, 화면의 “큐브 합계 = 원천 라인 합계” 대사가 이 지점을 검사합니다.

" ───────────────────────────────────────────────────────────
"  ZI_WipLine — 원천 원가 라인
"  역할    : 오더 원가 개별 라인을 측정값 컬럼으로 펼친다.
"  나눈 이유: 드릴스루가 읽는 단 하나의 라인 뷰이므로 큐브와 어긋날 수 없게 한다.
"  확인 필요: 원가요소 → 측정값(투입 · 입고 · 정산 · 충당) 매핑은 운영에서 확정.
" ───────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '재공 평가 — 원천 원가 라인'
define view entity ZI_WipLine
  as select from coep
    inner join   cobk on  cobk.kokrs = coep.kokrs
                      and cobk.belnr = coep.belnr
{
  key coep.kokrs                                   as ControllingArea,
  key coep.belnr                                   as DocNo,
  key coep.buzei                                   as ItemNo,
      coep.perio                                   as Period,
      coep.objnr                                   as ObjectKey,
      @Semantics.currencyCode : true
      coep.twaer                                   as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      case when coep.wrttp = '04' then coep.wtgbtr else 0 end as ActAmt,
      @Semantics.amount.currencyCode : 'Currency'
      case when coep.wrttp = '11' then coep.wtgbtr else 0 end as CrdAmt
}

④ 큐브 — 차원 8종 · 측정값 8종

이 뷰가 정하는 것: 어떤 축 배치에서도 같은 총합이 나오는 집계. 화면 피벗은 이 큐브를 한 번 읽어 브라우저에서 행 · 열로 다시 묶으므로, 큐브가 합계의 유일한 원천이어야 합니다.

" ───────────────────────────────────────────────────────────
"  ZI_WipCube — 분석 큐브
"  역할    : ZI_WipLine 을 차원 8종으로 합산한 측정값 8종
"  나눈 이유: 피벗을 서버가 아니라 화면이 다시 묶으려면 합계의 원천이 하나여야 한다.
" ───────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '재공 평가 — 분석 큐브'
@ObjectModel.usageType.dataClass : #MIXED
define view entity ZI_WipCube
  as select from ZI_WipLine as l
    inner join   ZI_WipOrder as o on o.OrderNo = l.ObjectKey
{
      @AnalyticsDetails.query.axis : #ROWS
  key l.Period,
  key o.Plant,
  key o.OrderNo,
  key o.OrderType,
  key o.Material,
      @Semantics.currencyCode : true
      l.Currency,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      l.ActAmt,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      l.CrdAmt,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Currency'
      cast( l.ActAmt - l.CrdAmt as abap.curr(15,2) ) as WipAmt
}

⑤ 분석 쿼리 — 화면 조건을 받는 소비 뷰

이 뷰가 정하는 것: 화면의 조회조건(기간 · 사업장 · 오더 상태 ...)이 서버로 넘어가는 모양. 조건은 필터로 선언해 두고 쿼리 안에서 합계를 다시 만들지 않습니다.

" ───────────────────────────────────────────────────────────
"  ZC_WipQuery — 분석 쿼리(Consumption)
"  역할    : 큐브를 화면 조건으로 읽는다. 합계는 큐브 그대로.
"  나눈 이유: 조건과 표시는 쿼리에, 합계의 정의는 큐브에 둔다.
" ───────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : '재공 평가 — 분석 쿼리'
define view entity ZC_WipQuery
  as projection on ZI_WipCube
{
      @Consumption.filter : { selectionType : #INTERVAL, mandatory : true }
      @AnalyticsDetails.query.axis : #FREE
  key Period,
      @Consumption.filter.selectionType : #SINGLE
      @AnalyticsDetails.query.axis : #ROWS
  key Plant,
  key OrderNo,
  key OrderType,
  key Material,
      @AnalyticsDetails.query.axis : #COLUMNS
      ActAmt,
      CrdAmt,
      WipAmt
}

⑥ 권한 — 집계 단계에서 거는 사업장 범위

이 객체가 정하는 것: 누가 어느 사업장의 숫자를 보는가. 드릴스루에만 걸면 전체 합계에서 자기 몫을 빼서 남의 숫자를 알 수 있으므로 큐브 단계에서 겁니다.

" ───────────────────────────────────────────────────────────
"  ZR_WipCube — 접근 제어(DCL)
"  역할    : 사업장 권한 객체로 큐브 · 쿼리 행을 제한한다.
"  나눈 이유: 합계 뺄셈으로 남의 사업장 값이 새는 일을 막는다.
"  확인 필요: 권한 객체와 역할 설계는 운영 PFCG 에서 확정.
" ───────────────────────────────────────────────────────────
@EndUserText.label : '재공 평가 큐브 권한'
@MappingRole : true
define role ZR_WipCube {
  grant select on ZI_WipCube
    where ( Plant ) = aspect pfcg_auth( M_MTDI_WRK, WERKS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩 — 화면이 부르는 이름

이 객체가 정하는 것: 화면이 호출하는 서비스 이름과 엔티티셋 목록. 화면은 서비스 주소만 바꾸면 샘플 서비스에서 운영 서비스로 옮겨 갑니다.

" ───────────────────────────────────────────────────────────
"  ZUI_WipHub — 서비스 정의
"  역할    : 큐브 · 쿼리 · 문서 뷰를 OData V2 엔티티셋으로 노출한다.
"  나눈 이유: 서비스 이름과 엔티티셋 이름을 화면과 약속하는 단일 지점.
" ───────────────────────────────────────────────────────────
@EndUserText.label : '재공 평가·오더 정산 서비스'
define service ZUI_WipHub {
  expose ZC_WipQuery  as CubeSet;
  expose ZI_WipOrder  as OrderSet;
  expose ZI_WipLine   as ItemSet;
}
" 바인딩: OData V2 - UI 로 만들어 게시한다. 서비스 활성화는 /IWFND/MAINT_SERVICE 에서 확인한다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 왼쪽은 대부분 코딩이 아니라 합의입니다.

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

가장 비싼 질문은 “이 숫자 맞아?”입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 샘플 전체에 돌렸습니다. 사례로 든 숫자와 같은 자료의 결과입니다.

규칙 4종의 차이는 샘플에 의도적으로 심은 예외 10건(머리 금액 2 · 정산 전표 2 · 장부 재공 2 · 기술완료 재공 4)이며 모두 찾아냈습니다. 큐브 합계 · 요인 합 · 시뮬레이션 합계는 차이가 0 입니다. 화면 쪽은 브라우저 자동화로 따로 확인했습니다.

운영 데이터로 갈 때

샘플의 규모는 아래와 같습니다. 운영에서 오더와 문서가 수천만 건이 되어도 큐브 행 수는 건수가 아니라 차원 조합 수를 따라갑니다. 그래서 집계만 DB 로 내리면 화면이 들고 있을 행 수는 크게 달라지지 않습니다.

드릴스루는 집계가 아니라 조회이므로, 칸 하나에 매우 많은 라인이 매달려 있으면 건수를 먼저 세어 보고 일정 수를 넘으면 범위를 좁히라고 안내하는 편이 낫습니다. 응답 시간 기준은 운영 전환 때 정합니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영