SAP 제품원가 롤업·정산 통합 관리 — 전표 승인에서 일괄 실행·대사·차이 분석까지 한 앱으로 끝내는 원가 마감

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

월 마감 때 원가팀이 받는 질문은 해마다 같습니다. 롤업은 끝났나, 누가 승인했나, 표준과 실적은 왜 어긋나나. 지금은 이 세 답이 표준 T-code 여러 개와 엑셀 대사표, 메일 승인으로 흩어져 있습니다. 산정과 확정은 표준 화면이 잘하지만, 그 앞뒤에서 사람이 손으로 잇는 일이 마감 시간을 가장 많이 씁니다.

이 앱은 그 앞뒤를 한 화면, 한 가지 숫자로 잇습니다. 롤업 전표를 작성해 승인선에 태우고, 확정한 뒤 일괄 실행으로 공통 부품 → 반제품 → 완제품 순서의 정산을 시뮬레이션부터 확인해 실행하고, 대사 규칙 4종으로 어긋난 숫자를 예외로 받아 조치하고, 같은 큐브 위에서 표준 대비 차이를 요인별로 가릅니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 승인 · 대사 · 분석의 관점을 더해 확장합니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(사업장 2개, 품목 38개, 2026년 1~9월, 원가 라인 3,445행)로 분석 화면의 차이 요인분해를 돌린 결과입니다. 표준 원가 합계는 28,087,270,500원, 실적 합계는 28,554,407,800원이라 차이는 +467,137,300원(1.7%)입니다. 표준 리포트도 여기까지는 말해 줍니다. 이 앱은 그 차이를 네 요인으로 가릅니다.

같은 데이터로 대사 규칙 4종을 돌리면 전표 144건 가운데 머리 금액과 항목 차변 합계 대사 1건, 확정 전표 대변과 원가 라인 대변 대사 2건, 품목 장부 잔액과 원가 라인 대사 4건의 차이가 나옵니다. 이 차이는 대사 화면을 확인하려고 의도적으로 심은 예외로 모두 설명되고, 그 밖의 차이는 0건입니다. 예외마다 조정 · 사유 · 보류로 처리하고 처리 기록이 남는 흐름까지 화면에서 확인했습니다.

도입하면 달라지는 것

• 마감 준비 — 전표 작성 · 승인 · 일괄 실행 · 대사가 한 화면에서 이어져 엑셀 취합과 메일 승인 확인이 줄어듭니다.
• 회의의 주제 — "어느 숫자가 맞나" 대신 "남은 예외를 어떻게 처리할까" 를 이야기합니다. 미해결 예외는 개요 카드에 건수로 보입니다.
• 책임 소재 — 누가 만들고 누가 승인했는지가 전표마다 상태 이력에 남아 사후에 찾을 일이 줄어듭니다.
• 중복과 누락 — 시뮬레이션과 중복 실행 거절로 같은 롤업이 두 번 만들어지는 일이 구조적으로 막힙니다.
• 감사 대응 — 확정한 전표는 지우지 않고 역처리 문서로 되돌려 원본과 취소 내역이 함께 남습니다.

이런 회사에 맞습니다

공통 부품 → 반제품 → 완제품 단계로 원가를 정산하는 제조업에 맞습니다. 사업장이 둘 이상이고, 월 수백 건의 롤업 · 조정 전표를 작성자와 승인자를 나눠 처리하며, 금액 구간별로 승인 단계가 달라지는 조직이라면 효과가 큽니다. 담당은 원가 · 관리회계팀(작성), 원가 책임자(승인), 재무 책임자(대사 확인)이고, 표준 화면은 그대로 두고 승인 · 대사 · 분석만 이 화면으로 모으려는 경영지원 조직에 어울립니다. 반대로 월 처리 건수가 수십 건 이하이고 승인선이 없다면 표준 화면과 엑셀로도 충분합니다.

실행 화면

아래 화면 42종은 검증용 샘플 데이터로 앱을 실제로 실행해 찍은 캡처입니다. 순서는 처음 열었을 때 → 기준정보 → 문서 처리 → 일괄 실행 → 대사 → 분석 → 연계 · 감사 → 레이아웃과 좁은 화면입니다. 사용 방법과 구성, 화면별 설명, 그 뒤에서 일어나는 판정과 조회조건을 차례로 적었습니다.

사용 방법

