생산 계획·능력 통합 관리 — 수요에서 계획오더·생산오더까지, 능력 부하와 실적 차이를 한 앱에서

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

생산 계획 회의의 질문은 늘 같습니다. 이번 달 수요를 받을 능력이 있는가, 누가 승인했고 무엇이 아직 막혀 있는가, 계획과 실적은 왜 벌어졌는가. 지금 이 세 답은 소요량 계획(MD01·MD04) 결과, 생산오더 조회(COOIS), 능력 평가(CM01·CM21), 그리고 밤새 맞춘 엑셀과 메일 승인으로 흩어져 있습니다. 이 앱은 세 답을 한 화면에 붙여, 계획 담당자가 표준 거래 사이를 오가며 숫자를 옮기는 일을 줄입니다.

표준 거래는 한 건을 정확히 처리하는 데 강하고, 이 앱은 그 사이를 잇는 쪽에 섭니다. 계획오더 문서를 만들고 검토 요청·승인·확정까지 상태를 서버가 지키며, 수요를 일괄로 계획오더로 바꾸기 전에 시뮬레이션으로 부하와 가공비를 먼저 보고, 확정한 숫자는 대사식으로 검산합니다. 그 위에 작업장 × 기간 부하를 축을 바꿔 가며 보고, 가공비 차이를 요인으로 가르는 분석을 얹었습니다.

핵심 포인트 여덟 가지

사례로 보는 효과 — 가공비 차이 3,485만 원의 진짜 이유

2026년 1~10월 계획 가공비는 800,494,307원, 실적은 835,342,365원이었습니다. 차이 +34,848,058원(4.4%)까지는 표준 리포트도 말해 줍니다. 이 앱은 그 다음을 답합니다. 네 요인으로 가르자 몫이 가장 큰 것은 능률 +39,276,968원이었습니다 — 같은 물량을 만드는 데 계획보다 시간이 더 든 몫입니다. 물량 +2,858,012원과 수율 +2,570,390원이 더해졌고, 요율은 −9,857,312원으로 총차이를 일부 줄여 주었습니다.

분해에는 조건을 걸었습니다. 네 요인의 합이 총차이와 1원도 어긋나면 안 됩니다. 화면이 매번 그 등식을 검산해 보여 줍니다. 2,858,012 + 2,570,390 + 39,276,968 − 9,857,312 = 34,848,058. 이 한 줄이 맞아야 "능률이 문제"라는 말이 회의에서 통합니다. 대사식 검사 건수와 차이 0건은 검증 결과 절에 따로 적었습니다.

도입하면 달라지는 것

• 계획 회의 준비 — 부하율·승인 대기·예외가 개요 한 화면에 모이므로 엑셀 취합과 메일 확인 시간이 줄어듭니다.
• 승인의 기록 — 누가 언제 어떤 사유로 승인·반려했는지가 상태 이력과 감사 로그에 남아 사람이 바뀌어도 규칙이 이어집니다.
• 일괄 실행의 안전 — 시뮬레이션 합계와 실행 결과가 같고, 같은 조건의 두 번째 실행은 막혀 중복 오더가 생기지 않습니다.
• 회의의 주제 — "어느 숫자가 맞나"가 아니라 "능률이 왜 벌어졌나"를 이야기합니다.
• 놓치는 날이 없는 점검 — 아무도 화면을 열지 않은 날에도 규칙에 걸린 항목은 받을 역할의 대기함에 올라갑니다.

이런 회사에 맞습니다

작업장 여러 곳을 공유하는 제조 법인으로, 수요가 월 단위로 들어오고 계획오더를 일괄로 만들며 승인 단계가 둘 이상인 회사에 맞습니다. S/4HANA의 생산 계획·오더 관리를 쓰면서 능력 평가와 계획 대비 실적을 엑셀로 맞추고 있는 생산관리팀, 그리고 숫자의 출처를 통제하면서 AI 해설을 쓰고 싶은 경영지원 조직이 대상입니다. 반대로 한 작업장에서 한 가지 제품만 만들거나 승인 단계가 없는 곳이라면 표준 거래만으로 충분할 수 있습니다.

실행 화면

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

사용 방법

