SAP 수입 미착품 장기 체류 점검 — 선적 후 아직 입고되지 않은 물건의 경과일·금액을 허용 일수와 장부에 맞춰 보는 화면

개발 배경 — 이 앱을 사용해야 하는 이유

수입 담당자는 월말마다 같은 질문을 받습니다. 배는 떠났는데 아직 들어오지 않은 물건이 지금 얼마인가, 그중 약속한 기간을 넘겨 바다 위에 머무는 건은 어디인가, 그 금액이 장부의 미착품 계정과 맞는가. 이 세 답은 구매오더(ME23N)와 오더 현황(ME2N), 입고 처리(MIGO), 자재 문서 목록(MB51), 그리고 포워더가 보내는 선적 통지 엑셀에 나뉘어 있습니다. 화면마다 보는 단위가 다릅니다. 구매오더는 품목, 입고는 자재 문서, 포워더 자료는 선하증권(B/L) 한 건을 단위로 움직입니다.

이 앱은 그 사이를 이어 붙입니다. 선하증권 한 건을 기준으로 외화 물품 대가를 원화로 옮기고, 입고된 수량만큼을 빼서 미착 수량과 미착 금액을 구한 뒤, 선적 후 경과일을 운송 방식별 허용 일수와 견주고, 인코텀즈로 정한 소유권 이전 시점을 가정해 기대 장부 금액을 만들어 실제 장부 미착품 잔액과 나란히 놓습니다. 새로 계산하는 값은 모두 SAP 표준 데이터 구조(구매오더·납품 일정·자재 문서·회계 전표)에서 읽은 값을 그대로 이어받습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다.

이 앱은 특정 기준서의 요구사항을 직접 구현하는 화면이 아니라 수입 미착품 관리용 업무 분석 앱입니다. 그래서 관련 기준서 칸은 ‘-’ 로 두고 대상 영역(수입 미착품 관리)을 표기합니다. 재고 인식 시점과 같은 회계 판단은 회사와 감사인이 하며, 이 화면은 그 판단에 필요한 사실(경과일, 잔량, 금액, 장부 차이)을 모아 보여 줍니다.

배는 떠났는데 입고는 없다 — 미착품은 조용히 쌓인다

선적이 끝나면 구매 쪽의 일은 끝난 것처럼 보입니다. 하지만 입고 전까지 이 물건은 재고도 매입채무도 아닌 어정쩡한 자리에 있습니다. 포워더가 선적 통지를 보내고 입고가 처리될 때까지, 담당자는 ‘곧 들어오겠지’ 라고 믿고 있을 뿐입니다. 선적 후 40일이 지나도, 60일이 지나도 화면에는 아무 신호가 없습니다.

이 앱은 선하증권마다 선적일과 입고일, 경과일을 한 줄에 놓습니다. 입고가 끝난 건은 입고일까지의 일수가, 아직 들어오지 않은 건은 기준일까지의 일수가 경과일입니다. 이 글의 검증용 샘플(기준일 2026-10-31)에서는 선하증권 29건 가운데 13건이 아직 운송 중이고, 그 미착 금액은 1,232,707,798원입니다.

허용 일수는 해상과 항공이 다르다

같은 경과일 40일이라도 해상은 평범하고 항공은 이례적입니다. 이 앱은 운송 방식별 허용 일수(샘플 기본값은 해상 45일, 항공 10일, 모두 가정값)를 두고, 미착 수량이 남아 있는 건에서 경과일이 허용 일수를 넘은 만큼을 초과일로 보여 줍니다. 샘플에서는 해상 2건(초과 35일, 17일)과 항공 1건(초과 9일)이 장기 미착으로 올라오고, 이 세 건의 합계는 109,095,865원입니다.

허용 일수는 항로, 거래처, 품목에 따라 회사마다 다릅니다. 그래서 화면에 박아 두지 않고 규칙 테이블로 두었고(CDS 절 참고), 조건이 바뀌면 값만 고치면 됩니다.

도착 예정일이 지난 건은 누가 챙기나

허용 일수 이내라도 포워더가 알려준 도착 예정일이 이미 지났다면 확인할 이유가 됩니다. 이 앱은 허용 일수를 넘지 않았지만 도착 예정일이 기준일보다 앞선 건을 따로 ‘도착 예정일 경과’ 로 점검 필요에 올립니다. 샘플에서는 세 건이며 그중 한 건은 일부만 입고되고 잔량이 남은 건입니다. 이런 건은 장기 미착으로 번지기 전에 포워더에게 상태를 묻기 좋은 시점입니다.

