제조관리 MF · 프로젝트 상세 › 제조

프로젝트의 작업지시(제품)마다 최신 제작도를 한 줄로 보고, 정형 제품 제작도를 자동 출력한다. 행을 고르면 오른쪽 미리보기가 갱신된다. 관련 요구사항 FR-MF-003 · 근거: DE22-1 §10 v1.1-r1 §4.1

진입 — SCR-PM-016 프로젝트 상세 [제조] 탭 · 탭 진입 시 기본 화면. 프로젝트 축이라 작업지시를 고르지 않고 열린다 (§3.4 규칙 1)

1. 검색 · 거르개 — 도면번호·제품 코드·제품명 부분 일치(Enter 또는 [검색] 을 눌러야 부르는 제출 전용). 유형(전체/정형/비정형/미판정)·상태(전체/출력완료/대기/업로드 필요) 거르개는 모두 서버 인자이고 [미판정] 하나만 화면에서 거른다 — 서버가 그 값을 받지 않는다 (§4.1.3).
2. 정형 제작도 자동 출력 — 두되 눌리지 않게 한다. 서버가 501 DRAWING_GENERATION_DEFERRED 를 돌려준다(자재 구성표에서 도면을 만드는 엔진이 아직 없다). 숨기면 엔진이 섰을 때 자리를 다시 찾아야 하고 그냥 두면 눌러 봐야 오류뿐이다. 곁에 까닭을 적고 오류 색을 쓰지 않는다 — 고장이 아니라 아직 안 만든 것이다 (§4.1.5).
3. 제작도 현황 목록 — 한 줄이 제작도 하나가 아니라 작업지시(제품) 하나다. 제작도를 줄로 잡으면 「업로드 필요」인 행이 영영 안 나타난다(아직 아무것도 안 올렸으니 shop_drawing 에 없다). 정렬은 작업지시 내림차순 고정이라 정렬 고르개를 두지 않는다 (§4.1.1).
4. 「판」 칸 — 한 작업지시에 제작도가 여러 판 쌓이는데(version 은 서버가 MAX+1 로 매긴다) 목록은 최신 하나만 보인다. 몇 판인지 보이지 않으면 사용자가 지난 판의 존재를 알 길이 없다 (§4.1.1).
5. 관리 칸 — 정형이고 판이 1 이상이면 [보기](오른쪽 미리보기 갱신, 화면 이동 없음), 비정형이면 [뷰어](SCR-MF-002 이동). 정형 0판·미판정은 — 다. [뷰어] 를 누르면 그 행의 작업지시가 MF 셸 문맥으로 들어앉는다 (§3.4 규칙 3).
6. 도면 미리보기 — 정형은 PDF 라 브라우저 내장 문서 보기가 확대·축소·인쇄·저장을 이미 준다. 같은 도구줄을 다시 만들지 않고 [원본 내려받기] 한 단추만 둔다. 비정형(DWG)은 여기서 못 그리므로 [뷰어로 가기] 로 보낸다 (§4.1.5).
7. 미판정 행 — 제품 마스터에 정형/비정형 판별 칸이 없어 제작도가 0건이면 유형을 읽을 수 없다. 그래도 행을 감추지 않는다 — 감추면 목록 건수가 작업지시 수와 어긋나 빠진 제품을 찾을 방법이 없어진다 (§4.1.1).

비정형 제품의 제작도는 웹에서 고치지 않는다(편집기 미채택, 2026-07-08 확정, @김지광). 외부 CAD(AutoCAD 등)에서 만든 DWG 를 올려 열람만 한다 — 확대·축소·화면 이동까지다. 관련 요구사항 FR-MF-004 · 근거: DE22-1 §10 v1.1-r1 §4.3

진입 — SCR-MF-001 목록의 비정형 행 [뷰어] · MF 탭 줄 [비정형 뷰어] (작업지시 문맥이 있어야 열린다 — 비어 있으면 SCR-MF-003 으로 보내 고르게 한다, §3.4 규칙 3)