1. 조회조건을 입력합니다. 화면 맨 위 한 줄에 사업장·기간(시작)·기간(종료)이 있고 모두 선택 입력입니다. 기간은 2026-01 형식이며 시작이 종료보다 늦으면 안내가 뜹니다.
2. 조회를 누르거나 입력 칸에서 Enter 키를 누릅니다. 개요·문서 처리·기준정보 화면은 열 때 현재 조건으로 자동 조회되고, 분석 화면은 조회를 눌러야 큐브를 읽습니다.
3. 개요의 요약 타일(부하율·승인 대기·반려·미해결 예외·확정·열린 할 일)을 먼저 봅니다. 아래 "내 할 일"에서 줄을 누르면 해당 문서나 예외로 바로 이동합니다.
4. 왼쪽 메뉴를 위에서 아래로 따라갑니다 — 개요 · 기준정보 관리(작업장·자재·공정 순서 탭) → 문서 처리 → 일괄 실행 → 대사·점검 → 분석 → 영역 간 연계 → 이력·감사·권한.
5. 행이나 칸을 눌러 상세를 엽니다. 문서 처리에서는 오른쪽에 항목·상태 이력·연계 문서·감사 로그가 열리고, 분석에서는 피벗 칸을 누르면 그 값을 만든 문서 라인이 열립니다.
6. 처리자가 문서를 만들어 검토 요청하면 승인자가 승인(또는 사유를 적어 반려)하고 처리자가 전기합니다. 일괄 실행은 시뮬레이션 → 결과 검토 → 실행, 대사는 대사 실행 → 예외 목록 → 조치 → 재대사 순서입니다.
7. 내보내기 — 기준정보·문서·드릴스루·연계 내역·피벗의 CSV는 UTF-8(BOM)이라 엑셀에서 한글이 깨지지 않습니다. 문서는 xlsx 내보내기와, 미리 검사한 뒤 반영하는 xlsx 업로드도 있습니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤로 짰고, 판정과 집계는 서비스가 맡습니다. 어디에 무엇을 두었는지와 그렇게 한 까닭을 표로 적었습니다.

앱 정보

처음 열었을 때 — 부하율과 할 일이 앞에 선다

처음 여는 화면은 숫자 몇 개와 할 일입니다. 조회조건 아래에 타일 여섯 개가 서고, 그 아래 "내 할 일"이 역할에 맞게 줄을 세웁니다.

가장 먼저 보이는 것은 이번 기간의 작업장 부하율(2,563 / 4,122 h, 62.2%)과 승인 대기 34건 · 반려 22건 · 미해결 대사 예외 15건 · 확정 202건 · 열린 할 일 145건입니다. 타일 색은 부하율이 85% 이하면 녹색, 85%를 넘으면 주황, 95%를 넘으면 빨강으로 바뀝니다. 오른쪽 위 사용자 전환으로 역할을 바꾸면 같은 화면이 그 역할의 눈높이로 다시 그려집니다.

할 일은 서버가 문서 상태에 맞춰 만들고 닫습니다. 승인 대기 · 반려 · 대사 예외 · 시작일 임박이 한 목록에 모이고, 한 줄을 누르면 해당 문서 상세로 바로 넘어갑니다. 상태 오른쪽의 색 글씨는 기한이 지났거나 임박했는지를 뜻합니다.

기준정보 관리 — 작업장 · 자재 · 공정 순서

기준정보는 계획 숫자의 바닥입니다. 작업장의 가용 능력·효율·시간당 가공비가 여기서 정해지고, 부하율과 가공비가 모두 이 값에서 나옵니다.

일 가용 능력(h) · 효율(%) · 교대 · 시간당 가공비가 한눈에 보이고, 위쪽 검색어는 코드와 이름에 모두 걸립니다. 생성 · 수정 · 사용 중지 버튼은 관리자에게만 켜지며, 행의 라디오를 먼저 골라야 수정과 사용 중지가 열립니다. 목록은 CSV로 내려받을 수 있습니다.

표준 로트는 일괄 실행이 계획오더 수량을 자를 때 쓰는 값이라 이 탭에서 고치면 다음 실행부터 반영됩니다. 사용 중지한 자재는 목록에 남되 새 문서에서는 고를 수 없습니다.

저장을 누르면 화면이 아니라 서비스가 필수값과 중복을 확인합니다. 이미 있는 작업장 코드를 다시 넣으면 "이미 있는 작업장입니다"라는 메시지가 그대로 돌아옵니다. 입력을 바꾼 뒤 닫으려 하면 저장하지 않은 변경이 있다고 한 번 더 묻습니다.

