EWM Deep Dipe : SCU BP

Master Data

마스터 데이터는 다양한 비즈니스 기능 전반에 걸쳐 공통적으로 사용되는 비즈니스 오브젝트(대상)들의 집합을 의미합니다.

이는 시스템 내외부에서 비즈니스 프로세스를 수행하기 위해 SAP 시스템에 필요한 필수 데이터의 일부를 형성하며,

기업 내에서 해당 비즈니스 오브젝트의 고유한 식별자 역할을 합니다.

 

분산형 SAP EWM(Decentralized SAP EWM)으로 작업할 때,

마스터 데이터는 SAP ERP와 SAP EWM 시스템 양쪽 모두와 연결 고리를 가집니다.

자재 마스터(Material Master), 공급업체(Vendor), 고객 마스터(Customer Master), 플랜트(Plant) 등

특정 마스터 데이터는 SAP ERP에서 생성되어 **CIF(Core Interface)**를 통해 SAP EWM 시스템으로 전송됩니다.

(우리는 CIF를 통한 SAP ERP로부터의 마스터 데이터 전송에 대해 자세히 알아볼 것입니다.)

 

반면, 제품 마스터의 창고 뷰(Warehouse View), 공급망 유닛(SCU) 등과 같은 다른 마스터 데이터는

SAP EWM에서 직접 유지 관리됩니다.

 

SAP ERP와 SAP EWM 간의 마스터 데이터 전송에는 CIF가 사용됩니다.

CIF는 일반적으로 SAP ERP와 SAP SCM(Supply Chain Management) 간의 통신에 사용되는 기술입니다.

SAP EWM의 경우, 마스터 데이터는 SAP ERP에서 SAP EWM으로만 전송되며, CIF를 통해 다시 돌아오는 통신은 없습니다.

그림 4.1과 4.2에서 보듯, SAP EWM은

SAP ERP, SAP TM(운송 관리), 그리고 SAP Business Suite의 기타 제품 및 구성 요소들과 완전히 통합되어 있습니다.

 

따라서 어떤 형태의 마스터 데이터가 SAP EWM 고유의 데이터(Native)이고,

어떤 것이 외부에서 전송되어 온 것인지 이해하는 것이 중요합니다.

Figure 4.1 Data Communication between SAP ERP and SAP EWM

Figure 4.2 A Possible SAP EWM System Landscape

 

실무 포인트

자재 코드나 고객 정보가 잘못되었을 때 어디서 수정해야 하는지를 결정합니다.

ERP에서 전송되는 데이터(자재, 타겟 플랜트 등)를 EWM에서 강제로 수정하려 하면 안 됩니다.

원천 시스템(ERP)에서 수정 후 다시 CIF로 쏘아주는 것이 기본 원칙입니다.

 

CIF는 '실시간'처럼 보이지만 기술적으로는 큐(Queue) 방식입니다. 

현업에서 "ERP에서 자재를 만들었는데 왜 EWM 입고 문서가 안 만들어지나요?"라고 묻는다면, 

십중팔구 CIF 큐(Transaction Code: SMQ1, SMQ2)에 에러가 걸려 데이터 전송이 멈춘 경우입니다. 

이 메커니즘을 이해해야 장애 대응이 가능합니다.

 

ERP에서 자재 정보가 넘어왔다고 해서 바로 쓸 수 있는 게 아닙니다.

EWM 시스템에 접속해 '창고 제품 마스터(Warehouse Product Master)' 화면에서 해당 제품이 어느 창고(Warehouse Number)에서 쓰일지, 어떤 적치 전략(Putaway Strategy)을 가질지 등의 'EWM 전용 속성'을 별도로 세팅해주어야

비로소 물류 흐름이 완성됩니다.

 

ERP의 플랜트(Plant)와 저장위치(Storage Location) 개념이

EWM에서는 SCU라는 좀 더 포괄적인 지리적/조직적 단위로 매핑됩니다.

이는 나중에 운송 관리(TM)와 연동될 때 '장소(Location)'를 식별하는 기준이 되므로 초기 설정 시 매우 신중해야 합니다.

---

공급망 유닛(SCU)

공급망 유닛 (Supply Chain Unit, SCU)은 SAP EWM이 조직의 공급망 기능을 모델링하기 위해 사용하는 요소입니다.

이는 물류 프로세스 내에서 하나 이상의 비즈니스 특성(Business Characters)을 가진 물리적 또는 조직적 단위입니다.

SAP는 사용자가 선택할 수 있도록 이러한 비즈니스 특성을 미리 정의해 두었습니다.

예를 들어, 조직 단위는 입고 사무실(Goods Receiving Office)이나 출하 사무실(Shipping Office)이 될 수 있습니다.

 

SCU는 경로(Route) 생성과 같이 지리적 참조(Geographical Reference)가 필요한 트랜잭션에서 사용됩니다.

또한, SAP EWM의 입출고 기능의 일부로 운송 마스터 데이터를 생성할 때 SCU가 참조됩니다.

SAP EWM에서 장소(Location)가 수동으로 생성되거나 SAP ERP에서 전송되면,

EWM은 백그라운드에서 자동으로 SCU를 생성합니다.

SCU 데이터는 데이터베이스의 /SCMB/TOENTITY 테이블에 저장됩니다.

이러한 SCU는 하나 이상의 비즈니스 특성을 가지며, 속성(Attributes)을 통해 유지 관리됩니다.

속성에는 창고(Warehouse), 도어(Door), 출하 사무실(Shipping Office), 입고 사무실(Goods Receiving Office), 납품처(Ship-to Location), 구역(Zone) 등이 포함될 수 있습니다.

따라서 SCU가 자동으로 생성되든 수동으로 생성되든, 공급망에서 수행하는 역할에 따라 비즈니스 속성을 설정해야 합니다.

 

SCU를 유지 관리하려면(그림 4.3 참조), 트랜잭션 /SCMB/SCUMAIN을 사용하거나

