SAP GR/IR 미결정산 현황 — 입고와 송장이 맞물리지 않은 자리
구매오더별 입고 수량·금액과 송장 수량·금액의 차이를 계산해 GR/IR 잔액을 만들고, 결산 정리 대상과 정리 전표를 미리 확인하는 화면입니다.
GR/IR 계정은 물건은 들어왔는데 송장은 아직인, 혹은 그 반대인 상태를 담는 임시 자리입니다. 정상이라면 둘이 맞물리면서 잔액이 0으로 사라집니다.
남아 있다면 수량이 다르거나 금액이 다르거나입니다. 결산 전에 이 잔액을 설명하지 못하면 재고와 채무가 동시에 흔들립니다. 표준 GR/IR 구조를 그대로 이어받아 차이를 수량·금액으로 갈라 보여 주고 정리 대상까지 판정하도록 OpenUI5 화면으로 확장한 것이 이 앱입니다. 실제 구동 화면 3종을 함께 공개합니다.
SAP 표준 기능을 그대로 이어받은 부분
- 구매오더 — 오더번호(
Ebeln) · 품목(Ebelp) 키를 그대로 사용 - 입고 · 송장 실적 — 입고 수량(
MengeWe) · 금액(BetrWe), 송장 수량(MengeRe) · 금액(BetrRe) - GR/IR 계정 — 계정(
Konto)과 명칭으로 원재료·상품 등 구분 - 공급업체 · 플랜트 — 벤더(
Lifnr) · 플랜트(Werk)와 명칭 - 최종 일자 — 마지막 입고일(
LastGrDate) · 마지막 송장일(LastReDate)
| 항목 | 내용 |
|---|---|
| 대응 T-code | MR11 (GR/IR 정리) · MB5S (입고·송장 차이) |
| 업무 영역 | 재무회계(FI) · 구매(MM) 연계 · 결산 |
| Namespace | zui5.grir |
| 셸 구조 | 조회조건 영역(우측 조회·초기화) + GR/IR 차이 목록, 행 선택 시 정리 전표 시뮬레이션 |
| 화면 수 | 조회 화면 1개 + 정리 전표 미리보기 |
| 데이터 | GR/IR 차이 25건 · 계정 4건 |
| 성격 | 조회·시뮬레이션형 — 실제 정리는 표준 MR11 이 담당 |
| UI 테마 | sap_horizon 단일 적용 |
실제 화면 3종 둘러보기
회사코드·플랜트·계정으로 조회하면 오더 품목별 입고·송장 차이가 나옵니다 → 수량 차이와 금액 차이를 나눠 보고 → 정리 대상 건은 전표 시뮬레이션으로 분개를 미리 확인합니다.
아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.
조작 방법
- 회사코드와 플랜트를 고릅니다. 공장별로 GR/IR 성격이 달라 나눠 보는 것이 편합니다.
- GR/IR 계정으로 원재료·상품 등 성격을 나눕니다.
- 조회조건 입력필드에서 값을 바꾸거나 Enter 를 누르면 즉시 조회됩니다.
- 수량 차이가 있는 건과 금액 차이만 있는 건을 나눠 봅니다. 원인이 다릅니다.
- 마지막 입고일·송장일이 오래된 건은 잊힌 잔액일 가능성이 큽니다.
- 행을 선택하면 정리 전표가 시뮬레이션됩니다. 실제 정리는 표준 MR11 로 실행합니다.
- 결과는 CSV 다운로드로 내려받아 결산 조서에 첨부합니다.
차이 판정 규칙
차이는 두 축으로 갈립니다. 수량이 다른가, 단가가 다른가.
수량 차이 = 입고 수량(MengeWe) − 송장 수량(MengeRe)
금액 차이 = 입고 금액(BetrWe) − 송장 금액(BetrRe)
GR/IR 잔액 = 금액 차이
수량 차이 ≠ 0 → 입고·송장 수량 불일치 (미착 또는 미청구)
수량 차이 = 0, 금액 ≠ 0 → 단가 차이 (구매가격차이)
둘 다 0 → 정상 정산 — 잔액 없음
수량과 금액을 나눠 보는 이유
잔액만 보면 원인이 보이지 않습니다. 수량이 맞는데 금액만 다르면 단가 문제라 구매 계약이나 환율을 봐야 하고, 수량이 다르면 물건이 덜 왔거나 송장이 안 온 것이라 입고 담당이나 벤더에게 확인해야 합니다. 찾아갈 사람이 달라집니다.
GR/IR 잔액이 남는 네 가지 경우
| 경우 | 상황 | 다음 조치 |
|---|---|---|
| 입고 후 송장 미도착 | 물건은 왔는데 청구서가 아직 | 벤더에 송장 요청 |
| 송장 후 입고 미완 | 선청구 또는 미착 | 입고 예정 확인 |
| 단가 불일치 | 발주 단가와 송장 단가가 다름 | 구매 계약·가격 조건 확인 |
| 잔량 종결 | 일부만 납품되고 오더가 닫힘 | MR11 로 잔액 정리 |
조회조건
| 필드 | 필수 | 설명 |
|---|---|---|
회사코드 Bukrs | 필수 | 대상 회사코드 |
플랜트 Werk | 선택 | 공장 단위 |
GR/IR 계정 Konto | 선택 | 원재료·상품 등 계정 |
공급업체 Lifnr | 선택 | 벤더 코드·명칭 |
구매오더 Ebeln | 선택 | 특정 오더만 |
| 기준일 | 선택 | 정리 대상 판정 기준 |
결과 컬럼
| 컬럼 | 의미 · 표시 |
|---|---|
플랜트 Werk · WerkText | 공장 코드와 명칭 |
구매오더 Ebeln · 품목 Ebelp | 오더 키 |
자재 Matnr · Txz01 | 자재코드와 명칭 |
공급업체 Lifnr · Name1 | 벤더 코드와 명칭 |
GR/IR 계정 Konto · KontoText | 계정과 명칭 |
발주 수량 Bstmg · 금액 Bstwrt | 오더 기준 |
입고 수량 MengeWe · 금액 BetrWe | GR 실적 |
송장 수량 MengeRe · 금액 BetrRe | IR 실적 |
| 수량 차이 · 금액 차이 | 입고 − 송장. 0이 아니면 상태 색 |
최종 입고일 LastGrDate · 최종 송장일 LastReDate | 마지막 움직임 |
SAP 표준 기능 매핑
| 표준 | 역할 | 이 화면에서의 확장 |
|---|---|---|
MR11 | GR/IR 계정 정리 | 정리 대상 판정과 전표 시뮬레이션을 먼저 제공 |
MB5S | 입고·송장 차이 리스트 | 수량과 금액 차이를 나눠 원인 구분 |
EKKO · EKPO | 구매오더 헤더 · 품목 | 발주 기준 수량·금액 |
EKBE | 구매오더 이력 — 입고 · 송장 | 실적 집계 원천 |
LFA1 | 공급업체 마스터 | 벤더 명칭 |
SKA1 | 계정 마스터 | GR/IR 계정 명칭 |
도입 시 확인이 필요한 부분
GR/IR 계정이 자재 유형이나 조달 형태별로 나뉘어 있으면 계정별로 정리 기준이 다를 수 있습니다. 또 MR11 로 정리할 때 차액을 어느 계정으로 보낼지(구매가격차이 또는 기타손익)가 설정에 따라 갈리므로, 시뮬레이션 계정이 실제 전기와 같은지 먼저 확인해야 합니다.
참고 CDS 뷰
@AbapCatalog.sqlViewName: 'ZCGRIR'
@EndUserText.label: 'GR/IR 미결정산 (Z)'
define view Z_C_GRIR_BALANCE
as select from ekpo as Item
inner join ekko as Header on Item.ebeln = Header.ebeln
left outer join lfa1 as Vendor on Header.lifnr = Vendor.lifnr
left outer join ekbe as Hist on Item.ebeln = Hist.ebeln
and Item.ebelp = Hist.ebelp
{
key Item.ebeln, key Item.ebelp,
Header.bukrs, Item.werks as Werk,
Item.matnr, Item.txz01,
Header.lifnr, Vendor.name1 as Name1,
Item.menge as Bstmg, Item.netwr as Bstwrt,
// 입고(GR)·송장(IR) 실적을 이력에서 갈라 집계
sum( case when Hist.vgabe = '1' then Hist.menge else 0 end ) as MengeWe,
sum( case when Hist.vgabe = '1' then Hist.dmbtr else 0 end ) as BetrWe,
sum( case when Hist.vgabe = '2' then Hist.menge else 0 end ) as MengeRe,
sum( case when Hist.vgabe = '2' then Hist.dmbtr else 0 end ) as BetrRe
// 차이 = 입고 − 송장, GR/IR 잔액 = 금액 차이 (소비 뷰에서 계산)
}
group by Item.ebeln, Item.ebelp, Header.bukrs, Item.werks, Item.matnr,
Item.txz01, Header.lifnr, Vendor.name1, Item.menge, Item.netwr
매핑 이해를 돕기 위한 참고용 설계입니다. 실제 도입 시에는 운영 환경 설정과 릴리즈에 맞춰 조정합니다.
OpenUI5 구성
| 기능 | 사용 컨트롤 |
|---|---|
| 화면 골격 | sap.m.Page + 조회조건 영역 · 차이 테이블 |
| 조회조건 | sap.m.Select · sap.m.DatePicker · sap.m.Input — 우측 끝에 조회·초기화 |
| 이벤트 | 모든 버튼이 onPAI 단일 진입점, fcCode 로 분기 |
| 차이 테이블 | sap.m.Table — 발주·입고·송장을 인접 열로 배치 |
| 차이 표시 | sap.m.ObjectStatus — 수량·금액 차이 구분 |
| 시뮬레이션 | sap.m.Dialog — 정리 전표 차대 미리보기 |
세 실적을 나란히 둔 이유
발주·입고·송장이 각각 다른 화면에 있으면 세 번 조회해 숫자를 옮겨 적게 됩니다. 한 줄에 붙여 두면 5,000개 발주에 5,000개 입고, 4,800개 송장 같은 상황이 한눈에 읽히고 어느 단계에서 끊겼는지 바로 나옵니다.
파일 구성
| 경로 | 역할 |
|---|---|
manifest.json | 앱 디스크립터 — 앱 ID(zui5.grir) · ko 로케일 |
view/Main.view.xml | 조회조건과 차이 테이블 |
controller/Main.controller.js | 조회 · 차이 계산 · 전표 시뮬레이션 · CSV |
model/ModelMock.js | localdata JSON 읽기(Promise) |
js/formatter.js | 수량 · 금액 · 상태 색 포맷터 |
localdata/grir.json | GR/IR 차이 25건 |
localdata/konto.json | GR/IR 계정 4건 |
검증 결과
| 검증 항목 | 결과 |
|---|---|
| 수량 차이 = 입고 수량 − 송장 수량 (전 건) | 통과 |
| 금액 차이 = 입고 금액 − 송장 금액 | 통과 |
| 정리 전표 차변 합계 = 대변 합계 | 통과 |
| 입고·송장 수량이 발주 수량을 초과하지 않음 | 통과 |
| 계정·벤더 코드가 있으면 명칭도 존재 | 통과 |
| XML · JSON 전체 파싱 | 오류 0건 |
| 화면 렌더링 — 실브라우저 조회 → 시뮬레이션 실동작 후 캡처 | 3/3 |
| 테마 런타임 확인 | sap_horizon |
자주 묻는 질문
GR/IR 잔액은 항상 정리해야 하나요?
아닙니다. 입고와 송장의 시차 때문에 생긴 잔액은 시간이 지나면 저절로 맞물립니다. 정리 대상은 오더가 종결됐는데 남은 잔액이나, 오래 움직임이 없는 건입니다.
수량은 맞는데 금액만 다르면 어떻게 하나요?
단가 차이입니다. 발주 단가와 송장 단가가 다르거나 환율이 달라진 경우이며, 구매 조건을 확인해 정당하면 구매가격차이로 처리하고 오류면 송장을 수정합니다.
MR11 로 정리하면 무엇이 바뀌나요?
GR/IR 계정 잔액이 사라지고 차액이 지정된 계정(구매가격차이 등)으로 넘어갑니다. 재고 수량은 바뀌지 않으므로, 수량 자체가 틀렸다면 입고 정정이 먼저입니다.
SAP 표준 기능과 어떻게 이어지나요?
입고와 송장은 표준 MM 프로세스가 만들고 이력은 구매오더 이력에 남습니다. 이 화면은 그 이력을 오더 품목 단위로 대조해 수량·금액 차이로 갈라 보여 주고, MR11 실행 전에 분개를 미리 확인하게 하는 확장입니다.