1. 사용자 고르기 — 오른쪽 위에서 조회자 · 처리자 · 승인자 · 관리자 중 하나를 고릅니다. 역할에 따라 버튼이 켜지고 꺼집니다(데모용이며 운영에서는 SAP 권한으로 바뀝니다).
2. 개요에서 시작 — 잔액이 남은 품목, 승인 대기 문서, 대사 예외와 내 할 일을 카드로 확인하고 숫자를 눌러 해당 목록으로 이동합니다.
3. 조회조건 입력 — 각 화면 위쪽에서 사업장 · 기간 · 상태 등을 정합니다. 필수 조건은 일괄 실행과 분석에만 있고, 나머지는 비워 두면 전체입니다.
4. 조회 버튼 또는 Enter — 조회 버튼은 필터 영역 오른쪽 위에 있습니다. 분석은 들어올 때 자동 조회하지 않고 조회를 눌러야 합니다.
5. 전표 작성과 검토 요청 — 문서 처리에서 생성을 눌러 사업장 · 기간 · 보내는 품목을 입력하면 받는 품목과 금액을 서버가 롤업 규칙으로 계산합니다. 여러 건은 엑셀 업로드로 한 번에 올립니다.
6. 승인과 확정 — 승인자가 승인하거나 반려합니다. 5,000,000원 이상은 서로 다른 승인자 2명이 필요합니다. 승인된 문서를 확정하면 원가 라인과 품목 장부 잔액에 반영됩니다.
7. 일괄 실행 — 사업장 · 대상 기간 · 실행 유형을 고르고 시뮬레이션으로 먼저 결과를 본 뒤 실행합니다. 시뮬레이션하지 않은 조건으로는 실행되지 않습니다.
8. 대사와 예외 조치 — 대사 실행으로 규칙 4종을 한 번에 검사하고, 차이가 난 예외는 행을 선택해 조정 · 사유 · 보류 중 하나로 처리합니다.
9. 분석 탭 · 축 이동 — 차원을 끌어 행과 열을 바꾸고, 금액 칸을 눌러 원천 라인을 열며, 비교 기준을 켜면 차이와 요인분해가 나옵니다.
10. 행 · 셀 상세와 내려받기 — 목록의 행을 누르면 상세가 열리고 상태 이력 · 연계 문서가 함께 보입니다. 목록과 분석 표는 CSV · xlsx 로, 분석 보고서는 PowerPoint 로 내려받으며 현재 화면의 필터가 반영됩니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤로, 데이터는 OData V2 모델 하나로 연결했습니다. 서비스 주소를 바꾸면 같은 화면이 운영 서비스에 그대로 붙도록 모델 설정 수준에서만 서비스에 의존합니다.

처음 열었을 때 — 잔액과 할 일이 먼저 보인다

첫 화면은 조회 조건을 묻기 전에 해야 할 일부터 보여 줍니다. 처리자 · 승인자 · 관리자가 열자마자 자기 몫을 확인하게 하려는 구성입니다.

카드는 위에서부터 미정산 잔액, 승인 대기, 반려, 확정, 미해결 대사 예외 순서입니다. 숫자를 누르면 해당 목록이 필터가 걸린 채 열립니다. 기간은 2026년 1~9월이 기본이고 사업장은 전체입니다. 아래쪽 "내 할 일" 은 로그인한 역할 기준으로 달라집니다.

기준정보 관리 — 롤업 순서와 규칙이 숫자의 뼈대다

롤업이 어느 순서로 누구의 잔액을 누구에게 넘기는지는 기준정보가 정합니다. 문서와 일괄 실행, 대사가 모두 이 값을 읽습니다.

품목 38개가 유형(공통 부품 6 · 반제품 10 · 완제품 22)과 롤업 순서와 함께 나옵니다. 롤업 순서 1 → 2 → 9 가 일괄 실행의 처리 순서가 됩니다. 장부 잔액 열은 원가 라인의 잔액 합계와 같아야 하며, 다르면 대사 규칙 R03 이 예외로 올립니다.

원가요소 12개가 재료비 · 노무비 · 외주가공비 · 제조경비 · 기타 원가 다섯 그룹으로 묶여 있고 변동 · 고정 행태가 붙어 있습니다. 요인분해의 재료비 · 노무비 · 제조경비 단가 요인이 이 그룹을 기준으로 갈립니다. 변경은 관리자 역할만 할 수 있습니다.

롤업 규칙 74건이 "어느 품목의 잔액을 어느 품목에 얼마씩 넘기는가" 를 정합니다. 구동 기준과 가중치가 규칙마다 있고, 시뮬레이션과 일괄 실행이 이 표를 그대로 읽습니다. 규칙을 바꾸면 다음 시뮬레이션부터 반영됩니다.

관리자 역할에서만 생성 버튼이 켜집니다. 필수 항목을 비우면 저장되지 않으며, 같은 사업장에 같은 이름의 사용 중 품목이 있으면 저장 전에 서버가 거절합니다. 삭제는 없고 사용 중지 표시로 처리해 이력이 남습니다.

문서 처리와 승인 — 작성에서 확정까지

상태는 정해진 길로만 넘어갑니다. 화면 버튼은 서비스가 돌려주는 판정을 따르므로 같은 규칙이 업로드와 일괄 실행에도 똑같이 적용됩니다.

왼쪽 목록은 문서 번호 · 유형(롤업 · 재분류 · 조정) · 상태 · 사업장 · 기간으로 거릅니다. 행을 누르면 오른쪽에 상세가 열립니다. 상태 칩의 색은 10 임시저장 · 20 검토요청 · 30 승인 · 40 확정 · 90 반려 · 99 취소를 구분합니다.

임시저장(10) 문서는 항목 · 상태 이력 · 연계 문서 · 감사 로그를 탭으로 봅니다. 차변과 대변 합계가 같아야 검토를 요청할 수 있으며, 처리자 역할에서는 승인 버튼이 켜지지 않고, 승인자 역할로 바꿔야 승인할 수 있습니다.

사업장 · 기간 · 보내는 품목만 정하면 받는 품목과 금액은 서버가 롤업 규칙으로 계산합니다. 사람이 금액을 입력하지 않는 구조라 대변이 어긋날 자리가 없습니다. 저장하면 임시저장(10) 문서가 되고 문서 번호가 채번됩니다.

필수 항목을 비우면 저장 전에 어느 항목인지 알려 줍니다. 같은 사업장 · 기간 · 품목의 롤업 전표가 이미 있으면 화면이 아니라 서버가 거절하고 그 사유를 그대로 보여 줍니다. 거절된 입력은 저장되지 않습니다.

양식을 내려받아 채운 xlsx 를 올리면 서버가 형식과 규칙을 먼저 검사합니다. 아직 문서를 만들지 않는 단계라 파일을 잘못 올려도 데이터가 바뀌지 않습니다. 양식의 필수 열과 허용 값은 같은 창에 표로 보입니다.

