수출 부대비용 배부 점검 — 선적 한 건의 운임·보험료·수수료를 품목에 나눠 배부 후 공헌이익과 예정 대비 차이를 다시 구하는 수출 화면

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

수출 선적 한 건에는 해상·항공 운임, 적하보험료, 포워더 수수료, 국내 부대비용이 줄줄이 따라붙습니다. 이 비용을 누가 내는지(인코텀즈), 어느 품목이 얼마나 떠안는지(배부), 견적과 얼마나 달랐는지(예정 대비 차이)는 지금 청구서 · 엑셀 · 담당자의 기억으로 흩어져 있습니다. 이 앱은 세 답을 한 화면에 붙여, 선적 합계 뒤에 가려진 품목별 손익을 드러냅니다.

핵심 포인트 여덟 가지

사례로 보는 효과 — 합계는 흑자인데 한 품목은 적자

선적 한 건의 합계만 보면 이상이 없는데 품목을 나누면 달라지는 일이 실제로 생깁니다. 이 샘플의 중국행 CFR 선적(XB-2607-06)이 그렇습니다. 품목은 두 가지입니다 — 정밀 베어링 세트(수량 800, 용적 73.05 CBM)와 냉각 팬 유닛(수량 61, 용적 0.49 CBM). 해상 운임 1,928,634원을 용적으로 나누면 베어링 세트가 1,915,732원, 곧 99.3% 를 떠안습니다.

그 결과 정밀 베어링 세트의 공헌이익은 배부 전 980,092원(6.53%) 에서 배부 후 −1,413,968원(−9.42%) 으로 바뀝니다. 선적 전체로는 이익이 남아 있어 선적 단위 리포트에는 문제가 드러나지 않지만, 품목 단위로 내려가면 이 품목은 팔수록 손해입니다. 냉각 팬 유닛은 같은 선적에서 배부 후에도 4,427,456원이 남습니다. 가격 조건을 다시 볼지, 부피 큰 품목은 FOB 로 돌릴지를 이야기할 근거가 숫자로 생깁니다.

위 숫자는 가상 고객 · 가상 품목으로 만든 샘플입니다. 환율과 인코텀즈별 부담 주체, 판정 기준값도 샘플 가정이며 실제 계약 조건으로 확인해야 합니다.

이 샘플로 본 전체 모습

이 샘플에서 부대비용률이 가장 높은 달과 낮은 달의 차이, 인코텀즈별 비중은 유형·월 집계 탭에서 바로 확인할 수 있습니다. 요약 지표는 조회조건을 바꾸면 그 범위로 다시 계산됩니다.

실행 화면

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

사용 방법

1. 조회조건을 정합니다 — 회계연도는 필수, 선적월 · 인코텀즈 · 고객 · 판정은 선택입니다. 선택하지 않으면 전체가 조회됩니다.
2. 조회 버튼을 누르거나 조건 칸에서 Enter 키를 누릅니다. 초기화 버튼은 같은 줄에 있습니다.
3. 요약 카드에서 선적 건수 · 부대비용률 · 점검 필요 건수 · 적자 전환 품목 수를 먼저 봅니다.
4. 탭은 선적 명세 → 품목 배부 → 비용 내역 → 유형·월 집계 → 대사 결과 순서로 봅니다.
5. 궁금한 행을 누르면 그 선적의 비용 내역과 품목 배부가 한 창에 열립니다. ESC 키로 닫습니다.
6. 현재 탭의 결과는 UTF-8 CSV 로 내려받을 수 있습니다. 유형·월 집계 탭은 두 표를 각각 받습니다.

처음 열었을 때와 탭별 화면

처음 열면 조회조건 한 줄, 요약 카드, 선적 명세 탭이 한 화면에 세로로 쌓입니다. 요약 카드는 선적 건수 · 매출 · 부대비용 · 부대비용률 · 배부 후 공헌이익 · 점검 필요 건수 · 적자 전환 품목 수 일곱 개이며, 조회가 끝나면 조건에 맞춰 다시 채워집니다. 회계연도만 필수이고 나머지는 비워 두면 전체입니다. 조건 칸에서 Enter 키를 눌러도 조회됩니다.