1. 올리기 — 끌어다 놓거나 [파일 선택]. .dwg·.dxf 만, 55MB 까지. 화면이 먼저 막고 서버도 막는다 — 55MB 파일을 다 올린 뒤 413 을 받는 것은 낭비다. 이 상한은 제조관리 몫이라 견적설계 도면 올리기(50MB)와 다른 값이다 (§4.3.6).
2. 판 목록 — 이 작업지시에 올린 제작도가 판(version)마다 한 줄이다(내림차순·활성만). 올리기는 덮어쓰기가 아니라 판 쌓기다 — 같은 이름을 다시 올려도 앞 판이 남는다. 서버가 MAX+1 로 매기고 지운 판까지 세므로 번호가 되쓰이지 않는다. 지우기(논리 삭제)도 여기 둔다 — 판이 늘어서는 자리라야 무엇을 지우는지 보인다 (§4.3.5).
3. 도면 (보기 전용) — 확대·축소·이동만 한다. 지금은 변환이 이어지지 않아 그릴 수 없다(화면 상태 conversion-pending) — 도구 네 개는 비활성이고 [원본 DWG 내려받기] 만 살린다. 오류 색을 쓰지 않는다. ⚠️ 견적설계 쪽 「올려도 변환이 안 걸린다」와 다른 자리다 — 그쪽은 흐름이 있는데 안 거는 것이고 이쪽은 흐름 자체가 제작도를 모른다 (§4.3.5).
4. 도면 정보 — 상세 응답이 주는 값 그대로다. 올린 사람 이름을 서버가 붙여 준다(화면이 사람 이름을 따로 조회하지 않는다). 내려받기 주소는 서명돼 있고 기한이 있어 만료되면 상세를 다시 불러 조용히 새 주소로 받는다 — 사용자에게 오류를 보이지 않는다 (§4.3.1).
5. 범위 밖 (만들지 않는다) — 도구 팔레트 · 편집 캔버스 · 치수 수정 · 개소 찍기 · 눈금자 · 배치물 놓기 · 코멘트. 견적설계 배치 캔버스(SCR-ES-015)가 하는 그 일들을 가져오지 않는다. 다시 쓰는 것은 파일을 그림 자료로 바꾸는 흐름과 그것을 그려 내는 부품뿐이다 (§4.3.5).

작업지시를 골라 상태를 옮기고(발행 → 착수 → 완료) 작업지시서를 화면으로 보거나 종이로 낸다. MF 에서 작업지시를 고르는 자리가 이 화면이다. 관련 요구사항 FR-MF-012 작업지시서 출력·전달 · 근거: DE22-1 §10 v1.1-r1 §4.2

진입 — MF 탭 줄 [작업지시서] · 작업지시 문맥이 빈 채로 작업지시 축 화면(비정형 뷰어·절단 재계산·공정 진행)을 누르면 여기로 온다(선택 게이트, §3.4 규칙 3)

1. 검색 · 상태 거르개 — 둘 다 화면에서 거른다. 목록 주소가 인자를 하나도 받지 않고 그 프로젝트의 활성 작업지시를 최신순 전건으로 준다(as-built). 검색은 지시번호·발주번호 부분 일치다 — 발주번호는 칸으로 두지 않고 검색 대상에만 넣는다 (§4.2.3).
2. 묶음 출력 확인칸 — 왼쪽 확인칸으로 고른다. 최대 20건이고 21건째는 화면이 먼저 막는다(서버도 400 으로 막지만 스무 건을 고른 뒤에 알면 늦다). 없거나 취소된 건은 빠지고 나머지가 나오며, 전건이 빠지면 404 다 (§4.2.6).
3. 「제품」 칸 — ⚠️ 목록 응답이 제품을 productId 숫자 하나로만 주어 지금은 — 로 흐른다. 고르는 화면인데 무엇을 고르는지 안 보이는 자리라 칸은 두고 서버 보강을 기다린다 — #1727 (area:BE). 고른 뒤 오른쪽 시트에서 확인한다 (§4.2.1).
4. 상태 전이 단추 — 시트 패널 머리 — 액션 바가 아니다. 전이는 작업지시 하나에 거는 동작이라 액션 바에 두면 무엇에 거는지 흐려지고 여러 건을 고른 상태에서 누르면 어떻게 되는지가 정해지지 않는다. 종전 [작업지시 전달] 은 [발행](release)·[PDF 내려받기]·[인쇄](export) 로 갈랐고, 「시스템으로 보낸다」는 그런 주소가 없어 만들지 않는다 (§4.2.5).
5. 작 업 지 시 서 — 화면에서 보는 모습이다. 화면이 시트 자료(JSON)를 받아 HTML 로 그린다. 종이로 나가는 모습은 서버가 MF-WORK-ORDER-SHEET 서식으로 따로 만든다 — 현장에 나가는 문서라 서식이 서버에 고정돼야 한다 (§4.2.6).
6. 지시 항목 = 공정 단계 목록 — 차례는 자재 구성표에서 온 값이라 성기다(10·20·30). 화면이 다시 번호 매기지 않는다. DRAFT 인 작업지시는 여기가 비어 있고 그것이 정상이다 — 공정 진행 행은 발행할 때 서버가 미리 만든다. 그 자리에 「발행하면 공정 단계가 생긴다」를 두고 오류로 보이지 않는다 (§4.2.2).
7. 쪽 넘김을 두지 않는다 — 전건을 받으므로 「화면 거르개 + 쪽 넘김」이 어긋나는 일이 없다(§00 §5.2 가 금하는 조합이 성립하지 않는다). 목록 아래에 그 사실을 한 줄로 알린다. ⚠️ 프로젝트당 수백을 넘어서면 서버 거르개·쪽 넘김이 필요하고 그때 이 결정을 다시 본다 (§4.2.3).