생성과 수정이 시각 · 사용자 · 이전 값 · 이후 값으로 남습니다. 효율과 시간당 가공비를 바꾸면 두 값이 한 줄에 같이 기록되므로, 가공비가 달라진 이유를 나중에 따라가기 쉽습니다.

문서 처리와 승인 — 상태와 권한을 서버가 지킨다

문서가 한 번 만들어지면 상태는 서버가 지킵니다. 목록·상세·생성·업로드가 한 화면 안에서 이어지고, 버튼은 현재 상태와 내 역할에 맞는 것만 켜집니다.

상태 글씨 색으로 임시저장 · 검토요청 · 승인 · 확정을 구분합니다. 위쪽 문서번호·자재 검색과 구분 · 상태 필터로 좁히고, 업로드(xlsx) · CSV · xlsx 버튼으로 여러 건을 올리거나 내려받습니다.

공정 항목마다 작업장 · 시간(h) · 준비 시간(h) · 가공비가 있고, 머리의 총 시간과 가공비는 항목 합계와 같아야 합니다. 상태 칸에는 승인 단계(0 / 1 단계)와 작성자가 보여, 누가 승인할 수 있는지 미리 알 수 있습니다. 가운데 손잡이를 끌어 목록과 상세 너비를 조절합니다.

자재를 고르면 공정 순서(라우팅)에서 항목이 자동으로 펼쳐지고, 시간 · 준비 시간 · 가공비도 서비스가 계산합니다. 수량이 0 이하이거나 종료일이 시작일보다 앞서면 저장되지 않습니다.

"검사 통과 3건 · 확인 필요 1건"처럼 먼저 요약하고, 수량이 0보다 커야 한다는 식의 사유를 행에 붙입니다. 반영을 누르면 서버가 같은 검사를 다시 하며, 통과한 행만 문서로 만들어집니다.

일괄 실행 — 시뮬레이션을 거쳐야 실행된다

수요를 계획오더로 바꾸는 일괄 실행은 되돌리기 어렵습니다. 그래서 시뮬레이션을 거쳐야만 실행되도록 순서를 고정했습니다.

미충족 수요 8건이 계획오더 8건 · 638.1 h · 가공비 26,805,730 KRW로 바뀌는 모습이 보이고, 오른쪽 위에 최대 부하율 278.1%가 빨갛게 표시됩니다. 오른쪽 열에는 능력이 넘치는 작업장(M101 · M102)이 적혀 있어 실행 전에 일정을 조정할 수 있습니다. 시뮬레이션 없이는 실행 버튼이 서버에서 거절됩니다.

로그 열 개가 시작 → 문서 생성 8건 → 완료 순서로 남고, 아래에는 만들어진 문서가 문서 처리 화면으로 이어지는 링크와 함께 놓입니다. 시뮬레이션 합계(8건 · 638.1 h)와 실행 결과(8건 · 638.06 h)는 반올림 차이 외에는 같습니다. 같은 조건으로 다시 실행하면 서버가 거절합니다.

대사와 예외 조치 — 15건은 의도적으로 남겨 두었다

대사는 "숫자가 맞는가"를 사람 대신 돌려 보는 일입니다. 규칙 네 개가 예외를 만들고, 예외에는 조치와 이력이 붙습니다.

R01 문서 머리 시간과 항목 시간 합계, R02 계획 시간과 실적 시간(허용 오차 8%), R03 작업장 월 부하와 가용 능력, R04 당월 수요와 계획오더 수량을 점검합니다. 차이가 난 건은 아래 예외 목록으로 내려가 미해결 → 조치 중 → 해소로 추적합니다.

같은 데이터를 다시 돌려도 예외가 중복으로 쌓이지 않고 기존 예외가 갱신됩니다. 의도적으로 남겨 둔 15건(R01 1 · R02 5 · R03 3 · R04 6)은 예외 목록에서 조정 문서 · 사유 · 보류로 조치합니다.

분석 — 능력 부하를 축을 바꿔 가며 본다

분석은 이 앱의 중심입니다. 작업장 × 기간 부하를 같은 큐브 위에서 축을 바꿔 가며 보고, 차이는 요인으로 가르고, 칸은 원천 라인까지 내려갑니다.

조회를 누르면 큐브를 한 번 읽어 피벗을 만듭니다. 합계는 22,324.8 h이고 오른쪽 차트는 같은 값을 그립니다. 조회 전에도 조회조건과 보드 틀이 먼저 보이며, 머리 영역은 접으면 요약 한 줄만 남습니다.

