SAP 리베이트 계약 현황 — 계약 기간은 끝났는데 정산은 안 끝났다

고객 리베이트 계약은 대개 1년 단위로 등록됩니다. 그 1년 동안 청구가 쌓이고, 쌓인 매출실적에 조건율을 곱해 리베이트가 계산되고, 분기마다 또는 계약이 끝나는 시점에 정산이 실행됩니다. 문제는 계약 유효기간이 끝난다고 시스템이 저절로 "이 계약은 이제 정산해야 합니다"라고 알려주지는 않는다는 점입니다. 최종정산(VBOF)을 실행하기 전까지는 발생액이 계속 잔액으로 남아 있을 뿐이고, 계약 건수가 수십 건을 넘어가면 담당자가 어느 계약을 놓쳤는지 눈으로 훑어보기 어려워집니다.

이 화면은 앞서 공개한 매출 가격조건 현황(조건 레코드의 유효기간 임박·만료를 보는 화면)과는 판정축이 다릅니다. 가격조건은 유효기간 하나만 보면 상태가 정해지지만, 리베이트 계약은 유효기간과 잔여발생액 두 축을 함께 봐야 "계약은 끝났는데 아직 정산이 안 된 건"을 가려낼 수 있습니다. SAP 표준 리베이트 계약(VBO1) 데이터 구조를 그대로 이어받아, 누적매출실적 → 발생리베이트(예상) → 기지급액 → 잔여발생액의 흐름과 선등록·진행중·정산예정·정산완료 4단계 상태를 화면에서 계산해 보여주도록 OpenUI5 화면으로 확장한 것이 ZLSD0090입니다. 실제 구동 화면 5종을 함께 공개합니다.

실제 화면 5종 둘러보기

계약유형·판매조직·고객·정산상태·조회 기준일을 넣고 조회하면 계약이 목록으로 뜹니다 → 계약번호로 다시 좁혀보고 → 계약을 골라 기본정보·월별 매출실적·정산이력을 확인합니다.

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

Main.view.xml

계약번호 조회

상세 · 기본정보

상세 · 월별 매출실적

상세 · 정산이력

조작 방법

1. 계약번호·계약유형·판매조직·고객·정산상태는 필터로 좁혀볼 수 있으며, 계약번호·고객은 코드나 이름 일부만 입력해도 부분일치로 걸립니다.
2. 조회 기준일 기본값은 오늘입니다. 날짜를 바꾸면 그 시점 기준으로 정산상태가 다시 계산됩니다.
3. 조회조건 입력필드에서 Enter 를 눌러도 바로 재조회됩니다. 조회·초기화 버튼은 조회조건 영역 오른쪽 끝에 있습니다.
4. 목록에서 행을 클릭하면 상세 다이얼로그가 열립니다. 기본정보·월별 매출실적·정산이력 세 탭을 오갑니다.
5. 정산이력이 없는 계약(아직 한 번도 정산되지 않은 계약)은 "정산 이력이 없습니다"로 표시됩니다.
6. 목록은 CSV 다운로드로 내려받습니다. 현재 필터링된 결과만 담기며, UTF-8 BOM 이 붙어 엑셀에서 한글이 깨지지 않습니다.

정산 상태 4단계 판정 로직

이 화면의 핵심은 목록이 아니라 조회 기준일 대비 재계산입니다. 표준 트랜잭션은 계약 유효기간이 끝나도 자동으로 "정산 필요" 표시를 하지 않으므로, 이 화면이 유효기간과 잔여발생액 두 축을 함께 보고 담당자가 놓치기 쉬운 상태를 대신 판정합니다.

리베이트 발생액 계산 5단계

계약 하나의 발생액이 얼마인지 확정하기까지, 화면이 참고자료로 정리한 처리 흐름입니다.

실제 정산 실행(리베이트 크레딧 메모 발행)은 표준 트랜잭션(VBOF)이 담당하며, 이 화면은 그 이전 단계의 수치를 투명하게 보여주는 역할만 합니다.

조회조건

결과 컬럼

SAP 표준 기능 매핑

이 화면이 조회하는 데이터와 판정 기준은 SAP 표준 리베이트 처리 구조를 그대로 이어받습니다. 표준 실행은 VBO1·VBO2·VBO3(계약 생성·변경·조회)과 VBOF(최종정산)가 담당하고, 이 화면은 그 결과를 정산 진행 관점에서 확장한 것입니다 — 실행 자체를 대체하지 않습니다.

참고 CDS 뷰

운영 서비스로 연결할 때는 계약 헤더·조건·정산이력을 결합한 뷰로 서빙하는 구성을 제안합니다.

@AbapCatalog.sqlViewName: 'ZLSDREBATE'
@EndUserText.label: '리베이트 계약 현황 조회용 (Z)'
define view Z_C_RebateAgreementStatus
  as select from kona as Agreement
    inner join      konp as Condition on  Condition.knumh = Agreement.knumh
    left outer join vbox as Settlement on Settlement.knuma_pi = Agreement.knuma
{
  key Agreement.knuma           as AgreementNo,
      Agreement.botyp           as AgreementType,
      Agreement.vkorg           as SalesOrg,
      Agreement.datab           as ValidFrom,
      Agreement.datbi           as ValidTo,
      Agreement.bonba           as CapAmount,
      Condition.kschl           as ConditionType,
      Condition.kbetr           as Rate,
      sum(Settlement.bonba)     as PaidAmount,
      // 발생리베이트는 누적매출실적(별도 집계) × Rate 로 애플리케이션 레이어에서 계산,
      // CapAmount 가 있으면 상한 적용
      case when Agreement.datbi < $session.system_date and sum(Settlement.bonba) < 0
           then 'DUE' else 'ACTIVE' end as StatusHint
}
group by Agreement.knuma, Agreement.botyp, Agreement.vkorg,
         Agreement.datab, Agreement.datbi, Agreement.bonba,
         Condition.kschl, Condition.kbetr

매핑 이해를 돕기 위한 참고용 설계입니다. 실제 도입 시에는 누적매출실적 집계 원천(청구 실적 갱신 구조)과 정산이력 테이블의 커스터마이징 여부를 함께 확인해야 합니다.

OpenUI5 구성

파일 구성

운영 전환 시에는 ModelMock 내부만 실제 서비스 호출로 바꾸면 화면과 판정 로직은 그대로 씁니다.

검증 결과

화면 구성에 쓴 데이터는 리베이트 계약 46건(정산예정 8건 · 진행중 24건 · 정산완료 14건)이며, 발생액·정산액 항등식까지 전수 검증했습니다.

고객·계약번호·금액은 모두 검증용 데이터입니다.

자주 묻는 질문