배부 전과 배부 후 공헌이익을 같은 줄에 두었습니다. 두 숫자의 차이가 곧 그 품목이 떠안은 부대비용이고, 부호가 바뀐 줄이 적자 전환입니다. 배부액은 비용 유형별로 열이 나뉘어 있어 어느 비용이 이익을 깎았는지 바로 읽힙니다. 마지막 품목에서 조정한 단수 차이도 열로 따로 남깁니다.

비용 내역은 포워더 청구서 한 줄에 해당합니다. 부담 주체가 매수인이면 배부 대상에서 빠지고, 매도인이면 아래 배부 기준대로 품목에 나뉩니다. 차이율이 ±10% 를 넘고 차이액이 300,000원 이상인 줄만 점검 필요로 표시해, 작은 금액의 큰 비율 때문에 화면이 붉어지지 않게 했습니다.

위쪽은 유형별 집계입니다 — 해상·항공 운임, 적하보험료, 포워더 수수료, 국내 부대비용 네 줄에 예정·실제·매도인 부담·매수인 부담이 놓입니다. 아래쪽은 선적월별 집계로 월마다 부대비용률이 어떻게 움직이는지 보입니다. 두 표는 CSV 도 따로 내려받습니다.

대사식 여덟 가지의 검사 건수와 차이 건수, 최대 차이가 표로 나옵니다. 모두 차이 0건이어야 하고, 하나라도 0이 아니면 그 자체가 오류 신호입니다. 의도적으로 넣은 예외(청구서 미수신 선적, 단수 조정)는 차이 건수와 섞이지 않게 아래 따로 적습니다.

선적 명세 · 품목 배부 · 비용 내역 어느 탭의 행을 눌러도 같은 창이 열립니다. 위에는 선적 요약, 가운데는 비용 내역, 아래는 품목 배부입니다. 창은 닫기 버튼이나 ESC 키로 닫습니다. 적자 전환 품목과 그 원인이 된 비용을 위아래로 맞춰 볼 수 있어서 설명 자료로도 그대로 쓰입니다.

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 화면을 없애야 하느냐” 는 질문이 꼭 나오는데, 대부분 없애지 않고 둡니다 — 청구서 입력과 결제, 감사 대응은 표준 거래가 맡는 편이 안전합니다.

부대비용 배부·판정 규칙

판정은 위에서부터 차례로 따져 처음 맞는 조건으로 정해집니다. 기준값은 샘플 가정이므로 운영에서는 회사 기준으로 바꿉니다.

인코텀즈별 부담 주체와 배부 기준

누가 내는 비용인지가 먼저 갈리고, 매도인 몫만 비용 유형별 기준값 비율로 품목에 나뉩니다. 아래 표는 샘플 가정이며 실제 부담은 계약 조건으로 확인해야 합니다.

OData 서비스 구성

화면은 서비스를 expcost_srv 라는 이름의 OData V2 서비스로 부릅니다. 엔티티셋은 위 여섯 개이고, 펑션은 GetTotalActCost(선택한 선적월의 매도인 부담 실제 부대비용 합계) 와 GetMaxCostRate(매출 대비 부대비용률 최댓값) 두 개입니다. 조회조건은 $filter 로만 전달하고, 전체를 고르면 그 필터를 만들지 않습니다.

서비스 주소는 모두 상대 경로입니다. 화면이 실제로 부르는 요청은 앱 설명서의 9번 절에 엔티티셋별로 적혀 있고, 표의 행을 누르면 요청 문자열이 팝업으로 열려 복사할 수 있습니다. 보안 검토나 연계 설계에서는 이 절을 가장 먼저 보게 됩니다.

숫자를 믿을 수 있는가 — 대사식 8종

점검 화면에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 만드는 쪽에서 먼저 대사식을 세우고 전수로 돌렸습니다. 모두 차이 0건이며, 대사 결과 탭에서 같은 표를 볼 수 있습니다.

의도적 예외는 차이 건수와 섞지 않고 따로 둡니다 — 판정 제외 2건(포워더 청구서를 받지 못한 선적 XB-2607-08 · XB-2609-02)과 단수 조정 12건(조정액 절댓값 합계 13원)입니다. 계약 쪽 검사도 함께 합니다: 엔티티 여섯 개 모두에 키가 있는지, 서비스 경로에 동사 세그먼트가 없는지, 전체를 고를 때 필터를 보내지 않는지, 날짜 조건이 맞게 걸리는지를 확인했습니다.

CDS 구성

