SAP 공급사 통합 관리 — 등록·평가·계약·단가를 한 앱에서 처리하고 승인하고 대사하는 구매 운영

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

공급사를 새로 들이고, 평가해 등급을 매기고, 계약을 맺고, 단가를 고치는 일은 구매 부서에서 매달 반복됩니다. 그런데 공급사 정보는 BP, 단가는 ME12, 구매오더는 ME21N, 평가는 ME61 처럼 화면이 나뉘어 있어 "이 등급은 어느 평가에서 나왔는지", "이 단가는 어느 계약 문서가 근거인지"를 한 번에 확인하기 어렵습니다.

공급사 통합 관리는 등록 → 평가 → 계약 → 단가 개정 → 확정 → 분석의 업무 흐름을 문서 단위로 한 앱에 모읍니다. 처리와 승인, 일괄 실행, 대사 점검, 분석과 드릴스루를 같은 데이터 위에서 하므로 담당자와 승인자, 관리자가 같은 숫자를 보고 이야기할 수 있습니다. 이 앱은 점검과 처리를 돕는 도구이며 최종 판단은 회사와 감사인이 합니다.

핵심 포인트 일곱 가지

사례로 보는 효과

검증용 샘플 데이터에서 대사 규칙 4개를 75건 모두 돌렸더니 차이가 정확히 4건 나왔고, 그 4건은 의도적으로 넣어 둔 예외(단가표 직접 수정 1 · 평가 점수 불일치 1 · 등급 불일치 1 · 큐브 계약금액 불일치 1)와 같았습니다. 큐브 합계와 품목 합계는 측정값 11종 모두 차이 0원이었고, 계획 대비 차이는 기준 1,426,465,667원에 요인 합계 10,006,986원을 더해 실적 1,436,472,652원과 일치했습니다. 어느 숫자가 어디서 생겼는지 화면에서 거슬러 올라갈 수 있다는 뜻입니다.

도입하면 달라지는 것

• 마스터를 직접 고치는 대신 문서로 요청하고 승인·확정하므로 변경 근거와 이력이 남습니다.
• 등급과 평가 점수가 문서에서 나와 마스터와 어긋나는지를 대사로 먼저 찾습니다.
• 평가 도래와 계약 만료 임박 대상을 시뮬레이션으로 미리 보고 한 번에 처리합니다.
• 승인 회의에서 같은 분석 화면을 보며 칸을 눌러 원천 문서까지 확인합니다.
• 월말 엑셀 대사표 대신 규칙 4개의 결과 표를 기준으로 예외만 조치합니다.

이런 회사에 맞습니다

공급사가 수십~수백 곳이고 공급사 평가와 단가 개정이 정기적으로 일어나는 제조·유통 회사, 구매 부서와 품질·경영지원이 평가 결과를 함께 보는 조직, 단가 개정에 승인 단계가 있고 담당자 변경 이력을 남겨야 하는 곳에 맞습니다. 사업장이 여러 곳이고 구매 그룹이 나뉜 회사라면 플랜트별 분석 축이 특히 쓸모 있습니다.

실행 화면

사용 방법

1. 조회조건 입력 — 화면 위쪽에서 사업장과 기간을 고릅니다. 기간은 기본값이 채워져 있어 바꾸지 않아도 되고, 검색어와 구분·상태는 선택입니다.
2. 조회 버튼과 Enter 키 — 입력칸 오른쪽의 파란 조회 버튼을 누르거나 검색어에서 Enter 키를 누릅니다. 개요 화면은 열 때 한 번 자동으로 조회됩니다.
3. 요약 확인 — 개요 타일(계약 준수율 · 활성 공급사 · 평가 도래 · 만료 임박 단가 · 승인 대기 등)에서 오늘 할 일을 확인합니다.
4. 탭·화면 이동 — 왼쪽 메뉴를 위에서 아래로 개요 → 기준정보 → 문서 처리 → 일괄 실행 → 대사·점검 → 분석 → 문서 흐름 → 이력·감사·권한 순으로 이동합니다.
5. 행 클릭 상세 — 목록의 행을 누르면 품목, 상태 이력, 연계 문서가 열립니다. 분석에서는 피벗 칸을 누르면 원천 문서 행이 열립니다.
6. 내보내기 — 목록은 CSV · xlsx, 분석은 CSV · PowerPoint 버튼으로 현재 조회 결과를 받습니다.