행별로 검사 통과 · 확인 필요가 나뉘어 표시됩니다. 확인 필요 행에는 이유(품목 없음 · 기간 형식 오류 등)가 붙습니다. 행별 결과를 보고 반영 여부를 정하며, 반영하기 전에는 어떤 전표도 만들어지지 않습니다.

반영을 누르면 서버가 같은 규칙으로 다시 검사해 전표를 만듭니다. 미리보기에서 통과했어도 그사이 같은 기간 전표가 생겼다면 서버가 거절하고 행마다 사유를 남깁니다. 만들어진 문서는 모두 임시저장(10)에서 시작합니다.

처리자가 검토를 요청하면 문서가 검토요청(20)이 되고 승인자의 할 일이 생깁니다. 요청 시점의 차변 · 대변 합계가 다시 검사되며, 맞지 않으면 요청이 거절됩니다. 요청 메모는 상태 이력에 함께 남습니다.

5,000,000원 이상 문서는 승인이 두 번 필요합니다. 첫 승인 뒤에도 상태는 검토요청(20)에 머물고 승인 단계가 "1 / 2" 로 표시됩니다. 같은 사람이 두 번 승인하는 것도 서버가 막습니다.

첫 번째와 다른 승인자가 승인하면 승인(30)으로 넘어갑니다. 작성자가 자기 문서를 승인하려 하면 버튼이 꺼져 있을 뿐 아니라 서버도 같은 판정으로 거절합니다. 반려할 때는 사유가 필수이며 작성자에게 할 일이 생깁니다.

확정(전기)을 누르면 문서가 확정(40)이 되고 원가 라인과 품목 장부 잔액에 반영됩니다. 마감된 기간의 문서는 확정이 거절됩니다. 확정 뒤 품목 기준정보의 장부 잔액이 바로 달라지는 것으로 반영 여부를 확인합니다.

상태 이력 · 연계 문서 · 취소 — 지우지 않고 되돌린다

확정한 전표는 지우지 않습니다. 취소하면 부호가 반대인 역처리 문서가 만들어지고, 그 연결이 이력과 연계 문서에 모두 남습니다.

작성부터 확정까지 누가 언제 어떤 동작으로 상태를 바꿨는지 순서대로 쌓입니다. 메모와 반려 사유도 같은 줄에 붙습니다. 이력은 읽기 전용이어서 지우거나 고칠 수 없습니다.

원본 문서와 역처리 문서, 일괄 실행으로 만든 문서가 서로 연결되어 보입니다. 문서 번호를 누르면 해당 문서로 바로 이동합니다. 취소한 원본을 찾으려고 목록을 다시 거를 필요가 없습니다.

확정한 전표를 취소하면 사유를 적게 하고, 부호가 반대인 역처리 문서(RV)를 만들어 연결합니다. 원본은 지워지지 않고 취소(99)로 남습니다. 마감된 기간의 문서는 역처리할 수 없습니다.

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

실행 전에 만들어질 전표를 먼저 계산해 식별 값을 받고, 같은 조건일 때만 실행합니다. 실행 합계가 시뮬레이션과 다르면 중단합니다.

일괄 실행 17건이 유형 · 기간 · 상태 · 전표 수 · 금액과 함께 나옵니다. 행을 누르면 건별 로그 170행 가운데 해당 실행의 로그가 열립니다. 실행 이력은 시뮬레이션 식별 값과 함께 남아 같은 조건의 재실행을 가려내는 근거가 됩니다.

사업장 · 대상 기간 · 실행 유형을 고르고 시뮬레이션하면 만들어질 전표가 표로 나옵니다. 잔액이 없어 제외되는 품목도 이유와 함께 보입니다. 이 단계에서는 어떤 데이터도 바뀌지 않습니다.

실행을 누르면 시뮬레이션 결과 그대로 실행할지 한 번 더 묻습니다. 확인 창에는 전표 수와 금액이 다시 적혀 있어 조건이 바뀌지 않았는지 눈으로 확인할 수 있습니다. 시뮬레이션 없이 직접 실행하는 경로는 없습니다.

롤업 전표가 공통 부품 → 반제품 → 완제품 순서로 만들어지고 실행 이력에 한 건이 쌓입니다. 실행 합계가 시뮬레이션 합계와 다르면 실행이 중단되고 로그에 남습니다. 만들어진 문서는 연계 문서로 이어집니다.

이미 실행한 시뮬레이션을 다시 실행하면 서버가 거절합니다. 같은 롤업이 두 번 만들어지는 것을 막는 장치이며, 화면을 새로 고쳐도 마찬가지입니다.

대사와 예외 조치 — 어긋난 숫자는 예외로 올라온다

규칙 4종이 전표 · 원가 라인 · 품목 잔액 · 롤업 뒤 잔액을 서로 맞춰 봅니다. 허용 오차 1원을 넘는 차이만 예외가 되고, 조치는 기록에 남습니다.

규칙 R01~R04 별로 검사 건수와 차이 건수, 최대 차이가 한 줄씩 나옵니다. 아래 예외 목록은 상태(미해결 · 처리 완료)로 거를 수 있습니다. 샘플 데이터에는 대사 화면을 확인하려고 예외 14건을 일부러 심어 두었고 그중 9건이 미해결입니다.

대사 실행을 누르면 규칙 4종을 한 번에 다시 검사하고 결과를 쌓습니다. 허용 오차는 규칙마다 1원이며, 그 안의 차이는 예외로 올라오지 않습니다. 실행할 때마다 검사 시각이 남아 이력으로 비교할 수 있습니다.