메뉴 경로(Master Data > Maintain Supply Chain Unit)를 이용합니다. 데이터는 다음 세 가지 탭을 통해 관리됩니다:

• General (일반): 지리적 위치 상세 정보 및 비즈니스 파트너 정보.
• Address (주소): 주소 및 연락처 정보.
• Alternative (대안): 조직의 공급망 모델에서 이 SCU가 수행하는 역할(Roles).

장소 생성 후 SCU가 자동 생성된 경우 일반 데이터와 주소 데이터가 자동으로 끌어오게 되며,

사용자는 SCU의 역할에 따라 추가 속성을 유지 관리할 수 있습니다.

실무에서 SCU는 단순히 '주소'가 아니라 **"시스템이 시간과 장소를 인식하는 기준"**입니다.

 

① 비즈니스 속성(Business Attributes)의 의미

• 실무 포인트: 단순히 SCU를 만드는 것만으로 끝나는 것이 아니라, 해당 SCU에 INV(재고 관리), SO(출하 사무실), RO(입고 사무실) 등의 속성을 부여해야 합니다. 만약 창고 번호(Warehouse Number)에 할당된 SCU에 '창고' 속성이 없다면, 시스템은 해당 창고에서 물류 흐름을 처리할 수 없습니다.

② 시간대(Time Zone) 설정의 중요성

• 실무 포인트: 'General' 탭에서 설정하는 Time Zone은 실무적으로 매우 치명적입니다. 글로벌 기업의 경우 ERP 서버 시간과 창고의 실제 시간이 다를 수 있습니다. SCU의 시간대가 잘못 설정되면 입고 예정 시간이나 출하 마감 시간이 어긋나 현장 작업에 혼선을 줄 수 있습니다.

③ ERP Location과의 자동 동기화

• 실무 포인트: 보통 ERP의 플랜트(Plant)나 저장위치(Storage Location)를 CIF로 전송하면 EWM에 Location이 생기고, 본문에 언급된 것처럼 SCU가 자동 생성됩니다. 실무자는 자동 생성된 SCU에 들어가서 주소가 정확한지, 그리고 EWM 운영에 필요한 추가적인 역할(Role)이 빠지지는 않았는지 점검하는 프로세스를 거쳐야 합니다.

④ 지리적 참조(Geographical Reference)와 경로(Route)

• 실무 포인트: EWM에서 트럭이 들어오고 나가는 경로를 계산할 때 SCU의 위도/경도나 우편번호 정보를 참조합니다.
• 운송 관리(TM) 모듈을 함께 사용한다면 SCU 데이터의 정확도는 배차 및 운송 비용 계산의 기초 데이터가 되므로
• 관리가 매우 엄격해야 합니다.

Figure 4.3 Supply Chain Unit Business Attributes

 

플랜트(Plant)는 창고의 역할을 수행하는 SCU입니다.

플랜트는 저장 위치(Storage Location)를 통해 창고와 연결됩니다.

CIF를 통해 SAP ERP에서 SAP EWM으로 플랜트가 전송되면, EWM에는 장소(Location)와 SCU가 자동으로 생성됩니다. 이때 해당 SCU가 '창고(Warehouse)'라는 **비즈니스 속성(Business Attribute)**을 포함하고 있는지 반드시 확인해야 합니다.

여러분은 이 SCU를 SAP EWM의 조직 요소인 '창고 번호(Warehouse Number)'에 할당하며,

이것이 바로 공급망 요소(SCU)를 SAP EWM 조직 요소에 연결하는 방법입니다.

 

SCU를 창고에 할당하려면(그림 4.4 참조), 트랜잭션 /SCWM/LGNBP를 사용하거나 메뉴 경로(Settings > Assignments: Warehouse Numbers/Business Partners)를 이용합니다.

또한 이 화면에서 필요에 따라 보관인(Custodian), 기본 권한 당사자(Dflt Pty Entld), 기본 납품처(Default Ship-To) 필드를 유지 관리합니다.

Figure 4.4 Supply Chain Unit Business Attributes

이 설정은 EWM 구축 초기 단계에서 수행하는 '연결 고리' 작업으로, 실무적으로 다음과 같은 의미를 가집니다.

① "플랜트 = 창고 SCU"의 공식

• ERP에서는 물건이 '플랜트'에 있다고 말하지만, EWM에서는 '창고 번호'에 있다고 말합니다.
• 시스템이 "A 플랜트의 재고가 곧 이 EWM 창고의 재고다"라는 것을 인식하게 하려면 반드시 /SCWM/LGNBP에서 SCU를 할당해야 합니다. 이 설정이 누락되면 입고 시 어떤 창고로 물건을 넣어야 할지 시스템이 결정하지 못합니다.

② '비즈니스 속성' 확인의 필수성

• SCU에 'Warehouse' 속성이 체크되어 있지 않으면 할당 자체가 불가능하거나 오류가 발생합니다. 
• CIF로 넘어온 데이터가 완벽하지 않을 수 있으므로, /SCMB/SCUMAIN에서 해당 SCU의 역할을 먼저 점검하는 것이 실무자의 기본 루틴입니다.

③ Default Party Entitled (권한 당사자)의 중요성

• /SCWM/LGNBP 화면에서 설정하는 'Party Entitled to Dispose(권한 당사자)'는 보통 ERP의 플랜트를 의미합니다.
• EWM 창고 하나를 여러 플랜트가 공유하는 경우(Multi-Plant Warehouse), 입고되는 재고가 어느 플랜트의 소유인지 결정하는 핵심 기준이 됩니다.

④ Custodian (보관인) 및 Ship-To (납품처)

• Custodian: 재고를 물리적으로 보관하는 주체(보통 창고 운영사)를 지정합니다.
• Default Ship-To: 출고 시 별도의 정보가 없을 때 기본적으로 사용될 납품처 정보입니다. 이 필드들은 이후 운송 관리나 가시성 확보를 위한 리포팅에 활용됩니다.