이 사례의 화면은 샘플 자료를 서비스가 읽어 배부를 계산해 주는 구조입니다. 데모라서 되는 일이고, 운영 데이터에서는 배부 계산을 CDS 로 내립니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로 그대로 붙여 넣지 말고 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 확인 필요 로 적었습니다.

뷰 레이어 구성

① 인코텀즈별 부담 주체 매핑 테이블

이 표 하나로 매도인이 내는 비용과 매수인이 내는 비용이 갈립니다. 샘플에서는 FOB · FCA · CFR · CIF 네 조건을 넣었지만, 실제 부담은 계약서의 조건으로 정해지므로 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간 열을 둔 이유는 조건이 바뀌어도 이미 닫은 선적의 숫자가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZEXC_BEARER — 인코텀즈 × 비용 유형 → 부담 주체 (투명 테이블)
"  코드에 박지 않는 이유 : 조건은 계약마다 달라지고, 바뀔 때마다
"  개발자를 부르게 만들면 리포트가 금방 낡는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '수출 부대비용 부담 주체 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " SM30 뷰를 함께 만들어 둔다
define table zexc_bearer {
  key mandt    : mandt not null;
  key inco1    : inco1 not null;         " 인코텀즈 (FOB · FCA · CFR · CIF …)
  key cost_typ : abap.char(5) not null;  " OCEAN · INS · FWD · DOM
  bearer       : abap.char(1);           " S = 매도인 부담 · B = 매수인 부담
  basis_code   : abap.char(3);           " CBM · VAL · WGT · QTY (배부 기준)
  valid_from   : abap.dats;
  valid_to     : abap.dats;
}

② 선적 · 비용 베이스 뷰

운송비 정산 문서(VFKK · VFKP)를 선적 번호 단위로 정리합니다. 원천 테이블의 필드 이름은 릴리스마다 다르므로 View Browser(F2170) 로 실제 이름을 확인해야 하는 자리를 주석에 적어 두었습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '선적별 비용 내역 베이스'
define view entity ZI_ShipCostBase
  as select from vfkp as p
    inner join   vfkk as k on k.fknum = p.fknum
    left outer join zexc_bearer as b
      on  b.inco1    = k.inco1                 " 확인 필요 : 인코텀즈 보유 필드
      and b.cost_typ = p.cost_typ              " 확인 필요 : 비용 유형 매핑 필드
{
  key k.tknum                       as BlNo,   " 확인 필요 : 선적 번호 연결 필드
  key p.fkpos                       as CostSeq,
      p.cost_typ                    as CostType,
      k.waers                       as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      p.netwr                       as ActAmt,
      @Semantics.amount.currencyCode: 'Currency'
      p.plan_netwr                  as PlanAmt, " 확인 필요 : 예정(견적) 금액 필드
      coalesce( b.bearer, 'S' )     as Bearer,  " 매핑이 없으면 매도인으로 본다
      b.basis_code                  as BasisCode
}

③ 품목 기준값 뷰

배부 기준이 되는 네 가지 값을 한 뷰에서 읽게 합니다. 용적과 중량은 납품 품목에, 금액은 청구 품목에 있어서 선적 번호와 품목 번호로 맞붙입니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '선적 품목 배부 기준값'
define view entity ZI_ShipItemBase
  as select from lips as l
    inner join   vbrp as r
      on  r.vgbel = l.vbeln
      and r.vgpos = l.posnr
{
  key l.vbeln                       as DeliveryNo,
  key l.posnr                       as ItemNo,
      l.matnr                       as Material,
      l.lfimg                       as Qty,       " 수량 기준
      l.brgew                       as GrossKg,   " 중량 기준
      l.volum                       as Cbm,       " 용적 기준
      r.netwr                       as SalesAmt,  " 금액 기준
      r.wavwr                       as VarAmt     " 확인 필요 : 변동비로 쓸 원가 필드
}

④ 배부 뷰