무엇으로 만들었나

처음 열었을 때 — 한 화면에서 오늘 할 일까지

개요 화면은 열자마자 한 번 자동으로 조회됩니다. 타일 숫자는 해당 화면으로 이동하는 입구이기도 합니다.

타일은 계약 준수율 80.3퍼센트, 활성 공급사 12곳, 평가 도래 7곳, 만료 임박 단가 28건처럼 산식이 아래에 적혀 있습니다. 사업장과 기간을 바꾸고 조회하면 같은 집계로 다시 계산합니다.

기준정보 관리 — 공급사 · 단가 · 등급 기준을 한 곳에서

공급사, 자재, 구매 단가, 등급 기준 네 탭으로 나뉩니다. 처리자 역할에서만 생성·수정 버튼이 켜집니다.

공급사 목록은 등급, 평가 점수, 최근 평가일을 함께 보여 줍니다. 검색어에서 Enter 키를 누르면 조회하고, 행을 고르면 수정·사용 중지 버튼이 켜집니다.

계약 단가 옆에 이전 단가와 마지막 문서가 붙어 개정 근거를 바로 확인합니다. 유효 종료가 가까운 단가는 일괄 실행의 갱신 대상이 됩니다.

등급 구간은 A 85점 이상, B 70~84점, C 55~69점, D 55점 미만입니다. 구간을 고치면 다음 평가부터 등급이 다시 계산됩니다.

문서 처리와 승인 — 작성자 본인은 승인할 수 없다

등록(ON) · 평가(EV) · 계약(CT) · 단가 개정(PC) 문서가 한 목록에 모입니다. 상태에 따라 켜지는 버튼이 달라지고, 확정은 마스터를 갱신하며 취소는 되돌립니다.

문서 번호 앞 두 글자가 유형(ON 등록 · EV 평가 · CT 계약 · PC 단가 개정)입니다. 구분과 상태로 거르고 CSV · xlsx 로 내려받을 수 있습니다.

상세에는 품목 단가와 이전 단가, 상태 이력, 연계 문서가 모입니다. 확정된 계약 문서는 단가표의 근거가 됩니다.

평가 문서는 항목별 가중치와 환산 점수의 합이 총점이 됩니다. 총점은 확정 때 공급사 마스터에 반영됩니다.

임시저장 문서를 검토요청으로 올리기 전에 한 번 더 확인합니다. 메모를 남기면 상태 이력에 같이 기록됩니다.

작성자 본인 승인이나 권한 없는 역할의 처리는 서버가 거절하고 현재 역할을 안내합니다. 화면 버튼과 서버 판정이 같은 규칙을 씁니다.

확정(전기) 후 상태가 40 확정으로 바뀌고 이력에 처리자와 시각이 남습니다. 이 시점부터 마스터 갱신이 일어납니다.

평가 문서를 확정하면 공급사 점수와 등급, 최근 평가일이 바로 갱신됩니다. 대사 R02 · R03 이 이 값을 문서와 대조합니다.

단가 개정 문서를 확정하면 단가표의 계약 단가가 새 값으로 바뀌고 이전 단가가 보존됩니다.

취소는 반대 문서(RV)를 만들고 금액 부호를 반전합니다. 원 문서와 반대 문서는 문서 흐름으로 연결됩니다.

반대 문서가 확정되면 단가표가 이전 단가로 복원됩니다. 마스터를 직접 고치지 않아도 되돌릴 수 있습니다.

엑셀 업로드 — 미리 보고 정상 건만 반영한다

단가 개정을 엑셀로 올리면 미리보기에서 정상 건과 확인 필요 건을 나누고, 정상 건만 문서로 만듭니다.

양식에 맞춘 엑셀을 올리면 서버가 아니라 화면에서 먼저 읽어 미리보기를 만듭니다.

정상 3건과 확인 필요 1건(플랜트 형식)을 나눠 보여 줍니다. 정상 건만 반영하면 단가 개정 문서 3건이 생성됩니다.

일괄 실행 — 시뮬레이션 합계와 실행 결과가 같다

실행 전에 만들어질 문서를 미리 보여 주고, 미리 본 결과 그대로만 실행합니다. 같은 조건으로 다시 실행하면 처리 대상이 없다고 안내합니다.

시뮬레이션은 저장하지 않고 대상 공급사, 현재 점수, 예상 총점 합계만 보여 줍니다. 실행 버튼은 이 결과가 있어야 켜집니다.