인코텀즈에 따라 장부에 잡을 시점이 다르다

선적 시점에 위험과 소유권이 넘어오는 조건(FOB · CIF · FCA · CPT 등)과 도착 시점에 넘어오는 조건(DAP · DDP)은 미착품을 장부에 올리는 시점이 다를 수 있습니다. 이 앱은 인코텀즈로 소유권 이전 시점을 가정해 기대 장부 금액을 만들고, 실제 장부 미착품과의 차이를 점검 필요로 띄웁니다. 샘플에는 세 가지 예외가 일부러 들어 있습니다. 장부에 일부만 계상된 건, 아예 계상되지 않은 건, 도착 시점 조건인데 선적 시점에 계상된 건입니다. 어떤 시점에 장부에 올릴지는 계약과 회사 정책이 정하고, 이 화면은 그 가정과 장부가 다른 곳을 먼저 열어 보게 해 줄 뿐입니다.

그래서 무엇을 보려는 앱인가

세 가지입니다. 허용 일수를 넘겨 오래 머무는 미착 건이 무엇인지, 도착 예정일이 지났는데 아직 들어오지 않은 건이 무엇인지, 그리고 장부 미착품이 기대 금액과 다른 건이 무엇인지입니다. 이 앱은 점검 도구입니다. 입고를 처리하거나 전표를 만들지 않으며, 결과를 근거로 한 판단은 회사와 감사인이, 관세와 부가가치세 신고는 회사와 세무 대리인·관세사가 합니다.

사용 방법

1. 조회 조건에서 기준 연월(필수)을 확인합니다. 통화·운송 방식·점검 상태·선적일(부터·까지)은 선택이며, 비워 두면 조건에서 빠집니다.
2. 조회 버튼을 누릅니다. 조회 버튼은 조건 영역 오른쪽 끝에 있고, 기준 연월 입력 칸에서 Enter 키를 눌러도 같은 조회가 실행됩니다. 초기화 버튼은 그 옆에 있습니다.
3. 위쪽 요약(미착 B/L · 미착 금액 · 장기 미착 건수와 금액 · 점검 필요 · 장부 대비 차이)을 확인합니다.
4. 탭을 차례로 봅니다 — 미착품 현황 → 품목 잔량 → 경과 구간 → 월별 수불 → 대사 결과.
5. 궁금한 행을 누르면 선하증권 상세 창이 열려 경과일·허용일·기대 장부·장부 미착품과 품목 잔량을 함께 봅니다.
6. 하단 CSV 내려받기로 지금 열려 있는 탭의 내용을 UTF-8 CSV 로 저장합니다.

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

미착품 점검에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세우고 검증용 샘플 데이터 전수로 돌렸습니다.

앞의 다섯 대사식은 모두 차이 0 입니다. 마지막 장부 대사의 차이 3건은 점검 화면을 시연하려고 일부러 넣은 예외(일부 계상 1건 · 미계상 1건 · 도착 시점 조건 계상 1건)이며, 앞의 정합성 대사와 섞지 않고 따로 셉니다. 화면 위쪽 요약의 장부 대비 차이(+61,521,225원)는 검증 스크립트 합계와 같습니다.

무엇으로 만들었나

앱 정보

실행 화면

실제로 돌아가는 화면 8종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 보는 자리이고 숫자를 어떻게 읽는지를 아래에 적었습니다. 숫자는 모두 같은 검증용 샘플 데이터에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

기준 연월이 기본으로 들어간 상태에서 조회조건, 요약 숫자, 첫 번째 탭이 한 화면에 세로로 쌓입니다. 조회 버튼은 조건 입력 칸의 가장 오른쪽에 있습니다.

요약은 미착 B/L 13건, 미착 금액 1,232,707,798원, 장기 미착 3건 109,095,865원, 점검 필요 8건, 장부 대비 차이 +61,521,225원입니다. 표는 초과일이 큰 건부터, 같으면 선적일이 최근인 건부터 정렬되어 위쪽 세 건이 곧 장기 미착입니다. 상태 칸이 ‘점검 필요’ 인 행부터 열어 보면 됩니다.

점검이 필요한 건만 골라 보기

점검 상태를 ‘점검 필요’ 로 두고 조회하면 먼저 열어 볼 선하증권만 남습니다. 요약 숫자도 같은 조건으로 다시 계산됩니다.

