SAP 운임 반영 수익성 점검 — 매출총이익은 남는데 운임을 반영하면 적자가 되는 오더를 찾는 월마감 점검

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

월마감 회의에서 영업과 물류가 같은 질문으로 부딪칩니다. 매출총이익은 남는데 왜 공헌이익은 줄었나, 운임은 누가 부담했나, 청구는 제대로 했나. 지금 이 세 답은 판매 오더 · 청구 문서 · 운송 비용 문서에 흩어져 있고, 한 오더의 운임이 이익을 얼마나 깎았는지는 엑셀에서 세 화면을 붙여야 나옵니다.

이 앱은 오더 한 건의 순매출, 표준 매출원가, 운임 비용, 고객에게 청구한 운임을 한 줄에 놓고 운임 반영 공헌이익을 다시 계산합니다. 그리고 적자로 돌아선 오더, 운임률이 높은 오더, 받아야 할 운임을 받지 못한 오더를 골라 노선과 월 단위로 다시 묶어 보여 줍니다. 관련 기준서는 없는 내부 관리 목적의 점검 화면이며, 대상 영역은 수익성 분석입니다.

매출총이익만 보면 운임이 이익을 깎는 자리가 가려진다

표준 수익성 리포트는 매출과 원가의 차이를 잘 보여 주지만, 운임은 운송 비용 문서와 청구 문서에 따로 있어 오더 단위로 만나는 자리가 없습니다. 이 샘플의 전체 숫자가 그 예입니다. 매출총이익률은 23.87% 인데 운임 비용 3,060만 원 가운데 고객에게 청구된 것은 1,384만 원(회수율 45.2%)뿐이어서, 운임을 반영한 공헌이익률은 21.75% 로 내려옵니다. 평균으로는 2.1%p 지만 오더 단위로 내려가면 매출총이익이 흑자인데 운임 반영 후 적자가 되는 오더가 7건 나옵니다.

점검은 건 하나가 아니라 노선과 월로 묶어야 의미가 있다

소량 긴급 발송 한 건의 운임률이 높은 것은 사정이지만, 같은 노선이 달마다 기준을 넘으면 계약이나 운송방식의 문제입니다. 그래서 같은 점검을 오더 · 노선 · 월 세 수준에서 하고, 세 수준의 합이 같은지를 대사식으로 검사합니다. 이 샘플에서는 노선 60행 중 23행, 월 9행 중 5행이 기준을 넘도록 구성해 두었습니다.

점검 도구는 판단을 대신하지 않는다

점검 필요는 기준을 넘었으니 근거를 확인하라는 표시이지 잘못이라는 판정이 아닙니다. 그래서 원인을 단정하는 문구를 쓰지 않고, 걸린 기준과 눌러서 내려갈 수 있는 근거(운임 구성 줄 · 표준 거래 문서)를 함께 줍니다. 최종 판단은 회사가 합니다.

사용 방법

1. 조회조건을 채웁니다. 회계연도는 필수이고, 전기 월 범위 · 지역 · 운송방식 · 고객 · 점검 결과는 선택입니다. 비워 두면 전체입니다.
2. 조건 줄 오른쪽 끝의 조회 버튼을 누르거나 입력칸에서 Enter 를 누릅니다. 처음 열면 자동으로 한 번 조회됩니다.
3. 조건 아래 요약 아홉 개를 확인합니다. 점검 필요 오더 · 노선 · 적자 전환 오더가 먼저 눈에 들어옵니다.
4. 탭을 오더 명세 → 노선 → 월별 추이 → 운임 구성 → 대사 결과 순서로 옮겨 가며 범위를 좁힙니다.
5. 오더 · 노선 · 월 행을 누르면 상세가 열립니다. 오더는 운임 구성 줄을, 노선과 월은 그 범위의 오더 명세를 보여 줍니다.
6. CSV 내려받기 로 지금 보는 탭의 조회 결과를 내려받습니다(UTF-8, 엑셀에서 바로 열림).

숫자를 믿을 수 있는가 — 검증 결과

점검 화면에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 만드는 쪽에서 먼저 대사식을 세우고 전수로 돌린 결과입니다.