화면이 하던 계산을 DB 로 내리는 자리입니다. 선적 안에서 비용 유형별 기준값 ÷ 기준값 합계를 비율로 곱합니다. 합계는 윈도우 함수가 아니라 선적 단위 서브 집계로 구해 두면 실행 계획이 예측 가능합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 부대비용 품목 배부'
define view entity ZI_ExportCostAlloc
  as select from ZI_ShipCostBase as c
    inner join   ZI_ShipItemBase as i on i.DeliveryNo = c.BlNo   " 확인 필요 : 선적-납품 연결
    inner join   ZI_ItemBasisSum as s on  s.BlNo     = c.BlNo
                                      and s.BasisCode = c.BasisCode
{
  key c.BlNo,
  key c.CostSeq,
  key i.ItemNo,
      c.CostType,
      c.BasisCode,
      /* 매도인 부담 비용만 배부 대상 — 매수인 부담은 0 */
      case c.Bearer
        when 'S' then
          cast( round(
            c.ActAmt * case c.BasisCode
                         when 'CBM' then i.Cbm      / s.SumCbm
                         when 'VAL' then i.SalesAmt / s.SumSales
                         when 'WGT' then i.GrossKg  / s.SumKg
                         else             i.Qty     / s.SumQty
                       end, 0 ) as abap.dec(17,0) )
        else 0
      end                          as AllocRaw
}

⑤ 단수 조정

품목마다 원 단위로 반올림하면 합계가 실제 비용과 몇 원씩 어긋납니다. 어긋난 만큼을 마지막 품목 한 곳에서 조정하고, 조정액을 별도 필드로 남겨 화면이 숨기지 않고 보여 주게 합니다. 이 샘플에서는 12개 선적에서 조정이 일어났고 조정액 절댓값 합계는 13원입니다.

@EndUserText.label: '배부 단수 조정'
define view entity ZI_ExportCostAllocAdj
  as select from ZI_ExportCostAlloc as a
    inner join   ZI_ShipCostSum     as t on t.BlNo = a.BlNo and t.CostSeq = a.CostSeq
{
  key a.BlNo,
  key a.CostSeq,
  key a.ItemNo,
      a.AllocRaw,
      /* 선적 안의 마지막 품목에만 합계 차이를 얹는다 */
      case when a.ItemNo = t.LastItemNo
           then t.ActSeller - t.SumAllocRaw
           else 0 end            as AllocAdj,
      a.AllocRaw
        + case when a.ItemNo = t.LastItemNo
               then t.ActSeller - t.SumAllocRaw
               else 0 end        as AllocFinal
}

⑥ 판정 쿼리

판정 규칙은 화면이 아니라 여기 한 곳에서 정의합니다. 기준값(±10% · 300,000원 · 공헌이익률 10%)은 상수로 박지 않고 파라미터로 받아 운영에서 조정할 수 있게 했습니다.

@EndUserText.label: '수출 부대비용 배부 판정'
@Analytics.query: true
define view entity ZC_ExportCostCheck
  with parameters
    p_diff_pct : abap.dec(5,2),     " 기본 10
    p_diff_amt : abap.dec(17,0),    " 기본 300000
    p_cm_rate  : abap.dec(5,2)      " 기본 10
  as select from ZI_ShipSummary as s
{
  key s.BlNo,
      s.SalesKrw,
      s.ActCost,
      s.CmBefore,
      s.CmAfter,
      s.TurnLossCnt,
      case
        when s.InvoicePending = 'X'                       then 'EXC'    " 판정 제외
        when s.TurnLossCnt > 0                            then 'LOSS'   " 적자 전환
        when abs( s.PlanDiffPct ) > $parameters.p_diff_pct
         and abs( s.PlanDiff )    >= $parameters.p_diff_amt then 'DIFF' " 예정 대비 차이
        when s.CmRateAfter < $parameters.p_cm_rate        then 'THIN'   " 공헌이익률 낮음
        else 'OK'
      end                         as CheckCode
}

⑦ 권한 (DCL)

권한은 집계를 읽는 자리에 걸어야 합니다. 드릴다운 화면에만 걸면 선적 합계와 자기 몫의 차이로 남의 숫자를 유추할 수 있습니다.

@EndUserText.label: '수출 부대비용 배부 권한'
@MappingRole: true
define role ZI_EXPORTCOSTALLOC {
  grant select on ZI_ExportCostAlloc
    where ( BlNo ) = aspect pfcg_auth( V_VBRK_VKO, VKORG, ACTVT = '03' );
  " 확인 필요 : 권한 오브젝트와 필드는 환경의 권한 설계에 따른다
}

도입 시 정해야 할 것

위 여섯 가지는 코딩이 아니라 합의입니다. 합의가 끝나기 전에 뷰부터 만들면 나중에 다시 이송해야 합니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문들입니다. 네 묶음으로 나눠 적었습니다.

배부의 기본

판정과 점검

숫자와 대사

도입과 운영