---

공급망 유닛(SCU) 달력 할당

SCU 및 플랜트의 운영 시간은 정확한 활동 계획과 고객 인도 날짜 계산에 필수적인 역할을 합니다.

이를 위해 각 SCU에 적절한 **출발 달력(Departure Calendar)**을 생성하고 할당해야 합니다.

트랜잭션 /SCTM/DEPCAL을 사용하거나 메뉴 경로를 통해 이동할 수 있습니다. 

Master Data > Shipping and Receiving > Route Determination > Assign Calendar to Supply Chain Unit

이 트랜잭션 화면에서 직접 달력을 생성할 수도 있으며,

'행 추가(Append Row)' 버튼을 사용하여 기존의 달력을 하나 이상 해당 SCU에 할당할 수 있습니다.

---

비즈니스 파트너 (Business Partners, BP)

창고 내 비즈니스 프로세스에는 조직 내외부의 개인, 그룹 또는 조직이 관여됩니다.

조직 내부 거래라 할지라도 나중에 내부 당사자 간의 재무 정산이 필요할 수 있습니다.

SAP EWM 시스템에서 이를 원활하게 처리하기 위해 **비즈니스 파트너(BP)**를 생성해야 하며,

여기에는 프로세스의 각 단계에서 요구되는 필수 데이터가 포함됩니다.

BP에는 공급업체(Vendor), 고객(Customer), 자사 조직의 다른 플랜트, 제3자 공급업체, 화물 주선인(Freight Forwarder),

운송업체(Carrier) 등이 포함됩니다.

이러한 엔티티들은 이미 SAP ERP 시스템에 존재할 수 있으며, EWM으로 전송하거나 EWM 내에서 직접 생성할 수 있습니다.

 

주의: 마스터 데이터가 시작되는 원천 시스템은 SAP MDM, CRM, SRM, ERP 또는 기타 레거시 시스템일 수 있습니다.

하지만 여기서는 가장 일반적인 시나리오인 SAP ERP를 원천 시스템으로 한정하여 논의합니다.

이러한 엔티티들 간의 관계 성격에 따라 관리해야 할 데이터 세트가 달라집니다.

SAP EWM에서는 이러한 관계를 **BP 역할(BP Roles)**을 통해 정의합니다.

각 BP는 시스템 내에서 하나 또는 여러 개의 BP 역할을 가질 수 있습니다.

예를 들어, 동일한 청구지(Sold-to party)와 납품처(Ship-to party) 주소를 가진 고객이 있을 수 있습니다.

① 달력 할당: "창고가 언제 쉬는가?"의 문제

• 실무 포인트: 창고의 휴무일(공휴일, 주말)이나 운영 시간이 시스템에 등록되어 있지 않으면, 시스템은 일요일에도 트럭이 출발할 수 있다고 계산하여 **납기 약속(ATP)**에 오류를 범하게 됩니다.
• Route Determination 연동: 특히 출고 시 '경로 결정(Route Determination)' 프로세스에서 이 달력을 참조하여 "지금 피킹을 시작해야 제시간에 상차하여 고객에게 도착할 수 있다"는 역산(Backward Scheduling)을 수행합니다.

② BP 역할(BP Role)의 다중성

• 실무 포인트: 실무에서는 한 업체가 우리에게 물건을 공급하는 '공급처(Vendor)'이면서 동시에 물건을 사가는 '고객(Customer)'일 수 있습니다. SAP EWM에서는 하나의 BP 번호에 'Vendor' 역할과 'Customer' 역할을 동시에 부여하여 데이터를 통합 관리합니다. 이는 ERP에서 벤더와 고객 마스터가 분리되어 관리되던 것보다 훨씬 유연한 구조입니다.

③ ERP 플랜트가 BP로 변환되는 이유

• 실무 포인트: 본문에 언급된 "자사 조직의 다른 플랜트"가 BP로 생성되는 점에 주목해야 합니다. 창고 간 재고 이동(STO) 시, 보내는 플랜트는 '공급처'가 되고 받는 플랜트는 '고객'이 되어야 서류(Delivery Note)를 발행할 수 있기 때문에 EWM은 모든 조직 단위를 BP라는 객체로 인식합니다.

④ 데이터 거버넌스 (Caution 부분)

• 실무 포인트: 실무 환경에서는 데이터의 **'주인(Owner)'**을 명확히 해야 합니다. 본문에서는 ERP를 예로 들었지만, 만약 기업에서 MDM(Master Data Management)을 사용 중이라면 EWM에서 직접 BP 정보를 수정하는 것은 데이터 불일치를 초래하는 위험한 행동입니다. 수정 사항은 반드시 원천 시스템에서 시작되어 인터페이스를 통해 반영되어야 합니다.

 

[표 4.1 비즈니스 파트너 역할]

• 000000 (Business partner (general)): 비즈니스 파트너(일반). 모든 BP에게 공통적으로 할당되는 기본 역할입니다.
• CRM000 (Sold-to party): 주문처. 물건을 주문하고 대금을 지불하는 주체입니다.
• CRM002 (Ship-to party): 납품처. 물건이 실제로 배송되는 목적지입니다.
• CRM010 (Carrier): 운송업체. 창고에서 물건을 실어 나르는 업체입니다.
• BBP000 (Vendor): 공급업체. 우리 창고로 물품을 납품하는 업체입니다.
• BBP003 (Plant): 플랜트. 자사 조직 단위를 EWM 내에서 인식하기 위한 역할입니다.
• BUP003 (Employee): 종업원. 창고 내에서 작업하는 개별 작업자입니다.
• SFPRT (Ship-from party): 발송처. 입고 시 실제 물건이 출발한 장소입니다.
• LUM001 (Processor): 처리자. **노무 관리(Labor Management)**에서 사용되는 매우 중요한 역할로, 15장에서 자세히 다룹니다.