여덟 건의 이유가 서로 다릅니다. 장기 미착이 3건, 도착 예정일 경과가 3건(그중 1건은 부분 입고), 장부 차이만 있는 건이 1건, 도착 시점 조건인데 선적 시점에 계상된 건이 1건입니다. 한 건에 이유가 겹치면 소유권 가정 → 장부 차이 → 장기 미착 → 도착 예정일 순으로 대표 이유 하나를 붙이고, 겹친 이유는 상세 창에서 확인합니다.

품목까지 내려가기

품목 잔량 탭은 선하증권 안의 품목을 한 줄씩 펼칩니다. 선적 수량과 입고 수량, 미착 수량, 그리고 외화 금액과 원화 미착 금액이 나란히 놓입니다. 일부만 입고된 선하증권은 이 탭에서 어느 품목이 덜 들어왔는지 바로 보입니다.

품목 수준의 합이 선하증권 수준의 합과 같다는 것이 대사 03 입니다. 같은 선하증권이 여러 품목을 싣고 있어도 외화 미착은 품목별 외화 금액에서 입고 비율만큼을 빼서 구하고, 서로 다른 통화의 외화 금액은 더하지 않습니다.

얼마나 오래 머무는가 — 경과 구간

경과 구간 탭은 미착 금액을 선적 후 경과일 구간(0~14일, 15~30일, 31~45일, 46~60일, 61일 이상)과 통화로 나눕니다. 오래된 구간에 금액이 남아 있는지 한눈에 보는 자리입니다.

61일 이상 구간에는 USD 2건 57,668,566원이 있고, 31~45일 구간에는 EUR 한 건이 238,429,884원으로 가장 큽니다. 모든 구간의 원화 합계를 더하면 1,232,707,798원으로 현황 탭의 미착 금액 합계와 맞습니다(대사 05).

한 달 단위로 맞춰 보기 — 월별 수불

월별 수불 탭은 기초 미착에 그 달의 선적을 더하고 입고를 빼서 기말 미착을 구합니다. 한 달의 기말은 다음 달의 기초가 됩니다.

10월은 기초 834,343,387원에 선적 892,110,301원이 더해지고 입고 493,745,890원이 빠져 기말 1,232,707,798원이 됩니다. 이 기말은 현황 탭의 미착 금액 합계와 같고, 9월의 기말 834,343,387원은 10월의 기초와 같습니다. 이 두 가지가 맞으면 선적과 입고 날짜가 흐름 안에 빠짐없이 들어갔다는 뜻입니다.

하나의 선하증권을 열어 보기

현황 탭이나 품목 잔량 탭의 행을 누르면 상세 창이 열립니다. 위쪽에는 거래처, 인코텀즈와 운송 방식, 소유권 이전 가정, 선적·도착 예정·입고 일자, 경과일·허용일·초과일, 환율(가정), 금액이 있고, 아래쪽에는 품목 잔량이 있습니다.

이 창의 건은 선적 후 80일이 지나 허용 45일을 35일 넘긴 해상 건입니다. 미착 금액 35,538,664원이 기대 장부인데 장부 미착품은 31,274,024원이라 4,264,640원이 모자랍니다. 점검 결과 칸에는 장부 차이와 장기 미착 이유가 함께 적힙니다.

숫자가 맞는지 확인하기 — 대사 결과

대사 결과 탭은 여섯 개 대사식의 좌변·우변, 검사 건수, 차이 건수, 최대 차이를 보여 줍니다. 정합성 대사와 장부 점검 대사는 구분 칸으로 나뉩니다.

장부 점검 대사의 좌변은 기대 장부 합계 994,277,914원, 우변은 장부 미착품 합계 1,055,799,139원입니다. 건별 차이는 서로 상쇄될 수 있어서 합계만 보지 않고 차이 건수(3건)와 최대 차이(238,429,884원)를 함께 봅니다.

좁은 화면에서 달라지는 것

폭이 좁으면 조회 조건이 줄바꿈되고 요약 숫자가 세로로 쌓입니다. 표는 가로로 넘겨 보며 행 클릭 상세는 그대로 열립니다.

