📌 배경
입고(GR)는 재고·회계·PO 상태에 직접 영향을 주는 핵심 프로세스이기 때문에,
입력 오류나 처리 기준의 불명확성이 존재할 경우 연쇄적인 정합성 문제가 발생할 가능성이 있었다.
이에 따라 다음과 같은 운영 리스크를 사전에 통제할 필요가 있었다.
1) 잘못된 입력으로 인한 연쇄 오류 가능성
- 주말·미래일·마감일 입력
- 미운영/삭제된 창고·플랜트 선택
- 삭제·완료된 문서를 기반으로 GR 생성 시도
➡ 재고 수량·회계 반영·PO 진행 상태가 모두 틀어지는 문제 발생
2) 정상 입고·반품 입고가 동일하게 처리되는 구조
- 반품 사유(정상/불량)에 따라 재고 반영 여부가 달라야 함에도
- 하나의 로직으로 처리되어 재고가 과다 혹은 중복 반영되는 사례 발생 ➡ 반품 유형별 재고 처리 기준을 시스템적으로 강제하는 것이 필요
3) 신규 품번/창고 조합의 재고 테이블 누락 문제
- 재고 테이블에 “자재 × 플랜트 × 창고 × 사이즈” 조합이 없으면 운영자가 직접 레코드를 생성해야 했다.
- 신규 플랜트 오픈 혹은 신규 라인 투입 시 누락·지연·운영 부담 증가 ➡ 입고 시점에서 재고 레코드가 자동 생성되는 구조가 필요
📌 설계 의도(Why this design?)
입고(GR) 생성 단계에서 발생하는 모든 오류와 재고 반영 문제를 입력 시점에서 바로 잡고,
정상 입고·반품 입고·재고 생성까지 하나의 일관된 흐름으로 처리하기 위해 다음 의도를 중심으로 설계를 진행했다.
1) GR 생성 전에 오류를 ‘선제적으로 차단’하는 Validation Layer 구축
입고 화면 상단에 Validation 유틸리티 레이어를 두어,
- 입고일(주말·미래일·마감일)
- 플랜트/창고 상태(운영/미운영/삭제)
- 참조 문서(삭제·완료·0수량 Item)
등을 GR 생성 이전 단계에서 즉시 검증한다.
검증 결과는
- 메시지 클래스 기반의 명확한 안내문구,
- Function Group 의 스크린 팝업을 통한 상세 정보 확인
으로 사용자에게 전달되어, 사용자 스스로 오류 원인을 빠르게 확인하고 수정할 수 있도록 했다.
2) DONUM 기반으로 정상 입고와 반품 입고를 구조적으로 분리
입고 유형을 DONUM 규칙으로 명확히 구분하였다.
- 1xxxx → PO 기반 정상 입고
- 4xxxx → GI 기반 반품 입고
또한 반품 사유(정상/불량)에 따라
- 재고 반영
- 재고 미반영
을 자동 분기해, 기존에 반복적으로 발생하던 반품 재고 과반영 문제를 시스템 단에서 차단했다.
✔ 정상 반품/불량 반품을 재고 수량만으로 구분할 수 없는 문제 해결
“정상 반품과 불량 반품을 모두 재고 증가로 처리하면, 재고 수량만 보고는 ‘판매 가능한 수량’과 ‘불량 적치 수량’을 구분할 수 없었다.
이에 ‘판매 가능 여부’를 기준으로 재고 반영 기준을 분리해, 정상 반품만 재고로 복귀시키고 불량 반품은 별도 흐름으로 관리하도록 설계했다.”
✔ 불량 반품의 재고 미반영 기준을 명확히 설정
“불량 반품은 실제로 재판매·재출고가 불가능한 ‘폐기 예정 수량’이라는 점에 주목했다.
따라서 정상 재고로 편입하는 대신, 품질(QM)·폐기(Scrap) 프로세스에서 별도로 관리하는 것이 현업 운영 방식과 가장 일치한다고 판단해, 시스템에서도 재고를 ‘미반영’하도록 설계했다.”
3) 신규 품번·창고·사이즈 조합도 GR 시점에 자동 생성
재고 테이블에
‘자재 × 플랜트 × 창고 × 사이즈’
조합이 존재하지 않더라도,
입고 처리 시 해당 조합을 재고 테이블의 레코드로 자동 생성하도록 설계하여
- 신규 플랜트/창고 오픈
- 첫 입고 품번
- 신규 라인 투입
상황에서도 운영자가 사전 세팅을 하지 않아도 재고 반영이 누락되지 않도록 했다.
✔ 재고 조합만 자동 생성하도록 한 이유
‘자재 × 플랜트 × 창고 × 사이즈’ 조합은 입고 시점에 재고테이블에 자동 생성되도록 했지만,
자재 마스터나 플랜트, 창고 마스터 자체는 여전히 표준 마스터 관리 프로세스를 통해서만 생성되도록 구분했다.
재고 구조는 운영 편의를 위해 자동화하되, 마스터 데이터 생성 권한까지 열어버리면 통제 리스크가 커진다고 판단했기 때문이다.
✔ 자동화 범위를 ‘재고 조합’으로 제한한 설계 의도
자동 생성 대상을 재고 조합으로 한정함으로써, 가장 번거로워하던 사전 세팅(조합 추가) 작업만 제거하고, 나머지 마스터 관리 프로세스는 기존 거버넌스를 유지하도록 했다. 결과적으로 ‘자동화로 편해지지만, 데이터 거버넌스는 깨지지 않는’ 선을 찾는 것이 설계의 핵심 기준이었다.
📌 구현 방식(How?)
1) 입고일 유효성 검사(Date Validation)
입고일 입력 시 다음 규칙을 즉시 검증하여 잘못된 날짜 입력을 사전 차단했다.
- 오늘 기준 7일 이전까지만 허용
- ‘실제 업무에서 소급 처리가 필요한 최대 기간’을 기준으로 7일로 정의
- 미래날짜 자동 차단
- 명확한 메시지로 오류 원인 안내
→ 반복적으로 발생하던 입고일 및 회계 불일치 오류를 입력 단계에서 원천 방지했다.
2) 플랜트·창고 운영 상태 Validation
입고 생성 시 선택된 플랜트과 창고의 운영 여부를 즉시 검증해 잘못된 저장위치 선택을 막았다.
검증 항목
- 운영(Active)
- 미운영(Inactive)
- 삭제(Delete)
- 재고 반영 가능 여부
오류 발견 시
- 팝업 경고
- GR 생성 차단
- 대체 창고/플랜트 서치헬프
→ 잘못된 장소로 재고가 반영되는 사고를 시스템이 선제적으로 차단하도록 설계했다.
창고/플랜트 상태를 엄격하게 검증한 이유는,
현업에서 ‘테스트용’으로 열어둔 창고나 더 이상 사용하지 않는 창고에 입고가 들어가는 등 재고조정 업무가 과도하게 발생할 수 있기 때문이다.
운영 주체가 ‘사용 안 한다’고 판단한 저장 위치는 아예 입고 자체가 불가능하도록 시스템 통제 수준을 끌어올렸다.
3) DONUM 기반 문서 Validation + 입고/반품 자동 분기
GR 생성 시 DONUM 규칙으로 원본 문서를 자동으로 구분한다.
- 1xxxx → PO 기반 정상 입고
- 4xxxx → GI 기반 반품 입고
추가로 참조 문서 상태도 동시에 검증한다.
- 삭제된 문서(LOEKZ)
- 입고 완료된 Item
- 0수량 Item
→ 삭제·완료·무효 Item을 GR 생성 단계에서 자동 제외하여
정상 입고·반품 입고 로직을 정확하게 분리 처리할 수 있는 기반을 마련했다.
4) 메시지 클래스 통합 + Popup Utility 정비
모든 Validation 및 경고 메시지를 단일 메시지 클래스로 통합하여:
- 규칙·문구의 일관성 확보
- 다국어 대응 용이
- 유지보수 비용 감소
- 사용자에게 이해 쉬운 메시지 제공
기존에는 유사한 오류라도 프로그램마다 다른 메시지와 코드가 섞여 있어서, 오류 로그만 보고는 정확한 원인을 추적하기 어려웠다.
그래서 Validation 관련 메시지를 하나의 메시지 클래스로 일원화하고 코드 체계도 통합해, 장애 분석 시 ‘메시지 코드만으로도 어떤 레이어에서 막힌 건지’를 바로 인지할 수 있도록 하였다.
또한 Function Group 팝업스크린으로 다음 정보를 화면 이동 없이 조회할 수 있도록 했다.
- 자재 상세 정보
- 플랜트·창고 기본 정보
- 참조 문서 정보
- 담당자 정보
동시에 여러 화면에서 동일한 조회 스크린을 공통으로 재사용할 수 있도록 했다.
공용 FG 팝업을 두면서, 화면마다 비슷한 조회 로직과 UI를 중복 개발하지 않고 한 곳에서만 유지보수하면 되기 때문에, 개발 및 운영 비용을 줄이면서도 사용자 경험(UI/메시지)을 일관되게 유지할 수 있도록 했다.
5) 일반 입고(PO 기반) 재고 반영 로직
일반 입고(1xxxx) 시:
- GR Item 수량만큼 재고(matqty) 증가
- 동일 자재라도 플랜트/창고/사이즈/자재그룹 조합별로 분리 관리
→ 표준 재고 흐름을 유지하면서도
각 사업장·창고·라인의 재고 상태를 독립적으로 관리할 수 있게 했다.
6) 반품 입고(GI 기반) 재고 반영 분기
반품 입고(4xxxx)는 반품 사유에 따라 재고 반영을 자동 분기한다.
- 정상 반품 → 재고 증가
- 불량 반품 → 재고 미반영 (GR 문서만 생성)
→ 정상 입고와 반품 입고를 동일하게 처리해 발생하던
재고 과반영·중복 반영 문제를 구조적으로 차단했다.
7) ‘자재 × 플랜트 × 창고 × 사이즈’ 조합 자동 생성
입고(GR) 시점에 재고 테이블을 조회해 조합이 없으면:
- 신규 레코드 자동 INSERT
- 있으면 기존 matqty UPDATE
→ 운영자가 사전에 테이블을 세팅할 필요 없이,
입고 프로세스 자체가 신규 조합을 자동 생성하는 기준점으로 동작하도록 했다.
