SAP BP 업로드 — 탭 아홉 개를 세 갈래로 나눠 처리하기
고객·공급업체 마스터를 양식 한 파일로 올리고, 대상에 따라 읽는 탭과 호출 API 를 나눠 처리하는 화면입니다.
거래처 하나를 등록하려면 일반 정보와 은행, 회사코드, 세금, 영업, 구매까지 여러 화면을 거칩니다. 신규 거래처가 열 곳이면 이 과정을 열 번 반복해야 합니다.
그래서 업로드 양식은 탭을 나눠 한 파일에 담습니다. 문제는 탭마다 처리 방식이 다르다는 점입니다. 일반·은행·회사코드·세금은 하나의 펑션으로 묶어 넣지만, 영업 데이터는 고객 API 를, 구매 데이터는 공급업체 API 를 따로 호출해야 합니다. 이 화면은 처리 대상을 고르면 그에 해당하는 탭만 읽어 맞는 API 로 넘기고, 나머지 탭은 건드리지 않은 채로 둡니다.
SAP 표준 구조를 그대로 이어받은 부분
- 마스터 구조 —
KNA1·KNVV·KNVI·KNVP·LFA1·LFM1그대로 - BP 처리 —
ZFIG_BP_MAINTAIN(IV_MODE 'I' 생성 / 'U' 변경) - 영업 데이터 —
cmd_ei_api=>maintain_bapi(KNVV 유무로 task 'U'/'I') - 구매 데이터 —
vmd_ei_api=>maintain_bapi(LFA1 에 Vendor 코드 확인)
| 항목 | 내용 |
|---|---|
| 업무 영역 | 재무회계(FI) · Business Partner 일괄 등록 |
| Namespace | zui5.bpupload |
| 셸 구조 | 실행조건 영역(우측 실행) + 결과 리스트, 탭·에러 필터 |
| 화면 수 | 조회·실행 화면 1개 |
| 데이터 | 업로드 50행 · 탭 9종 (에러 7행) · 기존 마스터 5개 |
| 성격 | 등록형 — 마스터 생성·변경은 표준 펑션·API 가 수행 |
| UI 테마 | sap_horizon 단일 적용 |
실제 화면 8종 둘러보기
양식을 선택하면 아홉 개 탭이 올라옵니다 → 처리 대상을 바꿔 가며 세 번 실행하고 → 에러만 보기로 고칠 줄을 추립니다.
아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.
조작 방법
- Template Download로 양식을 받아 탭별로 작성합니다. 탭마다 필요한 컬럼이 다릅니다.
- 파일 선택으로 양식을 올리면 모든 탭의 내용이 한 목록에 표시됩니다.
- 처리 대상을 고릅니다. business partner 를 고르면 create·update 라디오가 함께 나타납니다.
- 실행하면 해당 대상의 탭만 처리되고, 나머지 탭은 '작업전'으로 남습니다.
- 대상을 바꿔 가며 business partner → sales → purchase 순으로 세 번 실행합니다.
- 탭 필터와 에러만 보기로 확인할 줄을 추리고, 결과 CSV로 전체를 내려받습니다.
탭 분기와 검증 규칙
탭에 따라 점검 항목이 다릅니다. 라인마다 해당하는 규칙만 적용합니다.
처리 대상별 분기
business partner → general · bank · customer · customer_tax
vendor · vendor_tax · vendor_altpay
→ ZFIG_BP_MAINTAIN (IV_MODE 'I' 생성 / 'U' 변경)
sales → sales 탭
→ cmd_ei_api=>maintain_bapi
sales-task = KNVV 에 값이 있으면 'U', 없으면 'I'
purchase → purchase 탭
→ vmd_ei_api=>maintain_bapi
LFA1 에 Vendor 코드가 없으면 에러| 항목 | 산식 · 규칙 |
|---|---|
E01 BP 그룹 | 정의되지 않은 그룹이면 반려 |
E02 상호 | NAME1 이 비어 있으면 반려 |
E03 국가코드 | 유효하지 않은 국가면 반려 |
E04 사업자번호 | 국내 BP 의 번호 형식이 어긋나면 반려 |
E05 은행코드 | 등록되지 않은 은행이면 반려 |
E06 Vendor 코드 | purchase 탭 전용 — LFA1 에 없으면 반려 (사양서 지정) |
E07 지급조건 | 유효하지 않은 지급조건이면 반려 |
purchase 만 Vendor 존재를 먼저 확인하는 이유
사양서에 명시된 조건입니다. 구매 데이터는 이미 있는 공급업체에 구매조직 정보를 붙이는 작업이라 대상이 없으면 붙일 곳이 없습니다. 반면 일반 정보 탭은 BP 자체를 만드는 단계라 기존 존재 여부가 생성·변경을 가르는 기준이 될 뿐 에러는 아닙니다.
처리 대상 3종
고른 대상에 따라 읽는 탭과 호출하는 인터페이스가 달라집니다.
| 처리 대상 | 읽는 탭 | 호출 | 처리 구분 |
|---|---|---|---|
| business partner | general · bank · customer · customer_tax · vendor · vendor_tax · vendor_altpay | ZFIG_BP_MAINTAIN | 라디오에서 고른 create/update 가 IV_MODE |
| sales | sales | cmd_ei_api=>maintain_bapi | KNVV 유무로 task 자동 판정 |
| purchase | purchase | vmd_ei_api=>maintain_bapi | LFA1 존재 확인 후 처리 |
세 갈래로 나눈 덕분에 실패한 단계만 다시 올릴 수 있고, 어느 인터페이스에서 막혔는지도 분명해집니다.
실행 조건
| 필드 | 필수 | 설명 |
|---|---|---|
| File name | 필수 | 업로드 양식 경로. Template Download 로 빈 양식을 받을 수 있음 |
| 처리 대상 | 필수 | business partner / sales / purchase |
| create · update | 조건부 | business partner 를 골랐을 때만 표시 (사양서) |
| 탭 필터 | 선택 | 결과를 특정 탭만 추려 보기 |
| 에러만 보기 | 선택 | 실패한 줄만 남기기 |
결과 컬럼
| 컬럼 | 의미 · 표시 |
|---|---|
| 라인 | 양식의 행 번호 |
| 상태 | 작업전 / 완료 / 에러 — 사양서의 YELLOW·GREEN·RED 에 대응 |
| 탭 | 그 줄이 들어 있던 양식 탭 |
| Partner · 상호 | BP 코드와 이름. 신규 생성 시 코드가 채워짐 |
| 처리구분 | 생성 / 변경 |
| BP그룹 · 국가 · 사업자번호 | 일반 정보 탭 항목 |
| 조정계정 · 지급조건 | 고객·공급업체 회사코드 탭 항목 |
| 조직 | 영업조직/유통경로 또는 구매조직 |
| 호출 API | 실제 처리에 쓰인 펑션 또는 API |
| 결과메시지 | 성공 내용 또는 에러 코드와 사유 |
보조 기능
| 컬럼 | 의미 · 표시 |
|---|---|
| 탭 필터 | 특정 탭만 추려 확인 |
| 에러만 보기 | 실패한 줄만 남겨 수정 대상을 추림 |
| Template Download | 탭별 컬럼 구성이 담긴 빈 양식 |
| 결과 CSV | 전체 라인을 상태·메시지와 함께 내려받기 |
SAP 표준 기능 매핑
마스터 생성·변경은 표준 펑션과 BAPI 가 수행합니다. 이 화면은 양식을 읽어 맞는 인터페이스로 넘기고 결과를 모읍니다.
| 표준 | 역할 | 이 화면에서의 확장 |
|---|---|---|
ZFIG_BP_MAINTAIN | BP 생성·변경 펑션 | 일곱 개 탭을 T_GENERAL 등 테이블 파라미터로 묶어 한 번에 전달 |
cmd_ei_api | 고객 마스터 API | 영업 데이터(KNVV)와 세금(KNVI)·파트너기능(KNVP) 처리 |
vmd_ei_api | 공급업체 마스터 API | 구매 데이터(LFM1) 처리 |
BP 트랜잭션 | BP 단건 유지보수 | 건수가 적거나 예외 건은 표준 화면에서 처리 |
XD03 · XK03 관점 | 마스터 조회 | 업로드 결과 확인 |
운영 데이터 소스 매핑
| 항목 | SAP 원천 | 비고 |
|---|---|---|
| 일반·주소 | KNA1 · LFA1 | BP 그룹 · 상호 · 국가 · 사업자번호 |
| 영업 데이터 | KNVV | 영업조직 · 유통경로 · 제품군 · Incoterms |
| 고객 세금·파트너 | KNVI · KNVP | ALAND='KR' · TATYP='MWST' 조회, 필수 파트너기능 보완 |
| 구매 데이터 | LFM1 | 구매조직 · 통화 · 지급조건 |
| 처리 방식 | 펑션 · BAPI | ZFIG_BP_MAINTAIN / cmd_ei_api / vmd_ei_api |
도입 시 확인이 필요한 부분
BP 역할(FLCU01·FLVN01 등)과 번호범위 규칙이 회사마다 다릅니다. 내부 채번인지 외부 채번인지에 따라 양식에 Partner 코드를 넣을지가 갈립니다. 또 필수 파트너기능은 표준 체크 클래스로 보완하도록 사양서에 지정돼 있으므로, 영업 데이터 업로드 전에 파트너기능 설정을 함께 확인해야 합니다.
참고 CDS 뷰
업로드 후 어떤 역할이 등록됐는지 확인할 때는 BP 와 고객·공급업체 데이터를 묶은 뷰가 편합니다.
@AbapCatalog.sqlViewName: 'ZCBPMASTER'
@EndUserText.label: 'BP 마스터 현황 (Z)'
define view Z_C_BP_MASTER
as select from but000 as Bp
left outer join kna1 as Cust on Bp.partner = Cust.kunnr
left outer join lfa1 as Vend on Bp.partner = Vend.lifnr
left outer join knvv as Sales on Cust.kunnr = Sales.kunnr
left outer join lfm1 as Purch on Vend.lifnr = Purch.lifnr
{
key Bp.partner as Partner,
Bp.bu_group as BpGroup,
Bp.name_org1 as Name1,
Cust.land1 as Country,
Cust.stcd2 as TaxNumber,
// 역할별 등록 여부 — 업로드 후 무엇이 빠졌는지 확인
case when Cust.kunnr is not null then 'X' else '' end as IsCustomer,
case when Vend.lifnr is not null then 'X' else '' end as IsVendor,
case when Sales.kunnr is not null then 'X' else '' end as HasSalesData,
case when Purch.lifnr is not null then 'X' else '' end as HasPurchData,
Sales.vkorg as SalesOrg,
Purch.ekorg as PurchOrg
}업로드 후 어떤 역할이 등록됐고 무엇이 빠졌는지 확인할 때 쓰는 참고용 설계입니다. 생성·변경은 표준 펑션과 API 가 담당합니다.
OpenUI5 구성
| 기능 | 사용 컨트롤 |
|---|---|
| 화면 골격 | sap.m.Page + 실행조건 영역 · 결과 리스트 |
| 실행조건 | sap.m.Input · sap.m.RadioButtonGroup — 우측 끝에 실행 |
| 조건부 표시 | business partner 선택 시에만 create/update 라디오 노출 |
| 결과 리스트 | sap.ui.table.Table — 라인·상태·탭·Partner 4컬럼 고정 |
| 상태 표시 | sap.m.ObjectStatus + 아이콘 — 작업전·완료·에러 |
| 필터 | 탭 ComboBox + 에러 토글 버튼 |
| CSV | Blob + UTF-8 BOM — 양식 · 결과 2종 |
상태를 세 단계로 둔 이유
사양서의 YELLOW(작업전)·GREEN(생성완료)·RED(에러) 구분을 그대로 옮겼습니다. 대상이 아닌 탭의 줄을 성공도 실패도 아닌 '작업전'으로 남겨 두면, 같은 파일로 세 번 실행하는 동안 어디까지 진행됐는지가 한 화면에서 보입니다.
파일 구성
| 경로 | 역할 |
|---|---|
manifest.json | 앱 디스크립터 — 앱 ID(zui5.bpupload) · ko 로케일 · sap_horizon |
Component.js | 실행조건 모델 · 결과 모델 초기화 |
view/Main.view.xml | 실행조건 + 결과 리스트 |
controller/Main.controller.js | 파일 적재 · 대상 분기 · 실행 · 탭/에러 필터 · CSV |
model/ModelMock.js | 탭 그룹 정의 · 라인 검증 · API 분기 · 처리 시뮬레이션 |
model/formatter.js | 상태 · 처리구분 · 탭 이름 포맷터 |
i18n/i18n_ko.properties | ko 로케일 리소스 — 에러 메시지 포함 |
localdata/bpupload.json | 업로드 양식 샘플과 기존 마스터 |
검증 결과
화면 구성에 쓴 데이터는 아홉 개 탭에 신규·변경·에러가 섞인 업로드 양식과 기존 마스터입니다.
| 데이터 | 규모 | 구성 |
|---|---|---|
| 업로드 양식 | 50행 | general 17 · bank 7 · customer 5 · vendor 4 · sales 4 · purchase 4 등 |
| 양식 탭 | 9종 | BP 7 · Sales 1 · Purchase 1 |
| 검증 규칙 | 7종 | BP그룹 · 상호 · 국가 · 사업자번호 · 은행 · Vendor · 지급조건 |
| 검증 항목 | 결과 |
|---|---|
| 모든 라인의 탭이 양식 탭 목록에 존재 | 통과 |
| general 정상 라인의 BP그룹·상호·국가 유효 | 통과 |
| 국내 BP 의 사업자번호 형식 준수 | 통과 |
| bank 정상 라인의 은행코드 등록 확인 | 통과 |
| customer·vendor 지급조건 유효 · 조정계정 체계 일치 | 통과 |
| sales 라인의 영업조직·유통경로·제품군 보유 | 통과 |
| sales task 가 기존 KNVV 유무와 일치 | 통과 |
| purchase 정상 라인의 Vendor 가 LFA1 에 존재 | 통과 |
| E01~E07 각 에러가 실제 위반 조건과 일치 | 통과 |
| 화면 렌더링 — 적재 → BP → Sales → Purchase → 에러 필터 | 8/8 |
거래처 상호·사업자번호는 모두 검증용 데이터입니다.
자주 묻는 질문
처리 대상을 왜 세 갈래로 나눴나요?
탭마다 SAP 에서 부르는 인터페이스가 다르기 때문입니다. 일반·은행·회사코드·세금은 BP 펑션 하나로 묶어 넣을 수 있지만, 영업 데이터는 고객 API 를, 구매 데이터는 공급업체 API 를 따로 호출해야 합니다. 한 번에 다 넣으려 하면 어느 단계에서 실패했는지 알기 어려워집니다.
BP 를 만들기 전에 sales 를 올리면 어떻게 되나요?
영업 데이터는 이미 존재하는 고객에 붙는 정보이므로 BP 가 먼저 있어야 합니다. 순서를 지키지 않으면 해당 줄이 에러로 남습니다. 실무에서는 business partner → sales → purchase 순으로 세 번 실행하는 흐름을 씁니다.
create 와 update 라디오는 왜 BP 에서만 보이나요?
사양서에 그렇게 지정돼 있고, 실제로도 그 편이 안전합니다. BP 펑션은 IV_MODE 를 명시적으로 받기 때문에 담당자가 의도를 밝혀야 합니다. 반면 영업·구매 데이터는 기존 KNVV·LFM1 존재 여부로 판정하는 편이 정확해 자동으로 갈립니다.
대상이 아닌 탭의 줄은 어떻게 되나요?
'작업전' 상태로 그대로 남습니다. 건드리지 않기 때문에 같은 파일로 대상을 바꿔 가며 여러 번 실행해도 앞서 처리한 결과가 지워지지 않습니다.
SAP 표준 기능과 어떻게 이어지나요?
마스터 생성·변경은 표준 펑션과 BAPI 가 수행하고 데이터도 KNA1·LFA1 등 표준 구조에 그대로 남습니다. 이 화면은 양식을 탭별로 읽어 검증하고 맞는 인터페이스로 넘기며, 돌아온 메시지를 라인별로 모아 보여 주는 역할을 합니다.