합계 실적 22,324.8 h에 대해 기준 22,323.0 h, 차이 +1.8 h입니다. 색은 금액이나 시간 부호가 아니라 가공비에 준 영향 방향으로 칠하며, 금액 임계와 비율 임계를 모두 넘을 때만 입힙니다. 차트는 실적과 기준을 묶음 막대로 바꿉니다.

행 축은 최대 3단계, 열 축은 최대 2단계까지 쌓을 수 있고, 열 조합이 36을 넘으면 추가를 막습니다. 축을 바꿔도 이미 읽어 온 큐브를 브라우저에서 다시 묶기 때문에 합계가 달라지지 않고 서버 요청도 일어나지 않습니다.

물량 +2,858,012 · 수율 +2,570,390 · 능률 +39,276,968 · 요율 −9,857,312로 나뉘고, 맨 아래 검산 줄이 요인 합과 총차이가 같음(차이 0)을 매번 보여 줍니다. 가장 큰 요인은 능률이며, 원인은 사람이 확인해야 한다고 화면이 적어 둡니다. 오른쪽은 같은 값을 잇는 워터폴 차트입니다.

질의 조건(작업장 유형 = 조립 · 기간 = 2026-02)이 맨 위에 적히고, 칸 부하 598.2 h와 드릴스루 합계 598.2 h · 라인 32개가 같음("일치")을 표시합니다. 문서번호를 누르면 문서 처리의 해당 문서로 이동하고, CSV로 내려받을 수 있습니다.

같은 차원 안에서는 "또는", 차원 사이에서는 "그리고"로 묶입니다. 목록에는 큐브에 실제로 있는 값만 올라오고, 모두 해제로 한 번에 비웁니다.

레이아웃 저장 · AI 분석 · 에이전트

자주 쓰는 배치는 이름을 붙여 저장하고, 숫자 해설은 AI가 말로 쓰되 숫자는 서비스가 계산하며, 에이전트는 사람이 열지 않아도 감시 규칙을 돌립니다.

기본 레이아웃과 자동 조회를 지정하면 다음에 열 때 조회된 채로 시작합니다. 저장은 서버(LayoutSet)에 사용자별로 남아 다른 브라우저에서도 이어집니다.

기본 체크는 하나만 켤 수 있고, 적용을 누르면 그 배치가 바로 피벗에 반영됩니다. 연필은 이름 바꾸기, 휴지통은 삭제입니다.

현재 범위의 부하율 55.6%와 가공비 차이 +4.4%를 읽어 요약하고, 계획 대비 5% 넘게 벌어진 작업장을 핵심 발견으로 올립니다. 해설은 기본이 규칙 기반이며 모델 연결은 서비스 설정에서만 켤 수 있고 기본은 꺼져 있습니다. 아래 근거 표를 펼치면 해설이 읽은 값과 출처가 그대로 나옵니다.

규칙은 작업장 월 부하율 상한 · 양품 수량 계획 미달 · 불량률 상승 · 시간당 가공비 상승 · 승인 대기 장기 문서 다섯 개이고, 걸리면 받을 역할(생산 책임자 · COO · 원가 책임자 · 자재 책임자) 관점의 보고가 대기함에 올라갑니다. 실행은 하루 한 번으로 서버가 제한하며, 걸린 것이 없어도 활동 기록은 남습니다.

영역 간 연계 — 수주에서 구매요청까지

문서는 혼자 있지 않습니다. 수요가 계획오더가 되고 구매요청으로 이어지는 앞뒤를 한 줄로 따라갑니다.

영업 수주 SO26004007이 생산 계획오더 PL26000001이 되고, 그 소요 자재가 구매요청 MR26000001로 이어집니다. 각 문서를 누르면 생산 문서는 문서 처리로 이동하며, 연계 내역은 CSV로 내려받습니다.

이력 · 감사 · 역할

모든 쓰기는 기록이 남고, 역할마다 할 수 있는 일이 다릅니다. 같은 문서를 다른 사람이 열면 버튼이 달라지는 모습입니다.

모든 쓰기와 상태 전이, 실행이 서버에서 기록되고, 거절된 요청(직무 분리 · 권한 없음)도 남습니다. 허용되지 않는 전이는 서버가 400으로 거절합니다. 사용자 전환은 데모용이며 운영에서는 SAP 권한 객체로 바꿉니다.

