수출 신용장 선적기일·제시기한 점검 — 신용장 조건과 실제 선적·서류 제시를 건마다 견주어 점검 필요 건을 가려내는 수출 대금 결제 점검 화면

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

수출 담당자가 신용장 건에서 반복해서 묻는 질문은 거의 같습니다. 정해진 날짜 안에 선적했는가, 허용된 금액 안에서 선적했는가, 정해진 기한 안에 서류를 냈는가. 이 세 답이 판매오더 · 납품 · 은행 통지 · 엑셀로 흩어져 있어서, 지금은 선적이 끝나거나 서류를 낼 때쯤 사람이 신용장 사본과 선적 자료를 한 건씩 맞춰 봅니다.

이 화면은 그 맞춰 보는 일을 한 화면에 올렸습니다. 신용장에 적힌 최종 선적기일 · 유효기간 · 허용 과부족 · 제시기간과 실제 선적일 · 누적 선적 금액 · 서류 제시일을 같은 선적 한 건 위에 나란히 놓고, 어긋나는 자리를 선적기일 경과 · 허용 한도 초과 · 제시기한 경과 · 서류 미제시 네 갈래로 가립니다. 어디까지나 점검 도구입니다. 신용장 조건 충족 여부와 하자 처리의 최종 판단은 회사와 거래 은행이 하며, 이 글과 화면의 제시기간 · 환율 · 기준 비율은 모두 샘플 가정값입니다.

핵심 포인트 여섯 가지

같은 선적이 조건 안이기도 하고 밖이기도 한 이유

신용장은 선적과 서류 제시에 여러 날짜 조건을 겁니다. 이 화면의 샘플 정책은 선적 경과 = 선적일 − 최종 선적기일, 제시 기한 = min(선적일 + 제시기간, 유효기간 만기), 허용 한도 = L/C 금액 × (1 + 허용 과부족 %) 로 둡니다. 선적이 기일 안이라도 서류를 늦게 내면 제시기한 경과가 되고, 서류를 제때 내도 선적이 기일을 넘었으면 선적기일 경과가 됩니다. 한 건에 조건이 둘 이상 겹칠 수 있다는 뜻이라, 이 화면은 유형은 먼저 해당하는 하나만 붙이되 해당하는 사유는 모두 판정 내용에 적습니다.

제시기간 21일 같은 값은 신용장마다 다를 수 있어 샘플 가정값으로만 쓰였습니다. 실제 조건은 신용장 원문에 적힌 값을 따라야 하며, 어느 값을 어떻게 읽어 올지는 도입 때 정할 일로 남겨 두었습니다.

분할 선적은 차수를 넘어 누적으로 봐야 한다

한 L/C 를 두세 번에 나누어 선적하면 차수마다 금액은 작아 보여도 누적이 허용 한도를 넘는 일이 생깁니다. 샘플에도 마지막 차수에서 누적 선적이 허용 과부족 5%를 넘는 L/C 한 건이 있습니다. 이 화면은 차수마다 누적 선적과 미사용 잔액을 이어서 보여 주고, 한도를 넘은 차수와 넘은 외화 금액을 한 칸에 둡니다. 외화 금액은 통화별로만 모으고, 원화는 가정 환율로 환산해 차수별 값이 누적 환산의 차이로 정해지도록 하여 L/C 단위 합이 어긋나지 않게 했습니다.

사용 방법

1. 조회조건을 입력합니다. 회계연도(필수, 4자리)만 정하면 되고, 거래처 · 개설은행 · 통화 · 판정 유형 · 선적일 범위 · 판정은 필요할 때만 고릅니다. 비워 두면 전체입니다.
2. 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 화면을 처음 열면 기본 조건으로 자동 조회됩니다.
3. 요약 지표 여섯 개를 확인합니다. 선적 건수 · 판정 대상 건수 · 점검 필요 건수 · 선적 금액 · 점검 필요 선적 · 대사 차이 건수입니다.
4. 탭을 옮겨 가며 봅니다. 선적 명세 → 월별 → 개설은행별 → 판정 유형별 → 통화별 → 대사 결과 순서입니다.
5. 표의 행을 눌러 상세 창을 엽니다. 선적 행은 그 건의 상세를, 요약 행은 그 조건에 속한 선적 건 목록을 함께 보여 줍니다. 닫기 버튼이나 ESC 키로 닫습니다.
6. CSV 내려받기를 누르면 지금 보고 있는 탭의 조회 결과가 UTF-8 CSV 로 내려받아집니다.

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

