SAP 반품/크레딧메모 처리 현황 — 입고는 됐는데 왜 환급이 안 됐을까
반품 접수, 반품입고, 크레딧메모 발행. 세 단계 중 어디서 멈춰 있는지 라인 하나로 보여주는 화면입니다.
반품은 접수한다고 끝나지 않습니다. 창고에서 실물을 받아 반품입고를 확정해야 하고, 그 다음 회계·영업관리가 크레딧메모를 발행해야 고객에게 대금이 돌아갑니다. 세 단계 각각은 SAP 표준에서 잘 처리되지만, "이 반품 건이 지금 어디서 멈춰 있는지"를 한 화면에서 보려면 반품주문(VA05) · 반품배송 · 크레딧메모(VF05)를 따로 조회해 손으로 대조해야 합니다.
SAP 표준 반품주문과 크레딧메모 데이터 구조를 그대로 이어받아 반품 라인아이템 기준으로 세 단계를 한 줄에 결합하고, 접수·입고 각 단계에서 정해둔 처리기한을 넘긴 건을 자동으로 골라내도록 OpenUI5 화면으로 확장했습니다. 기존에 공개한 수주잔량·미청구(정상 주문의 출고 전 단계)나 신용블록(여신한도로 막힌 주문) 화면과 달리, 이 화면은 반품이 접수된 이후의 후속 처리를 다룬다는 점이 다릅니다. 실제 구동 화면 4종을 함께 공개합니다.
SAP 표준 기능을 그대로 이어받은 부분
- 반품주문 — 헤더(
VBAK)와 아이템(VBAP), 주문유형RE구조를 그대로 사용 - 반품입고 — 반품배송(
LIPS/LIKP), 이동유형651 - 크레딧메모 — 빌링 헤더·라인(
VBRK/VBRP), 빌링유형G2 - 고객·자재 마스터 —
KNA1·MAKT
| 항목 | 내용 |
|---|---|
| 업무 영역 | 영업(SD) · 반품/크레딧메모 처리 |
| Namespace | zui5.retcredit |
| 셸 구조 | 조회조건 영역(우측 조회) + 반품 라인아이템 결과 테이블, 상세 Dialog |
| 화면 수 | 조회 화면 1개 + 상세보기 Dialog |
| 대응 T-code | VA05(주문유형 RE) · VF05(빌링유형 G2) |
| 성격 | 조회·모니터링형 — 반품주문 생성·입고·크레딧메모 발행은 표준 트랜잭션이 담당 |
| UI 테마 | sap_horizon 단일 적용 |
실제 화면 4종 둘러보기
영업조직·반품사유·고객·자재·기간을 조회조건에 넣고 조회하면 라인아이템별 처리현황이 지연 우선으로 정렬돼 뜹니다 → 상세보기로 입고·크레딧메모 이력과 산출근거를 확인합니다.
아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.
조작 방법
- 영업조직·반품사유 드롭다운, 고객/자재 텍스트, 반품접수일(부터/까지), 처리상태 중 필요한 조건을 입력합니다(모두 선택 사항).
- [조회] 버튼을 누르거나 입력 필드에서 Enter 키를 누르면 바로 재조회됩니다.
- 결과는 처리상태 우선순위(지연 → 입고완료 → 반품접수 → 크레딧완료)로 정렬되어, 가장 급한 건이 위에 옵니다.
- 행의 상세 아이콘을 누르면 반품입고이력·크레딧메모·산출근거를 확인할 수 있습니다.
- [CSV 다운로드]로 현재 조회 결과를 UTF-8 BOM CSV 로 내려받습니다.
처리상태 판정 로직
이 화면의 핵심은 "지금 지연되고 있는 반품 건"을 자동으로 골라내는 것입니다. 판정은 반품입고·크레딧메모 존재 여부와 경과일수, 두 축으로 이뤄집니다.
| 상태 | 판정 기준 | 배지 |
|---|---|---|
| 반품접수 | 반품이 접수됐고 아직 입고 전 (접수 후 7일 이내) | 반품접수 |
| 입고완료 | 반품입고까지 완료, 크레딧메모 발행 대기 (입고 후 5일 이내) | 입고완료 |
| 지연 | 위 두 단계 중 하나가 임계일수를 초과 — SLA 위반 후보 | 지연 |
| 크레딧완료 | 크레딧메모까지 발행 완료 (처리 종결) | 크레딧완료 |
임계치는 화면 상수로 관리
입고대기 7일, 크레딧대기 5일이라는 기준은 화면 컨트롤러 상단의 상수 두 개로 관리됩니다. 회사마다 반품 SLA 정책이 다르므로, 실제 도입 시에는 이 값을 조직 기준에 맞춰 조정하는 것을 전제로 합니다.
반품 처리 3단계
반품 한 건이 완결되기까지 순서대로 세 단계를 거칩니다. 이 화면은 각 단계의 완료 여부와 그 사이에 걸린 기간을 라인 하나로 보여줍니다.
| 단계 | 내용 |
|---|---|
| ① 반품 접수 | 고객 요청으로 반품주문(주문유형 RE)을 원거래(주문/인보이스) 참조로 생성. 반품수량·반품사유가 이 시점에 확정 |
| ② 반품입고 | 물류창고가 실물을 인수하면 반품배송(이동유형 651)으로 입고 처리. 부분입고도 실제 입고수량으로 반영 |
| ③ 크레딧메모 발행 | 입고 확인 후 크레딧메모(빌링유형 G2)를 발행해 고객 계정에 대금을 환급. 발행까지 걸린 기간을 함께 관리 |
조회조건
| 필드 | 설명 |
|---|---|
| 영업조직 | Vkorg 코드 선택 (전체 포함) |
| 반품사유 | 불량/오배송/초과주문취소/단순변심/파손 5종 코드 선택 |
| 고객(코드/명) | 고객코드 또는 고객명 부분일치 |
| 자재(코드/명) | 자재코드 또는 자재명 부분일치 |
| 반품접수일(부터/까지) | 접수일 구간 필터 |
| 처리상태 | 반품접수/입고완료/지연/크레딧완료 선택 |
결과 컬럼
| 컬럼 | 의미 · 표시 |
|---|---|
| 반품주문번호 · Item | 반품주문 라인아이템 키 |
| 고객코드 · 고객명 | 텍스트 검색 대상 |
| 영업조직 | 코드와 텍스트를 함께 표시 |
| 자재코드 · 자재명 | 텍스트 검색 대상 |
| 반품수량 · 반품금액 | 우측정렬, 천단위 콤마 |
| 반품사유 | 코드 텍스트로 표시 |
| 반품접수일 | YYYY.MM.DD 형식 |
| 경과일수 | 접수일 기준 오늘까지(완료건은 크레딧메모 발행일까지) 경과일 |
| 처리상태 | 아이콘·색상으로 강조된 배지 |
SAP 표준 기능 매핑
표준 실행은 T-code 가 그대로 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다.
| 단계 | SAP 표준 화면 | 이 앱이 더하는 것 |
|---|---|---|
| 반품주문 조회 | VA05(주문유형 RE) | 입고·크레딧메모 진행상태를 같은 줄에 결합 |
| 반품입고 조회 | VL06O 계열 · MB51(이동유형 651) | 반품주문 라인아이템에 자동 매칭 |
| 크레딧메모 조회 | VF05(빌링유형 G2) | 발행까지 걸린 경과일수를 자동 계산 |
도입 시 확인이 필요한 부분
지연 판정 임계치(7일/5일)는 회사 반품 SLA 정책에 맞춰 조정합니다. 반품사유 코드 체계와 크레딧메모 부분발행(일부 수량만 환급) 처리 규칙도 실제 도입 조직의 운영 기준을 따라야 합니다.
참고 CDS 뷰
운영 서비스로 연결할 때를 가정한 참고용 설계입니다(이 화면은 OData 를 구현하지 않고 mock JSON 으로 동작합니다).
@AbapCatalog.sqlViewName: 'ZLSDRETCREDIT'
@EndUserText.label: '반품/크레딧메모 처리 현황 (Z)'
define view Z_C_SD_RETURN_CREDIT_STATUS
as select from vbap as Item
inner join vbak as Header on Header.vbeln = Item.vbeln
left outer join lips as Delivery on Delivery.vgbel = Item.vbeln
and Delivery.vgpos = Item.posnr
left outer join vbrp as CreditLine on CreditLine.aubel = Item.vbeln
and CreditLine.aupos = Item.posnr
{
key Item.vbeln as ReturnOrder,
key Item.posnr as ReturnItem,
Header.kunnr as Customer,
Header.vkorg as SalesOrg,
Item.matnr as Material,
Item.retmenge as ReturnQty,
Item.netwr as ReturnAmount,
Item.grund as ReasonCode,
Header.erdat as RequestDate,
Delivery.lfimg as ReceivedQty,
Delivery.wadat_ist as ReceivedDate,
CreditLine.vbeln as CreditMemo,
CreditLine.netwr as CreditAmount,
CreditLine.fkdat as CreditDate
// 처리상태(지연 판정)는 연장 뷰 또는 화면 계산 로직에서 산출
}
매핑 이해를 돕기 위한 참고용 설계이며, 실제 도입 시에는 반품 프로세스 커스터마이징(이동유형·빌링유형 설정)에 맞춰 조정합니다.
OpenUI5 구성
| 기능 | 사용 컨트롤 |
|---|---|
| 화면 골격 | sap.f.DynamicPage — 조회조건(Header) + 결과 테이블(Content) |
| 조회조건 | sap.m.Select · sap.m.Input · sap.m.DatePicker — 우측 끝에 조회 버튼, Enter 키 조회 지원 |
| 결과 테이블 | sap.ui.table.Table — 컬럼 9개, 상태별 행 하이라이트(RowSettings) |
| 상세보기 | sap.m.Dialog — 요약 카드(ObjectNumber/ObjectStatus) + 이력 테이블 3종 |
| 데이터 | OData 미구현 — ModelMock 이 localdata/*.json 을 fetch, Promise 로 제공 |
| 다운로드 | CSV(UTF-8 BOM) — BaseController.downloadCsv 공통 함수 |
파일 구성
| 경로 | 역할 |
|---|---|
index.html | OpenUI5 부트스트랩 — sap_horizon · lodash · moment |
Component.js | 디바이스 모델 초기화, 라우터 시작 |
manifest.json | 앱 디스크립터 — 앱 ID(zui5.retcredit) · ko 로케일 |
view/Main.view.xml · fragments/* | 조회조건 · 결과 테이블 · 상세 Dialog |
controller/Main.controller.js | 조회 · 처리상태 판정 · 상세보기 · CSV |
model/ModelMock.js | localdata JSON 읽기(Promise) |
js/formatter.js | 금액 · 일자 · 상태 배지 포맷 |
i18n/i18n_ko.properties | ko 로케일 리소스 |
localdata/retitems.json 등 | 반품 라인아이템 · 입고이력 · 크레딧메모 검증용 데이터 |
검증 결과
화면 구성에 쓴 데이터는 반품주문 44건 · 라인아이템 79건이며, 반품입고 74건 · 크레딧메모 52건이 반영돼 있습니다.
| 검증 항목 | 결과 |
|---|---|
| 반품입고수량 ≤ 반품수량 (전건) | 통과 |
| 반품입고일 ≥ 반품접수일, 크레딧메모발행일 ≥ 반품입고일 | 통과 |
| 크레딧메모금액 = 실제 입고수량 × 자재단가 | 통과 |
| XML/JSON 전체 파싱 · i18n 키 누락 0건 | 통과 |
| 조회 버튼 위치(조회조건 영역 우측) · 적용 테마(sap_horizon) | 통과 |
| Enter 키 조회 실동작 | 통과 |
| 화면 렌더링 — 실브라우저에서 조회 → Enter 조회 → 상세보기 실동작 후 캡처 | 4/4 |
고객·자재·금액은 모두 검증용 데이터입니다.
자주 묻는 질문
처리상태(지연)는 어떻게 판정하나요?
크레딧메모가 있으면 완료로 봅니다. 없다면 반품입고 여부를 봅니다 — 입고됐는데 크레딧메모가 5일 넘게 없으면 지연, 아직 입고 전인데 접수한지 7일이 넘었으면 역시 지연으로 판정합니다. 두 임계치는 회사 SLA 정책에 맞춰 조정할 수 있는 값입니다.
부분입고나 부분 크레딧메모는 반영되나요?
반영됩니다. 반품수량보다 적게 입고된 부분입고 케이스를 포함했고, 크레딧메모 금액은 신청수량이 아니라 실제 입고수량을 기준으로 계산합니다.
기존에 공개한 수주잔량·신용블록 화면과는 무엇이 다른가요?
수주잔량·미청구 화면은 정상 주문이 출고·청구되기 전 단계를 다루고, 신용블록 화면은 여신 한도로 막힌 주문을 다룹니다. 이 화면은 반품이 접수된 이후 입고와 크레딧메모로 이어지는 후속 처리 단계를 다룬다는 점이 다릅니다.
SAP 표준 기능과 어떻게 이어지나요?
반품주문 생성과 반품배송, 크레딧메모 발행은 모두 표준 트랜잭션이 담당하고 VBAP·LIPS·VBRK/VBRP에 그대로 남습니다. 이 화면은 그 세 데이터를 라인 단위로 결합해 지금 어디서 멈춰 있는지를 조회·검증 관점에서 보여주도록 확장한 것입니다.