생성 · 업로드 버튼이 흐려지고 문서 상세의 검토 요청 · 승인 · 전기 버튼이 사라집니다. 화면에서 숨기는 데서 끝나지 않고, 조회자가 직접 쓰기 요청을 보내도 서버가 403으로 거절합니다.

좁은 화면에서는

휴대폰 폭에서는 조회조건과 보드가 한 줄씩 쌓이고, 메뉴는 아이콘으로 접힙니다. 숨기는 기능은 없습니다.

왼쪽 메뉴는 아이콘만 남아 본문 폭을 돌려주고, 차트는 표 아래로 내려갑니다. 행과 열 조합이 상한을 넘으면 반쯤 그린 표 대신 범위를 좁히라는 안내가 뜹니다.

타일은 한 줄에 하나씩 놓이고 내 할 일 목록이 그 아래에 이어집니다. 알림 영역은 목록 아래로 내려갑니다.

화면 뒤에서 일어나는 일

판정 규칙 — 조건에서 결과까지

아래 표는 화면에서 어떤 조건이 어떤 결과가 되고 사용자가 무엇을 하면 되는지를 정리한 것입니다. 모두 서버가 판정하는 규칙이며, 화면은 결과만 보여 줍니다.

문서 상태 전이

부하율 판정

일괄 실행 판정

대사 규칙

기준 대비 차이 색칠

업무 흐름과 대사식

수요에서 능력 부하·차이까지의 흐름을 단계별 상태와 SAP 데이터 지점, 이 앱의 모듈로 정리했습니다.

조회조건

화면마다 쓰는 조건과 서비스 조건($filter)의 대응입니다. 모든 조건은 한 번 정하면 메뉴를 옮겨도 따라옵니다.

결과 컬럼

문서 목록의 컬럼입니다.

개요와 분석의 컬럼입니다.

좁은 화면에서 달라지는 것

파일 구성

앱 폴더/
  index.html · readme.html · Component.js · manifest.json
  controller/    화면별 컨트롤러 10개
  view/          화면 XML 9개 + 창(fragment) XML 15개
  model/         오류 처리 · 권한 · 큐브 재집계 · SVG 차트 · 레이아웃 · 보고서(pptx) · 내보내기(xlsx) · 서식
  i18n/          화면 문구
  odata/         서비스 정의(메타데이터) · 서비스 로직 · 엔티티셋별 데이터
  media/         소개 영상 · 포스터 · 재생 지점 목록

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지 적었습니다. 운영에 올릴 때 꼭 나오는 질문이 "기존 거래를 없애야 하는가"인데, 대부분은 없애지 않고 둡니다 — 법정·감사 대응과 세무 신고에 쓰는 숫자는 표준 거래가 만든 값이어야 하기 때문입니다.

지표 정의 — 숫자가 어디서 오는가

화면의 숫자가 표준 데이터의 어느 값에서 어떤 산식으로 만들어지는지 적었습니다. 표준 화면의 값과 맞춰 볼 때 이 표를 씁니다.

원천 테이블 — 이 앱이 읽는 표준 데이터

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

표준 CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office와 이 앱이 어떻게 겹치고 나뉘는지 층으로 적었습니다.

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

CDS 구성

이 사례의 화면은 원천 라인 2,834건을 큐브 1,380행으로 묶어 브라우저가 들고 다시 묶습니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일이 집계를 DB로 내리는 것이고, 그 설계가 아래 CDS 뷰입니다.

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

뷰 레이어 구성

① 작업장 유형 매핑 테이블 — 표준 작업장 카테고리를 분석 유형으로 묶는 기준

표준 작업장은 카테고리 한 칸(CRHD.VERWE)으로 구분됩니다. 그 값을 그대로 분석 차원으로 쓰면 고객사마다 코드가 달라 큐브가 갈라지므로, 사업장 · 카테고리별로 "조립 · 가공 · 검사 · 포장 · 도장" 같은 분석 유형을 한 번 정해 두는 매핑 테이블을 둡니다. 운영에서는 이 표가 부하율을 어느 묶음으로 보여 줄지를 결정합니다.