화면을 만들기 전에 대사식을 먼저 세우고, 선적 36건의 판정과 L/C 33건의 누적 · 잔액 · 원화 합, 요약 23행을 원천 칸에서 다시 구해 저장값과 견주었습니다. 결과는 모두 차이 0건이며, 아래 대사식은 화면의 대사 결과 탭에서 직접 확인할 수 있습니다.

위 여덟 개 식의 검사 건수를 모두 더하면 161건이고 차이는 0건입니다. 이와 별도로 의도적 예외 1종을 두었습니다. 선적일이 없는 L/C 5건은 판정을 할 수 없는 것이 정상이므로 대사 차이 건수에 섞지 않고 건수만 따로 기록합니다. 날짜 조회조건(선적일 범위)도 서버에서 직접 걸러지는 것을 확인했습니다.

무엇으로 만들었나

실행 화면

아래는 검증용 샘플 데이터로 실제 렌더링한 화면 7종입니다. 사용 순서대로 — 처음 연 화면, 점검 필요 건, 월 · 개설은행 · 판정 유형 탭, 한 건의 상세, 대사 결과 — 놓았습니다.

처음 열었을 때와 점검 필요 건만 보기

처음 연 화면은 한 번에 많이 보여 주되, 사람이 확인할 건만 추려 보는 길이 바로 옆에 있습니다.

화면 맨 위 안내 문구는 신용장 조건을 어떻게 견주는지 한 번 읽어 두라는 용도입니다. 회계연도 기본값(2026)으로 자동 조회되어 선적 41건 · 판정 대상 36건 · 점검 필요 8건이 요약 지표에 뜨고, 선적 금액은 8,933.8백만 원, 점검 필요 선적은 1,610.0백만 원입니다. 표 마지막 쪽에 판정과 판정 내용이 있고, 선적일이 비어 있는 행은 선적 전 L/C 라 판정에서 빠집니다.

조회조건의 판정을 "점검 필요"로 바꾸고 조회 버튼(또는 Enter)을 누르면 이상 없는 건이 빠지고 사람이 확인할 건만 남습니다. 요약 지표도 같은 조건으로 다시 계산되어 선적 건수 · 판정 대상 건수 · 점검 필요 건수가 모두 8 로 맞춰집니다. 담당자는 이 목록을 위에서부터 열어 보면 됩니다.

월 · 개설은행 · 판정 유형 — 같은 선적을 세 방향으로 다시 모으기

건별 표는 하나지만 질문은 세 가지입니다. 어느 달에 몰렸나, 어느 은행과의 거래에서 반복되나, 어떤 이유가 큰가. 탭만 바꾸면 같은 조회조건 위에서 답이 나옵니다.

선적월마다 선적 건수 · 점검 필요 건수 · 선적기일 경과 건수 · 제시기한 경과 건수와 금액, 점검 필요 비율이 한 줄에 놓입니다. 샘플에서는 3월이 60.00%(5건 중 3건), 8월이 40.00%, 6월이 33.33% 로 기준 30.00%(가정값)를 넘어 점검 필요로 표시되고, 7월과 9월은 25.00% 로 기준 아래입니다. 행을 누르면 그 달의 선적 건이 상세 창에 열립니다.

개설은행마다 선적 건수 · 점검 필요 건수와 비율, 선적 금액, 평균 제시 소요(일)가 놓입니다. 샘플에서는 Pacific Trade Bank 가 30.00%(10건 중 3건), Meridian Overseas Bank 가 33.33%(6건 중 2건)로 기준에 닿아 점검 필요로 표시됩니다. 같은 은행에서 반복되는지 보면 서류 보완 요청이나 은행과의 사전 협의 순서를 정하는 데 쓸 수 있습니다.