일곱 가지 대사식이 모두 차이 0 입니다. 운임률 대사의 최대 차이 0.0050 은 반올림 오차로 허용 오차 안입니다. 점검 필요 45건(적자 전환 7 · 운임률 초과 23 · 청구 누락 15)은 의도적 예외로 넣은 것이며 대사 차이와 별개입니다. 화면 쪽은 브라우저 자동화로 조건 조합별 건수와 상세 합계가 눌렀던 행과 같은지를 따로 확인했습니다.

무엇으로 만들었나

실행 화면

실제로 돌아가는 화면 8종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다.

처음 열었을 때

조회조건 한 줄과 요약 아홉 개, 그 아래 다섯 탭이 한 화면에 놓입니다. 화면을 열면 자동으로 한 번 조회하므로 빈 화면에서 시작하지 않습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

맨 위는 조회조건 한 줄이고, 조회 버튼은 그 줄의 오른쪽 끝에 있습니다. 입력칸에서 Enter 를 눌러도 같은 조회가 돕니다. 그 아래 요약 아홉 개(순매출 · 운임 비용 · 청구 운임 · 운임률 · 운임 반영 공헌이익 · 점검 필요 오더 · 점검 필요 노선 · 적자 전환 오더 · 정합성 대사 차이)가 이번 조회 범위의 숫자입니다. 화면을 처음 열면 자동으로 한 번 조회하므로 빈 화면에서 시작하지 않습니다.

점검 결과 조건은 서비스에 $filter 로 전달되어 서버가 걸러 주므로, 화면이 전체를 받아 숨기는 방식이 아닙니다. 남은 45건은 첫 번째로 걸린 기준 코드와 점검 내용이 함께 보이고, 운임 반영 공헌이익이 낮은 순으로 정렬해 두면 손실이 큰 오더부터 읽습니다. 걸린 기준이 여럿이면 코드는 하나만 보여 주고 점검 내용에 모두 적습니다.

노선과 월로 묶어 보기

오더 한 건씩 볼 때는 보이지 않던 편차가 묶으면 드러납니다. 노선은 지역과 운송방식의 조합, 월은 전기 월 단위입니다.

오더 한 건씩 보면 보이지 않던 편차가 노선으로 묶으면 드러납니다. 같은 지역이라도 육상과 항공의 운임률이 크게 다르고, 운임률 5.5% 초과 또는 반영 공헌이익률 15% 미만인 노선에는 점검 필요가 붙습니다. 행을 누르면 그 월 · 그 노선에 속한 오더 명세가 열립니다.

월마감 회의에서 가장 먼저 열리는 탭입니다. 운임률이 4% 를 넘거나 점검 필요 오더가 6건 이상인 달에 점검 필요가 붙습니다. 9개월 가운데 5개월이 기준을 넘도록 샘플을 구성해 두어 점검 표시가 실제로 어떻게 보이는지 확인할 수 있습니다.

노선 숫자가 이상할 때 "어느 오더 때문인가" 를 묻는 자리입니다. 명세의 합계는 노선 행의 숫자와 같아야 하고, 이 합계 일치는 대사식(노선 합계 = 월 합계 = 전사 합계)으로 검사합니다.

한 오더의 운임 구성까지 내려가기

숫자를 의심할 때 같은 화면 안에서 줄 단위로 내려갑니다. 비용 줄과 청구 줄이 어디서 나왔는지, 걸린 기준이 무엇인지를 한 번에 봅니다.

운임 비용과 청구 운임이 어느 줄에서 나왔는지를 보는 자리입니다. 비용 줄 합계가 오더의 운임 비용과, 청구 줄 합계가 청구 운임과 같아야 하며 이 두 등식은 대사식으로 전수 검사합니다. 운송사 이름도 줄에 붙어 있어 어느 운송사의 비용이 큰지 바로 보입니다.

위쪽에는 순매출에서 운임 반영 공헌이익까지 내려오는 계산이, 아래쪽에는 운임 구성 줄이 있습니다. 점검 내용 칸에는 이 오더가 걸린 기준이 모두 적혀 있어서, 표준 거래(VA03 · VF03 · VI03)에서 어느 값을 대조해야 하는지가 바로 정해집니다.

숫자를 믿어도 되는가

이 화면은 점검 도구라 자기 숫자를 먼저 의심합니다. 대사 결과 탭이 그 답입니다.