실무적으로 BP 역할 설정은 **"트랜잭션의 가용성"**과 **"데이터의 세분화"**를 결정합니다.

① 왜 역할을 여러 개 부여하는가?

• 실무 예시: 한 회사가 우리 창고의 공급처(Vendor)이면서 동시에 우리 물건을 사가는 고객(Customer)일 수 있습니다. 이 경우 해당 BP 번호 하나에 BBP000과 CRM002 역할을 모두 부여합니다. 이렇게 하면 하나의 마스터 데이터로 입고와 출고 프로세스 모두에서 해당 업체를 불러올 수 있어 데이터 관리가 일원화됩니다.

② LUM001 (Processor) 역할의 특수성

• 실무 포인트: 일반적인 외부 업체와 달리, 창고 현장에서 스캐너를 들고 피킹(Picking)을 하거나 패킹(Packing)을 하는 **'현장 작업자'**들도 시스템적으로는 BP로 등록되어야 합니다. 이때 사용되는 역할이 LUM001입니다. 이 역할이 있어야 해당 작업자의 작업 효율(Performance)을 측정하거나 인건비를 계산하는 Labor Management 기능을 사용할 수 있습니다.

③ CRM 계열 역할 (CRM000, CRM002 등)

• 실무 포인트: EWM은 과거 SCM 모듈에서 파생되었기 때문에 고객 관련 역할 코드가 CRM으로 시작합니다. 실무에서는 배송지 주소가 수천 개일 수 있는데, 각 배송지마다 CRM002(Ship-to) 역할을 가진 BP를 생성하여 관리합니다. 출고 문서(Outbound Delivery)가 생성될 때 이 역할 정보를 바탕으로 배송 라벨의 주소가 인쇄됩니다.

④ 트랜잭션 BP의 만능성

• 실무 포인트: 과거 ERP(ECC)에서는 공급업체는 XK01, 고객은 XD01 등 트랜잭션이 분리되어 있었습니다. 하지만 S/4HANA 및 EWM에서는 오직 BP 트랜잭션 하나에서 모든 것을 관리합니다. 실무자는 상단 탭에서 '역할'만 바꿔가며 데이터를 입력하는 방식에 익숙해져야 합니다.

Figure 4.5 Maintain Business Partner Screen

비즈니스 파트너 유지 관리 화면

그림 4.5에 표시된 Find(찾기) 탭을 통해 시스템에 존재하는 기존 BP를 검색할 수 있습니다.

이름, 번호, 외부 번호, 주소 또는 이미 유지 관리된 검색어(Search terms)를 사용하여 개인, 조직 또는 그룹별로 BP를 검색할 수 있습니다(Start 버튼 사용).

검색 결과는 화면의 왼쪽 하단에 나타납니다.

 

주의: 여기에 표시된 Delete(삭제) 버튼은 검색 기준(Search criterion)을 삭제하기 위한 것이지,

시스템에서 BP 자체를 삭제하는 버튼이 아닙니다.

BP 마스터 자체를 삭제하는 것은 매우 까다로운 작업(Archiving 등 필요)이며,

화면상의 삭제 버튼은 보통 **'입력 필드 초기화'**인 경우가 많으니 안심하고 사용하셔도 됩니다.

검색 결과에서 해당 항목을 더블 클릭하여 선택하면, 화면 오른쪽 창에 상세 데이터가 표시됩니다(그림 4.6 참조)."

 

실무에서 BP 트랜잭션을 사용할 때 반드시 알아야 할 기술적/운영적 포인트입니다.

① 검색 기능의 활용 (Search Term)

• 실무 포인트: 수만 개의 BP가 등록된 실무 환경에서 번호를 일일이 외우기는 어렵습니다. 따라서 BP 생성 시 'Search Term' 필드에 업체 약칭이나 관리 코드를 입력해두면 검색 속도가 비약적으로 빨라집니다. 본문에서 언급한 'Find' 탭의 유용성이 바로 여기서 나옵니다.

② 삭제 버튼의 오해 방지

• 실무 포인트: 교재의 'Caution'처럼, SAP GUI의 삭제 아이콘은 문맥에 따라 기능이 다릅니다. BP 마스터 자체를 삭제하는 것은 매우 까다로운 작업(Archiving 등 필요)이며, 화면상의 삭제 버튼은 보통 **'입력 필드 초기화'**인 경우가 많으니 안심하고 사용하셔도 됩니다.

③ 외부 번호(External Number)의 중요성

• 실무 포인트: 본문에 언급된 'External Number'는 주로 ERP에서의 고객/공급업체 번호를 의미합니다. EWM 내의 BP 번호와 ERP의 번호가 다를 경우, 이 외부 번호 필드가 두 시스템 간의 데이터를 매핑하는 핵심 고리가 됩니다.

④ 화면 구성 (Left: Search / Right: Data)

• 실무 포인트: 이 화면 구조는 SAP의 표준 디자인 패턴입니다. 왼쪽에서 목록을 선택하고 오른쪽에서 상세 속성(주소, 세금 정보, 역할 등)을 수정합니다. 실무적으로는 오른쪽 상단의 'Display <-> Change' 버튼을 눌러야 수정 모드로 전환된다는 점을 기억하세요.

Figure 4.6 Tools for Maintaining Business Partners

[BP 역할 확인 및 수정]

• 이미 유지 관리된 BP의 역할을 보려면 'Change in BP role' 드롭다운 메뉴를 클릭하면 됩니다. 이미 설정된 역할 옆에는 'Maintained'(그림 4.7 참조)라는 문구가 추가되어 있어 쉽게 구분할 수 있습니다.
• Edit(편집) 버튼을 통해 새로운 역할을 추가하거나 기존 데이터를 보강할 수 있으며, 이 버튼은 '조회'와 '수정' 모드를 전환하는 토글 기능도 수행합니다.
• ERP에서 전송된 BP는 자동으로 관련 역할이 생성되므로 EWM에서 수정할 일은 많지 않지만, 필요에 따라 추가(Enhance)할 수 있습니다.