예외를 선택하면 왼쪽 값과 오른쪽 값, 차이, 대상 문서가 나옵니다. 어느 규칙이 어느 문서에서 어긋났는지가 보이므로 대상 문서 열기로 바로 원인 문서를 확인합니다. 이미 처리된 예외는 조치 버튼이 꺼집니다.

조정(정정 전표 연결) · 사유 기록 · 보류 중에서 정합니다. 조정은 열린 기간에서만 가능하며 마감 기간은 사유나 보류로만 처리합니다. 어떤 조치를 했는지가 감사 기록에 남습니다.

분석 — 합계가 같은 피벗, 칸에서 원천 라인까지

분석 화면의 모든 축은 같은 큐브에서 나옵니다. 그래서 축을 바꿔도 합계가 변하지 않고, 칸을 누르면 그 금액을 만든 원가 라인까지 내려갑니다.

기간과 품목 그룹 · 품목을 행과 열에 놓고 투입 실제원가 · 롤업 수신 · 롤업 송신 · 잔액 등 지표를 봅니다. 모든 축이 같은 큐브에서 나오므로 축을 바꿔도 합계가 변하지 않습니다. 행↔열 바꾸기는 서비스를 다시 부르지 않고 화면에서 재배치합니다.

품목 · 유형 · 그룹 · 원가요소 · 행태로 범위를 좁힙니다. 여러 값을 한꺼번에 고를 수 있고, 걸린 필터 개수가 버튼에 표시됩니다. 필터는 서버 질의에 반영되어 큐브 합계도 함께 달라집니다.

금액 칸을 누르면 그 칸에 들어간 원가 라인이 열리고 건수와 합계가 위에 나옵니다. 라인 합계가 칸 금액과 같은지 화면이 검산해 일치 여부를 표시합니다.

비교 기준을 표준으로 두면 칸마다 차이와 증감률이 붙고 오른쪽에 폭포 차트가 나옵니다. 표준 28,087,270,500원에서 실적 28,554,407,800원까지의 흐름이 요인별로 보입니다.

총차이 +467,137,300원을 생산 수량 · 재료비 단가 · 노무비 단가 · 제조경비 단가 네 요인으로 가릅니다. 가장 큰 요인은 생산 수량(+379,894,286원)입니다. 맨 아래 검산 줄이 요인 합과 총차이의 차이를 매번 0 으로 확인합니다.

경영진 · 생산 책임자 · 원가 책임자 · 재무 책임자 관점으로 같은 숫자를 다시 묶어 보여 줍니다. 새로운 계산이 아니라 같은 큐브의 다른 단면입니다.

AI 해설과 에이전트 — 숫자는 서비스가, 설명은 모델이

AI 해설은 숫자를 만들지 않습니다. 서비스가 계산한 근거 표를 읽어 요약만 하므로 모델을 꺼도 같은 숫자의 규칙 기반 해설이 나옵니다.

AI 해설은 서비스가 계산한 근거 표의 값을 읽어 요약합니다. 모델이 숫자를 새로 만들지 않으며, 원인은 "확인 필요" 로만 적습니다. 같은 범위를 표와 차트가 담긴 PowerPoint 보고서로 내려받을 수 있습니다.

감시 규칙 5개를 평가해 기준을 넘는 항목을 보고 대기함에 올립니다. 규칙마다 받을 역할이 붙어 있고, 같은 규칙은 하루에 한 번만 판정합니다. 판단과 조치는 사람이 하며, 에이전트는 올리기까지만 합니다.

영역 간 연계 — 앞뒤 문서를 따라간다

롤업 전표만 따로 보지 않고 그 앞뒤로 이어지는 문서를 같은 화면에서 따라갑니다.

롤업 전표에서 이어지는 앞뒤 문서를 따라갑니다. 생산 · 재무 · 손익 쪽 후속 문서가 영역과 금액, 일자와 함께 나오며 문서 번호를 누르면 해당 문서로 이동합니다. 실제 환경에서는 이 자리가 문서 흐름 키로 연결됩니다.

이력 · 감사 · 역할 — 승인 버튼은 승인자에게만 보인다

누가 무엇을 했는지는 감사 기록이, 누가 무엇을 할 수 있는지는 역할이 정합니다. 화면을 가리는 데서 끝나지 않고 서버가 같은 판정으로 거절합니다.

누가 언제 무엇을 했는지가 시각 · 사용자 · 역할 · 동작 · 대상 · 변경 전후 · 결과로 나옵니다. 거절된 요청도 결과 열에 남아 시도 자체를 추적할 수 있습니다. 같은 화면에서 역할별 권한 표를 봅니다.

조회자 역할에서는 생성 버튼이 꺼지고 처리 버튼이 보이지 않습니다. 화면을 우회해 요청을 보내도 서버가 같은 판정으로 거절하며 그 시도도 감사 기록에 남습니다. 운영에서는 이 역할 구분이 SAP 권한 객체로 대체됩니다.

레이아웃과 좁은 화면 — 저장한 배치와 휴대폰

분석 배치는 이름을 붙여 저장해 두면 다음에도 그 배치로 시작합니다. 휴대폰에서는 같은 순서의 화면이 세로로 쌓입니다.

행 · 열 배치와 필터, 지표를 이름을 붙여 저장하고 다시 불러옵니다. 저장한 레이아웃은 사용자별로 서비스에 남아 다음에 불러올 수 있습니다.

좁은 화면에서는 카드가 세로로 쌓이고 메뉴가 접힙니다. 숫자와 순서는 넓은 화면과 같고 배치만 바뀝니다. 휴대폰에서도 승인 대기 건수를 확인하고 해당 목록으로 이동할 수 있습니다.