숫자를 믿어도 되는지를 화면이 스스로 보여 주는 탭입니다. 차이 건수가 0 이 아니면 요약의 대사 차이 칸이 바뀌어 처음 화면에서도 알 수 있습니다. 운임률 대사의 최대 차이 0.0050 은 소수 둘째 자리 반올림 오차입니다.

화면 뒤에서 일어나는 일

조회를 누르면 조회조건이 필터로 바뀌어 서비스로 갑니다. 서비스가 조건에 맞는 오더를 골라 점검 판정과 노선 · 월 집계를 돌려주고, 화면은 받은 그대로 보여 줄 뿐 판정을 다시 하지 않습니다. 같은 판정을 다른 화면이나 배치가 쓸 수 있게 하려는 구조입니다.

점검 판정 규칙

한 건이 여러 기준에 걸리면 F01 → F02 → F03 순서로 코드를 하나 보여 주고, 점검 내용에는 걸린 기준을 모두 적습니다. 원인은 단정하지 않고 “점검 필요” 로 표시합니다.

산출 순서

1. 매출총이익 = 순매출 − 표준 매출원가
2. 순 운임 부담 = 운임 비용 − 청구 운임, 운임 반영 공헌이익 = 매출총이익 − 순 운임 부담
3. 운임 비용 = 운임 구성의 비용 줄 합계, 청구 운임 = 운임 구성의 청구 줄 합계
4. 청구 차이 = 청구 운임 − 약정 청구 운임 (0 보다 작으면 미청구)
5. 운임률 = 운임 비용 ÷ 순매출 × 100, 운임 회수율 = 청구 운임 ÷ 운임 비용 × 100, 반영 공헌이익률 = 운임 반영 공헌이익 ÷ 순매출 × 100
6. 노선 · 월 합계 = 오더 합계, 노선 합계 = 월 합계 = 전사 합계

조회조건

“전체” 는 코드값으로 보내지 않고 해당 조건을 빼는 방식입니다. 그래서 새 운송방식이 생겨도 전체 조회가 깨지지 않습니다.

결과 컬럼

좁은 화면에서 달라지는 것

폭이 줄면 조회조건이 여러 줄로 접히고 요약이 두 열로 쌓이며, 표는 가로로 넘겨 봅니다. 상세 창은 화면 폭에 맞춰 전체 폭으로 열립니다. 기능은 줄어들지 않고 배치만 달라집니다.

파일 구성

화면 진입(index) · 설명서 · 앱 구성(Component · manifest)
controller/  화면 흐름 (기본 컨트롤러 + 메인)
view/        메인 화면 + 상세 창
model/       숫자 표시 규칙 · 오류 안내
odata/       서비스 정의(메타데이터) + 서비스 로직 + 샘플 자료
media/       소개 영상

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 리포트를 없애야 하나” 는 질문이 꼭 나오는데, 대부분은 없애지 않고 둡니다. 대사와 감사 대응은 표준 거래가 맡는 편이 안전합니다.

S/4HANA 분석 스택과의 자리

S/4HANA 에는 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 표준 분석 도구가 있습니다. 이 앱의 집계와 판정을 CDS 로 내리면(CDS 구성 절) 같은 뷰를 표준 도구가 그대로 읽을 수 있습니다. 즉 이 화면은 표준 분석 스택과 경쟁하는 것이 아니라, 점검 판정과 청구 조건 매핑이라는 표준에 없는 부분을 같은 스택 위에 얹은 것입니다.

확장 포인트 — 운영에서 실제로 손대는 자리

요구사항 매핑 — 분석 지표 정의

관련 기준서가 없는 내부 관리 지표이므로 기준서 요구사항 대신 지표 정의표로 적습니다.

CDS 구성

이 사례의 화면은 샘플 자료 몇백 건을 서비스 로직이 직접 묶습니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일이 집계와 판정을 CDS 로 내리는 것입니다. 아래는 그때 만드는 객체를 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 청구 조건 매핑 테이블

