SAP 구매 B/L·입고·송장 3자 대조 — 지급 전에 선적·입고·송장 수량과 단가를 한 줄에서 견주는 수입 대금 점검

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

수입 대금을 내보내기 전의 질문은 늘 같습니다. 선적된 만큼 들어왔나, 들어온 만큼 송장이 왔나, 단가는 계약대로인가. 지금 이 세 답은 선적서류 · 창고 입고 내역 · 회계 송장으로 흩어져 있어, 한 건이 어긋나도 서로 다른 화면을 열어 맞춰 보기 전에는 알 수 없습니다. 이 앱은 세 문서를 같은 줄에 놓고, 어긋난 줄에는 이유까지 붙여 지급 전에 먼저 볼 건을 가립니다.

핵심 포인트 여섯 가지

이 자료에서 드러난 것

검증용 자료는 2026년 7월~9월 선적분 B/L 60건 · 라인 150행입니다. 판정 결과는 정상 93 · 안내 22 · 점검 필요 35이고, 점검 필요는 입고 수량 차이 12 · 송장 수량 차이 7 · 단가 차이 5 · 입고 전 송장 5 · 송장 미도착 6 으로 갈립니다. 같은 점검 필요라도 원인이 다르면 연락할 곳이 다릅니다 — 입고 수량 차이는 창고와 공급자, 송장 수량 · 단가 차이는 송장을 보낸 쪽, 입고 전 송장은 회계입니다. 판정이 원인까지 붙어 있어야 확인 요청이 한 번에 갈 수 있습니다.

가장 단순한 사례는 BL-2609-003 의 첫 라인입니다. 선적 800 · 입고 640 · 송장 800, 단가는 3.71 로 같습니다. 송장 2,968.00 USD 가 입고 기준 2,374.40 에 수량 효과 593.60 이 얹힌 값이고 단가 효과는 0 입니다. 즉 단가가 아니라 수량 때문이며, 원화로는 +832,702원(환율 1,402.80, 가정값)입니다.

실행 화면

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

처음 열었을 때

조회조건은 선적 연월(필수) · 통화 · 공급자 일부 · 점검 상태 · 판정 · B/L 일자 범위입니다. 조회를 누르거나 입력 칸에서 엔터를 누르면 같은 조회가 돌고, 조건 영역 맨 위 안내 문장이 이 화면은 점검 후보를 가리는 도구라는 것과 허용 오차가 가정값이라는 것을 먼저 밝힙니다. 표에서는 BL-2609-003 의 첫 라인처럼 선적 800 · 입고 640 · 송장 800 이 한눈에 어긋나 보이고, 점검 필요는 주황 글씨로 칠해 눈에 먼저 들어옵니다.

정상 38라인을 걷어 내고 12라인만 남긴 모습입니다. 송장 금액은 380,432,976원, 송장−입고 차이는 +18,958,806원으로 요약이 같이 바뀝니다. 같은 B/L 에서도 BL-2609-006 의 첫 라인은 송장 미도착(송장 0), 둘째 라인은 송장 수량 차이(315 대 300)로 서로 다른 판정을 받습니다. 판정이 라인 단위라서 한 B/L 안에서도 원인이 갈립니다.

문서와 집계로 접어 보기

B/L 에 점검 필요 라인이 하나라도 있으면 그 B/L 이 점검 필요가 됩니다. BL-2609-005 는 입고가 모자란 라인 때문에 +36,792.00(JPY) 이 생겼고, BL-2609-009 는 선적 83,790 대비 입고 기준 금액이 18,134.50 에 그쳐 송장이 먼저 온 모양이 드러납니다. 통화가 서로 달라 금액은 통화별로 읽고, 원화 환산은 오른쪽 열과 다른 탭에서 봅니다.

금액이 큰 쪽과 건수가 많은 쪽이 다르다는 것이 여기서 드러납니다. 송장 미도착 3건은 −38,654,106원으로 가장 크지만 건수는 입고 수량 차이(5건)가 더 많습니다. 어느 점검부터 할지 건수와 금액 두 축으로 정하게 됩니다. 판정 코드는 코드표(CodeSet)에서 읽어 이름과 상태를 붙입니다.

