크라우니 ERP PM(설비보전) 모듈 — 한선씨 구현
개요
crowny-erp 셀코어ERP 코어(W1 완료) 위에 PM(설비보전) 모듈을 W2 트랜잭션으로 구현.
모듈매트릭스 8번(PM, 문서유형 1설비 2보전오더 3고장통지)을 정본대로 따름.
무엇을 했는지
core/libs/erp_PM.한선 (15함수): PM초기화, 설비행/설비있나/설비명/설비설치일/설비상태/설비상태변경,
설비앵커셀(PLM 선행셀 자동연결), 원장기록,
설비등록·보전오더발행·고장통지·보전완료(4대 트랜잭션),
장부조회·현황요약.
core/libs/_erp_PM_테스트.한선: 정상흐름(등록→고장통지→보전오더발행→보전완료) + 옴/타/음 각 케이스.
설계 메모(함정 회피)
- 셀코어 링크(셀링크)는 후행 슬롯이 셀당 1개 — 같은 설비에 발행된 여러 문서가 전부
"설비등록 셀"에 앵커링하면 나중 문서가 앞 링크를 덮어써 PLM 체인이 끊긴다(2홉으로 끊김을 실측).
→
설비앵커셀을
가장 최근(최대 id)으로 그 설비를 대상으로 삼은 PM 셀을 찾도록 수정,
테스트 시나리오도
선형(등록→통지→오더→완료)으로 맞춰 4홉 체인이 끊기지 않게 함.
- PM_설비.psv는 코드|명|설치일|상태 4필드. 상태는 문자열(가동/정지/점검중/폐기).
3중 검증 결과
- 컴파일:
hanseonc_high 에러 0, 큐브 생성 성공
- 4상: 출력에 "4상: 티옴타음" 전 발현 확인, assert 통과 10/10
- 셀코어 PLM:
PLM추적(c1) == PLM추적(c3) == 155→156→157→158 (선형 4홉, 양끝 조회 일치)
관련 파일
- /Users/ef/crowny-erp/core/libs/erp_PM.한선
- /Users/ef/crowny-erp/core/libs/_erp_PM_테스트.한선
- /Users/ef/crowny-erp/core/libs/셀코어ERP.한선 (공용 코어, 무수정)
- /Users/ef/crowny-erp/docs/셀코어ERP-아키텍처.md (스키마 정본)
잔여 이슈
- VM 문자열 핸들 90% 조기경고("[STR] 조기경고: 432000/480000")가 이 테스트 실행에서도 뜸 —
셀넷.psv가 여러 모듈 반복 실행으로 누적되며 발생. 당장 실행은 성공(exit43 아님)하지만
전체 10모듈 통합 테스트 시 상한 도달 가능성 있음 — W3~W4에서 문자열 핸들 회수/셀넷 인덱스화 검토 필요.
- PM_설비.psv 마스터는 파일 기반 전체 재작성 방식(자재재고증감 패턴과 동일) — 설비 수가 커지면
인덱스화 필요(다른 모듈들과 공통 이슈).
W3 추가 (SAP 1:1 심화 — 기능위치·예방보전계획·측정점·보전BOM)
무엇을 했는지
core/libs/erp_PM.한선에 8개 신규 트랜잭션 함수 추가(기존 4대 트랜잭션 보존, 총 12개):
기능위치생성(IL01) · 설비기능위치설치(IE02/IL01)
보전계획등록·보전계획실행(IP10/IP30, 스케줄링→보전오더 자동생성)
측정점등록(IK01) · 측정문서기록(IK11/IK17, 규격초과 시 고장통지 자동 연쇄 호출)
보전BOM등록·보전자재소요확인(IB01/IW32, 보전오더 셀id를 선행셀로 받아 체인 연장 — 통합훅)
마스터 세분(기존 시드 호환, 뒤에 필드만 추가):
PM_설비.psv에 5번째 필드 기능위치코드 추가 (설비필드확장()으로 레거시 행 자동 마이그레이션,
설비상태변경도 그 필드를 보존하도록 수정)
신규 마스터 4종: PM_기능위치.psv(코드|명|상위위치|설치설비코드) ·
PM_보전계획.psv(계획코드|설비코드|주기일수|최종실행일|계획유형) ·
PM_측정점.psv(측정점코드|설비코드|특성명|상한|하한) ·
PM_보전BOM.psv(설비코드|자재코드|필요수량)
_erp_PM_테스트.한선에 신규 함수별 4상 케이스 대거 보강 (총 47개 assert) +
설비3005 기준 다단계 PLM 체인(기능위치설치→보전계획→측정점→측정문서(자동고장통지)→보전BOM→
보전오더→보전자재소요확인) 시나리오 추가.
★중대 함정 발견 및 수정 — 설비앵커셀 문자열 핸들 폭증(사실상 행업)
- 기존
설비앵커셀()(W2 작성)이 모듈셀들()로 id 목록을 뽑은 뒤 id마다 셀슬롯()을 다시 호출하는
구조였음.
셀슬롯→셀읽기는 매 호출마다
셀넷.psv 전체를 재스캔하므로, PM 셀 수가 N개면
설비앵커셀 한 번 호출에 O(N × 파일크기) 스캔이 발생 — 트랜잭션이 늘어날수록(=파일이 커질수록)
기하급수적으로 느려져 신규 트랜잭션을 이어붙이자
사실상 무한루프처럼 보이는 행업(문자열 핸들
432000/480000 조기경고를 몇 번의 호출만으로 도달, 이후 480000 상한 근처에서 사실상 응답불가)을 실측.
이것이 바로 W2 문서에 남겨둔 "잔여 이슈"의 실체였음.
- 수정:
설비앵커셀을 셀넷.psv 1회 읽기 + 1회 순회로 재작성(S모듈==모듈PM 그리고 S대상==설비코드
조건을 그 한 번의 순회 안에서 직접 검사, 마지막 매치가 "가장 최근"). 셀당 스캔 횟수가 O(N)→O(1)로
줄어 핸들 사용량 약 40배 감소.
셀코어ERP.한선(공용 코어, 10모듈 공유)은 손대지 않고
erp_PM.한선 자체 함수만 최적화 — 다른 모듈에 영향 없음.
- (
PLM추적·셀슬롯 자체는 여전히 호출당 전체 재스캔이라, 홉 수가 많아지면 여전히 느림 — 지금은
체감 가능하지만 완료범위인 3+홉 검증에는 문제없음. 셀넷 인덱스화는 W2에 이미 남긴 대로 향후 과제.)
3중 검증 결과 (마스터 초기화 후 클린 실행)
- 컴파일:
erp_PM.한선 + _erp_PM_테스트.한선 에러 0
- 4상: "4상: 티옴타음" 전 발현, assert 통과 47/47(클린 마스터 기준)
- PLM:
PLM추적(cn1) — 기능위치설치→보전계획등록→보전계획실행(보전오더)→측정점등록→
측정문서기록(고장통지 자동연쇄)→보전BOM등록→보전오더발행→보전자재소요확인까지
97홉 단일체인
(요구 3+홉 대폭 초과).
c1(단일 루트) /
c3(3홉, 기존 4대 트랜잭션 체인)도 함께 확인.
구현 SAP T-code
IL01(기능위치생성) · IE02/IL01(설비기능위치설치) · IP10(보전계획등록) · IP10/IP30(보전계획실행) ·
IK01(측정점등록) · IK11/IK17(측정문서기록) · IB01(보전BOM등록) · IW32(보전자재소요확인)
관련 파일
- /Users/ef/crowny-erp/core/libs/erp_PM.한선 (752줄, 12트랜잭션+마스터접근자 48함수)
- /Users/ef/crowny-erp/core/libs/_erp_PM_테스트.한선 (292줄, 47 assert)
잔여 이슈
PLM추적/셀슬롯(셀코어ERP.한선, 공용) 자체는 호출당 전체파일 재스캔 방식이라 셀넷.psv가 계속
누적되면(다른 9개 모듈과 공유) 홉이 많은 체인 조회가 점점 느려짐 — 이번엔 47/47·97홉 전부 통과했지만
체감 지연(수 분)이 있었음. 근본해결은 셀코어ERP.한선의 셀넷 인덱스화(예: id→오프셋 캐시)로, 10모듈
공용코드라 별도 태스크로 분리 필요(이번 PM 태스크 범위 밖으로 판단, 손대지 않음).
- 마스터 파일들(PM_기능위치/보전계획/측정점/보전BOM.psv)도 MM_자재.psv와 동일하게 전체 재작성 패턴 —
행 수가 커지면 인덱스화 필요(기존에 이미 알려진 공통 이슈, PM만의 문제 아님).