리포트의 청구 누락 점검이 이 표에서 갈립니다. 어떤 고객에게 운임을 얼마나 청구하기로 했는지를 정하는 자리라 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 조건이 바뀌어도 과거 점검 결과가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZFRT_BILLTERM — 고객별 운임 청구 조건 매핑 (투명 테이블)
"  표준에는 "이 고객에게 운임을 얼마나 청구하기로 했는가" 를 모아 둔
"  자리가 없다. 계약서 · 영업 담당자의 기억 · 엑셀에 흩어져 있던 것을
"  이 표 한 곳으로 옮긴다. 청구 누락 점검(F03)은 이 표가 있어야 돈다.
"  코드에 박지 않는 이유 : 청구 조건은 고객이 늘 때마다 바뀌고,
"  바뀔 때마다 개발자를 부르게 하면 점검이 금방 낡는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '고객별 운임 청구 조건'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " SM30 뷰를 함께 만들어 현업이 직접 넣는다
define table zfrt_billterm {
  key mandt      : mandt not null;
  key vkorg      : vkorg not null;        " 판매 조직
  key kunnr      : kunnr not null;        " 고객
  key valid_from : abap.dats not null;    " 조건이 바뀌어도 과거 점검이 흔들리지 않게
  valid_to       : abap.dats;
  bill_term      : abap.char(4);          " FULL 전액 · PART 일부 · FREE 무료
  bill_rate      : abap.dec(5,2);         " 일부 청구일 때 비운임 대비 청구 비율(%)
  note           : abap.char(60);         " 계약 근거 메모
}

② 오더 기준 뷰

순매출에서 운임 청구분을 제외한다는 전제가 여기서 결정됩니다. 운임 청구 품목을 순매출에 섞으면 운임률 분모가 흔들리므로 품목 범주로 걸러 냅니다.

" ────────────────────────────────────────────────────────────────
"  ZI_FrtOrderBase — 오더 기준 뷰 : 오더 한 건의 매출과 표준원가
"  이 뷰가 정하는 것 : 순매출에서 운임 청구분을 제외한다는 전제.
"  운임을 순매출에 섞으면 운임을 많이 청구한 오더의 이익률이
"  부풀어 보이고 운임률의 분모도 흔들린다.
"  확인 필요 : 필드 이름은 릴리스에 따라 다르므로 View Browser(F2170)로
"  I_SalesDocumentItem 의 실제 필드를 확인한다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '운임 점검 — 오더 기준'
@VDM.viewType                        : #BASIC
define view entity ZI_FrtOrderBase
  as select from I_SalesDocumentItem as Itm
  association [1..1] to I_SalesDocument as _Doc
    on _Doc.SalesDocument = $projection.SalesOrder
{
  key Itm.SalesDocument                                   as SalesOrder,
      _Doc.SoldToParty                                    as Customer,
      _Doc.SalesOrganization                              as SalesOrg,
      _Doc.SalesDocumentDate                              as OrderDate,
      Itm.TransactionCurrency                             as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when Itm.SalesDocumentItemCategory <> 'TAD'   " 운임 청구 품목 제외
                then Itm.NetAmount else 0 end )           as NetSales,
      @Semantics.quantity.unitOfMeasure : 'Unit'
      sum( Itm.OrderQuantity )                            as Qty,
      Itm.OrderQuantityUnit                               as Unit,
      _Doc
}
group by Itm.SalesDocument, _Doc.SoldToParty, _Doc.SalesOrganization,
         _Doc.SalesDocumentDate, Itm.TransactionCurrency, Itm.OrderQuantityUnit
" 표준 매출원가(품목 표준원가 × 수량)는 품목 평가 뷰와 join 해 이 뷰에 더한다.
" 표준원가 필드와 평가 영역은 확인 필요 — 원가 회계와 먼저 합의한다.

③ 운임 구성 줄 뷰

운송 비용 문서의 비용 줄과 고객 청구 줄을 한 모양으로 맞춥니다. 운송 비용 문서와 오더를 잇는 키가 환경마다 달라서, 이 뷰가 가장 많이 손보는 자리입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_FrtLine — 운임 구성 줄 : 비용 줄(운송 비용 문서)과 청구 줄을 한 모양으로
"  오더 한 건의 운임이 어느 줄에서 나왔는지를 보이는 자리다.
"  두 원천을 union all 로 같은 열 구성에 맞춰 LineKind 로 구분한다.
"  확인 필요 : 운송 비용 문서의 오더 연결 방식(참조 문서)과 비용 유형은
"  환경마다 다르다. 표준 뷰 이름을 확인하지 못해 테이블 기준으로 적었다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '운임 점검 — 운임 구성 줄'
define view entity ZI_FrtLine
  as select from vfkp as Hd                    " 운송 비용 문서 헤더
    inner join   vfkn as It                    " 운송 비용 문서 품목
      on It.fknum = Hd.fknum
{
  key Hd.fknum                  as CostDoc,
  key It.fkpos                  as CostItem,
      It.knumv                  as PricingDoc,        " 확인 필요 : 오더 연결 키
      cast( 'COST' as abap.char(4) ) as LineKind,
      Hd.netwr                  as Amount,
      Hd.waers                  as Currency
}
union all
select from I_BillingDocumentItem as Bil
{
  key Bil.BillingDocument       as CostDoc,
  key Bil.BillingDocumentItem   as CostItem,
      Bil.SalesDocument         as PricingDoc,
      cast( 'BILL' as abap.char(4) ) as LineKind,
      Bil.NetAmount             as Amount,
      Bil.TransactionCurrency   as Currency
}
where Bil.SalesDocumentItemCategory = 'TAD'      " 운임 청구 품목만