@EndUserText.label : '작업장 유형 매핑 — 능력 분석 차원'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpcap_wccat_map {
  " ─────────────────────────────────────────────────────────────
  "  ZPCAP_WCCAT_MAP — 작업장 카테고리 → 분석 유형
  "  역할 : 사업장 + 작업장 카테고리를 앱이 쓰는 유형 코드로 변환
  "  이유 : 표준 코드를 직접 차원으로 쓰면 고객사 코드 변경이 곧 큐브 변경이 된다
  " ─────────────────────────────────────────────────────────────
  key client    : abap.clnt not null;
  key werks     : werks_d not null;
  key verwe     : abap.char(4) not null;   " 작업장 카테고리 (CRHD-VERWE, 확인 필요)
  wc_cat        : abap.char(3);            " ASM · MCH · INS · PKG · PNT
  wc_cat_text   : abap.char(20);
  active        : abap_boolean;
}

② 작업장 차원 뷰 — 코드 · 이름 · 유형을 한 자리에

차원 뷰는 큐브가 붙잡을 "작업장" 한 가지를 정의합니다. 키는 사업장 + 작업장 코드이고, 이름은 로그온 언어로 가져옵니다. 이 뷰에서 결정되는 것은 "어떤 작업장이 분석에 올라오는가"이므로 작업장 유형(타입 A)만 읽도록 조건을 걸어 둡니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '작업장 차원'
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #M, dataClass: #MASTER }
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'WorkCenter'
define view entity ZI_WorkCenterDim
  as select from crhd as wc
    left outer join crtx as tx
      on  tx.objty = wc.objty
      and tx.objid = wc.objid
      and tx.spras = $session.system_language
    left outer join zpcap_wccat_map as mp
      on  mp.werks = wc.werks
      and mp.verwe = wc.verwe
{
      @ObjectModel.text.element: ['WorkCenterText']
  key wc.werks      as Plant,
  key wc.arbpl      as WorkCenter,
      wc.objid      as WorkCenterObjectId,
      tx.ktext      as WorkCenterText,
      mp.wc_cat     as WorkCenterCategory,
      mp.wc_cat_text as WorkCenterCategoryText
}
where wc.objty = 'A'   " 작업장 오브젝트 유형

③ 능력 부하 큐브 — 공정 한 줄이 부하 시간이 되는 자리

큐브는 이 앱의 숫자가 태어나는 곳입니다. 생산오더 공정(AFVC)과 공정 수량 · 값(AFVV)을 읽어 공정 표준 시간에 오더 수량을 곱하고, 시간 단위를 시간(h)으로 환산합니다. 집계는 월 단위 · 작업장 · 자재 그룹 · 자재 · 근무조로 묶으며, 화면의 "칸 금액 = 드릴스루 라인 합계" 검산은 이 뷰의 라인을 그대로 다시 합쳐서 맞춥니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '능력 부하 큐브 — 생산오더 공정'
@Analytics.dataCategory: #CUBE
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZI_CapaLoadCube
  as select from afko as hd
    inner join afpo as it on it.aufnr = hd.aufnr
    inner join afvc as op on op.aufpl = hd.aufpl
    inner join afvv as vv on vv.aufpl = op.aufpl and vv.aplzl = op.aplzl
    inner join crhd as wc on wc.objid = op.arbid and wc.objty = 'A'
  association [0..1] to ZI_WorkCenterDim as _WorkCenter
    on  _WorkCenter.Plant = $projection.Plant
    and _WorkCenter.WorkCenter = $projection.WorkCenter
{
  " ── 키: 오더 + 공정 ───────────────────────────────────────
  key hd.aufnr                                           as OrderNumber,
  key op.vornr                                           as Operation,
      wc.werks                                           as Plant,
      wc.arbpl                                           as WorkCenter,
      it.matnr                                           as Material,
      substring( cast( hd.gstrp as abap.char( 8 ) ), 1, 6 ) as PeriodYYYYMM,

  " ── 측정값: 부하 시간(h) = 가공 표준시간 × 오더 수량 ÷ 기준 수량 + 준비 시간 ──
      @Semantics.quantity.unitOfMeasure: 'HourUnit'
      @Aggregation.default: #SUM
      cast(
        unit_conversion( quantity    => division( vv.vgw02 * hd.gamng, vv.bmsch, 3 ) + vv.vgw01,
                         source_unit => vv.vge02,
                         target_unit => cast( 'H' as abap.unit( 3 ) ),
                         error_handling => 'SET_TO_NULL' )
        as abap.quan( 13, 3 ) )                          as LoadHours,
      cast( 'H' as abap.unit( 3 ) )                      as HourUnit,

  _WorkCenter
}
where hd.autyp = '10'   " 오더 범주 10 = 생산오더

