
프로젝트의 기준상 입고(GR)는 두 가지 서로 다른 프로세스에서 발생한다.
그러나 GR을 PO나 GI에 FK로 연결하는 구조로는 두 흐름을 하나의 입고 프로세스 안에서 처리할 수 없었다.
PO와 GI를 GR에 직접 FK로 물리게 되면,
입고 유형마다 서로 다른 테이블과 관계를 관리해야 해서 구조가 지나치게 복잡해지고, 테이블 설계부터 손봐야 하는 문제가 있었다.
그래서 이미 사용 중이던 DONUM (관련문서번호 필드)규칙을 공통 식별자로 재사용해,
두 프로세스를 하나의 GR 구조 안에서 통합하는 것을 설계 기준으로 삼았다.
현업에서는 동일 거래처의 여러 PO를 한 번에 입고 처리하는 경우가 많았기 때문에,
이를 반영하여 여러 PO의 Item을 하나의 GR 문서에서 참조할 수 있는 구조로 목표로 하였다.
또한, 하나의 PO에 하나의 GR이 대응되는 방식에서 발생하던
과 같은 문제를 개선하고자 하였다.
➡ 이에 따라, 정상입고와 반품입고를 하나의 처리 구조 안에서 통합 관리하면서,
여러 PO의 Item을 하나의 GR 문서에서 참조 및 집계할 수 있는 방식으로 설계하였다.
입고 문서의 Origin(생성 근거) 을 추적하기 위해
GR Item에 관련문서번호(DONUM) 를 공통 기준으로 설계했다.
💡DONUM 규칙
이 규칙을 기반으로 시스템은 GR 생성 시 자동으로 문서 타입을 판별한다.
➡ 정상입고/반품입고 흐름을 하나의 GR 구조에서 통합할 수 있는 구조적 기반 확보
➡ GR을 특정 문서에 FK로 연결하지 않아도 문서 흐름을 정확히 추적 가능

입고 라인아이템 테이블 - DONUM, DLNUM
PO, GI, GR 모두 Header–Item 구조로 통일하여
GR Item이 반드시 PO Item 또는 GI Item과 1:1로 매핑되도록 설계했다.
이를 통해
등 입고 처리의 효율성과 문서 간 일관성을 확보했다.
같은 거래처이면
사용자가 선택한 여러 PO의 Item을 모두 수집하여 GR Header 1건 아래에 배치한다.
➡ 입고 처리 속도 대폭 증가, 누락/중복 방지, 문서 수 감소
‘‘PO 한 건 → GR 한 건’ 구조에서는 동일 트럭에 실려 온 물량이라도 PO 개수만큼 나누어 반복 입력해야 했다. 이 과정에서 누락 및 중복 입력이나 상태 오류가 발생할 가능성이 높았다.
이에 따라, 기술 구조 역시 실제 업무 단위를 그대로 반영하여 여러 PO를 하나의 GR로 병합 처리할 수 있는 방향을 설계 기준으로 삼았다.
PO 상태를 담당자가 수기로 관리하는 경우,
부서별 해석 차이와 관리 기준 불일치로 인한 혼선이 발생할 가능성이 있었다.
이에 따라, PO 상태를 사람이 판단하는 것이 아니라 실제 입고 이력이 자동으로 정의하도록 설계하였다.
GR 생성 시 각 PO Item의 입고 수량을 분석하여,
로 PO header의 상태를 자동 판정하도록 로직을 구현하였다.


➡ 이를 통해, PO 관리의 정합성을 운영 단계에서 안정적으로 확보하였다
입고 이후 회계(FI)를 별도로 생성하는 방식은
문서 매칭 오류와 회계 반영 지연을 유발할 수 있었다.
이에 따라, 입고 시점(GR)을 회계 처리의 기준 시점으로 정의하고,
GR 생성과 동시에 FI 문서를 자동 생성하도록 설계하였다.
(※ Invoice 프로세스는 별도 흐름으로 운영되었으며, GR–FI 기준의 회계 반영 구조에 집중하였다.)
GR Header 정보를 기반으로 FI 문서를 생성하고,
GR–FI 간 참조 관계를 자동 설정함으로써 문서 연결이 즉시 확정되도록 구현하였다.
➡ 입고(GR) → 회계(FI) 프로세스가 한 번에 자동 완결되는 구조 확보
초기 운영 설계에서 별도의 Invoice 프로세스를 태우지 않기로 하면서, 실제 비용 인식의 기준 시점을 어디로 둘지에 대한 합의가 필요했다.
논의 결과,
물류 기준으로 재화가 실제 창고에 입고되는 시점(GR)을 재고 및 원가 등 회계 처리의 기준 시점으로 삼는 것이 가장 직관적이라고 판단해, GR 생성과 동시에 FI 문서를 함께 생성하는 구조를 채택했다.
이를 통해 Invoice 없이도 입고 기준으로 재고와 비용이 일관되게 반영되도록 했다.