실행하면 평가 문서가 생성되고 실행 이력과 로그가 남습니다. 로그의 문서 수와 금액이 시뮬레이션과 같습니다.

같은 조건으로 다시 실행하면 이미 만든 문서는 건너뛰고 처리 대상이 없다고 안내합니다.

갱신 실행은 유효 종료가 90일 이내인 계약을 대상으로 단가 개정 문서를 만듭니다.

대사와 예외 조치 — 차이는 사유와 함께 남긴다

규칙 네 개로 마스터와 확정 문서를 대조하고, 차이는 예외 목록에서 사유와 조치를 기록합니다.

규칙 R01~R04 의 검사 건수와 차이 건수, 최대 차이를 표로 보여 줍니다. 차이는 점검 필요 신호이며 원인은 예외에서 확인합니다.

예외마다 사유와 조치를 입력하고 확정 문서 기준으로 정정하거나 보류합니다. 조치 이력은 감사 로그에 남습니다.

분석 — 같은 집계에서 축만 바꿔 본다

차원 칩을 끌어 행 축과 열 축을 정하고, 역할별 요약으로 시작점을 바꿉니다. 칸을 누르면 원천 문서 행이 열립니다.

역할별 요약에서 재무 책임자를 고르면 확정 계약금액을 플랜트 × 공급사 구분 행, 기간 열로 보여 줍니다. 합계는 약 11억 7천만 원입니다.

자재 담당 요약은 계약 외 구매금액을 중심으로 봅니다. 계약 외 구매 비율이 높은 공급사를 먼저 찾을 수 있습니다.

품질 담당 요약은 불량 수량과 불량률을 공급사별로 보여 줍니다.

피벗의 칸을 누르면 그 값을 만든 문서 행이 열리고 합계가 피벗과 일치하는지 함께 표시합니다. CSV 로 내려받을 수 있습니다.

행과 열을 바꿔도 서버에 다시 묻지 않고 같은 합계로 다시 배치합니다. 바꾼 뒤에도 총합은 그대로입니다.

AI 분석과 에이전트 — 근거가 붙은 해설과 알림

AI 분석은 조회 범위의 숫자에서 근거 문장을 만들고, 에이전트는 점검 규칙을 돌려 알림을 남깁니다.

조회 범위의 숫자에서 규칙 기반으로 해설 문장과 근거를 만듭니다. 문장은 판단이 아니라 점검 출발점입니다.

에이전트는 납기 지연 · 단가 상승 · 계약 만료 임박 같은 규칙을 돌려 대상이 있으면 알림을 남깁니다.

영역 간 연계 · 이력 · 역할 · 좁은 화면

문서 흐름과 감사 이력, 역할별 버튼 차이, 390px 폭의 화면입니다.

문서 흐름은 선택한 계약 문서에 이어진 단가 개정 · 취소 문서를 영역과 함께 보여 줍니다.

누가 언제 어떤 동작을 했는지와 변경 전후 값, 결과가 이력으로 남습니다. 거절된 시도도 기록됩니다.

조회자 역할은 읽기만 가능해 생성 · 업로드 버튼이 꺼집니다. 서버도 같은 권한표로 다시 확인합니다.

390px 폭에서는 왼쪽 메뉴가 레일로 접히고 목록의 보조 열이 숨겨집니다.

분석은 차트가 표 아래로 내려오고 조회 · 초기화 버튼 위치는 같습니다.

화면 뒤에서 일어나는 일

버튼을 누르면 화면은 서비스에 요청만 보내고, 상태 전이 · 승인 판정 · 금액 계산은 서비스 로직이 합니다. 아래 표는 그 판정 규칙입니다.

일괄 실행의 처리 단계

평가 실행은 마지막 평가가 180일을 지났거나 평가가 없는 공급사를 대상으로, 갱신 실행은 유효 종료가 90일 이내인 계약을 대상으로 합니다. 시뮬레이션이 만든 확인값(SimHash)이 있어야 실행되고, 같은 조건으로 다시 실행하면 처리 대상이 없다고 안내합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

390px 폭에서는 왼쪽 메뉴가 레일로 접히고 목록의 보조 열이 숨겨집니다. 분석은 차트가 표 아래로 내려옵니다. 조회와 초기화 버튼의 위치는 같고 가로 스크롤은 생기지 않습니다.

파일 구성

