생산 통합 관리 — 문서 처리·일괄 실행·대사·원가 분석을 한 흐름으로 잇는 생산 영역 업무 앱
기준정보 · 문서 처리 · 일괄 실행 · 대사와 예외 · 원가 다차원 분석 · 영역 간 연계 · 이력과 감사까지 — 소개 영상과 실제 화면 9종
소개 영상업무 순서대로 · 자막 포함9개 장면개요 → 기준정보 → 문서 처리 → 일괄 실행 → 대사 → 원가 분석 → 연계 → 감사
주요 재생 지점
도입 포인트 — 이 앱을 사용해야 하는 이유
생산 현장의 숫자는 자재 투입, 공정 실적, 제품 입고, 정산 문서로 만들어지고, 그 문서마다 검토와 승인과 전기가 따라붙습니다. 그런데 처리는 처리대로, 대사는 대사대로, 원가 분석은 엑셀대로 흩어져 있으면 "어느 문서가 어디에서 멈췄나", "이 차이는 누가 처리하나", "계획과 왜 달라졌나"에 답하는 데 하루가 갑니다. 이 앱은 세 질문을 한 화면 흐름으로 붙입니다.
핵심 포인트 여덟 가지
| 포인트 | 얻는 것 | 지금 방식이라면 |
|---|---|---|
| ① 한 문서의 상태가 한 길로만 흐른다 | 작성중 → 검토중 → 승인 → 전기, 반려되면 작성중으로 돌아갑니다. 건너뛰는 길이 없어 "승인 없이 전기됐다"가 구조적으로 불가능합니다. | 메일과 엑셀 목록으로 승인 여부를 따로 관리하고, 전기 후에야 빠진 승인을 발견합니다. |
| ② 작성자와 승인자를 시스템이 분리한다 | 작성자는 자기 문서를 승인할 수 없고, 큰 금액은 서로 다른 승인자 두 명이 순서대로 승인해야 전기됩니다. | 권한 분리를 규정으로만 두고 사후 점검에서 위반을 찾습니다. |
| ③ 모의 실행 후에 실행한다 | 일괄 실행은 저장 없이 대상과 금액, 제외 사유를 먼저 보여 줍니다. 실행해도 확정이 아니라 작성중 문서가 만들어질 뿐입니다. | 일괄 처리를 돌린 뒤 잘못된 문서를 하나씩 찾아 지웁니다. |
| ④ 네 규칙 대사와 예외 처리 흐름 | 차이를 찾는 데서 멈추지 않고 보류·수용·조정 전표·재오픈까지 한 목록에서 처리합니다. 조정 전표가 전기되면 재대사 때 차이가 상쇄됩니다. | 차이 목록은 엑셀로, 조치 결과는 메일로 흩어집니다. |
| ⑤ 계획 대비 차이를 요인으로 가른다 | 물량·자재 사용·자재 단가·시간 효율·환산율 요인으로 나누고 반올림 요인을 두어 요인 합이 총차이와 정확히 같아지게 했습니다. | 총액 차이만 보고 원인은 담당자 설명에 의존합니다. |
| ⑥ 하루 한 번 도는 점검 에이전트 | 규칙에 걸린 건을 하루 한 번 점검해 보고로 남기고, 개요의 "안 읽은 보고"로 알립니다. 걸린 것이 없는 날도 활동 기록은 남깁니다. 판단은 "점검 필요"로만 적습니다. | 화면을 여는 사람이 없으면 차이가 며칠씩 방치됩니다. |
| ⑦ 쓰기 요청마다 감사 기록 | 성공과 거절을 가리지 않고 한 요청에 한 줄씩 남습니다. 누가 어떤 문서에 무엇을 시도했는지 그대로 추적됩니다. | 변경 이력이 화면마다 달라 사고가 나면 로그부터 뒤집니다. |
| ⑧ 서비스 하나, 규칙 하나 | 화면은 OData V2 서비스 하나만 쓰고, 업무 규칙은 서비스와 샘플 화면이 같은 코드를 공유합니다. 규칙을 고치면 둘이 함께 바뀝니다. | 화면과 서버에 같은 검증을 따로 짜서 어긋납니다. |
도입하면 달라지는 것
- 처리 현황이 한눈에 — 승인 대기·반려·전기 대기가 개요 타일로 서서 메일로 묻고 답하는 일이 줄어듭니다.
- 사후 점검에서 사전 차단으로 — 승인 분리와 기간 점검을 화면이 막으므로 위반을 나중에 찾지 않습니다.
- 차이가 조치까지 이어짐 — 대사에서 나온 차이가 예외 목록에서 보류·수용·조정으로 끝까지 처리됩니다.
- 다음 달로 이어지는 기록 — 레이아웃과 감사 기록이 남아 매번 같은 설명을 처음부터 하지 않습니다.
이런 조직에 맞습니다
생산오더 기준으로 투입·실적·입고·정산 문서를 다루면서 처리 현황과 차이 점검을 엑셀과 메일로 관리하는 생산관리·원가 조직, 그리고 승인 분리와 감사 추적을 시스템으로 끌어올리고 싶은 경영지원 조직에 맞습니다. 실제 시스템과의 연결 범위는 확인 필요입니다.
실행 화면
아래 9장은 샘플 데이터로 띄운 실제 화면입니다. 업무 순서대로 실었습니다.
처음 여는 사람이 "무엇부터 해야 하나"를 묻지 않도록 첫 화면을 목록이 아니라 할 일로 열었습니다. 숫자는 생산 영역 문서 기준이며, 전기 기한이 다가온 문서도 할 일 목록에 함께 올라옵니다.
기준정보를 문서 화면과 같은 앱에 둔 이유는 문서에서 오더를 누르면 곧바로 기준정보로 건너가 확인할 수 있게 하려는 것입니다. 탭 머리의 숫자는 탭을 열기 전에도 건수가 보이도록 따로 읽어 둡니다.
한 문서의 상태는 작성중 → 검토중 → 승인 → 전기 순서로만 움직입니다. 목록의 상태 글자색만 봐도 어디에서 멈춰 있는지 알 수 있습니다.
같은 문서를 작성자(처리자)로 열면 "검토 요청"이, 승인자로 열면 "승인·반려"가 켜집니다. 작성자와 승인자가 같은 사람이면 승인 버튼이 꺼지고 이유가 안내 문구로 나옵니다.
모의 실행 결과 머리에 "저장되지 않았습니다"를 적어 둔 것은 실수로 이미 실행됐다고 오해하지 않게 하려는 것입니다. 실행하면 같은 표에 만들어진 문서 번호가 채워집니다.
이미 있는 예외는 값만 갱신하고, 범위 안으로 돌아오면 자동으로 해소됩니다. 허용 범위는 가정값이므로 실제 기준은 확인이 필요하다고 화면에 적어 두었습니다.
수량·투입·시간이 모두 있는 칸만 집계에 넣고 나머지는 "산출 없는 셀 제외"로 따로 센다고 머리에 적습니다. 합계가 어긋날 자리를 처음부터 없앤 것입니다.
입고나 정산이 전기되면 후속 원가 문서가 자동으로 만들어지고 연계 목록에 줄이 늘어납니다.
거절 기록을 남기는 이유는 "왜 안 됐는지"가 나중에 가장 자주 묻는 질문이기 때문입니다. 권한은 조회자·처리자·승인자·관리자 네 단계입니다.
업무 규칙과 SAP 표준 기능
화면이 막거나 알려 주는 규칙은 아래와 같습니다. 허용 범위와 기준 금액은 가정값이며, 실제 기준은 확인 필요입니다.
| 구분 | 내용 |
|---|---|
| 상태 전이 | 작성중·반려 → 검토 요청 → 검토중 → 승인 → 승인됨 → 전기 → 전기됨. 취소(역분개)는 자재 투입·실적 확인·제품 입고 문서만 가능합니다. |
| 승인 분리 | 작성자와 승인자는 달라야 합니다. 금액 50,000,000 이상은 2단계 승인이며 2단계 승인자는 1단계 승인자와 달라야 합니다. |
| 기간·균형 | 전기와 취소는 열린 기간에서만 가능하고, 차변과 대변 합계가 같아야 전기됩니다. |
| 후속 문서 | 입고와 정산이 전기되면 후속 원가 문서가 자동으로 만들어집니다. |
| 대사 R1 | 자재 투입 수량 대 표준 소요량, 허용 ±5% |
| 대사 R2 | 제품 입고 대 실적 확인, 입고가 있는 오더만 점검 |
| 대사 R3 | 재공품 장부 잔액 차이, 허용 ±1,000 |
| 대사 R4 | 미정산 잔액, 허용 ±1,000 |
| 예외 처리 | 상태는 미처리·보류·해결·수용. 수용은 승인자·관리자만 가능하고, 조정 전표는 가장 최근 열린 기간에 만들어집니다. |
SAP 표준 거래와의 대응
이 앱의 문서와 점검은 아래 표준 거래가 다루는 업무와 대응합니다. 표준을 대체한다는 뜻이 아니라, 같은 업무를 한 흐름으로 묶어 보여 준다는 뜻입니다.
| 업무 | 표준 거래 | 이 앱에서의 자리 |
|---|---|---|
| 자재 투입 | MIGO (이동유형 261) | 화면의 자재 투입 문서가 만드는 분개와 같은 성격 |
| 공정 실적 확인 | CO11N | 실적 수량·시간 입력에 해당 |
| 오더 정산 | CO88 · KO88 | 미정산 잔액(R4) 점검의 기준 |
| 오더 조회·변경 | CO01 · CO02 · COOIS | 기준정보의 생산오더와 대응 |
| 오더 차이 계산 | KKS1 · KKS2 | 원가 분석의 요인 분해와 비교 대상 |
| 재고·자재 원장 | MB51 · CKM3 | 자재 투입 이력과 단가 비교 시 참고 |
데이터 서비스 구성
화면은 OData V2 서비스 mfghub_srv 하나만 읽고 씁니다. 경로에 동사를 쓰지 않고, 엔티티 집합 읽기·쓰기와 함수 호출(POST)로만 동작합니다. 조회는 필터, 정렬, 페이징, 전체 건수, 선택 항목을 지원하고, 날짜는 /Date(밀리초)/, 금액은 문자열 소수로 돌려줍니다. 오류는 JSON 본문과 HTTP 상태로 알립니다.
엔티티 집합 35종
| 묶음 | 엔티티 집합 |
|---|---|
| 기준정보 | MaterialSet · WorkCenterSet · BomSet · OrderSet · DemandSet |
| 문서 | DocHeaderSet · DocItemSet · StatusRuleSet · StatusHistorySet · DocFlowSet |
| 일괄 실행 | RunSet · RunLineSet · RunLogSet |
| 대사·예외 | ReconRuleSet · ReconResultSet · ExceptionSet · ReasonSet |
| 분석 | CubeSet · PlanSet · DimSet · DimValueSet · MeasureSet · CalcSet · PeriodSet · ItemSet · CubeCheckSet · FactorSet · ExplainSet · LayoutSet |
| 에이전트·할 일·감사 | AgentRuleSet · AgentReportSet · AgentRunSet · TaskSet · AuditLogSet · UserRoleSet |
함수 12종
| 함수 | 하는 일 |
|---|---|
SubmitDocument | 검토 요청 |
ApproveDocument | 승인(1·2단계) |
RejectDocument | 반려 |
PostDocument | 전기 |
ReverseDocument | 취소(역분개) |
SimulateRun | 일괄 모의 실행 |
ExecuteRun | 일괄 실행 |
RunReconciliation | 대사 실행 |
ResolveException | 예외 처리 |
DecomposeVariance | 차이 요인 분해 |
ExplainScope | 범위 설명(규칙 기반) |
RunAgent | 점검 에이전트 실행 |
업무 규칙은 한 파일에 모아 서비스와 샘플 화면이 함께 씁니다. 서비스 쪽은 파일 저장소 위에서, 샘플 화면은 브라우저 메모리 위에서 같은 코드를 돌리므로 샘플에서 검증한 흐름이 서비스에서도 같게 동작합니다.
자주 묻는 질문
예상되는 질문을 네 묶음으로 정리했습니다.
문서와 상태
문서는 어떤 순서로 진행합니까?
작성중에서 검토 요청을 하면 검토중이 되고, 승인자가 승인하면 승인됨, 전기하면 전기됨이 됩니다. 반려되면 작성중으로 돌아가 수정 후 다시 요청합니다. 중간 단계를 건너뛰는 길은 없습니다.
작성한 사람이 직접 승인할 수 있습니까?
할 수 없습니다. 작성자와 승인자는 달라야 하며, 같은 사람이면 승인 버튼이 꺼지고 이유가 안내됩니다. 시도가 거절되면 감사 기록에 거절 한 줄이 남습니다.
2단계 승인은 언제 적용됩니까?
문서 금액이 50,000,000 이상이면 적용됩니다. 1단계 승인 후에도 상태는 검토중에 머물고, 1단계와 다른 사람이 2단계를 승인해야 승인됨이 됩니다. 이 기준 금액이 실제 규정과 같은지는 확인 필요입니다.
전기된 문서를 되돌릴 수 있습니까?
자재 투입·실적 확인·제품 입고 문서는 취소(역분개)할 수 있습니다. 정산·계획·오더·조정 문서는 취소 대상이 아니며, 필요하면 조정 문서로 바로잡습니다.
기간이 닫혀 있으면 어떻게 됩니까?
전기와 취소는 열린 기간에서만 됩니다. 닫힌 기간 문서를 전기하려 하면 거절되고 사유가 화면과 감사 기록에 남습니다.
차변과 대변이 맞지 않는 문서는요?
전기 단계에서 막힙니다. 문서 상세의 분개 탭 아래에 차변·대변 합계와 일치 여부가 한 줄로 나옵니다.
일괄 실행과 대사
일괄 실행은 무엇을 만듭니까?
계획은 새 오더와 계획 문서를, 투입은 표준 소요량 기준 자재 투입 문서를, 정산은 정산 문서를 대상 오더마다 작성중 상태로 만듭니다. 이후는 일반 승인 절차를 따릅니다.
모의 실행과 실행은 무엇이 다릅니까?
모의 실행은 아무것도 저장하지 않고 대상과 금액, 제외 사유만 보여 줍니다. 실행은 같은 규칙으로 실제 작성중 문서를 만들고 실행 로그를 남깁니다.
대사는 어떤 기준으로 점검합니까?
네 규칙입니다. 투입 수량과 표준 소요량(±5%), 입고와 실적 확인(입고가 있는 오더만), 재공품 장부 잔액(±1,000), 미정산 잔액(±1,000)입니다. 허용 범위는 가정값이라 실제 기준은 확인 필요입니다.
예외는 어떻게 처리합니까?
보류(사유 확인 전), 수용(승인자·관리자만), 조정(조정 전표 작성), 재오픈 중에서 고릅니다. 조정 전표가 전기되고 다시 대사하면 해당 차이가 상쇄되어 해결로 바뀝니다.
같은 대사를 여러 번 돌려도 예외가 중복됩니까?
중복되지 않습니다. 이미 있는 예외는 값만 갱신하고, 범위 안으로 돌아오면 자동으로 해결 처리합니다.
원가 분석과 점검 에이전트
집계에 빠지는 칸이 있습니까?
수량·투입·시간 중 하나라도 없는 칸은 집계에서 빼고, 머리 문구에 "산출 없는 셀 N개 제외"로 개수를 보여 줍니다. 포함하려면 체크박스를 켭니다.
차이 요인은 어떻게 나눕니까?
총차이를 물량·자재 사용·자재 단가·시간 효율·환산율로 나누고, 남는 오차는 반올림 요인으로 따로 세워 요인 합이 총차이와 정확히 같아집니다.
설명 문구는 AI가 만든 숫자입니까?
아닙니다. 숫자는 서비스가 계산하고, 설명은 그 숫자를 읽는 규칙 기반 문구입니다. 원인을 단정하지 않고 "점검 필요" 항목으로 제시합니다.
점검 에이전트는 언제 돕니까?
하루 한 번입니다. 자동 실행이 이미 있으면 건너뛰고 아무것도 저장하지 않으며, 수동 실행은 언제든 가능합니다. 결과는 개요의 "안 읽은 보고"로 알립니다.
검토용 자료는 어떻게 받습니까?
원가 분석 화면 오른쪽 위의 "검토용 자료(PPTX)"를 누르면 지금 보고 있는 범위의 표와 차트가 담긴 파워포인트 파일이 브라우저에서 만들어집니다. 이 글 왼쪽 목차 아래에서도 샘플을 받을 수 있습니다.
데이터와 도입
화면의 숫자는 실제 값입니까?
아닙니다. 소개와 이 글의 화면은 가상 샘플 데이터이며 실제 업무 수치가 아닙니다. 계정·기간·허용 범위가 실제 설정과 같은지는 확인 필요입니다.
어떤 서비스를 씁니까?
OData V2 서비스 하나입니다. 엔티티 35종과 함수 12종을 가지며 메타데이터, 필터, 정렬, 페이징, 전체 건수, 선택 항목을 지원합니다. 경로에 동사를 쓰지 않습니다.
날짜와 금액은 어떤 형식으로 오갑니까?
날짜는 /Date(밀리초)/ 형식, 금액은 문자열 소수로 보냅니다. 화면이 형식 변환을 따로 하지 않도록 서비스에서 맞춥니다.
권한은 어떻게 나뉩니까?
조회자는 읽기만, 처리자는 작성·검토 요청·전기, 승인자는 승인·반려·수용, 관리자는 전체입니다. 사용자는 요청 헤더로 전달합니다.
실제 SAP 시스템과 연결합니까?
이 앱 자체는 연결하지 않습니다. 같은 업무 규칙을 서비스 계층에 두었으므로, 실제 도입 시에는 문서·기준정보 읽기와 전기를 표준 API 또는 BAPI로 바꿔 끼우는 방식을 검토합니다. 구체 범위는 확인 필요입니다.
화면 규칙을 고치면 서비스도 같이 바뀝니까?
업무 규칙 코드를 서비스와 샘플 화면이 함께 쓰므로 같이 바뀝니다. 그래서 샘플 화면에서 검증한 흐름이 서비스에서도 같게 동작합니다.
모바일에서도 쓸 수 있습니까?
목록은 화면 폭에 따라 열이 접히도록 만들었지만, 전체 흐름의 모바일 사용성은 확인 필요입니다.