④ 큐브 — 오더 단위 운임 반영 공헌이익

화면이 서비스에서 받던 산식을 DB 로 내리는 자리입니다. 약정 청구 운임은 매핑이 없으면 전액으로 봅니다. 이 기본값은 정책 결정이므로 회계와 합의해야 합니다. 코드의 ZI_FrtLineSum 은 ③의 운임 구성 줄을 오더별로 비용 합계와 청구 합계로 묶는 보조 뷰이며(줄 종류로 나눠 더하는 단순 집계라 지면을 아껴 싣지 않았습니다), 큐브가 줄이 아닌 오더 한 건에 한 행만 갖도록 합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_FrtOrderProfit — 큐브 : 오더 단위 운임 반영 공헌이익
"  화면이 서비스에서 받던 판정을 DB 로 내리는 자리다.
"  차이를 화면이 아니라 여기서 한 번만 정의하는 이유 : 다른 화면 ·
"  배치 · 보고서가 같은 산식을 쓰게 하려는 것이다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK        " DCL 로 권한 확인
@EndUserText.label                   : '운임 반영 공헌이익 (오더)'
@Analytics.dataCategory              : #CUBE
define view entity ZI_FrtOrderProfit
  as select from ZI_FrtOrderBase as Ord
    left outer join ZI_FrtLineSum as Lin on Lin.SalesOrder = Ord.SalesOrder
    left outer join zfrt_billterm as Trm
      on  Trm.vkorg = Ord.SalesOrg and Trm.kunnr = Ord.Customer
      and Trm.valid_from <= Ord.OrderDate and Trm.valid_to >= Ord.OrderDate
{
  key Ord.SalesOrder,
      Ord.Customer,
      Ord.SalesOrg,
      Ord.OrderDate,
      Ord.NetSales,
      Ord.StdCogs,
      Ord.NetSales - Ord.StdCogs                                   as GrossProfit,
      Lin.FreightCost,
      Lin.FreightBilled,
      " 약정 청구 운임 : 전액 / 일부 / 무료 (매핑이 없으면 전액으로 본다)
      case Trm.bill_term
           when 'FREE' then cast( 0 as abap.curr(15,2) )
           when 'PART' then Lin.FreightCost * Trm.bill_rate / 100
           else Lin.FreightCost end                                as ExpectBill,
      Lin.FreightBilled - ( case Trm.bill_term
           when 'FREE' then 0
           when 'PART' then Lin.FreightCost * Trm.bill_rate / 100
           else Lin.FreightCost end )                              as BillGap,
      ( Ord.NetSales - Ord.StdCogs )
        - ( Lin.FreightCost - Lin.FreightBilled )                  as ContribAfter,
      case when Ord.NetSales = 0 then 0
           else Lin.FreightCost * 100 / Ord.NetSales end           as FreightRate
}

⑤ 소비 뷰 — 조회조건과 점검 코드