좁은 화면에서도 조회 버튼은 조건 영역 안에 있어 하단 막대를 찾지 않아도 됩니다. 열이 많은 현황 표는 가로 스크롤로 보고, 상태 칸은 일부러 두 번째 열에 두어 스크롤 없이도 보입니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 선하증권 엔티티셋에 필터·정렬·총건수 요청을 한 번 보내고, 받은 선하증권 번호로 품목 잔량을 다시 요청합니다. 경과 구간·월별 수불·대사 결과는 각자의 엔티티셋을 따로 읽습니다. 컨트롤러는 서비스가 돌려준 값을 요약 숫자로 합산하는 일만 합니다.

점검 판정 규칙 — 조건 → 결과 → 사용자 조치

조회조건

결과 컬럼

파일 구성

index.html · readme.html · Component.js · manifest.json
controller/ BaseController.js · Main.controller.js
view/ Main.view.xml · DetailDialog.fragment.xml
model/ formatter.js · ErrorHandler.js
css/ · i18n/
odata/ 서비스 정의(메타데이터 · 서비스 로직 · 엔티티셋별 데이터)
media/ 소개 영상

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 그래서 이 앱을 도입해도 기존 T-code 를 없애지 않습니다. 아래는 표준으로 되는 것과 이 앱이 더하는 것, 그리고 표준 T-code 와 맞닿는 지점입니다.

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

T-code 별 연계 지점

운영에 올릴 때 “기존 리포트를 없애야 하나” 라는 질문이 나오면 답은 아니오입니다. 법정·감사·세무 신고에 쓰는 자료는 표준 화면과 회사 절차에 남기고, 이 앱은 그 자료를 만들기 전에 어디부터 열어 볼지 정하는 점검 단계로 씁니다.

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

S/4HANA 에서는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 로 구매·재고 지표를 볼 수 있습니다. 이 앱은 그것들과 경쟁하지 않고, 선하증권 단위의 경과일 판정과 기대 장부 대조라는 좁은 점검을 맡습니다. 표준 분석 앱이 ‘무엇이 얼마인가’ 를 보여 준다면 이 앱은 ‘무엇을 먼저 확인해야 하는가’ 를 보여 줍니다. 확인하지 못한 표준 분석 앱의 이름은 쓰지 않았으니 고객사 환경에서 적용 가능한 표준 앱은 별도로 확인하시기 바랍니다.

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

분석 지표 정의표

CDS 구성

이 절은 샘플 서비스가 읽는 값을 S/4HANA 의 CDS 뷰로 만들 때의 구성을 코드와 함께 보여 줍니다. 뷰 이름은 기능을 뜻하는 새 이름으로 스케치한 것이며, 표준 CDS 뷰 이름은 확인하지 못한 것은 쓰지 않았습니다. 선적 통지와 선하증권 번호를 읽는 필드는 고객사마다 입력 방식이 달라 확인 필요로 표시했습니다.

뷰 레이어 구성

① 규칙 테이블 — 허용 일수와 소유권 이전 가정

허용 일수와 인코텀즈별 가정은 이 테이블의 값입니다. 운영에서 가장 먼저 합의하는 자리이고, 값을 고치면 화면의 장기 미착 판정이 바뀝니다.

" ───────────────────────────────────────────────
" zit_rule : 미착품 판정 규칙
" 이렇게 나눈 이유 : 허용 일수·소유권 이전 시점은 회사 정책이라
"                    코드가 아니라 값으로 관리한다.
" ───────────────────────────────────────────────
@EndUserText.label : '미착품 판정 규칙'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zit_rule {
  key client     : abap.clnt not null;
  key rule_type  : abap.char(1) not null;   " M=운송 방식별 허용일, I=인코텀즈별 이전 시점
  key rule_key   : abap.char(3) not null;   " SEA, AIR 또는 FOB, CIF, DAP ...
  limit_days     : abap.int4;               " 허용 일수(M 일 때)
  own_at_ship    : abap.char(1);            " X=선적 시점에 소유권 이전 가정(I 일 때)
}

② 선적 기준 뷰 — 구매오더와 선적 통지를 선하증권 단위로

선하증권 한 건이 한 행이 되도록 구매오더 품목과 선적 통지를 묶습니다. 선하증권 번호를 어느 필드에서 읽을지는 고객사마다 달라 확인 필요 자리로 남깁니다.