Figure 4.7 Maintained Indicator for a Business Partner Role

3개의 버튼 통해 신규 BP 생성 가능

[식별(Identification) 탭]

• 개인 데이터: BP가 '사람(Person)'으로 생성된 경우 생년월일, 국적, 사용자 ID 등을 기록합니다.
• ID 유형 및 카테고리: BP의 개별 특성을 정의하며, 'ID Uniqueness(고유성)' 설정을 통해 중복 입력을 방지할 수 있습니다. 예를 들어, 운송업체에 부여되는 SCAC(Standard Carrier Alpha Code) 코드를 고유값으로 관리할 때 유용합니다.
• 시스템 연동 정보: * External BP Number: 레거시 시스템(ERP 등)의 번호를 반영하는 데 사용됩니다.
  • User ID 매핑: BP가 시스템 사용자(예: 창고 작업자)인 경우 사용자 ID를 매핑합니다.
  • ID 유형 자동 할당: ERP에서 전송된 BP에는 ID 유형, 식별 번호, 책임 기관(데이터의 원천 시스템) 정보가 자동으로 부여됩니다.

Figure 4.8 Identification Tab of Business Partner

실무적으로 이 섹션은 **"누가 데이터를 소유하는가"**와 **"시스템 간의 데이터 매핑"**을 이해하는 데 핵심적입니다.

① 'Maintained' 표시의 실무적 의미

• 특정 업체가 입고(Vendor)로는 사용 가능한데 출고(Ship-to)로 검색이 안 된다면, 드롭다운 메뉴에서 해당 역할 옆에 'Maintained'가 붙어 있는지 확인해야 합니다. 만약 없다면 Edit 모드에서 해당 역할을 추가해주어야 프로세스가 진행됩니다.

② 데이터 수정의 금기 사항

• 본문에서 언급했듯, ERP에서 넘어온 데이터는 EWM에서 거의 수정하지 않습니다. 주소나 업체명이 바뀌었을 때 EWM에서 직접 고치면, 다음에 ERP에서 다시 데이터를 쏠 때 EWM의 수정사항이 덮어씌워지거나 데이터 불일치(Inconsistency)가 발생할 수 있기 때문입니다.

③ SCAC 코드와 운송업체 관리

• 물류 실무에서 SCAC는 글로벌 물류 표준 코드입니다. 운송 관리(TM) 모듈을 사용하거나 외부 운송사 시스템과 EDI로 연동할 때, 이 식별 번호가 정확해야만 통신이 성공합니다. Identification 탭에서 이를 'Unique'하게 관리하는 것은 데이터 품질 관리의 핵심입니다.

④ 작업자(Employee)와 User ID의 연결

• 창고 현장 작업자(BP)와 SAP 로그인 계정(User ID)을 연결하는 작업입니다. 이를 통해 "누가, 언제, 어떤 팔레트를 옮겼는가"에 대한 로그가 남게 되며, 이는 나중에 작업 실적 분석 및 노무 관리(Labor Management)의 기초 데이터가 됩니다.

⑤ ID Type (Identification Number)

• ERP에서 온 벤더 번호가 '1000'번인데 EWM의 BP 번호는 '5000'번으로 생성될 수 있습니다. 이때 Identification 탭의 ID Type 필드에 ERP 벤더 번호인 '1000'이 저장되어 있어야 시스템이 두 데이터를 동일 업체로 인식하고 인터페이스를 처리할 수 있습니다.

[표 4.2 SAP EWM 시스템의 식별 유형(Identification Types)]

SAP EWM에서 사용하는 표준 식별 유형과 그에 대한 설명입니다.

• CRM001 (External system identifier): 외부 시스템 식별자. ERP 외의 타 시스템 연동 시 사용됩니다.
• CRM002 (SAP R/3 customer number): SAP ERP(R/3) 고객 번호.
• CRM004 (SAP R/3 vendor number): SAP ERP(R/3) 공급업체 번호.
• CRM011 (Plant number): 플랜트 번호.
• BUP005 (Global location number): GLN(글로벌 위치 번호). 국제 표준 위치 식별 코드입니다.
• BUP006 (Standard carrier alpha code): SCAC 코드. 운송업체용 표준 알파벳 코드입니다.
• SLLIAT (IATA code airline carriers): IATA 코드. 항공 운송업체용 식별 코드입니다.

[설정 경로] 비즈니스 파트너(BP)와 관련된 모든 설정(Role, ID 번호, 세금 번호, 상태 관리 등)은 SAP EWM IMG(Spro)에서 다음 경로를 통해 수행할 수 있습니다:

Cross-Application Components > SAP Business Partner > Business Partner

 

 

① 왜 BP 번호 외에 ID Type이 별도로 필요한가?

실무 포인트: SAP ERP의 고객 번호가 100번인데, EWM 시스템에서는 이미 100번이라는 BP가 존재할 수 있습니다.

이 경우 EWM은 이 고객을 5001번이라는 새로운 번호로 생성하지만, CRM002라는 ID Type에 100이라는 값을 저장해 둡니다.

이를 통해 ERP에서 "100번 고객에게 물건 보내라"는 인터페이스가 오면, EWM은 "아, 내 시스템의 5001번 BP를 말하는구나"라고 인식하게 됩니다.

② CRM011 (Plant Number)의 특수성

실무 포인트: EWM 창고는 여러 플랜트의 재고를 한꺼번에 관리할 수 있습니다(Multi-Plant).

이때 입고되는 제품이 어느 플랜트 소유인지 구분하기 위해, 플랜트 자체가 BP로 등록되어야 하며

CRM011에 플랜트 코드(예: 1000, 1100)가 정확히 매핑되어 있어야 재고 주인이 뒤섞이지 않습니다.