조회조건과 기본 정렬을 정하고 점검 판정을 코드로만 만듭니다. 문구는 화면 번역에서 붙이므로 언어를 더해도 이 뷰는 바뀌지 않습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_FrtProfitQuery — 소비 뷰 : 화면 · Fiori · 분석 도구가 읽는 자리
"  조회조건(@Consumption.filter)과 기본 정렬을 여기서 정한다.
"  점검 판정(F01~F03)은 CASE 로 코드만 만들고 문구는 화면 번역에서 붙인다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '운임 반영 수익성 점검'
@Metadata.allowExtensions         : true
define view entity ZC_FrtProfitQuery
  as projection on ZI_FrtOrderProfit
{
      @UI.lineItem : [{ position: 10 }]
  key SalesOrder,
      @Consumption.filter : { selectionType: #SINGLE, mandatory: true }
      @UI.selectionField  : [{ position: 10 }]
      OrderDate,
      @Consumption.filter.selectionType : #RANGE
      @UI.selectionField  : [{ position: 20 }]
      SalesOrg,
      @UI.selectionField  : [{ position: 30 }]
      Customer,
      @UI.lineItem : [{ position: 20 }]  NetSales,
      @UI.lineItem : [{ position: 30 }]  FreightCost,
      @UI.lineItem : [{ position: 40 }]  FreightBilled,
      @UI.lineItem : [{ position: 50 }]  ContribAfter,
      @UI.lineItem : [{ position: 60 }]  FreightRate,
      " 점검 코드 : 적자 전환 → 운임률 초과 → 청구 누락 순서로 하나만
      case when GrossProfit > 0 and ContribAfter < 0 then 'F01'
           when FreightRate > 8                      then 'F02'
           when BillGap     < 0                      then 'F03'
           else ''  end                              as CheckCode
}

⑥ 접근 제어 (DCL)

집계를 읽는 자리에 권한을 겁니다. 판매 조직 단위 제한이 기본이고, 플랜트 · 고객 단위는 회사 권한 설계에 따릅니다.

" ────────────────────────────────────────────────────────────────
"  ZI_FRTORDERPROFIT — 접근 제어 (DCL)
"  집계를 읽는 자리에 걸어야 한다. 상세에만 걸면 전사 합계와
"  자기 몫의 차이로 남의 숫자를 알아낼 수 있다.
"  확인 필요 : 권한 오브젝트와 필드는 회사 권한 설계에 따라 달라진다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '운임 점검 — 판매 조직 권한'
@MappingRole : true
define role ZI_FRTORDERPROFIT {
  grant select on ZI_FrtOrderProfit
    where ( SalesOrg ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

화면이 부르는 문을 만듭니다. 읽기 전용이라 생성 · 수정 · 삭제 동작은 노출하지 않습니다.

" ────────────────────────────────────────────────────────────────
"  서비스 정의와 바인딩 — 화면이 부르는 문
"  OData V2 로 게시하면 화면의 서비스 주소만 바꿔 운영에 연결된다.
"  활성화 : 서비스 바인딩(ADT)에서 게시한 뒤 /IWFND/MAINT_SERVICE 에서
"  서비스를 등록한다. 화면 쪽은 manifest 의 서비스 주소 하나만 교체한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '운임 반영 수익성 점검 서비스'
define service ZUI_FrtProfit {
  expose ZC_FrtProfitQuery as OrderSet;
  expose ZI_FrtLine        as LineSet;
}
" 서비스 바인딩 : 이름 ZUI_FRTPROFIT_O2 · 바인딩 유형 OData V2 - UI
" 읽기 전용이므로 생성 · 수정 · 삭제 동작을 노출하지 않는다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 여섯 가지는 코딩이 아니라 합의이고, 합의가 끝나면 기술 작업은 위 객체를 만들고 서비스를 게시하는 일로 줄어듭니다.

운영 데이터로 갈 때

샘플은 오더 216건이라 서비스가 전부 읽어 묶지만, 오더가 수천만 건이면 다음 순서로 바꿉니다. 첫째, 집계는 CDS 에서 하고 화면은 결과만 받습니다. 둘째, 전기일 범위와 판매 조직을 필수 조건으로 받아 범위를 좁힙니다. 셋째, 오더 명세는 한 번에 전부 읽지 않고 서비스 질의의 건수 제한과 건너뛰기로 나눠 읽습니다. 넷째, 운임 구성 줄은 오더 상세를 열 때만 읽습니다. 응답 시간 기준(예: 조회 3초 이내)을 먼저 정하고, 넘는 조회는 범위를 좁히라는 안내를 띄우는 편이 낫습니다.

자주 묻는 질문

도입 상담과 데모에서 실제로 받은 질문들을 네 묶음으로 나눠 적었습니다.

숫자와 산식

화면과 사용

표준과의 관계

도입과 운영