" ───────────────────────────────────────────────
" ZI_InTransitShipment : 선하증권별 선적 기준
" 이렇게 나눈 이유 : 선적 정보의 출처를 한 곳으로 모아
"                    이후 뷰가 같은 키를 쓰게 한다.
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '미착품 선적 기준'
define view entity ZI_InTransitShipment
  as select from ekes as s
    inner join   ekko as h on h.ebeln = s.ebeln
    inner join   ekpo as p on p.ebeln = s.ebeln and p.ebelp = s.ebelp
{
  key s.ebeln                  as PurchaseOrder,
  key s.ebelp                  as PurchaseOrderItem,
  key s.etens                  as ShippingNoticeSeq,
      s.xblnr                  as BillOfLadingNo,   // 확인 필요 — 입력 필드는 고객사별
      h.inco1                  as Incoterms,
      p.werks                  as Plant,
      s.erdat                  as ShipDate,         // 선적일 매핑 확인 필요
      s.eindt                  as EtaDate,
      s.menge                  as ShippedQty,
      p.meins                  as OrderUnit
}
where s.ebtyp = 'LA'                                 // 선적 통지

③ 입고 기준 뷰 — 자재 문서에서 입고 수량과 전기일

입고 문서의 수량을 구매오더 품목 단위로 합산합니다. 입고 취소는 반대 부호로 들어오므로 합계가 자동으로 줄어듭니다.

" ───────────────────────────────────────────────
" ZI_InTransitReceipt : 구매오더 품목별 입고 수량·마지막 전기일
" 이렇게 나눈 이유 : 입고 취소(반대 부호)를 합계에서 자연스럽게 반영한다.
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '미착품 입고 기준'
define view entity ZI_InTransitReceipt
  as select from mseg as m
    inner join   mkpf as k on k.mblnr = m.mblnr and k.mjahr = m.mjahr
{
  key m.ebeln                              as PurchaseOrder,
  key m.ebelp                              as PurchaseOrderItem,
      max( k.budat )                       as LastReceiptDate,
      @Semantics.quantity.unitOfMeasure : 'Unit'
      sum( case m.shkzg when 'S' then m.menge else - m.menge end ) as ReceivedQty,
      m.meins                              as Unit
}
where m.bwart = '101' or m.bwart = '102'            // 구매오더 입고 / 입고 취소
group by m.ebeln, m.ebelp, m.meins

④ 장부 기준 뷰 — 미착품 계정 잔액

회계 전표 라인에서 미착품 계정의 금액을 합칩니다. 어떤 계정을 미착품으로 볼지는 고객사의 계정체계가 정하므로 계정 범위는 매핑 값으로 받습니다.

" ───────────────────────────────────────────────
" ZI_InTransitBook : 미착품 계정 잔액 (회사코드·계정)
" 이렇게 나눈 이유 : 계정 범위는 고객사 정책이라 뷰에 박지 않고
"                    변환 테이블/매핑에서 받는다(여기서는 계정 목록 가정).
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '미착품 장부 잔액'
define view entity ZI_InTransitBook
  as select from acdoca as a
{
  key a.rbukrs                                   as CompanyCode,
  key a.racct                                    as GLAccount,
      @Semantics.amount.currencyCode : 'Currency'
      sum( a.hsl )                               as BookAmount,
      a.rhcur                                    as Currency
}
where a.rldnr = '0L'
  and ( a.racct = '1140000' or a.racct = '1141000' )   // 가정 계정 — 고객사 값으로 교체
group by a.rbukrs, a.racct, a.rhcur

⑤ 큐브 — 경과일·미착 수량·기대 장부 계산

계산식은 이 뷰 한 곳에 둡니다. 기준일은 파라미터로 받아 같은 데이터를 어떤 날짜 기준으로도 볼 수 있습니다.

" ───────────────────────────────────────────────
" ZI_InTransitCube : 선하증권별 미착 계산 (기준일 파라미터)
" 이렇게 나눈 이유 : 경과일·초과일·기대 장부 산식을 한 곳에 모아
"                    화면과 다른 소비자가 같은 값을 쓰게 한다.
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '미착품 계산 큐브'
@Analytics.dataCategory : #CUBE
define view entity ZI_InTransitCube
  with parameters
    p_asof : abap.dats
  as select from ZI_InTransitShipment as s
    left outer join ZI_InTransitReceipt as r
      on r.PurchaseOrder = s.PurchaseOrder and r.PurchaseOrderItem = s.PurchaseOrderItem
    left outer join zit_rule as m
      on m.rule_type = 'M' and m.rule_key = 'SEA'
{
  key s.PurchaseOrder,
  key s.PurchaseOrderItem,
  key s.ShippingNoticeSeq,
      s.BillOfLadingNo,
      s.Incoterms,
      s.ShipDate,
      s.EtaDate,
      @Semantics.quantity.unitOfMeasure : 'OrderUnit'
      s.ShippedQty                                    as ShippedQty,
      @Semantics.quantity.unitOfMeasure : 'OrderUnit'
      coalesce( r.ReceivedQty, 0 )                    as ReceivedQty,
      @Semantics.quantity.unitOfMeasure : 'OrderUnit'
      s.ShippedQty - coalesce( r.ReceivedQty, 0 )     as OpenQty,
      s.OrderUnit,
      dats_days_between( s.ShipDate,
        case when r.ReceivedQty >= s.ShippedQty then r.LastReceiptDate
             else $parameters.p_asof end )            as AgeDays,
      m.limit_days                                    as LimitDays
}