목록과 상세가 한 화면씩 번갈아 열립니다. 목록에서 행을 누르면 상세로, 뒤로 가기를 누르면 목록으로 돌아옵니다. 승인 같은 처리 버튼은 상세 화면 아래에서 같은 규칙으로 켜지고 꺼집니다.

화면 뒤에서 일어나는 일 — 처리 단계

업무 흐름은 롤업 전표(임시저장) → 검토 요청 → 승인 → 확정(원가 라인 반영) → 일괄 실행 결과 → 대사 → 분석 순서입니다. 각 단계가 SAP 데이터의 어느 지점에 닿는지 아래에 정리했습니다.

문서 상태 판정 — 다음 상태로 넘어가는 조건

문서는 아래 규칙으로만 다음 상태로 넘어갑니다. 서비스가 역할과 조건을 판정하며 화면 버튼은 그 결과를 따릅니다.

일괄 실행의 판정

대사 규칙 4종

규칙마다 허용 오차는 1원이며, 그 안의 차이는 예외로 올라오지 않습니다.

차이 요인분해

기준(표준) 대비 총차이를 네 요인으로 나눕니다. 네 요인의 합이 총차이(실적 − 표준)와 같아야 하며 어긋나면 검산 표시가 오류로 바뀝니다. 검증용 샘플 데이터(2026년 1~9월)의 결과는 다음과 같습니다.

대사식

• 품목 잔액 = 투입 실제원가 + 롤업 수신 − 롤업 송신
• 롤업 균형 = 롤업 수신 합계 = 롤업 송신 합계 (롤업 뒤 반제품 · 공통 부품 잔액 0)
• 큐브 검산 = 큐브 지표 합계 = 원천 라인 합계 (지표 7개 모두)
• 요인 검산 = 네 요인의 합 = 실적 − 표준
• 드릴스루 검산 = 칸 금액 = 칸 안 원천 라인 합계

조회조건

조회 버튼은 필터 영역 오른쪽 위에 있고 Enter 로도 조회됩니다. 조건은 서버 질의($filter)로 넘어갑니다.

결과 컬럼

분석 지표

좁은 화면에서 달라지는 것

• 카드 · 목록 · 상세가 두 열에서 한 열로 바뀌고, 왼쪽 메뉴는 접힙니다.
• 문서 처리는 목록과 상세가 한 화면씩 번갈아 열립니다. 상세에서 뒤로 가면 목록으로 돌아옵니다.
• 분석의 피벗은 가로로 넓은 표라 좁은 화면에서는 좌우로 밀어 봅니다. 열 조합이 지나치게 많으면 그리지 않고 안내만 띄웁니다.
• 처리 버튼의 켜짐 · 꺼짐 규칙은 넓은 화면과 같습니다. 서버 판정이 같기 때문입니다.

파일 구성

앱 본체는 샘플 데이터를 참조하지 않으며, 운영에서는 서비스 주소만 바꾸면 됩니다.

(앱 폴더)
├─ index.html          앱 진입점
├─ readme.html         설명서
├─ manifest.json       서비스 · 모델 · 라우팅 선언
├─ Component.js
├─ controller/         화면별 컨트롤러
├─ view/               XML 뷰 (view/fragments/ 대화상자)
├─ model/              화면 모델 · 서비스 호출 래퍼
├─ css/  i18n/
├─ media/              소개 영상 · 포스터
└─ odata/              메타데이터 · 서비스 구현 · 엔티티셋별 샘플 데이터

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 표준을 대체하거나 다시 만든 것이 아니라 표준 데이터 구조를 그대로 이어받아 그 앞뒤의 승인 · 대사 · 분석을 한 곳에 모은 구성입니다.

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

T-code 별 연계 지점

운영 전환 때 기존 리포트와 표준 화면을 없애야 하나요? 아닙니다. 표준 거래는 그대로 두고, 월 마감 점검 순서에서 승인 · 대사 · 분석 단계만 이 화면으로 옮깁니다. 법정 · 감사 · 세무 대응에 쓰는 보고서는 계속 표준에서 만들고, 이 앱의 숫자와 맞춰 보는 절차(대사)를 운영 체크리스트에 추가합니다.

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

이 앱의 분석은 CDS 큐브와 분석 쿼리 위에 올리는 것을 전제로 합니다. 같은 쿼리를 Fiori 분석 앱이나 Analysis for Office 에서 열면 화면은 다르지만 숫자는 같습니다.

이 앱이 더하는 것은 업무 처리(승인 · 일괄 실행 · 예외 조치)와 차이 요인분해 · 에이전트입니다. 조회 전용 분석은 표준 분석 스택으로도 충분하므로 둘을 대체 관계로 보지 않고, 같은 CDS 를 공유하는 두 개의 창으로 봅니다.

표준 Fiori 분석 앱의 정확한 이름과 제공 범위는 시스템 버전에 따라 달라 이 글에서는 특정하지 않습니다. 도입 때 대상 시스템에서 확인해 연결 대상을 정합니다.

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

분석 지표 정의표

CDS 구성 — 코드와 운영 작업

화면이 읽는 숫자는 CDS 뷰에서 만들어집니다. 아래는 기준 → 차원 → 큐브 → 쿼리 → 권한 → 서비스 순서로 나눈 구성과 각 객체의 코드입니다. 이름은 기능을 뜻하는 예시이며 운영에서는 회사 명명 규칙에 맞춥니다.

뷰 레이어 구성

① 계정 → 원가 라인 종류 매핑 테이블