유형마다 건수와 선적 금액, 금액 비중을 보여 줍니다. 샘플에서는 이상 없음 28건(81.98%) 외에 제시기한 경과 3건(607.0백만 원), 선적기일 경과 3건(539.3백만 원), 허용 한도 초과 1건(249.2백만 원), 서류 미제시 1건(214.4백만 원)이 나옵니다. 금액이 큰 유형부터 확인하면 점검 순서가 정해지고, 행을 누르면 해당 선적 건이 열립니다.

한 건을 열어 보기와 대사 결과

숫자를 의심할 때 내려가는 길과, 숫자가 맞는다는 것을 확인하는 길입니다.

표의 행을 누르면 열리는 상세 창입니다. 이 건은 최종 선적기일이 3월 25일인데 3월 28일에 선적해 선적 경과 +3일로 "선적기일 경과"가 나옵니다. 서류는 제시 기한(4월 9일)보다 하루 앞선 4월 8일에 냈으므로 제시 쪽은 문제가 없다는 점이 요점입니다. 한도 초과 외화는 0 이라 금액 조건도 정상이며, 닫기 버튼이나 ESC 키로 닫습니다.

대사 결과 탭은 화면의 숫자가 어긋나지 않는지를 화면 안에서 보여 줍니다. 검사 건수 161건에서 차이 건수는 0건이고, 선적 전 L/C 5건은 의도적 예외 행으로 분리되어 차이 건수에 섞이지 않습니다. 대사식 좌변과 우변이 함께 나와 어디가 맞는지 바로 확인할 수 있습니다.

화면 뒤에서 일어나는 일

조회 한 번에 화면은 같은 조회조건으로 여섯 묶음(선적 명세 · 월별 · 개설은행별 · 판정 유형별 · 통화별 · 대사 결과)과 요약 지표를 읽습니다. 판정은 선적 건별로 한 번 정해져 저장된 값을 모든 묶음이 같이 쓰기 때문에, 탭을 옮겨도 같은 건이 다른 유형으로 바뀌지 않습니다. 선적일 범위는 서버 필터로 걸러지며, 선적일이 없는 L/C 는 범위 조건에서 빠집니다.

판정 규칙 — 조건에서 사용자 조치까지

한 건에는 아래 순서대로 가장 먼저 해당하는 조건 하나를 유형으로 붙이고, 해당하는 사유는 판정 내용에 모두 적습니다. 제시기간 · 기준 비율 · 환율은 샘플 가정값이며, 회사의 정책표로 바꿔 쓰는 자리입니다.

산출과 대사 순서

조회조건

결과 컬럼

파일 구성

앱 폴더/
  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/       서비스 선언(metadata.xml) · 서비스 로직(service.js) · 데이터(json/)
  media/       intro.mp4 · intro_poster.jpg

SAP 표준 기능 확장 포인트 — 표준 T-code 와 어떻게 연계되는지

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 판매오더 · 납품 · 청구 · 고객 항목을 보는 일은 표준 화면이 이미 충분하며, 이 화면은 그 값을 신용장 조건과 견주는 자리를 채웁니다.

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

T-code 별 연계 지점

기존 화면이나 리포트를 없애야 하나요? 없애지 않습니다. 신용장 개설 · 통지 · 매입 · 대금 회수는 회사와 거래 은행이 쓰는 체계에 그대로 두고, 이 화면은 선적과 서류 제시가 조건 안에 있는지 미리 점검하는 보조 화면으로 함께 둡니다.

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

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 도구가 있습니다. 이 화면은 그 위치를 대신하지 않고, 신용장 조건 점검이라는 한 가지 질문에 맞춘 CDS 뷰와 화면을 더하는 쪽입니다. 구체적인 Fiori 분석 앱 이름은 고객 시스템의 버전과 활성화 상태에 따라 달라 이 글에서는 쓰지 않으며, 확인 필요로 남깁니다. 같은 CDS 뷰 위에 Analysis for Office 시트를 얹어 쓰는 것도 가능합니다.

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

분석 지표 정의표

CDS 구성 — 기준 표에서 서비스까지

뷰 레이어 구성