2026년 7월 3,834,507,254원(점검 12) · 8월 4,504,681,126원(점검 11) · 9월 2,540,006,757원(점검 12). 월마다 B/L 20건 · 라인 50행입니다. 송장−입고 차이는 7월 +119,066,668원, 8월 +11,656,833원, 9월 −7,299,374원으로 방향까지 달라, 합계 금액만 보면 놓칠 흐름이 보입니다.

202609 의 JPY 는 송장 11,671,955.00 으로 입고 기준보다 112,392.00 많고, EUR 는 반대로 −8,590.20 입니다. 통화별 차이와 원화 차이의 부호가 같다는 점, 그리고 원화로 환산하면 EUR 쪽이 −13,090,606원으로 가장 크다는 점이 한 표에서 읽힙니다. 환율이 다른 통화끼리는 통화별 금액을 더하지 않습니다.

숫자를 믿어도 되는가

01 번은 선적 수량 합 126,700 이 입고 + 미입고와 같고, 02~05 번은 송장 원화 합 10,879,195,137원이 어느 방향으로 더해도 같다는 것을 보입니다. 검사 건수와 차이 건수가 함께 적히고 차이 건수는 모두 0 입니다. 화면의 숫자를 믿어도 되는지 묻는 자리에서 가장 먼저 열어 보시면 됩니다.

라인 하나를 풀어 보기

아래에는 같은 B/L 의 다른 라인이 표로 붙습니다. BL-2609-003 에서 001 라인만 입고 수량 차이이고 002 · 003 은 3자 일치입니다. 원화로는 +832,702원(환율 1,402.80)입니다. 차이가 수량 때문인지 단가 때문인지를 이 한 창에서 가를 수 있어, 공급자에게 보낼 확인 요청의 내용이 곧바로 정해집니다.

SAP 표준 기능 확장 포인트

이 앱은 표준을 대체하지 않습니다. 선적 · 입고 · 송장은 표준이 이미 기록하고 있고, 끊기는 곳은 세 문서를 한 줄에 놓는 자리입니다. 표준이 하는 일은 그대로 두고 그 자리만 이어 붙입니다.

표준에서 어디를 보는가

표의 표준 이름은 일반적인 배치를 적은 것입니다. 실제 환경에서는 사용자 정의 필드나 별도 입고 · 송장 프로세스가 끼어 있을 수 있어, 도입 전에 어느 필드가 B/L 번호를 들고 있는지부터 확인합니다.

이 앱의 서비스 구성

서비스 이름은 blmatch_srv 이고 OData V2 입니다. 화면은 $filter · $orderby · $top · $inlinecount 만 쓰며, 동작 이름이 붙은 주소 · 사용자 정의 파라미터 · 함수 임포트가 없습니다. 이 단순함이 운영 서비스로 바꿀 때 가장 큰 장점입니다 — 같은 주소를 CDS 기반 서비스가 이어받으면 화면은 고치지 않아도 됩니다.

대사 결과 — 전수 검증

모든 대사에서 차이는 0 입니다. 송장 원화 합계 10,879,195,137원이 라인별 · B/L별 · 월별 · 통화별 어느 경로로 더해도 같습니다.

CDS 구성

이 사례의 화면은 서비스가 내려 준 150라인을 브라우저가 묶어 보여 줍니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일이 집계와 판정을 CDS 로 내리는 것입니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 허용 오차 테이블

허용 오차는 판정이 갈리는 기준이라 코드에 박지 않고 테이블로 둡니다. 운영에서는 송장 검증 허용 오차(OMR6) 설정을 그대로 옮기거나 이 테이블에서 읽습니다. 유효기간을 둔 이유는 기준이 바뀌어도 과거 판정이 흔들리지 않게 하기 위해서입니다.

@EndUserText.label : '3자 대조 허용 오차'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C        " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED
define table zmm_blm_tol {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;          " 회사코드
  key valid_to : abap.dats not null;      " 유효 종료일
  qty_pct      : abap.dec(5,2);           " 수량 허용률(%)   이 자료 2
  prc_pct      : abap.dec(5,2);           " 단가 허용률(%)   이 자료 1
  wait_days    : abap.int2;               " 송장 대기 일수   이 자료 30
}