현장실측(FS) 결과를 반영해 절단 치수를 다시 셈하고, 견적 확정 스냅샷과 견줘 무엇이 얼마나 바뀌었는지 본다. 셈하는 방법은 DE24-1 §5.8.3 이 정본이고 이 화면은 셈한 결과를 어떻게 보이나만 정한다. 관련 요구사항 FR-MF-006 · 근거: DE22-1 §10 v1.1-r1 §4.4

진입 — MF 탭 줄 [절단 재계산] (작업지시 문맥이 있어야 열린다 — 비어 있으면 SCR-MF-003 으로 보낸다, §3.4 규칙 3)

1. 실측 회차 고르개 — 현장실측 주소를 그대로 쓴다(제조에 목록 주소를 따로 만들지 않는다). 조회 2건에 한해 ROLE_MF_VIEWER 이상이 통과하도록 이미 열려 있다. 「쓰지 않음 — 수기 보정」도 고를 수 있고 둘을 함께 쓰면 수기 보정이 실측값을 덮는다. 둘 다 없으면 재계산이 눌리지 않는다(서버도 422 로 막는다) (§4.4.2).
2. 재계산 실행 — dryRun=true. 셈만 하고 저장하지 않는 미리보기다. 서버가 부르는 순간 저장하던 시절에는 뒤엣것이 할 일이 없었는데, 정본이 그것을 뒤집었다 (§4.4.5).
3. 재계산 결과 적용 — dryRun=false. MF_FINAL 계획을 새 판으로 만든다. 확인 창에 「이 값이 발주량 대조의 기준이 된다」를 적는다 — 눌러 보고 버린 시도 하나가 곧바로 추가 발주 판단의 기준이 되기 때문이다. 성공 알림에 [발주량 대조 보기] 를 함께 둔다 (§4.4.5·§4.4.7).
4. 「아직 저장되지 않았다」 띠 — 미리보기 상태에서 늘 띄운다. 단추 둘을 합치지 않는 까닭을 화면이 글로도 말하는 자리 (§4.4.5).
5. 대조 표 — 기준선이 견적 확정 스냅샷이지 직전 계획이 아니다. 그래서 열 이름이 「기존 절단치수」가 아니라 「견적 확정 절단치수」다 — 기준이 고정돼야 몇 번을 셈해도 「설계 대비 얼마나 벌어졌나」가 같은 답을 준다. 표는 서버가 만들어 준다(dimensionDiff[]) — 화면이 조립하지 않는다 (§4.4.1).
6. 차이 칸 — 「0」과 「—」를 가른다 — 0 은 견줘 봤더니 같다, — 는 견줄 짝이 없다(한쪽에만 있는 자재)는 뜻이다. — 를 0 으로 채우지 않는다 — 채우면 새로 생긴 자재를 발주에서 빠뜨리거나 빠진 자재를 계속 발주하게 된다. ⚠️ 실측값이 안 들어온 부재는 「빠짐」이 아니다 — 실측은 폭·높이만 담고 나머지는 견적값으로 셈되어 「같음」으로 나온다 (§4.4.1).
7. 「기준」 칸 — 한쪽만 손실 반영값이면 차이가 치수 변화가 아니라 손실률 유무를 나타내게 된다. 그럴 때 서버가 양쪽을 순수 평가값으로 내려 견주고 그 사실을 알린다. 화면은 이 칸을 숨기지 않는다 — 줄마다 견준 기준이 다르다는 것을 모르면 mm 몇의 차이를 잘못 읽는다 (§4.4.1).
8. 지난 판 — 적용은 덮어쓰기가 아니라 판 쌓기다. 앞 판은 지워지지 않고 여기 남는다. 되돌리는 길은 다시 셈해 적용하는 것이지 지우는 것이 아니다 — 계획을 지우는 주소가 서버에 없다 (§4.4.5).