SAP 에서 같은 일을 하려면 아래처럼 기준 표 · 기본 뷰 · 큐브 · 분석 쿼리 · 권한 · 서비스의 순서로 나누어 만듭니다. 화면이 읽는 OData 서비스는 맨 아래 서비스 층이 대신합니다.

① 기준 표 — 정책값과 신용장 조건

제시기간 기본값과 점검 필요 비율 기준은 정책 표에, 신용장마다 다른 선적기일 · 유효기간 · 허용 과부족은 조건 표에 둡니다. 코드에 박아 두면 고객사마다 소스를 고쳐야 하므로 표로 빼 두고 현업이 유지하게 합니다. 아래 조건 표는 신용장 정보를 담는 자리의 스케치이며, 실제 원천은 고객사 신용장 관리 방식에 따라 확인이 필요합니다.

" ─────────────────────────────────────────────────────────────
" zexlc_policy — 점검 정책값
" 역할 : 제시기간 기본값, 점검 필요 비율 기준.
" 나눈 이유 : 기준값이 코드에 있으면 정책이 바뀔 때마다 이송이 필요하다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '신용장 점검 정책값'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zexlc_policy {
  key mandt        : mandt not null;
  key bukrs        : bukrs not null;
  pres_days_dflt   : abap.int4;        " 제시기간 기본값(일)
  need_rate_pct    : abap.dec(5,2);    " 점검 필요 비율 기준(%)
}

" ─────────────────────────────────────────────────────────────
" zexlc_lcterm — 신용장 조건(스케치)
" 역할 : L/C 번호별 선적기일 · 유효기간 · 허용 과부족 · 제시기간.
" 주의 : 실제 원천은 고객사 신용장 관리 방식에 따라 확인 필요.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '신용장 조건'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table zexlc_lcterm {
  key mandt      : mandt not null;
  key lc_no      : abap.char(12) not null;
  vbeln          : vbeln_va;           " 연결된 판매오더
  issue_bank     : abap.char(4);
  waers          : waers;
  lc_amt         : abap.dec(15,2);
  tol_pct        : abap.dec(5,2);      " 허용 과부족(%)
  latest_ship    : abap.dats;          " 최종 선적기일
  expiry_date    : abap.dats;          " 유효기간 만기
  pres_days      : abap.int4;          " 제시기간(일)
}

② 기본 뷰 — 선적 한 건의 원천을 한곳에

신용장 조건 · 판매오더 · 납품 문서를 이어 선적 한 건당 한 행을 만듭니다. 선적일은 납품 실제 출고일로 가정했으며, B/L 일자를 별도 자료에서 가져오는 고객사는 이 뷰의 해당 칸만 바꾸면 됩니다. 문서 흐름의 유형 조건은 고객 시스템에 맞춰 확인이 필요합니다.

" ─────────────────────────────────────────────────────────────
" ZI_ExportLcShipment — 선적 한 건당 한 행
" 역할 : 신용장 조건 + 납품 실제 출고일 + 차수의 단일 원천.
" 나눈 이유 : 이후 모든 뷰가 같은 선적 정의를 쓰게 한다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 신용장 선적 기본'
define view entity ZI_ExportLcShipment
  as select from zexlc_lcterm as lc
    inner join   vbak          as so on so.vbeln = lc.vbeln
    inner join   vbfa          as fl on fl.vbelv = so.vbeln
                                    and fl.vbtyp_n = 'J'          " 후속 문서 = 납품(확인 필요)
    inner join   likp          as dl on dl.vbeln = fl.vbeln
{
  key lc.lc_no                      as LcNo,
  key dl.vbeln                      as DeliveryNo,                " 차수는 납품 순번으로 매김(확인 필요)
      so.kunnr                      as CustId,
      so.vkorg                      as SalesOrg,
      lc.issue_bank                 as IssBank,
      lc.waers                      as Curr,
      lc.lc_amt                     as LcAmt,
      lc.tol_pct                    as TolPct,
      lc.latest_ship                as LatestShip,
      lc.expiry_date                as ExpiryDate,
      lc.pres_days                  as PresDays,
      dl.wadat_ist                  as BlDate,                    " 선적일 갈음값 — B/L 일자 원천은 확인 필요
      @Semantics.amount.currencyCode: 'Curr'
      dl.netwr                      as ShipAmt                    " 납품 금액 — 원천 칸은 확인 필요
}