app/
  Component.js · manifest.json · index.html · readme.html
  controller/   (화면별 컨트롤러 · 기반 컨트롤러)
  view/         (화면 XML 8개 · 대화상자 조각)
  model/        (집계 · 차트 · xlsx · pptx · 서식 · 권한 모듈)
  css/ · i18n/
  odata/        (서비스 로직 · 메타데이터 · 엔티티셋별 샘플 데이터)
  media/        (소개 영상 · 포스터 · 목차 트랙)

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다.

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

T-code 별 연계 지점

운영 전환 때 기존 표준 리포트를 없애야 하는 것은 아닙니다. 표준 리포트는 그대로 두고, 이 화면의 숫자가 표준 화면과 맞는지 대사 규칙으로 확인하면서 단계적으로 업무를 옮기면 됩니다.

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

SAP S/4HANA 의 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 표준 데이터를 보는 입구입니다. 이 앱은 그 위에서 공급사 단위의 평가 · 계약 · 단가를 한 흐름으로 처리하고 점검하는 자리를 맡습니다. 구체적인 표준 Fiori 앱 이름은 확인 필요이므로 여기서는 적지 않았습니다.

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

CDS 구성 — 운영 데이터로 갈 때의 구조

뷰 레이어 구성

기준 → 차원 → 큐브 → 쿼리 → 권한 → 서비스 순으로 나눕니다. 아래 객체 이름은 설명용 예시이며 표준 뷰 이름은 확인 필요입니다.

① 등급 구간 기준 테이블 — 점수에서 등급을 정하는 자리

등급 구간은 코드가 아니라 데이터로 둡니다. 구간을 바꿔도 뷰를 고치지 않고 운영 담당이 조정할 수 있어야 하기 때문입니다.

" ─────────────────────────────────────────────
" ZVHB_GRADE — 공급사 등급 구간 기준
" 역할 : 평가 총점이 속한 등급(A~D)을 정하는 구간표
" 이렇게 나눈 이유 : 구간 변경이 잦아 코드 전송 없이 데이터로 바꾸기 위해
" ─────────────────────────────────────────────
@EndUserText.label : '공급사 등급 구간'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zvhb_grade {
  key client   : abap.clnt not null;
  key grade    : abap.char(1) not null;
  min_score    : abap.dec(5,1);
  max_score    : abap.dec(5,1);
  active       : abap_boolean;
}

② 공급사 차원 — 마스터 값과 구분·지역 이름

공급사 코드마다 이름, 구분, 지역을 한 번에 읽는 기준 뷰입니다. 큐브와 쿼리는 이 뷰만 참조합니다.

" ZI_SupplierDim — 공급사 차원 (기준 레이어)
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '공급사 차원'
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'Supplier'
define view entity ZI_SupplierDim
  as select from lfa1
  association [0..1] to I_Country as _Country on $projection.Country = _Country.Country
{
  @ObjectModel.text.element : ['SupplierName']
  key lifnr as Supplier,
  name1     as SupplierName,
  ktokk     as SupplierGroup,
  land1     as Country,
  _Country
}

③ 단가 기준 뷰 — 계약 단가와 유효 기간

구매 정보 레코드의 조건 단가와 유효 기간을 한 줄로 읽습니다. 운영에서는 조건 유형을 정해 필터를 추가합니다. 표준 뷰 이름은 확인 필요이며 여기서는 원천 테이블 기준으로 적었습니다.

" ZI_SupplierPrice — 계약 단가 기준
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '공급사 계약 단가'
define view entity ZI_SupplierPrice
  as select from eina as info
    inner join   eine as org on org.infnr = info.infnr
{
  key info.lifnr          as Supplier,
  key info.matnr          as Material,
  key org.ekorg           as PurchasingOrg,
      @Semantics.amount.currencyCode : 'Currency'
      org.netpr           as ContractPrice,
      org.waers           as Currency,
      org.datlb           as LastPriceDate
}

④ 구매오더·입고 팩트 — 발주금액과 입고금액의 원천

발주금액과 입고금액을 같은 키로 모읍니다. 계약 외 구매 여부는 계약 단가 존재 여부로 파생합니다.