③ 글로벌 표준 코드(GLN, SCAC, IATA)의 활용

실무 포인트: SCAC/IATA: 항공사나 글로벌 선사와 연동할 때 필수적입니다.

이 코드가 Identification 탭에 입력되어 있지 않으면, 운송 관리(TM) 시스템과의 인터페이스나 EDI 전송 시 오류가 발생하여 물류 추적이 불가능해집니다.

GLN: 유통/소매업계에서 EDI를 사용할 때 업체 식별 기준으로 사용되므로 대형 마트나 글로벌 유통사와 거래 시 중요하게 관리됩니다.

④ 설정(Configuration)의 유연성

실무 포인트: 만약 표준으로 제공되는 ID Type 외에 우리 회사만의 고유 번호(예: 구 시스템 관리 코드)가 필요하다면,

본문에 언급된 IMG 경로에서 새로운 ID 유형을 정의할 수 있습니다.

이는 시스템 확장성 측면에서 매우 강력한 기능을 제공합니다.

 

플랜트 (Plant)

플랜트도 비즈니스 파트너(BP)와 마찬가지로 유지 관리되어야 합니다.

이는 플랜트가 고객이나 공급업체(Vendor) 역할을 수행할 수 있는 재고 전송(Stock Transfer) 프로세스에서 필요하기 때문입니다. 이를 위해 SAP ERP에서 플랜트를 공급업체/고객으로 유지 관리해야 하며, 이후 CIF를 통해 SAP EWM으로 BP로서 전송해야 합니다.

식별 유형(ID type) CRM011(SAP R/3 플랜트 번호) 외에도,

요구사항에 따라 플랜트는 CRM002(SAP R/3 고객 번호) 또는 CRM004(SAP R/3 공급업체 번호)를 가질 수도 있습니다.

 

고객 (Customer)

SAP ERP 시스템의 고객 또한 SAP EWM에서 BP로 매핑됩니다.

SAP ERP에서 고객과 공급업체가 동일한 번호로 존재할 때,

SAP EWM에서 동일한 번호로 두 개의 BP를 생성하는 것은 불가능합니다.

그러나 해당 엔티티가 고객과 공급업체 양쪽 모두 동일한 대상이라면,

SAP EWM 내에서 하나의 BP로 통합하여 생성할 수 있습니다.

SAP EWM의 BP ID를 사용하면 하나의 BP가 고객과 공급업체 기능을 동시에 수행하도록 할 수 있습니다.

CIF를 통하거나 수동으로 고객을 BP로 생성할 때, 특정 BP 역할들은 자동으로 생성됩니다.

추가적인 BP 역할은 SAP EWM 내에서 생성할 수 있습니다.

변경 모드에서 고객 정보를 유지 관리할 때, 드롭다운 메뉴에서 주문처(CRM000), 납품처(CRM002) 등 필요한 역할을 선택하고 해당 역할에 맞는 데이터를 입력해야 합니다.

어떤 BP에 대해 기존에 어떤 역할들이 있는지 알고 싶다면, 'BP 역할 변경' 드롭다운 옆의 상세(Details) 버튼을 클릭하십시오. 시스템은 기본 역할 외에 해당 BP에 대해 이미 유지 관리된 역할 목록을 팝업창으로 보여줍니다.

 

그림 4.9의 '주소 개요(Address Overview)' 탭에 있는 주소 용도(Address Usages) 섹션에서는 BP 내에 서로 다른 텍스트를 유지 관리할 수 있습니다.

이는 예를 들어 선하증권(B/L)이나 기타 법적 문서를 출력할 때,

납품처와 주문처의 주소를 다르게 사용해야 하는 경우 등에 필요합니다.

Figure 4.9 Address Usage for the Business Partner

 

① 플랜트가 BP여야 하는 이유 (재고 이동의 관점)

• 실무 포인트: A 플랜트에서 B 플랜트로 물건을 보낼 때(Stock Transport Order), A 플랜트는 '공급처'가 되고 B 플랜트는 '수령처'가 됩니다. EWM 시스템은 모든 입/출고 문서를 BP 기반으로 처리하기 때문에, 자사 플랜트라 할지라도 반드시 BP(CRM011)로 등록되어야 문서를 생성하고 재고를 이동시킬 수 있습니다.

② 고객과 공급업체의 통합 (BP의 강력한 장점)

• 실무 포인트: 과거 ERP(ECC)에서는 동일한 업체라도 고객 마스터와 벤더 마스터를 각각 관리해야 했습니다. 하지만 EWM(및 S/4HANA)에서는 **'하나의 BP 번호'**에 고객 역할(CRM002)과 벤더 역할(BBP000)을 모두 담습니다.
• 장점: 업체 정보(전화번호, 주소 등)가 변경되었을 때 한 곳만 수정하면 되므로 데이터 무결성 관리가 매우 쉬워집니다.

③ 주소 용도(Address Usage)의 활용

• 실무 포인트: 실무에서는 한 회사의 '본사 주소(주문처)'와 '실제 물류 창고 주소(납품처)'가 다른 경우가 매우 많습니다.
• EWM의 'Address Usage' 기능을 활용하면, 시스템은 하나지만 상황에 따라(송장 발행 시 vs 배송 라벨 출력 시) 서로 다른 주소를 자동으로 불러와 출력물에 반영할 수 있습니다. 이는 수작업 오류를 줄이는 핵심 기능입니다.

④ 상세(Details) 버튼을 통한 현황 파악

• 실무 포인트: 특정 파트너가 시스템에서 어떤 권한을 가졌는지 확인할 때 유용합니다. 만약 현업에서 "이 업체로 출하 지시가 안 내려갑니다"라고 문의가 온다면, Details 버튼을 눌러 납품처(CRM002) 역할이 해당 BP에 활성화되어 있는지 가장 먼저 체크해야 합니다.

공급업체 (Vendor)