리포트의 모든 숫자가 이 표에서 갈립니다. 어느 계정을 투입 실제원가로 보고 어느 계정을 롤업 수신 · 송신으로 볼지를 정하는 자리라 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 계정 체계가 중간에 바뀌어도 과거 기간의 숫자가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZPCR_ACCTMAP — 계정 → 원가 라인 종류 매핑 (투명 테이블)
"  ACT  : 투입 실제원가   RIN : 롤업 수신   ROUT : 롤업 송신
"  코드에 박지 않는 이유 : 계정은 늘어나는데 늘 때마다
"  개발자를 부르면 리포트가 금방 낡는다. 고객 유지 테이블로 둔다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '원가 라인 계정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpcr_acctmap {
  key mandt      : mandt not null;
  key ktopl      : ktopl not null;        " 계정과목표
  key saknr      : saknr not null;        " 계정
  key valid_from : datab not null;        " 유효 시작 — 체계 변경 시 새 행을 추가
  valid_to       : datbi;
  line_kind      : abap.char(4) not null; " ACT / RIN / ROUT
  comp_group     : abap.char(2);          " 재료비 MA · 노무비 LA · 외주 OS · 경비 OH · 기타 ET
  behavior       : abap.char(1);          " V 변동 · F 고정
}

② 롤업 규칙 테이블

보내는 품목의 잔액을 받는 품목에 얼마씩 넘길지를 정하는 규칙입니다. 시뮬레이션과 일괄 실행, 그리고 대사 규칙 R04 가 모두 이 표를 읽습니다. 구동 기준과 가중치를 컬럼으로 둔 이유는 품목마다 배부 기준(생산 수량 · 사용 수량 등)이 달라지기 때문입니다.

" ────────────────────────────────────────────────────────────────
"  ZPCR_ROLLRULE — 롤업 규칙 (보내는 품목 → 받는 품목)
"  rollseq 는 보내는 품목의 롤업 순서 : 공통 부품 1 → 반제품 2 → 완제품 9
"  같은 보내는 품목의 weight 합이 1 이 되도록 입력 검사를 둔다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '롤업 규칙'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpcr_rollrule {
  key mandt     : mandt not null;
  key werks     : werks_d not null;       " 사업장
  key rule_id   : abap.char(8) not null;
  from_matnr    : matnr not null;         " 보내는 품목
  to_matnr      : matnr not null;         " 받는 품목
  drive_basis   : abap.char(2);           " QT 생산 수량 · UQ 사용 수량 · FX 고정 비율
  weight        : abap.dec(7,4);          " 배부 가중치
  rollseq       : abap.numc(1);
  active        : abap_boolean;
}

③ 차원 뷰 — 품목

품목은 모든 큐브가 함께 쓰는 차원입니다. 품목 유형(공통 부품 · 반제품 · 완제품)은 MARA 의 자재 유형을 이 앱의 말로 바꾼 값이고, 롤업 순서는 규칙 테이블에서 가져옵니다. 이름은 언어에 맞는 텍스트를 association 으로 붙여 큐브 쪽에서 조인하지 않게 했습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_RollProduct — 품목 차원
"  자재 유형 → 품목 유형 변환은 case 로 한다. 새 자재 유형이 생기면
"  여기 한 곳만 고친다. (운영에서는 매핑 테이블로 빼도 된다)
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '롤업 품목 차원'
@ObjectModel.representativeKey       : 'Product'
@Analytics.dataCategory              : #DIMENSION
@Metadata.ignorePropagatedAnnotations: true
define view entity ZI_RollProduct
  as select from mara as m
  association [0..*] to makt as _Text on  _Text.matnr = $projection.Product
  association [0..1] to zpcr_rollrule as _Rule on  _Rule.from_matnr = $projection.Product
                                               and _Rule.active     = 'X'
{
  @ObjectModel.text.association: '_Text'
  key m.matnr                         as Product,
      m.mtart                         as MaterialType,
      case m.mtart
        when 'ROH' then 'CP'          " 공통 부품
        when 'HALB' then 'SF'         " 반제품
        when 'FERT' then 'FG'         " 완제품
        else 'ET'
      end                             as ProductType,
      m.matkl                         as ProductGroup,
      m.meins                         as BaseUnit,
      _Rule.rollseq                   as RollSeq,
      _Text
}

④ 실적 큐브 — ACDOCA 원가 라인

원천은 ACDOCA 입니다. 계정 매핑으로 투입 · 수신 · 송신을 가르고, 투입 + 수신 − 송신을 잔액 지표로 산출합니다. 드릴스루는 이 뷰를 그대로 읽습니다 — 집계 뷰를 따로 두면 칸 금액과 라인 합계가 어긋날 수 있기 때문입니다. 통화 금액에는 통화 코드를 반드시 붙여야 합계가 틀리지 않습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_RollCostLine — 원가 라인 큐브 (ACDOCA 기반)
"  ACT / RIN / ROUT 은 매핑 테이블 기준. 잔액 BAL = ACT + RIN - ROUT.
"  롤업 송신 계정은 대변(음수)으로 쌓이므로 부호를 맞춰 더한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '롤업 원가 라인 큐브'
@Analytics.dataCategory              : #CUBE
@Metadata.ignorePropagatedAnnotations: true
define view entity ZI_RollCostLine
  as select from acdoca as a
    inner join zpcr_acctmap as m on  m.ktopl = 'YCOA'
                                 and m.saknr = a.racct
                                 and a.budat between m.valid_from and m.valid_to
  association [1..1] to ZI_RollProduct as _Product on _Product.Product = $projection.Product
{
  key a.rldnr                         as Ledger,
  key a.rbukrs                        as CompanyCode,
  key a.gjahr                         as FiscalYear,
  key a.belnr                         as AccountingDocument,
  key a.docln                         as LedgerLine,
      a.poper                         as FiscalPeriod,
      a.werks                         as Plant,
      a.matnr                         as Product,
      a.racct                         as CostElement,
      m.line_kind                     as LineKind,
      m.comp_group                    as CompGroup,
      m.behavior                      as Behavior,
      @Semantics.currencyCode: true
      a.rhcur                         as Currency,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      case m.line_kind when 'ACT'  then a.hsl else cast( 0 as abap.curr(23,2) ) end as ActAmount,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      case m.line_kind when 'RIN'  then a.hsl else cast( 0 as abap.curr(23,2) ) end as RollInAmount,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      case m.line_kind when 'ROUT' then a.hsl else cast( 0 as abap.curr(23,2) ) end as RollOutAmount,
      @DefaultAggregation: #SUM
      @Semantics.quantity.unitOfMeasure: 'BaseUnit'
      a.msl                           as Quantity,
      @Semantics.unitOfMeasure: true
      a.runit                         as BaseUnit,
      _Product
}