" ZI_PurchaseFact — 발주·입고 팩트
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '구매 발주·입고 팩트'
define view entity ZI_PurchaseFact
  as select from ekpo as po
    left outer join ekbe as gr on  gr.ebeln = po.ebeln
                               and gr.ebelp = po.ebelp
                               and gr.vgabe = '1'
{
  key po.ebeln, key po.ebelp,
  po.werks                  as Plant,
  po.matnr                  as Material,
  @Semantics.amount.currencyCode : 'Currency'
  po.netwr                  as OrderAmount,
  po.waers                  as Currency,
  @Semantics.amount.currencyCode : 'Currency'
  sum( gr.dmbtr )           as ReceiptAmount
}
group by po.ebeln, po.ebelp, po.werks, po.matnr, po.netwr, po.waers

⑤ 공급사 큐브 — 측정값과 계산 항목의 자리

큐브는 합계 가능한 값만 담고 비율은 쿼리의 계산 항목에서 만듭니다. 계약 준수율은 (발주 − 계약 외 구매) ÷ 발주입니다.

" ZI_SupplierCube — 분석 큐브
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '공급사 분석 큐브'
define view entity ZI_SupplierCube
  as select from ZI_PurchaseFact as f
  association [0..1] to ZI_SupplierDim as _Supplier on _Supplier.Supplier = $projection.Supplier
{
  key f.ebeln, key f.ebelp,
  f.Plant,
  _Supplier.Supplier,
  @DefaultAggregation : #SUM
  @Semantics.amount.currencyCode : 'Currency'
  f.OrderAmount,
  @DefaultAggregation : #SUM
  @Semantics.amount.currencyCode : 'Currency'
  f.ReceiptAmount,
  f.Currency,
  _Supplier
}

⑥ 분석 쿼리 — 계산 항목과 기본 레이아웃

화면의 피벗에 대응하는 쿼리입니다. 필수 필터와 기본 행·열 축을 여기서 정합니다.

" ZC_SupplierAnalysisQuery — 소비 레이어(쿼리)
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : '공급사 분석'
define transient view entity ZC_SupplierAnalysisQuery
  provider contract analytical_query
  as projection on ZI_SupplierCube
{
  @AnalyticsDetails.query.axis : #ROWS
  Plant,
  @AnalyticsDetails.query.axis : #ROWS
  Supplier,
  @AnalyticsDetails.query.axis : #COLUMNS
  OrderAmount,
  @AnalyticsDetails.query.axis : #COLUMNS
  ReceiptAmount
}

⑦ 권한 — 플랜트별 접근 통제(DCL)

데모의 역할 전환은 운영에서 권한 객체로 바뀝니다. 플랜트 단위 조회 권한을 DCL 로 걸어 둡니다.

@EndUserText.label : '공급사 분석 — 플랜트 권한'
@MappingRole : true
define role ZVHB_SUPPLIER_DCL {
  grant select on ZI_SupplierCube
    where ( Plant ) = aspect pfcg_auth( M_BEST_WRK, WERKS, ACTVT = '03' );
}

⑧ 서비스 정의 — 화면이 읽는 서비스 한 줄

분석 쿼리와 기준 뷰를 서비스로 노출합니다. 화면의 서비스 선언 주소만 바꾸면 운영 데이터로 연결됩니다.

@EndUserText.label : '공급사 통합 관리 서비스'
define service ZUI_SupplierHub {
  expose ZC_SupplierAnalysisQuery as SupplierAnalysis;
  expose ZI_SupplierDim           as Supplier;
  expose ZI_SupplierPrice         as SupplierPrice;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목을 먼저 정해야 운영 연결이 순조롭습니다.

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

검증용 샘플 데이터로 대사식을 전수 돌린 결과입니다. 차이가 있는 4건은 의도적으로 넣은 예외와 같습니다.

운영 데이터로 갈 때

발주·입고 문서가 대량이면 집계는 데이터베이스에서 하고, 기간과 플랜트를 필수 조건으로 둬야 합니다. 큐브에는 합계 가능한 값만 담고 비율은 쿼리에서 계산하면 응답 시간을 안정적으로 유지할 수 있습니다. 응답 시간 기준은 도입 때 정합니다.

자주 묻는 질문 — 최대한 자세히

도입 검토에서 자주 나오는 질문을 숫자와 대사 · 화면과 사용 · 분석 기능 · 도입과 운영으로 묶었습니다. 이 앱은 점검 도구이며 최종 판단은 회사와 감사인(세무 신고는 회사와 세무 대리인·관세사)이 합니다.

숫자와 대사

화면과 사용

분석 기능

도입과 운영