실제로 발주한 양으로 제조 소요를 감당하는가를 자재별로 견준다. 모자란 자재가 있으면 발주관리로 추가 발주를 알린다. 관련 요구사항 FR-MF-009 (1차 vs 최종 자동 비교) · FR-MF-010 (추가 발주 처리) · 근거: DE22-1 §10 v1.1-r1 §4.5

진입 — MF 탭 줄 [발주량 대조] · SCR-MF-004 적용 알림의 [발주량 대조 보기]. 프로젝트 축이라 작업지시를 고르지 않고 열리지만 부르는 주소는 작업지시 축이다 (§4.5.1)

1. 집계 칸 넷 — 서버에 묻지 않고 화면이 표의 값으로 센다. 같은 수를 세는 주소를 서버에 따로 두지 않는다. 넷을 더하면 대조 자재 수가 된다 — 그 셈이 안 맞으면 거르개가 걸린 것이다 (§4.5.2).
2. 모자람 · 남음 · 맞음 — 색만으로 가르지 않는다. 부호(−·+·0)·글자(부족·남음·맞음)·자리·색 넷이 늘 함께 간다 — 색을 못 보는 사람에게도, 흑백으로 인쇄해도, 엑셀로 내보내도 뜻이 남는다 (§4.5.2 · §00 접근성 원칙).
3. 부호의 방향을 뒤집는다 — 서버 varianceQty 는 「최종 소요 − 1차 발주」라 모자라면 양수(+)다. 화면은 사람이 읽는 대로 모자람에 − 를 붙인다. 보이는 부호만 뒤집고 값은 뒤집지 않는다 — 정렬·거르개·엑셀은 서버 값 그대로 돈다. 이 어긋남을 화면 코드 한자리에 모아 둔다 (§4.5.2).
4. 1차 발주(바) — 계산값이 아니라 실제로 발주한 원자재 바 수(발주 라인 합)다. 담당자가 계산 결과에서 수량을 손봐 발주할 수 있어 둘이 다르다. 비교 단위는 바(정척) 개수이지 절단 조각 수가 아니다 — 절단이 늘어도 기존 바 안에서 잘리면 추가 발주가 필요 없다 (§4.5.3).
5. 빈칸을 0 으로 채우지 않는다 — 견줄 발주 근거가 없으면 1차 발주·차이·상태 세 칸을 비우고 최종 소요만 남긴다. 차이 금액은 단가를 못 찾거나 단위가 개수(EA)가 아니면 — 다(단가가 그 단위당 값이라 개수에 곱하면 금액이 틀린다). 0 을 찍으면 「0 개 발주」·「차액 없음」으로 읽힌다. ⚠️ 발주는 있는데 그 자재 라인만 없는 경우는 0 이 맞다 (§4.5.3).
6. 추가 발주 요청 — 서버가 권할 때만(ADDITIONAL_ORDER) 활성이고, 모자란 바가 하나여도 대상이다(문턱을 두지 않는다). ⛔ 지금 눌러도 발주서가 만들어지지 않는다 — 서버가 알림을 쏘지만 받는 쪽이 아직 없다. 그래서 문구를 「추가 발주가 필요하다고 알렸다」까지로 적고 「발주서가 만들어졌다」로 적지 않는다 (§4.5.5, #1731).

MES(제조실행시스템)와 오간 기록을 감시한다. 연동은 MES 가 당사 API 를 부르는 방향이라 당사가 실행 주체가 아니고, 그래서 이 화면에는 쓰기가 하나도 없다 — MF 화면 일곱 가운데 유일하다. 관련 요구사항 FR-MF-005 · 근거: DE22-1 §10 v1.1-r1 §4.7 (#416 · #1725)

진입 — MF 탭 줄 [MES 연동]. 프로젝트 축이라 작업지시를 고르지 않고 열린다 · 권한은 ROLE_MF_VIEWER 이상이면 전부 (§4.7.2)

1. 연동 상태 카드 — 「연결 상태」가 아니라 「마지막 결과」 — 서버는 연결을 확인하지 않는다. 마지막 전달 기록의 결과를 보일 뿐이라 「연결됨/끊김」으로 적으면 사용자가 지금 이 순간의 연결로 오해한다. 화면 상태 mes-disconnected 도 「연결이 끊겼다」가 아니라 「마지막 전달이 실패했거나 기록이 없다」는 뜻이고, 그때도 카드만 바뀌고 이력 표는 그대로 둔다 — 지난 기록은 연동이 끊겨도 읽을 수 있어야 한다 (§4.7.3·§4.7.6).
2. 전달이 안 걸린 작업지시 — workOrderCount − loggedWorkOrderCount 를 화면이 뺀다. 한 번도 전달을 시도하지 않은 작업지시가 몇인지 보이는 자리다. 카드 넷은 모두 프로젝트 전체 기준이라 쪽을 넘겨도 안 바뀐다 (§4.7.3·§4.7.5).
3. ⛔ 단추를 만들지 않는다 — 종전 그림에 있던 [수동 pull 실행]·[자동 pull 토글] 둘 다 없다. 연동 방향이 반대라 당사가 실행할 대상이 없고(그런 주소가 서버에 아예 없다), 얼마나 자주 가져갈지는 MES 쪽 일정이다. 비활성으로도 두지 않는다 — 자동 출력 단추(SCR-MF-001)는 엔진이 서면 열리지만 이 둘은 열릴 날이 오지 않는다. 대신 안내 한 줄을 두어 단추가 없는 것이 빠뜨린 것이 아니라 정한 것임을 화면이 스스로 말하게 한다 (§4.7.2).
4. 이력 표는 하나가 아니라 둘 — 탭으로 나눈다 — ① 전달 이력(push, 당사 → MES) 과 ② 접근 이력(pull, MES → 당사) 은 방향이 반대라 한 표에 섞으면 어느 쪽 이야기인지 알 수 없다. 서버 컨트롤러도 정확히 둘로 나뉘어 있다 (§4.7.1).
5. 전달 이력 탭은 지금 늘 비어 있다 — 당사가 MES 로 보내는 길이 아직 서지 않아 그 표에 쓰는 코드가 하나도 없다(읽는 쪽만 있다). 「연동 실패」로 보이지 않는다 — 빈 표에 오류 색을 칠하면 실제로 실패한 것과 구분되지 않는다. 그래서 탭 기본 선택이 ② 접근 이력이다 (§4.7.1).
6. 「방식(자동/수동)」 칸을 두 탭 어디에도 두지 않는다 — 그 개념 자체가 없다. 전달 기록에는 자동·수동을 담은 칸이 없고, 접근 기록은 전부 MES 가 부른 것이라 갈리지 않는다. ①은 구분(제작도·생산실적), ②는 요청자(MES 서비스 계정)로 바꿨다 (§4.7.4).
7. 대상은 숫자가 아니라 문자 키 — RBOM-…-EL{n} 꼴이다(종전 그림이 「resolvedBomId 등」이라 적어 숫자로 읽히던 자리). 결과 다섯 값은 우리말로 보인다 — 성공 200 · 없음 404 · 미확정 409 · 폐기 410 · 권한 없음 401. 「걸린 시간」은 연동이 느려지는 것을 눈치채는 자리다 (§4.7.4).

한 작업지시의 공정 단계를 차례대로 옮기고(대기 → 진행 중 → 완료) 늦음·불량을 적는다. 아래에 이 프로젝트의 최근 움직임을 함께 보인다. 관련 요구사항 FR-MF-011 (AN12-1-P2 v1.1 신규) · 근거: DE22-1 §10 v1.1-r1 §4.6

진입 — MF 탭 줄 [공정 진행] (작업지시 문맥이 있어야 열린다, §3.4 규칙 3) · SCR-MF-003 [발행] 뒤 알림

1. 집계 칸은 넷이 아니라 다섯 — 대기·진행 중·완료 위에 늦음·불량을 더한다. 불량은 재작업으로 이어지는 신호라 빼지 않는다. 이 다섯은 이 작업지시의 공정 현황이고 화면이 위 표에서 센다 (§4.6.2·§4.6.3).
2. 거르개 둘을 따로 둔다 — 상태(대기·진행 중·완료)와 표시(늦은 것만·불량만)를 합치지 않는다. 늦음·불량은 상태와 겹쳐 나타나므로(완료인데 불량인 줄이 있다) 한 고르개에 넣으면 「완료 그리고 불량」을 고를 수 없다 (§4.6.2).
3. 상태 칸은 늘 세 값 — 「늦음」은 네 번째 상태가 아니다. 서버에 그런 저장 상태가 없다. 되돌아가는 길도 없다 — 되돌리면 시작·완료 시각이 덮여 그 공정에 걸린 시간이 사라지고 집계가 무엇을 센 숫자인지 알 수 없게 된다. 상태 흐름을 화면에 한 줄로 늘 보인다 (§3.3 ⓐ·ⓑ).
4. 늦음 칸 — 기호(△)·글자·색 셋이 함께 간다. 갈래가 둘이다 — 사유가 적힌 것(delayIssue)은 그 글을 줄에 그대로 보이고(「늦음」이라고만 쓰면 왜 늦었는지 보려고 한 줄씩 열어야 한다), 날짜를 넘긴 것은 계획 종료일이 지났는데 아직 완료가 아닌 줄을 화면이 셈해 낸다 (§4.6.2).
5. 불량 칸 — ✕ + 불량 코드 + 재작업 표식. 불량과 재작업은 1:1 이 아니다 — 재작업 표식이 붙은 줄과 안 붙은 줄이 함께 있는 것이 정상이다(경미한 흠집까지 재작업으로 세면 목록이 부풀어 쓸모가 없어진다). 불량 코드는 정식 목록이 아직 없어 자유 입력이다 (§3.3 ⓒ·§4.6.2).
6. 고치기 — ROLE_MF_EDITOR 에게만 보인다(감춘다 — 흐리게 두지 않는다). 흐린 단추는 「지금은 못 하지만 언젠가 된다」로 읽히는데 권한은 화면에서 바뀌지 않는다. 시작·완료 시각에는 입력 칸을 두지 않는다(서버가 전이 때 자동으로 찍는다). 끝난 공정에도 불량을 적을 수 있고 그때 완료 시각이 다시 찍히지 않는다 — 불량은 대개 공정이 끝난 뒤 검사에서 나온다 (§4.6.4).
7. 아래 표는 「현황」이 아니라 「최근 움직임」 — 프로젝트 집계 주소는 그 기간에 갱신된 진행 줄만 센다(daily=오늘, weekly=최근 7일). 한 번도 손대지 않은 대기 줄은 안 잡힌다. 「현황」으로 읽히면 어제까지 끝난 공정이 오늘 표에서 사라지는 것을 보고 자료가 틀렸다고 여긴다 (§4.6.3).
8. 공장 통합 화면은 두지 않는다 — 집계 주소가 경로만 프로젝트 밖일 뿐 projectId 를 반드시 받아 프로젝트를 가로지르는 집계를 줄 수 없다. 그런 요구를 낸 요구사항도 없고 채울 자료도 얇다. 다시 열 조건은 ⓐ 가로지르는 집계 주소가 생기고 ⓑ 여러 프로젝트를 함께 보는 역할이 정해질 때다 (§4.6.3).