③ 누적 뷰 — 차수를 넘어 누적으로

분할 선적의 허용 한도 판정은 차수별 금액이 아니라 누적 금액으로 해야 합니다. CDS 에서는 같은 L/C 의 앞선 차수를 자기 조인으로 모아 합산합니다. 차수가 많은 대용량에서는 미리 집계한 뷰나 AMDP 로 바꾸는 쪽을 검토합니다.

" ─────────────────────────────────────────────────────────────
" ZI_ExportLcCumulative — 차수별 누적 선적
" 역할 : 같은 L/C 의 앞선 차수까지 합한 금액을 낸다.
" 나눈 이유 : 한도 판정이 누적 계산을 다시 하지 않게 한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 신용장 누적 선적'
define view entity ZI_ExportLcCumulative
  as select from ZI_ExportLcShipment as cur
    inner join   ZI_ExportLcShipment as prv
      on  prv.LcNo       = cur.LcNo
      and prv.DeliveryNo <= cur.DeliveryNo
{
  key cur.LcNo,
  key cur.DeliveryNo,
      cur.Curr,
      @Semantics.amount.currencyCode: 'Curr'
      sum( prv.ShipAmt ) as CumShip
}
group by cur.LcNo, cur.DeliveryNo, cur.Curr

④ 큐브 뷰 — 판정을 한 번만

허용 한도 · 제시 기한 · 경과 일수 · 판정 유형을 이 뷰에서 한 번 정하고, 이후 모든 쿼리가 같은 값을 읽습니다. 유형은 규칙 순서의 첫 조건 하나만 붙입니다.

" ─────────────────────────────────────────────────────────────
" ZI_ExportLcCheck — 선적 건별 판정
" 역할 : 허용 한도 · 제시 기한 · 경과 일수 · 판정 유형을 낸다.
" 나눈 이유 : 판정을 한 곳에서만 정해 탭을 옮겨도 같은 건이 바뀌지 않게 한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 신용장 선적 판정'
define view entity ZI_ExportLcCheck
  as select from ZI_ExportLcShipment as s
    inner join   ZI_ExportLcCumulative as c
      on c.LcNo = s.LcNo and c.DeliveryNo = s.DeliveryNo
{
  key s.LcNo,
  key s.DeliveryNo,
      s.SalesOrg,
      s.IssBank,
      s.Curr,
      s.ShipAmt,
      c.CumShip,
      s.BlDate,
      s.LatestShip,
      dats_days_between( s.LatestShip, s.BlDate )          as ShipLateDays,
      cast( s.LcAmt * ( 100 + s.TolPct ) / 100
            as abap.dec(15,2) )                            as MaxAmt,
      case when dats_add_days( s.BlDate, s.PresDays, 'NULL' ) < s.ExpiryDate
           then dats_add_days( s.BlDate, s.PresDays, 'NULL' )
           else s.ExpiryDate end                           as PresDeadline,
      case
        when dats_days_between( s.LatestShip, s.BlDate ) > 0     then 'LATESHIP'
        when c.CumShip > s.LcAmt * ( 100 + s.TolPct ) / 100      then 'OVERAMT'
        else 'OK' end                                      as CheckCode
      " 제시기한 경과 · 서류 미제시는 제시 기록 뷰를 붙여 같은 방식으로 이어 간다(확인 필요)
}

⑤ 분석 쿼리 — 화면이 읽는 모양으로

큐브를 그대로 노출하지 않고 화면에서 쓰는 필터와 정렬, 표시 주석만 붙인 쿼리 뷰를 둡니다. 회계연도는 필수 필터로 걸어 전 기간을 한 번에 읽는 일을 막습니다. 월별 · 개설은행별 · 통화별 묶음은 같은 큐브를 다른 그룹으로 읽는 쿼리를 따로 둡니다.

