SAP 수출 진행 단계 추적 지연 점검 — 수주부터 대금 회수까지 일곱 단계의 계획일과 실적일을 견줘 늦어진 단계를 찾는 수출 진행 관리 화면

도입 포인트 — 이 앱을 사용해야 하는 이유

수출 담당자가 매주 받는 질문은 같습니다. 이 건은 지금 어디까지 왔나, 어느 단계에서 늦어졌나, 누구에게 물어야 하나. 판매 오더 · 출하 · 청구 · 고객 반제 항목은 표준 화면으로 각각 볼 수 있지만, 수출 한 건을 수주부터 대금 회수까지 한 줄로 이어 ‘계획보다 며칠 늦었는가’ 를 단계마다 계산해 주는 화면은 표준에 없습니다. 이 앱은 그 한 줄을 만들어, 지연이 쌓이기 전에 늦은 단계를 찾도록 돕습니다.

핵심 포인트 여섯 가지

이 샘플에서 보이는 것

샘플 자료는 가상 해외 거래처 12곳의 수출 64건(통화 USD · EUR · JPY · CNY), 단계 448행입니다. 보류 건 2건을 빼고 62건을 판정하면 30건이 점검 필요입니다. 건별 최대 단계 지연일은 평균 4.44일이고 가장 긴 것은 14일입니다. 평균만 보면 가벼워 보이지만, 단계로 묶으면 선적 · 선하증권(B/L) 단계 15.87%, 수출통관 단계 19.35% 가 기준(15%)을 넘고 나머지 단계는 넘지 않습니다. 지연이 고르게 퍼져 있지 않고 서류가 오가는 두 단계에 몰려 있다는 사실이 이 화면의 첫 번째 발견입니다.

실행 화면

실제로 돌아가는 화면 7종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

조회조건은 회계연도(필수)와 거래처 · 통화 · 인코텀즈 · 현재 단계 · 수주일 범위 · 판정입니다. 앱을 열면 회계연도 2026 으로 바로 조회되어, 처음 여는 사람도 빈 화면을 보지 않습니다. 요약 여섯 칸은 아래 표와 같은 자료에서 다시 계산한 값이라 표와 어긋날 수 없습니다.

판정 칸 하나로 ‘지금 들여다볼 건’ 만 추립니다. 보류 건은 판정에서 빠지므로 이 목록에 나오지 않습니다. 조건을 바꿀 때마다 요약이 같이 바뀌어서, 목록과 숫자를 따로 맞춰 볼 필요가 없습니다.

단계 명세로 내려가기

“왜 점검 필요인가” 에 대한 답이 판정 근거 열에 날짜 계산식으로 적혀 있습니다. 끝나지 않은 단계는 실적일이 비어 있고, 기준일(2026-09-30)로 지연일을 셉니다.

건별로 보던 지연을 단계별로 묶으면 병목이 보입니다. 이 샘플에서는 선적·선하증권(B/L) 15.87%, 수출통관 19.35% 가 기준을 넘고 나머지 단계는 넘지 않습니다. 전체 지연일 평균이 4.44일로 낮아도 특정 단계에 쏠린 지연이 있다는 뜻입니다.

거래처와 대사

12개 거래처 가운데 네 곳이 기준을 넘습니다. 한 거래처의 건수가 적으면 비율이 크게 흔들리므로, 비율 옆에 판정 건수를 함께 둡니다.

화면의 숫자를 믿어도 되는지 스스로 검산한 결과입니다. 통화별 원화 환산을 따로 맞춘 이유는 통화가 다른 외화 금액을 그대로 더하면 의미가 없기 때문입니다.

단계별 · 거래처별 탭에서 행을 누르면 그 단계를 기다리는 건, 그 거래처의 건이 같은 창에 열립니다. 요약에서 건으로, 건에서 단계로 내려가는 길이 한 번의 클릭입니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

표준으로 되는 것과 안 되는 것

자료가 어디서 오는가