④ 계획 기준 뷰 — 계획오더와 라우팅 표준값으로 만드는 "기준"

기준 대비 차이를 보려면 실적과 같은 차원을 가진 기준이 있어야 합니다. 계획오더(PLAF)의 수량에 라우팅 표준값을 곱해 계획 부하를 만들고, 실적 큐브와 같은 키 이름(사업장 · 작업장 · 월 · 자재)을 씁니다. 어느 계획 원천을 기준으로 삼을지(계획오더 · 판매계획 · 별도 계획 테이블)는 도입 때 가장 먼저 합의할 항목입니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '능력 계획 기준 — 계획오더 × 라우팅'
@Analytics.dataCategory: #CUBE
define view entity ZI_CapaPlanCube
  as select from plaf as pl
    inner join mapl as ma on ma.matnr = pl.matnr and ma.werks = pl.plwrk and ma.plnty = 'N' and ma.loekz = ''
    inner join plas as pa on pa.plnty = ma.plnty and pa.plnnr = ma.plnnr and pa.plnal = ma.plnal and pa.loekz = ''
    inner join plpo as po on po.plnty = pa.plnty and po.plnnr = pa.plnnr and po.plnkn = pa.plnkn
    inner join crhd as wc on wc.objid = po.arbid and wc.objty = 'A'
{
  key pl.plnum                                           as PlannedOrder,
  key po.vornr                                           as Operation,
      pl.plwrk                                           as Plant,
      wc.arbpl                                           as WorkCenter,
      pl.matnr                                           as Material,
      substring( cast( pl.psttr as abap.char( 8 ) ), 1, 6 ) as PeriodYYYYMM,
      @Aggregation.default: #SUM
      cast( division( po.vgw02 * pl.gsmng, po.bmsch, 3 ) + po.vgw01 as abap.dec( 13, 3 ) ) as PlanLoadHours
}

⑤ 분석 쿼리 — 화면이 부르는 조회 형태를 고정한다

Consumption 뷰는 어떤 차원을 행 · 열 · 필터로 쓸 수 있는지를 선언합니다. 화면의 차원 다중 선택 필터는 아래 @Consumption.filter 선언과 같은 규칙(차원 안 or, 차원 사이 and)을 따릅니다. 가용 능력(KAKO 기반) 큐브를 같은 방식으로 붙이면 부하율을 쿼리 안 계산 키 수치로 둘 수 있으며, 이 글에서는 지면상 부하 시간까지만 보입니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '작업장 능력 부하 분석'
@Analytics.query: true
@VDM.viewType: #CONSUMPTION
define view entity ZC_CapaLoadQuery
  as select from ZI_CapaLoadCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #RANGE, multipleSelections: true }
  WorkCenter,

  @AnalyticsDetails.query.axis: #COLUMNS
  @Consumption.filter: { selectionType: #INTERVAL, mandatory: true }
  PeriodYYYYMM,

  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false, mandatory: true }
  Plant,

  Material,

  @AnalyticsDetails.query.axis: #COLUMNS
  @Semantics.quantity.unitOfMeasure: 'HourUnit'
  LoadHours,

  HourUnit
}

⑥ 접근 제어(DCL) — 사업장 권한을 집계 단계에 건다

권한은 드릴스루 화면에만 걸면 안 됩니다. 집계 합계에서 남의 사업장 숫자를 뺀 값으로 역산할 수 있기 때문입니다. 아래 DCL은 쿼리 단계에서 사업장 권한을 걸어, 합계도 드릴스루도 같은 범위만 보이게 합니다. 권한 객체 이름과 필드는 고객사 권한 설계에 맞춰 확인해야 합니다.

@EndUserText.label: '능력 부하 분석 — 사업장 권한'
@MappingRole: true
define role ZC_CapaLoadQuery {
  grant select on ZC_CapaLoadQuery
    where ( Plant ) = aspect pfcg_auth( C_AFKO_AWK, WERKS, ACTVT = '03' );
    " 권한 객체 이름 · 필드는 고객사 권한 설계에 맞춰 확인 필요
}

⑦ 서비스 정의와 바인딩 — OData V2 로 내보내는 자리