SAP ERP 시스템의 공급업체 마스터 또한 SAP EWM에서 비즈니스 파트너(BP)로 매핑됩니다.

만약 운송업체(Carrier)가 SAP EWM에서 BP로 유지 관리된다면,

관련 BP 역할은 CRM010(운송업체)과 BBP000(공급업체)입니다.

BP를 중앙에서 차단(Block)하려면 '상태(Status)' 탭의 Lock(잠금) 섹션에 있는 체크박스를 사용할 수 있습니다.

(그림 4.10 참조). 또한 BP의 릴리스(Release) 여부를 제어할 수도 있습니다.

Figure 4.10 Blocking and Release Control of a Business Partner

'제어(Control)' 탭에서는 **영업 시간(Business Hours)**을 유지 관리할 수 있는데, 여기에는 통화 가능 시간(Calling Hours), 입고 가능 시간(Goods Receiving Hours), 방문 가능 시간(Visiting Hours) 버튼이 포함됩니다.

만약 시간이 설정되어 있다면, 그림 4.11의 영업 시간 섹션에 'Goods Receiving Hours(입고 가능 시간)'라는 텍스트가 표시되는 것을 확인할 수 있습니다.

이 유지 관리 화면 내에서 약속(Appointment)을 위한 시간대를 관리하는 일반적인 **규칙(Rule)**을 지정할 수 있습니다.

또한 공장 달력(Factory Calendar)이나 휴일 달력(Holiday Calendar)과 연동하여 비영업일을 처리할 수 있는 예외(Exceptions) 설정도 가능합니다.

예외 기능을 사용하면 특정 활동(예: 입고 가능 시간)을 다음 날이나 이전 날로 이동시킬 수 있습니다.

Figure 4.11 Business Hours in Business Partner Master Data

① 운송업체(Carrier)의 이중 역할

• 실무 포인트: 물류 현장에서 운송사는 단순한 배달자가 아니라, 때로는 우리에게 운송 서비스를 제공하고 비용을 청구하는 **공급업체(BBP000)**이기도 합니다. 따라서 EWM 내에서는 반드시 CRM010과 BBP000 역할을 동시에 부여해야 합니다. 그래야만 입고 전표에서 운송사 정보를 기록하고, 나중에 운송비 정산까지 연계할 수 있습니다.

② 입고 가능 시간(Goods Receiving Hours)의 중요성

• 실무 포인트: 창고의 인력과 장비는 한정되어 있습니다. 모든 벤더가 월요일 아침 9시에 동시에 도착하면 창고 앞은 마비됩니다.
• BP 마스터의 Business Hours를 설정해두면, 시스템이 입고 예정 정보를 생성할 때 해당 벤더가 보낸 물건이 창고의 운영 시간 내에 도착할지, 혹은 특정 요일에만 입고가 가능한지 등을 사전에 체크할 수 있습니다.

③ 예외(Exceptions) 처리를 통한 유연성

• 실무 포인트: 갑작스러운 공휴일이나 창고 점검일이 생겼을 때, 'Exceptions' 설정을 통해 입고 일정을 자동으로 조정합니다. "일요일이 휴무라면 월요일로 입고를 미룬다"는 식의 로직이 여기서 결정됩니다. 이는 현장 작업자와 운송사 간의 불필요한 대기 시간을 줄여줍니다.

④ 중앙 잠금(Central Lock) 기능

• 실무 포인트: 특정 업체와 법적 분쟁이 생기거나 품질 이슈로 거래를 중단해야 할 때, 데이터를 삭제하는 대신 Status 탭에서 Lock을 겁니다. 이렇게 하면 기존 이력(History)은 보존하면서 향후 발생하는 모든 입/출고 트랜잭션에서 해당 업체가 선택되지 않도록 즉각적으로 차단할 수 있습니다.

EWM의 BP는 단순히 주소록이 아니라 **"언제(Business Hours), 어떤 자격(Role)으로, 거래가 가능한 상태(Status)인가"**를 결정합니다.

 

권한 당사자 (Party Entitled to Dispose)

SAP EWM에서 창고 재고는 반드시 '권한 당사자'에게 할당되어야 합니다. 즉, 해당 재고를 처분할 책임과 권한이 있는 당사자를 의미합니다. 참고: BP 섹션의 대부분 정보는 모든 역할에 공통적으로 적용되므로 각 BP 설명에서 반복하지 않습니다. 예를 들어 '상태' 탭의 중앙 차단(Central Block)이나 '주소 개요' 탭의 주소 용도(Address Usages)는 모든 역할에 적용 가능합니다.

 

운송업체 (Carrier)

운송업체는 운송 서비스를 제공하므로 SAP ERP에서 공급업체(Vendor)로 생성됩니다. SAP EWM으로 전송된 후에는 '운송업체' 역할로 유지 관리됩니다. 운송업체를 위한 BP 역할인 CRM010(운송업체)과 BBP000(공급업체)은 기본 역할(일반 BP 및 금융 서비스) 외에 추가로 유지 관리되어야 합니다. SCAC(표준 운송업체 알파 코드)는 식별 번호 필드의 ID 유형 BUP006 아래에서 관리됩니다.

 

 

종업원 (Employee) 종업원 또한 SAP EWM에서 비즈니스 파트너(BP)로 생성됩니다. SAP ERP 데이터는 CIF를 통해 SAP EWM으로 전송됩니다. 기본 역할 외에 종업원 BP 역할(BUP003)이 유지 관리됩니다. 그림 4.12는 BP 화면의 식별(Identification) 탭 내 '개인 데이터(Personal Data)' 및 '종업원 데이터(Employee Data)' 섹션에서 관리할 수 있는 필드들을 보여줍니다.

 

Figure 4.12 Employee Business Partner Personal and Employee Data

 

① Party Entitled to Dispose: "이 재고의 진짜 주인은 누구인가?"