수출 한 건의 일곱 단계 일자는 한 테이블에 있지 않고 여러 문서에 흩어져 있습니다. 수주일은 판매 오더에서, 출하일은 출하 문서에서, 청구일은 청구 문서에서, 회수일은 고객 반제 항목에서 읽습니다. 반면 선적(B/L) 일자 · 수출통관 일자 · 네고 · 추심 일자는 고객사의 수출 구성(물류 모듈 · 무역 서류 연동 · 별도 테이블)에 따라 위치가 다르므로 이 글에서는 “확인 필요” 로 표시했습니다. 도입 때 가장 먼저 합의할 일이 이 세 일자의 출처입니다.

단계 정의와 기준값

위 표준 소요일과 허용 지연일은 샘플에서 가정한 값입니다. 실제 값은 회사의 거래 조건과 업무 기준으로 정해야 하며, 이 글은 규정 값(관세율 · 신고 기한 등)을 다루지 않습니다.

판정 규칙

화면을 열기 전에 정할 것

• 기준일 — 끝나지 않은 단계의 지연일을 어느 날짜로 셀지 정합니다. 샘플은 2026-09-30 로 고정했고, 운영에서는 조회일이나 마감일 가운데 정해야 합니다.
• 보류 건의 범위 — 협상 중이거나 선적 지시가 내려오지 않은 건을 판정에서 뺄지 정합니다.
• 표준 소요일과 허용 지연일 — 단계별 숫자를 거래 조건(인코텀즈 · 운송 방식)에 따라 나눌지 정합니다.
• 점검 필요 비율의 기준 — 단계 15%, 거래처 60% 는 샘플 값입니다.

CDS 구성

이 사례의 화면은 수출 64건 · 단계 448행을 서비스가 한꺼번에 돌려주고 브라우저가 요약을 다시 계산합니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일이 단계 계산과 집계를 CDS 로 내리는 것입니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다. 특히 선적(B/L) · 수출통관 · 네고 · 추심 일자의 출처는 확인 필요입니다.

뷰 레이어 구성

① 단계 기준 테이블

단계마다 표준 소요일과 허용 지연일을 정하는 자리입니다. 지연 판정의 모든 숫자가 이 표에서 갈리므로 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 두면 기준이 바뀌어도 지난 판정이 흔들리지 않습니다.

" ──────────────────────────────────────────────────────────
"  ZEXP_STAGE_STD — 수출 단계 기준 (투명 테이블)
"  코드에 박지 않는 이유 : 기준일수는 거래 조건이 바뀔 때마다 달라진다.
" ──────────────────────────────────────────────────────────
@EndUserText.label : '수출 단계 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " SM30 뷰를 함께 만들어 둔다
define table zexp_stage_std {
  key mandt     : mandt not null;
  key stage_no  : abap.numc(2) not null;   " 10 수주 … 70 대금 회수
  key valid_to  : abap.dats not null;      " 유효 종료일 — 기준 이력을 남긴다
  stage_name    : abap.char(30);
  std_days      : abap.int4;               " 표준 소요일 (앞 단계 실적일 기준)
  tol_days      : abap.int4;               " 허용 지연일
  valid_from    : abap.dats;
}

② 단계 이벤트 인터페이스 뷰

단계마다 일자가 있는 문서가 다릅니다. 이 뷰는 서로 다른 출처를 (수출 건, 단계, 실적일) 한 줄 모양으로 맞춥니다. 위쪽 뷰는 출처를 몰라도 되고, 출처가 확인되지 않은 단계는 이 뷰에 한 줄만 보태면 됩니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '수출 단계 실적 이벤트'
define view entity ZI_ExportStageEvent
  as select from vbak as h
{
  key h.vbeln                 as ExpId,
  key cast('10' as abap.numc(2)) as StageNo,   " 수주
      h.audat                 as ActDate,
      h.waerk                 as Curr,
      h.vkorg                 as SalesOrg
}
union all
  select from lips as i
    inner join likp as l on l.vbeln = i.vbeln
{
  key i.vgbel                 as ExpId,        " 선행 문서(판매 오더) — 문서 흐름(VBFA) 확인 필요
  key cast('20' as abap.numc(2)) as StageNo,   " 출하
      l.wadat_ist             as ActDate,
      cast('' as abap.cuky(5)) as Curr,
      cast('' as vkorg)       as SalesOrg
}
// ※ 30 선적(B/L) · 40 수출통관 · 60 네고·추심 : 일자의 출처 테이블은 고객사 구성에 따라
//    다릅니다 — 확인 필요. 확인되면 같은 모양으로 union all 한 줄씩 보탭니다.
//    50 청구(VBRK-FKDAT) · 70 회수(BSAD-AUGDT) 도 같은 방식으로 보탭니다.