⑤ 표준 원가 계획 뷰

차이를 만들려면 비교 기준이 실적과 같은 차원 구조여야 합니다. 확정 표준원가의 구성(원가요소 그룹별 금액)을 KEKO · KEPH 에서 읽어 품목 · 기간 · 원가요소 그룹으로 맞췄습니다. 어느 원가 산정 버전을 표준으로 볼지(산정 변형 · 평가 변형)는 도입에서 가장 먼저 걸리는 질문이라 파라미터가 아니라 조건으로 박아 두지 않았습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_StdCostPlan — 확정 표준원가 구성 (KEKO / KEPH)
"  kadky 기준일의 확정 산정(freig = 'X')만 읽는다.
"  산정 변형(klvar)·평가 변형은 운영에서 합의한 값으로 교체한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '표준 원가 계획'
@Analytics.dataCategory              : #CUBE
define view entity ZI_StdCostPlan
  as select from keko as h
    inner join keph as p on  p.kalnr = h.kalnr
                         and p.kalka = h.kalka
                         and p.kadky = h.kadky
                         and p.tvers = h.tvers
{
  key h.kalnr                         as CostEstimate,
  key h.kadky                         as CostingDate,
      h.matnr                         as Product,
      h.werks                         as Plant,
      h.klvar                         as CostingVariant,
      @Semantics.currencyCode: true
      h.hwaer                         as Currency,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      p.kst001 + p.kst003 + p.kst005  as StdMaterial,   " 재료비 구성 (예시 — 구성 컬럼은 시스템 설정에 맞춘다)
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      p.kst002 + p.kst004             as StdLabor        " 노무비 구성 (예시)
}
where h.freig = 'X' 

⑥ 통합 큐브 — 실적 + 표준 + 차이

차이를 화면에서 빼면 화면마다 산식이 달라집니다. 그래서 실적과 표준을 같은 차원으로 합치고 차이는 이 뷰에서 한 번만 정의합니다. 네 요인으로 가르는 계산은 수량과 단가가 필요해 서비스(분해 동작)에서 하고, 이 큐브는 총차이까지를 책임집니다.

" ────────────────────────────────────────────────────────────────
"  ZI_RollCostCube — 실적(ACT) vs 표준(STD) 통합 큐브
"  실적과 표준은 같은 차원(기간·사업장·품목)으로 맞춘 뒤 union 한다.
"  차이 Variance = Actual - Standard 는 쿼리의 계산 지표에서 정의한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '롤업 원가 통합 큐브'
@Analytics.dataCategory              : #CUBE
define view entity ZI_RollCostCube
  as select from ZI_RollCostLine
{
  key Ledger, key CompanyCode, key FiscalYear, key AccountingDocument, key LedgerLine,
      FiscalPeriod, Plant, Product, CompGroup, Behavior, Currency,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      ActAmount   as Actual,
      @DefaultAggregation: #SUM
      cast( 0 as abap.curr(23,2) ) as Standard
}
union all
  select from ZI_StdCostPlan
{
  key cast( '0L' as fins_ledger )     as Ledger,
  key cast( '' as bukrs )             as CompanyCode,
  key cast( substring( CostingDate, 1, 4 ) as gjahr ) as FiscalYear,
  key CostEstimate                    as AccountingDocument,
  key cast( 0 as docln )              as LedgerLine,
      cast( substring( CostingDate, 5, 2 ) as poper ) as FiscalPeriod,
      Plant, Product,
      cast( '' as abap.char(2) )      as CompGroup,
      cast( '' as abap.char(1) )      as Behavior,
      Currency,
      cast( 0 as abap.curr(23,2) )    as Actual,
      StdMaterial + StdLabor          as Standard
}

⑦ 분석 쿼리

쿼리는 행 · 열 축의 기본 배치와 계산 지표만 정의합니다. 같은 쿼리를 표준 Fiori 분석 앱과 Analysis for Office 가 그대로 띄우므로, 이 앱의 숫자와 표준 분석 도구의 숫자를 나란히 놓고 맞춰 볼 수 있습니다. 필터 필수화(@Consumption.filter.mandatory)는 운영 데이터가 클 때 응답 시간을 지키는 첫 장치입니다.