② 선적 라인 뷰

B/L 번호는 납품 헤더에 있고 수량은 납품 품목에 있습니다. 구매오더 번호 · 품목으로 이어 붙이는 자리이므로 B/L 번호를 어느 필드가 들고 있는지가 환경마다 다릅니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '선적 라인'
define view entity ZI_BlmBlLine
  as select from likp as h
  inner join      lips as i on i.vbeln = h.vbeln
{
  key h.bolnr                     as BlNo,          " 확인 필요 — 환경에 따라 사용자 정의 필드
  key i.posnr                     as BlItem,
      i.vgbel                     as PurchaseOrder, " 선행 문서가 구매오더일 때
      i.vgpos                     as PurchaseOrderItem,
      h.lfdat                     as BlDate,
      i.meins                     as Unit,
      @Semantics.quantity.unitOfMeasure : 'Unit'
      i.lfimg                     as ShippedQty
}
where i.vgtyp = 'V'                                  " 구매오더 참조 납품

③ 입고 · 송장 집계 뷰

구매 이력(EKBE) 한 테이블에 입고와 송장이 함께 있습니다. 유형으로 나눠 구매오더 품목마다 합치고, 차변 · 대변 표시(SHKZG)로 역분개를 뺍니다. 입고 취소를 입고 수량에서 빼는지는 합의 항목입니다.

@EndUserText.label : '구매 이력 집계(입고·송장)'
define view entity ZI_BlmHist
  as select from ekbe
{
  key ebeln                                  as PurchaseOrder,
  key ebelp                                  as PurchaseOrderItem,
      @Semantics.quantity.unitOfMeasure : 'Unit'
      sum( case when vgabe = '1' and shkzg = 'H' then -menge
                when vgabe = '1'                 then  menge
                else 0 end )                 as GrQty,       " 입고
      sum( case when vgabe = '2' and shkzg = 'H' then -menge
                when vgabe = '2'                 then  menge
                else 0 end )                 as IvQty,       " 송장
      sum( case when vgabe = '2' and shkzg = 'H' then -wrbtr
                when vgabe = '2'                 then  wrbtr
                else 0 end )                 as IvAmtDoc,    " 송장 금액(전표통화)
      max( case when vgabe = '1' then budat end ) as GrDate,
      max( case when vgabe = '2' then budat end ) as IvDate,
      meins                                  as Unit
}
group by ebeln, ebelp, meins

④ 3자 대조 뷰 — 효과 분해

세 뷰를 이어 붙이고 수량 효과 · 단가 효과를 이 한 곳에서 정의합니다. 화면에서 계산하지 않는 이유는 식이 한 곳에만 있어야 합계가 어긋날 자리가 없기 때문입니다. 식은 g·p + (q−g)·p + q·(u−p) = q·u 입니다.

@EndUserText.label : 'B/L·입고·송장 3자 대조'
define view entity ZI_BlmMatch
  as select from ZI_BlmBlLine as b
  left outer join ZI_BlmHist  as h
       on  h.PurchaseOrder     = b.PurchaseOrder
       and h.PurchaseOrderItem = b.PurchaseOrderItem
  association [0..1] to ekpo as _Po
       on  _Po.ebeln = b.PurchaseOrder and _Po.ebelp = b.PurchaseOrderItem
{
  key b.BlNo, key b.BlItem,
      b.PurchaseOrder, b.PurchaseOrderItem,
      b.ShippedQty,
      coalesce( h.GrQty, 0 )                          as GrQty,
      coalesce( h.IvQty, 0 )                          as IvQty,
      _Po.netpr                                       as ContractPrice,
      case when h.IvQty > 0 then h.IvAmtDoc / h.IvQty end as InvoicePrice,

      " 입고 기준 금액 = 입고 수량 × 계약 단가
      coalesce( h.GrQty, 0 ) * _Po.netpr              as GrBaseAmt,
      " 수량 효과 = (송장 수량 − 입고 수량) × 계약 단가
      ( coalesce( h.IvQty, 0 ) - coalesce( h.GrQty, 0 ) ) * _Po.netpr  as QtyEffect,
      " 단가 효과 = 송장 수량 × (송장 단가 − 계약 단가)
      coalesce( h.IvQty, 0 ) * ( ( h.IvAmtDoc / nullif( h.IvQty, 0 ) ) - _Po.netpr ) as PriceEffect,

      h.GrDate, h.IvDate, b.BlDate
}