⑥ 분석 쿼리 — 화면이 읽는 컬럼과 필터

화면에 필요한 컬럼과 필터를 이 뷰에 선언합니다. 화면은 이 쿼리를 서비스로 게시한 엔티티셋만 읽습니다.

" ───────────────────────────────────────────────
" ZC_InTransitQuery : 화면용 분석 쿼리
" 이렇게 나눈 이유 : 화면이 바뀌어도 큐브의 계산식을 건드리지 않게 한다.
" ───────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '미착품 점검 쿼리'
@Analytics.query : true
@OData.publish : false
define view entity ZC_InTransitQuery
  with parameters
    @Consumption.derivation : { lookupEntity : 'I_CalendarDate', resultElement : 'CalendarDate' }
    p_asof : abap.dats
  as select from ZI_InTransitCube( p_asof : $parameters.p_asof )
{
  @UI.lineItem : [{ position : 10 }]
  @Consumption.filter : { selectionType : #SINGLE, multipleSelections : false }
  key PurchaseOrder,
  @UI.lineItem : [{ position : 20 }]
  BillOfLadingNo,
  @UI.lineItem : [{ position : 30 }]
  Incoterms,
  @UI.lineItem : [{ position : 40 }]
  @Consumption.filter : { selectionType : #INTERVAL }
  ShipDate,
  @UI.lineItem : [{ position : 50 }]
  AgeDays,
  @UI.lineItem : [{ position : 60 }]
  LimitDays,
  @UI.lineItem : [{ position : 70 }]
  OpenQty
}

⑦ 접근 제어 — 플랜트 권한

권한은 쿼리가 아니라 큐브에 겁니다. 쿼리에만 걸면 다른 뷰로 우회해서 읽을 수 있습니다.

" ───────────────────────────────────────────────
" ZR_InTransitCube : 구매 플랜트 권한
" 이렇게 나눈 이유 : 집계를 읽는 큐브에 걸어 우회 경로를 막는다.
" ───────────────────────────────────────────────
@EndUserText.label : '미착품 큐브 권한'
@MappingRole : true
define role ZR_InTransitCube {
  grant select on ZI_InTransitCube
    where ( Plant ) = aspect pfcg_auth( M_BEST_WRK, WERKS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

쿼리를 OData V2 서비스로 게시하는 마지막 단계입니다. 서비스를 활성화한 뒤에는 화면의 manifest 서비스 주소만 운영 주소로 바꿉니다.

" ───────────────────────────────────────────────
" 서비스 정의 : 화면이 읽는 엔티티셋 노출
" 이렇게 나눈 이유 : 서비스 이름과 노출 범위를 한 파일로 관리한다.
" ───────────────────────────────────────────────
@EndUserText.label : '미착품 점검 서비스'
define service ZUI_InTransit {
  expose ZC_InTransitQuery as TransitSet;
  expose ZI_InTransitReceipt as ReceiptSet;
  expose ZI_InTransitBook as BookSet;
}
" 바인딩 : OData V2 - UI  (게시 후 서비스 주소를 화면 manifest 에 반영)

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

운영 데이터로 갈 때

구매오더·자재 문서·회계 전표가 수천만 건이면 집계 위치가 성능을 좌우합니다. 기준일 파라미터와 기준 연월을 필수 조건으로 두고, 입고 합계는 구매오더 품목 키로 먼저 줄인 뒤 선적 기준과 합칩니다. 회계 전표 라인은 계정·회사코드·전기 기간을 먼저 걸러 읽습니다. 응답 시간 기준(예: 화면 첫 조회 몇 초 이내)은 도입 전에 정하고 운영 데이터로 시험해 확인합니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

분석 기능

도입과 운영