솔루션 홈
VA05 · VF05 · 반품 크레딧메모

SAP 반품/크레딧메모 처리 현황 — 입고는 됐는데 왜 환급이 안 됐을까

반품 접수, 반품입고, 크레딧메모 발행. 세 단계 중 어디서 멈춰 있는지 라인 하나로 보여주는 화면입니다.

반품은 접수한다고 끝나지 않습니다. 창고에서 실물을 받아 반품입고를 확정해야 하고, 그 다음 회계·영업관리가 크레딧메모를 발행해야 고객에게 대금이 돌아갑니다. 세 단계 각각은 SAP 표준에서 잘 처리되지만, "이 반품 건이 지금 어디서 멈춰 있는지"를 한 화면에서 보려면 반품주문(VA05) · 반품배송 · 크레딧메모(VF05)를 따로 조회해 손으로 대조해야 합니다.

SAP 표준 반품주문과 크레딧메모 데이터 구조를 그대로 이어받아 반품 라인아이템 기준으로 세 단계를 한 줄에 결합하고, 접수·입고 각 단계에서 정해둔 처리기한을 넘긴 건을 자동으로 골라내도록 OpenUI5 화면으로 확장했습니다. 기존에 공개한 수주잔량·미청구(정상 주문의 출고 전 단계)나 신용블록(여신한도로 막힌 주문) 화면과 달리, 이 화면은 반품이 접수된 이후의 후속 처리를 다룬다는 점이 다릅니다. 실제 구동 화면 4종을 함께 공개합니다.

SAP 표준 기능을 그대로 이어받은 부분

  • 반품주문 — 헤더(VBAK)와 아이템(VBAP), 주문유형 RE 구조를 그대로 사용
  • 반품입고 — 반품배송(LIPS/LIKP), 이동유형 651
  • 크레딧메모 — 빌링 헤더·라인(VBRK/VBRP), 빌링유형 G2
  • 고객·자재 마스터 — KNA1 · MAKT
항목내용
업무 영역영업(SD) · 반품/크레딧메모 처리
Namespacezui5.retcredit
셸 구조조회조건 영역(우측 조회) + 반품 라인아이템 결과 테이블, 상세 Dialog
화면 수조회 화면 1개 + 상세보기 Dialog
대응 T-codeVA05(주문유형 RE) · VF05(빌링유형 G2)
성격조회·모니터링형 — 반품주문 생성·입고·크레딧메모 발행은 표준 트랜잭션이 담당
UI 테마sap_horizon 단일 적용

실제 화면 4종 둘러보기

영업조직·반품사유·고객·자재·기간을 조회조건에 넣고 조회하면 라인아이템별 처리현황이 지연 우선으로 정렬돼 뜹니다 → 상세보기로 입고·크레딧메모 이력과 산출근거를 확인합니다.

아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.

sd006_retcredit — Main.view.xml
메인화면 초기 진입
메인화면 초기 진입 — 영업조직·반품사유·고객/자재 텍스트·반품접수일 구간·처리상태로 이뤄진 조회조건 영역입니다. 조회 버튼은 하단이 아니라 조회조건 영역 오른쪽 끝에 있습니다.
sd006_retcredit — Enter 키 조회
Enter 키 조회 결과
Enter 키 조회 — 고객(코드/명) 입력란에 텍스트를 넣고 Enter 를 누르면 버튼을 누르지 않아도 바로 재조회됩니다.
sd006_retcredit — 전체 조회 결과
전체 조회 결과 — 지연 우선 정렬
전체 조회 결과 — 지연 우선 정렬 — 왼쪽 색상 막대가 처리상태를 나타냅니다(빨강 지연 · 주황 입고완료/크레딧대기 · 초록 크레딧완료). 처리상태 우선순위로 정렬돼 가장 급한 건이 위로 올라옵니다.
sd006_retcredit — 상세보기
상세보기 다이얼로그
상세보기 다이얼로그 — 반품·입고·크레딧메모 수량 및 금액 요약 카드에 이어, 반품입고이력·크레딧메모·산출근거 3개 테이블이 함께 열립니다.

조작 방법

  1. 영업조직·반품사유 드롭다운, 고객/자재 텍스트, 반품접수일(부터/까지), 처리상태 중 필요한 조건을 입력합니다(모두 선택 사항).
  2. [조회] 버튼을 누르거나 입력 필드에서 Enter 키를 누르면 바로 재조회됩니다.
  3. 결과는 처리상태 우선순위(지연 → 입고완료 → 반품접수 → 크레딧완료)로 정렬되어, 가장 급한 건이 위에 옵니다.
  4. 행의 상세 아이콘을 누르면 반품입고이력·크레딧메모·산출근거를 확인할 수 있습니다.
  5. [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 미구현 — ModelMocklocaldata/*.json 을 fetch, Promise 로 제공
다운로드CSV(UTF-8 BOM) — BaseController.downloadCsv 공통 함수

파일 구성

경로역할
index.htmlOpenUI5 부트스트랩 — 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.jslocaldata JSON 읽기(Promise)
js/formatter.js금액 · 일자 · 상태 배지 포맷
i18n/i18n_ko.propertiesko 로케일 리소스
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에 그대로 남습니다. 이 화면은 그 세 데이터를 라인 단위로 결합해 지금 어디서 멈춰 있는지를 조회·검증 관점에서 보여주도록 확장한 것입니다.

반품 처리 지연, 지금 쓰는 SAP 위에서 바로 확인해 보세요

반품주문·반품입고·크레딧메모를 따로 조회해 손으로 대조하는 대신, 라인 하나로 지연 여부를 바로 걸러내면 반품 SLA 관리 시간이 줄어듭니다. 현재 SAP 환경 기준으로 어떻게 적용되는지 함께 확인해 드립니다.

SAP 반품크레딧메모VA05VF05VBAPVBRK반품입고OpenUI5