⑤ 판정 쿼리

판정 우선순위와 허용 오차 비교는 쿼리 뷰에 둡니다. 아래 순서는 스케치이며 어느 판정이 먼저 걸리는지는 회사 기준으로 합의해야 합니다. 허용 오차 테이블과 이어 붙이는 자리가 이 뷰입니다.

@EndUserText.label : '3자 대조 판정'
@Analytics.query : true
define view entity ZC_BlmMatchQuery
  as select from ZI_BlmMatch as m
  inner join      zmm_blm_tol as t on t.valid_to >= $session.system_date
{
  key m.BlNo, key m.BlItem,
      m.ShippedQty, m.GrQty, m.IvQty, m.QtyEffect, m.PriceEffect,
      case
        when m.IvQty > 0  and m.GrQty = 0                     then 'NGR'  " 입고 전 송장
        when m.IvQty = 0  and m.GrQty > 0
         and dats_days_between( m.GrDate, $session.system_date ) > t.wait_days
                                                              then 'NIV'  " 송장 미도착·대기
        when abs( m.GrQty - m.ShippedQty ) > m.ShippedQty * t.qty_pct / 100
                                                              then 'QTY'  " 입고 수량 차이
        when abs( m.IvQty - m.GrQty )      > m.GrQty      * t.qty_pct / 100
                                                              then 'IQT'  " 송장 수량 차이
        when abs( m.PriceEffect )          > m.GrBaseAmt  * t.prc_pct / 100
                                                              then 'PRC'  " 단가 차이
        when m.GrQty <> m.ShippedQty or m.IvQty <> m.GrQty    then 'TOL'  " 허용 범위 내
        else 'OK'
      end as Verdict
}

⑥ 권한(DCL)

집계를 읽는 뷰에 구매조직 범위를 겁니다. 합계 뷰에 걸지 않으면 합계에서 빠진 만큼으로 범위 밖 금액을 짐작할 수 있습니다.

@EndUserText.label : '3자 대조 구매조직 권한'
@MappingRole : true
define role ZI_BLMMATCH {
  grant select on ZI_BlmMatch
    where ( PurchasingOrganization ) = aspect pfcg_auth( M_BEST_EKO, EKORG, ACTVT = '03' );
}   " 확인 필요 — 쿼리 뷰에 구매조직 필드를 노출해야 걸립니다

⑦ 서비스 정의

화면이 부르는 엔티티셋을 서비스로 열어 둡니다. 화면은 $filter 등 표준 질의만 쓰므로 이 서비스가 같은 이름의 엔티티셋을 내려 주면 화면은 고치지 않아도 됩니다.

@EndUserText.label : 'B/L·입고·송장 3자 대조 서비스'
define service ZUI_BLMATCH_SRV {
  expose ZC_BlmMatchQuery as LineSet;
  " BlSet · MonthSet · CurSet · CodeSet 은 같은 방식으로 집계 뷰를 노출한다.
  " ReconSet 은 대사식을 SQL 로 돌려 좌변 · 우변 · 차이를 돌려주는 뷰다.
}

화면이 부르는 질의 예

서비스를 바꿔도 화면이 그대로 돌려면 주소와 응답 모양이 같아야 합니다. 아래는 9월 선적분 중 점검 필요만 금액 큰 순으로 열 건 가져오는 질의입니다.

GET /blmatch_srv/LineSet?$filter=Month eq '202609' and Status eq 'CHECK'
    &$orderby=DiffKrw desc&$top=10&$inlinecount=allpages
→ { "d": { "__count": "12", "results": [ … ] } }

운영 전환에서 정해야 할 것

자주 묻는 질문

도입 상담과 데모에서 나올 만한 질문을 네 묶음으로 적었습니다.

숫자와 판정

화면과 조회

서비스와 데이터

도입과 운영