뷰를 만든 뒤에는 서비스 정의로 무엇을 내보낼지 정하고, 서비스 바인딩으로 OData V2(UI)로 게시합니다. 이 앱의 화면은 엔티티셋 이름만으로 바인딩되므로, 내보내는 이름을 앱이 기대하는 엔티티셋 이름과 맞추는 일이 전환의 핵심입니다. 게시 뒤에는 서비스 활성화 도구에서 활성 여부를 확인하고 앱 설정의 서비스 주소를 바꿉니다.

@EndUserText.label: '생산 능력 통합 서비스'
define service ZUI_CapaLoadService {
  expose ZC_CapaLoadQuery  as CubeSet;
  expose ZI_WorkCenterDim  as WorkCenterSet;
  expose ZI_CapaPlanCube   as PlanSet;
}

" 서비스 바인딩(ADT)
"   이름 : ZUI_CAPALOAD_O2
"   유형 : OData V2 - UI
"   게시 후 : /IWFND/MAINT_SERVICE 에서 활성 확인 → 앱 manifest 의 서비스 주소 교체

⑧ 문서 처리 — 승인 · 전기를 RAP 동작으로

계획오더 · 생산오더 · 조정 문서의 상태 전이는 운영에서 RAP 동작으로 옮길 수 있습니다. 아래 동작 이름은 이 앱의 펑션(검토 요청 · 승인 · 반려 · 전기 · 역처리)과 1:1이고, 작성자와 승인자가 같으면 막는 직무 분리와 금액 구간별 승인 단계는 구현 클래스에서 판정합니다.

managed implementation in class zbp_i_planorderdoc unique;
strict ( 2 );

define behavior for ZR_PlanOrderDoc alias PlanDoc
persistent table zpcap_doc
lock master
authorization master ( instance )
etag master LastChangedAt
{
  create;
  update ( features : instance );
  delete ( features : instance );

  field ( readonly ) DocNo, Status, ApprovedBy, PostedBy, ApprovalStep;

  action ( features : instance ) submit  result [1] $self;
  action ( features : instance ) approve result [1] $self;
  action ( features : instance ) reject  parameter ZA_RejectReason result [1] $self;
  action ( features : instance ) post    result [1] $self;
  action ( features : instance ) reverse parameter ZA_ReverseReason result [1] $self;

  determination setDocumentNumber on save { create; }
  validation    checkSegregation  on save { field ApprovedBy; }   " 작성자 ≠ 승인자
  validation    checkPeriodOpen   on save { field Period; }

  mapping for zpcap_doc corresponding;
}

운영 시점에 해야 할 일

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

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

대시보드에서 가장 비싼 질문은 "이 숫자 맞아?"입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 전수로 돌렸습니다. 아래는 이 사례 데이터의 결과입니다.

의도적으로 넣은 예외 15건(규칙 R01 1건 · R02 5건 · R03 3건 · R04 6건)은 능력 초과와 계획·실적 불일치 같은 점검 시나리오를 보이려고 샘플 데이터에 일부러 넣은 것이며, 위 "차이 건수"와 같은 건입니다. 나머지 대사식의 차이는 모두 0입니다. 화면 쪽은 브라우저 자동화로 따로 돌려 축을 바꿔도 합계가 변하지 않는지, 칸 금액과 드릴스루 합계가 같은지를 확인했습니다.

운영 데이터로 갈 때 — 문서가 수천만 건이면

이 사례는 원천 라인 2,834건 → 큐브 1,380행입니다. 문서가 수천만 건이 되어도 큐브 행 수는 문서 건수가 아니라 차원 조합 수를 따라갑니다 — 작업장 13곳 × 월 × 자재 × 근무조처럼 조합이 정해져 있기 때문입니다. 그래서 먼저 막히는 곳은 큐브가 아니라 원천 라인 조회입니다.

한 가지 더. 드릴스루는 집계가 아니라 조회입니다. 칸 하나에 수만 건이 매달려 있으면 그 화면이 열리지 않으므로, 건수를 먼저 세어 보고 일정 수를 넘으면 조건을 더 좁히라고 안내하는 쪽으로 설계합니다.

자주 묻는 질문

도입을 검토하는 분들이 먼저 묻는 것을 네 묶음으로 모았습니다. 답은 이 글의 사례 데이터에서 확인한 범위로만 적었습니다.

숫자와 산식

화면과 조작

분석 기능과 AI

도입과 운영