" ────────────────────────────────────────────────────────────────
"  ZC_RollCostQuery — 분석 쿼리 (Consumption)
"  기간은 필수 필터로 두어 전량 집계를 막는다.
"  행: 품목 그룹 › 품목   열: 회계기간   지표: 표준·실적·차이·롤업률
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label               : '롤업 원가 분석 쿼리'
@Analytics.query                 : true
@Metadata.ignorePropagatedAnnotations: true
define view entity ZC_RollCostQuery
  as select from ZI_RollCostCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @AnalyticsDetails.query.displayHierarchy: #ON
  ProductGroup,
  @AnalyticsDetails.query.axis: #ROWS
  Product,
  @AnalyticsDetails.query.axis: #COLUMNS
  @Consumption.filter: { selectionType: #INTERVAL, multipleSelections: false, mandatory: true }
  FiscalPeriod,
  @Consumption.filter.selectionType: #SINGLE
  Plant,

  @AnalyticsDetails.query.axis: #COLUMNS
  @EndUserText.label: '표준 원가'
  Standard,
  @AnalyticsDetails.query.axis: #COLUMNS
  @EndUserText.label: '실적 투입 원가'
  Actual,
  @AnalyticsDetails.query.axis: #COLUMNS
  @EndUserText.label: '차이 (실적 - 표준)'
  @AnalyticsDetails.query.formula: 'Actual - Standard'
  cast( 0 as abap.curr(23,2) ) as Variance
}

⑧ 권한 — DCL

권한은 집계를 읽는 자리에 걸어야 합니다. 드릴스루 뷰에만 걸면 전사 합계에서 자기 몫을 뺀 값으로 남의 숫자를 알아낼 수 있기 때문입니다. 데모의 4개 역할(조회자 · 처리자 · 승인자 · 관리자)은 활동 구분(actvt)으로 옮깁니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ROLLCOSTCUBE — 통합 큐브 접근 제어
"  회사코드(bukrs)와 사업장(werks)을 PFCG 권한 객체로 건다.
"  actvt 03 조회 / 02 변경(처리) — 승인·확정은 별도 권한 객체로 분리한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '롤업 원가 통합 큐브 권한'
@MappingRole: true
define role ZI_ROLLCOSTCUBE {
  grant select on ZI_RollCostCube
    where ( CompanyCode, Plant ) =
          aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
      and Plant =
          aspect pfcg_auth( M_MSEG_WWE, WERKS, ACTVT = '03' );
}

⑨ 서비스 정의와 동작(RAP)

화면은 서비스 계약만 압니다. 조회는 쿼리와 큐브를 노출하고, 승인 · 확정 · 역처리 · 일괄 실행은 동작(action)으로 둡니다. 작성자 ≠ 승인자, 5,000,000원 2단계, 마감 기간 거절 같은 판정은 동작의 검증 안에서 하므로 화면을 우회해도 같은 결과가 나옵니다. 아래 코드는 구성의 뼈대이며 운영에서는 문서 번호 범위와 영역 간 연계 키에 맞춰 채웁니다.

" ────────────────────────────────────────────────────────────────
"  ZUI_RollCost — 서비스 정의 + 동작 정의(뼈대)
"  Service Binding 을 OData V2 로 게시하면 화면의 모델 설정에서
"  서비스 주소만 교체하면 된다. 활성화는 /IWFND/MAINT_SERVICE 또는
"  Service Binding 의 Publish 로 한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label: '롤업 원가 서비스'
define service ZUI_RollCost {
  expose ZC_RollCostQuery   as CostQuery;
  expose ZI_RollCostLine    as CostLine;
  expose ZI_RollProduct     as Product;
}

managed implementation in class zbp_i_rolldoc unique;
strict ( 2 );
define behavior for ZI_RollDoc alias RollDoc
persistent table zpcr_rolldoc
lock master
authorization master ( instance )
{
  create; update; delete;
  action ( features : instance ) submit  result [1] $self;     " 검토 요청
  action ( features : instance ) approve result [1] $self;     " 승인 — 작성자 ≠ 승인자, 5,000,000원 이상 2단계
  action ( features : instance ) reject  parameter ZA_Reason result [1] $self;
  action ( features : instance ) post    result [1] $self;     " 확정 — 마감 기간 거절
  action ( features : instance ) reverse parameter ZA_Reason result [1] $self;  " 역처리 문서 생성
  validation checkBalanced on save { create; update; }          " 차변 합계 = 대변 합계
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코딩이 아니라 합의이고, 합의가 끝나야 CDS 와 서비스를 확정할 수 있습니다.

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

대사식 9종을 전수로 돌린 결과입니다. 도입 포인트의 사례(총차이 +467,137,300원과 대사 예외)와 같은 숫자입니다. 아래 차이는 대사 화면이 예외를 제대로 보여 주는지 확인하려고 의도적으로 심은 예외로 모두 설명되며, 그 밖의 차이는 0건입니다.

의도적 예외는 R01 1건, R02 2건, R03 4건, R04 5건입니다. 큐브 지표 7개의 큐브 합계와 원천 라인 합계는 모두 일치합니다. V9 의 3건은 취소할 때 자동으로 만들어진 역처리 문서(RV)로 승인자가 없는 경우라 예외가 아닙니다.

운영 데이터로 갈 때

이 사례는 원가 라인 3,445행이 분석 큐브 7,800행으로 모입니다. 라인이 수천만 건이 되어도 큐브 행 수는 라인 수가 아니라 차원 조합 수를 따라가므로, 집계를 DB 로 내리고 기간을 필수 조건으로 두면 화면이 들고 있을 행 수는 크게 달라지지 않습니다. 인덱스는 기간 · 사업장 · 품목 순서의 조회 조건에 맞춥니다.

자주 묻는 질문

도입 검토에서 자주 나오는 질문을 네 묶음으로 나눠 적었습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영