• 실무 포인트: EWM 창고 하나를 여러 플랜트(Plant)가 공유할 때 매우 중요합니다. 창고 선반(Bin)에 있는 재고가 A 플랜트 소유인지 B 플랜트 소유인지 구분하는 기준이 바로 이 '권한 당사자'입니다.
• 보통 ERP의 Plant = EWM의 Party Entitled to Dispose로 매핑됩니다. 이 설정이 잘못되면 재고 금액이 엉뚱한 플랜트 장부에 잡히는 심각한 결산 오류가 발생할 수 있습니다.

② 운송업체(Carrier) 관리와 SCAC

• 실무 포인트: 단순히 '운송사 이름'만 넣는 것이 아니라 SCAC(BUP006) 코드를 넣는 이유를 이해해야 합니다. 글로벌 물류 EDI(전자문서교환) 표준에서 운송사를 식별하는 유일한 키가 SCAC이기 때문입니다.
• 또한, 운송사는 나중에 운송료를 지불해야 하는 대상이므로 반드시 BBP000(Vendor) 역할이 함께 있어야 전표 처리가 가능합니다.

③ 종업원(Employee) BP와 현장 작업의 연결

• 실무 포인트: EWM에서 종업원을 BP로 등록하는 이유는 크게 두 가지입니다.
  1. Resource 관리: RF 스캐너를 사용하는 작업자를 'Resource'로 등록할 때 이 BP 번호를 연결합니다.
  2. 작업 추적: 특정 입고/피킹 작업을 "누가" 했는지 기록하여 작업 생산성을 분석(Labor Management)하기 위함입니다.
• 실무적으로는 인사 시스템(HR)의 데이터가 ERP를 거쳐 EWM으로 자동으로 넘어오도록 구성하는 것이 일반적입니다.

④ 데이터 거버넌스 (Note 부분)

• 실무 포인트: 중앙 차단(Central Block) 기능은 매우 강력합니다. 만약 특정 종업원이 퇴사했거나 특정 운송사와 계약이 해지되었다면, 데이터를 지우지 말고 Status에서 차단하십시오. 그래야 과거의 작업 이력(History)은 보존하면서 향후 잘못된 사용을 막을 수 있습니다.

[종업원 데이터 활용]

• 개인 번호(Personnel Number) 및 사용자 이름(User Name)을 포함한 종업원 상세 정보는 노무 관리(Labor Management, LM) 모듈 및 인사(HR) 시스템과의 인터페이스에 사용됩니다.

4.2.8 기타 역할 (Miscellaneous Roles) 주요 역할 외에도 SAP EWM에서 다음과 같은 다양한 역할들이 사용될 수 있습니다:

• BBP001—Bidder: 입찰자
• BBP002—Portal provider: 포털 제공자
• BUP002—Prospect: 잠재 고객
• CRM012—Consolidator: 혼적업체 (여러 화물을 하나로 모으는 업체)
• CRM013—Remanufacturer: 재제조업체
• CRM014—MRP area: MRP 영역
• SLLAUT—Public authority: 공공 기관
• SLLCOF—Customs office: 세관
• SLLDAP—Data provider: 데이터 제공자

[새로운 역할 정의 및 제어] 비즈니스 요구에 따라 새로운 역할을 정의하려면 다음 경로에서 설정할 수 있습니다: Cross-Application Components > SAP Business Partner > Business Partner > Basic Settings > Business Partner Roles > Define BP Roles

설정 화면(그림 4.13)에서는 수정 지시자(Modification Indicator) 옵션을 통해 해당 BP의 비즈니스 트랜잭션 권한에 영향을 줄 수 있습니다. 이 지시자는 다음 값들을 가질 수 있습니다:

• Transaction allowed: 트랜잭션 허용
• Transaction allowed, warning message is issued: 트랜잭션 허용하되 경고 메시지 발생
• Transaction not allowed: 트랜잭션 불허

Figure 4.13 Define Business Partner Roles Screen

① 노무 관리(LM)와의 연동

• 실무 포인트: 종업원의 '인사 번호'와 'SAP ID'를 매핑하는 이유는 단순히 이름을 알기 위함이 아닙니다. LM 모듈에서 작업자의 실제 작업 시간(Actual Time)을 측정하고 이를 인사 시스템(HR)의 급여 계산이나 성과 지표와 연동하기 위한 기술적 기초가 됩니다.

② 특수 역할의 비즈니스 의미

• SLLCOF (세관): 보세 창고(Bonded Warehouse) 운영 시 필수적입니다. 수출입 신고와 관련된 문서 발행 시 해당 세관 정보가 BP에서 호출됩니다.
• CRM012 (혼적업체): 운송 관리(TM)와 연동하여 여러 하주의 물량을 하나의 컨테이너로 묶는 LCL(Less than Container Load) 작업 시 해당 파트너 정보가 필요합니다.

③ 수정 지시자(Modification Indicator)를 통한 통제

• 실무 포인트: 특정 업체에 문제가 생겼을 때, 단순히 데이터를 지우는 것이 아니라 이 설정을 통해 시스템적으로 '경고'를 띄우거나 '차단'할 수 있습니다.
  • 예를 들어, 신용도가 낮은 잠재 고객(Prospect)에게는 "경고"를 설정하여 담당자가 주의하게 하고, 계약이 종료된 업체는 "Transaction not allowed"로 설정하여 실수로 전표가 발행되는 사고를 원천 봉쇄합니다.

④ 확장성 (Define BP Roles)

• 실무 포인트: SAP EWM 프로젝트 시 표준 역할만으로 현업의 요구사항을 다 채우지 못하는 경우가 많습니다. (예: 특정 창고 전용 검수 외주업체 등) 이때 IMG 설정을 통해 새로운 역할을 정의하고, 해당 역할에 필요한 필드만 활성화하여 관리할 수 있는 유연성을 제공합니다.

Figure 4.13 Define Business Partner Roles Screen