③ 계획일 산출 뷰

계획일은 앞 단계 실적일 + 표준 소요일입니다. 앞 단계가 늦으면 뒤 단계 계획일이 같이 밀립니다. 이 뷰가 그 규칙을 한 곳에서만 정의합니다.

@EndUserText.label: '수출 단계 계획일'
define view entity ZI_ExportStagePlan
  as select from ZI_ExportStageEvent as cur
    left outer join ZI_ExportStageEvent as prv
      on  prv.ExpId   = cur.ExpId
      and prv.StageNo = ' ' " 앞 단계 번호 — 단계 기준표에 prev_stage 열을 두고 조인하는 편이 안전하다(확인 필요)
    inner join zexp_stage_std as std
      on  std.stage_no = cur.StageNo
{
  key cur.ExpId,
  key cur.StageNo,
      cur.ActDate,
      std.std_days   as StdDays,
      std.tol_days   as TolDays,
      // 계획일 = 앞 단계 실적일 + 표준 소요일 (앞 단계가 비어 있으면 계획일도 비운다)
      dats_add_days(prv.ActDate, std.std_days, 'NULL') as PlanDate
}

④ 지연·판정 뷰

지연일과 판정이 정해지는 자리입니다. 끝나지 않은 단계는 기준일로 세고, 앞 단계가 끝나지 않아 계획일이 없는 뒤 단계는 ‘대기 중’ 으로 두어 판정하지 않습니다. 판정 근거 문장을 DB 에서 만들어 화면이 같은 문장을 보여 줍니다.

@EndUserText.label: '수출 단계 지연 점검'
define view entity ZC_ExportStageDelay
  with parameters
    p_basedate : abap.dats       " 기준일 — 끝나지 않은 단계의 지연일을 셀 날짜
  as select from ZI_ExportStagePlan
{
  key ExpId,
  key StageNo,
      PlanDate, ActDate, TolDays,
      case
        when PlanDate is null then 'WAIT'                    -- 앞 단계 미완료: 판정하지 않음
        when ActDate  is not null then 'DONE'
        else 'OPEN'
      end as StageState,
      // DelayDays = max(0, coalesce(ActDate, 기준일) - PlanDate)
      case
        when PlanDate is null then 0
        else greatest( 0, dats_days_between( PlanDate,
                           coalesce( ActDate, $parameters.p_basedate ) ) )
      end as DelayDays
      // CheckStatus = DelayDays > TolDays ? 'CHECK' : 'OK' — 중첩 case 로 풀고,
      // Basis(판정 근거) 문장은 concat 으로 계획일 · 실적일 · 허용 지연일을 이어 붙인다.
}

⑤ 수출 건 요약 뷰

화면 첫 탭이 읽는 뷰입니다. 건마다 현재 단계(끝나지 않은 첫 단계)와 최대 단계 지연일, 판정을 한 줄로 모읍니다. 수주 단계는 계획일이 없으므로 판정 단계에서 뺍니다.