" ─────────────────────────────────────────────────────────────
" ZC_ExportLcQuery — 선적 명세 화면용 쿼리
" 역할 : 필터 · 정렬 · 표시 주석. 계산은 큐브에서 이미 끝났다.
" 나눈 이유 : 화면 요구가 바뀌어도 계산 로직은 건드리지 않는다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '신용장 선적 명세'
@Metadata.allowExtensions: true
define view entity ZC_ExportLcQuery
  as projection on ZI_ExportLcCheck
{
      @UI.lineItem: [{ position: 10 }]
  key LcNo,
  key DeliveryNo,
      SalesOrg,
      @UI.lineItem: [{ position: 20 }]
      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true }
      IssBank,
      @UI.lineItem: [{ position: 30 }]
      Curr,
      @UI.lineItem: [{ position: 40 }]
      ShipAmt,
      @UI.lineItem: [{ position: 50 }]
      CumShip,
      @UI.lineItem: [{ position: 60 }]
      BlDate,
      @UI.lineItem: [{ position: 70 }]
      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true }
      CheckCode
}

" ─────────────────────────────────────────────────────────────
" ZC_ExportLcMonth — 월별 요약 쿼리
" 역할 : 선적월마다 선적 건수와 점검 필요 건수를 센다.
" 나눈 이유 : 요약도 건별과 같은 큐브를 읽어 합계가 어긋나지 않게 한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '신용장 월별 요약'
define view entity ZC_ExportLcMonth
  as select from ZI_ExportLcCheck
{
  key substring( BlDate, 1, 6 )                       as YmCode,
      count( * )                                      as ShipCnt,
      sum( case when CheckCode <> 'OK' then 1 else 0 end ) as NeedCnt
}
group by substring( BlDate, 1, 6 )

⑥ 접근 제어 — 판매 조직 단위로

권한은 집계 단계에 겁니다. 상세 단계에만 걸면 합계에서 남의 몫이 뺄셈으로 드러납니다. 아래 권한 객체는 판매오더의 판매 조직 권한을 쓰는 예이며, 고객사의 권한 설계에 맞춰 확인이 필요합니다.

" ─────────────────────────────────────────────────────────────
" ZC_ExportLcQuery — DCL
" 역할 : 판매 조직 권한이 있는 선적 건만 읽게 한다.
" 나눈 이유 : 전사 합계와 자기 몫의 차이로 남의 숫자가 드러나지 않게.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '신용장 선적 명세 권한'
@MappingRole: true
define role ZC_ExportLcQuery {
  grant select on ZC_ExportLcQuery
    where ( SalesOrg ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩 — 화면이 부르는 서비스

쿼리를 서비스로 노출하는 마지막 층입니다. 화면의 앱 설정에는 서비스 주소가 상대 경로 하나로 적혀 있어, 운영에서는 Binding 을 게시한 뒤 이 주소만 바꾸면 됩니다.

" ─────────────────────────────────────────────────────────────
" Z_UI_ExportLcService — Service Definition
" 역할 : 화면이 읽는 묶음을 한 서비스로 노출한다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '수출 신용장 점검 서비스'
define service Z_UI_ExportLcService {
  expose ZC_ExportLcQuery as LcShipment;
  expose ZC_ExportLcMonth as LcMonth;
}
" Service Binding : OData V2 - UI 로 만들어 게시한다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코드가 아니라 합의입니다.

운영 데이터로 갈 때

선적이 해마다 수천 건을 넘기면 먼저 막히는 곳은 판정이 아니라 누적 계산의 자기 조인입니다. 회계연도를 필수 조건으로 두고, 선적일 범위를 좁혀 읽게 하며, 누적 뷰는 미리 집계해 두는 쪽을 검토합니다. 응답 시간 기준은 고객사와 정해야 하며 이 글은 수치를 약속하지 않습니다. 샘플 41건에서의 응답은 운영 규모를 대표하지 않습니다.

자주 묻는 질문

도입 전에 가장 많이 나오는 질문을 숫자와 판정 · 화면과 사용 · 표준 SAP 와의 관계 · 도입과 운영으로 묶었습니다. 이 글은 점검 도구를 소개하며 신용장 하자 여부나 대금 지급의 판단을 대신하지 않습니다.

숫자와 판정

화면과 사용

표준 SAP 와의 관계

도입과 운영