@EndUserText.label: '수출 건 진행 현황'
define view entity ZC_ExportShipStatus
  with parameters p_basedate : abap.dats
  as select from ZC_ExportStageDelay( p_basedate : $parameters.p_basedate ) as s
{
  key s.ExpId,
      // 현재 단계 = 끝나지 않은 단계 중 가장 앞 번호
      min( case when s.StageState <> 'DONE' then s.StageNo end ) as CurStage,
      // 최대 단계 지연일 — 수주(10) 제외, 보류 건은 상위 뷰에서 제외
      max( case when s.StageNo <> '10' then s.DelayDays end )    as MaxDelayDays,
      max( case when s.DelayDays > s.TolDays and s.StageNo <> '10'
                then 1 else 0 end )                              as NeedCheck
}
group by s.ExpId

⑥ 단계별 · 거래처별 집계 뷰

병목 단계와 문제 거래처를 찾는 뷰입니다. 비율의 분모는 판정 건수(보류 · 대기 제외)입니다. 기준 비율(단계 15%, 거래처 60%)은 샘플 값이므로 별도 테이블에서 읽도록 바꾸는 편이 낫습니다.

@EndUserText.label: '수출 단계별 지연 요약'
define view entity ZC_ExportStageSummary
  with parameters p_basedate : abap.dats
  as select from ZC_ExportStageDelay( p_basedate : $parameters.p_basedate )
{
  key StageNo,
      count( distinct ExpId )                                        as JudgeCnt,
      sum( case when DelayDays > TolDays then 1 else 0 end )         as LateCnt,
      // 점검 필요 비율 = LateCnt / JudgeCnt * 100
      division( sum( case when DelayDays > TolDays then 1 else 0 end ) * 100,
                count( distinct ExpId ), 2 )                         as LateRate,
      avg( cast( DelayDays as abap.dec(7,2) ) )                      as AvgDelay,
      max( DelayDays )                                               as MaxDelay
}
where StageState <> 'WAIT'
group by StageNo

⑦ 대사 뷰

화면 숫자가 맞는지 DB 가 직접 세는 뷰입니다. 통화가 다른 외화 금액은 더하지 않고 통화별로 따로 맞춥니다. 차이 건수가 0 이 아니면 그 줄을 배치에서 알림으로 올립니다.

@EndUserText.label: '수출 진행 대사'
define view entity ZC_ExportRecon
  as select from ZC_ExportShipLine           " 수출 건 + 수량 + 외화 · 환율 한 줄 모양(별도 인터페이스 뷰)
{
  key Curr,
      count(*) as CheckCnt,
      // 출하 수량 = 청구 수량 + 미청구 수량
      sum( case when ShipQty <> BillQty + UnbillQty then 1 else 0 end ) as QtyDiffCnt,
      // 외화 금액 × 환율 = 원화 환산 (통화별로 따로)
      sum( case when abs( FcAmt * Rate - KrwAmt ) > 0.5 then 1 else 0 end ) as AmtDiffCnt
}
group by Curr

⑧ 권한 객체(DCL)

수출 실적은 판매 조직 · 거래처별로 보는 사람이 다릅니다. 권한은 집계를 읽는 뷰에 걸어야 합니다. 상세에만 걸고 집계에 걸지 않으면 합계에서 뺀 값으로 남의 숫자가 드러납니다.

@EndUserText.label: '수출 지연 점검 권한'
@MappingRole: true
define role ZI_EXPORTSTAGEDELAY {
  grant select on ZC_ExportShipStatus
    where ( SalesOrg ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );
  // 거래처 단위로 나눌 때는 같은 방식으로 KUNNR 조건을 보탭니다 — 확인 필요
}

운영 전환에서 하는 일

6번이 가능한 이유는 화면이 엔티티셋 계약(키 · 프로퍼티 · 필터 이름)만 보기 때문입니다. 서비스 구현을 바꿔도 화면은 그대로 두고, 엔티티셋 이름과 프로퍼티 이름을 지키는 쪽으로 CDS 를 맞춥니다.

자주 묻는 질문

도입 상담과 데모에서 실제로 받을 만한 질문들을 25개로 정리했습니다. 네 묶음으로 나눠 적었습니다.

업무 질문

계산 규칙

화면과 서비스

도입과 운영