Hyowon's Archive

머리말

SAP의 마스터 데이터가 무엇이고 SD관련 마스터 데이터 중 3가지와 관련된 내용을 살펴본다. Customer(business partenr)에 대한 내용은 나중에 제대로 다루고, Pricing도 간단하게 다루고 나중에 제대로 세세히 살펴본다. 

1. Material Master
2. Customer-Material info records
3. Pricing condition master records

1. Material Master

SAP에서 마스터 데이터란 회사의 고객, 임직원, 공급자, 제품, 자산 등에 관한 비즈니스 데이터를 뜻한다. 트랜잭션 데이터는 기업의 활동으로 인해 발생하는 데이터를 뜻한다. 예를 들면 자재 '1001'은 마스터 데이터이지만 이 자재를 판매하는 주문정보인 Sales Order는 트랜잭션 데이터이다. 회사의 유형 자산인 건물 'A001' 마스터 데이터이지만, 해당 건물의 감가상각비를 처리한 회계전표는 트랜잭션 데이터이다.

1.1. Maintaining Material Master ( 관련 T-CODE : MM01, MM02, MM03 )

SD 모듈에서 비즈니스 트랜잭션이 처리되는 동안, 많은 데이터가 마스터 데이터에서 Sales Document로 전달된다. 이 데이터들은 다시 Delivery(Shipping), Billing 문서들로 전달되며 처리된다. 그러므로 미리 비즈니스 트랜잭션을 발생시키기 전에 정확한 마스터 데이터를 만들어 놓아야 한다. 이 마스터 데이터들은 몇몇 조직 구조 레벨(ex. Sales Org, Plant 등)에서 정의되기 때문에 정확한 값으로 마스터 데이터를 확장해 두어야 제대로 비즈니스 트랜잭션이 수행된다. 

Material 을 정의하기 위해서는 먼저 Industry Sector와 Material Type을 지정해야 한다.

• Industry Sector : 자재가 속하는 산업을 정함(retail, chemical, mechanical engineering), 자재의 industry sector가 자재가 가지고 있어야할 필드와 자재 정보화면(MM01,MM02,MM03)의 스크린 순서를 정한다. 즉, 어떤 view와 필드들을 가질 지 미리 정의된 템플릿을 정하는 값이다.
• Material Type : 비슷한 성격으로 그룹화하기 위한 값(services, trading goods, raw materials 등). 자재 번호를 내부적으로 채번할지 외부적으로 채번할 지 정하거나, 가치 평가를 이동평균법으로 할 지, 표준원가법으로 할 지 정하는 기준이 된다. 또한, Industry Sector와 마찬가지로 스크린의 순서와 필드 여부를 결정하는 값으로 쓰인다.

• DIEN - Service : Storage 데이터가 없고 생산되거나 벤더로부터 공급받을 수 없는 자재 유형이다.
• FERT - Finished Product : 제품, in-house로 제조하는 상품이며 구매될 수 없는 자재 유형이다.
• HAWA - Trading Goods : 벤더로부터 구매한 자재로 추후 따로 추가적인 변형을 거치지 않고 고객에게 판매하는 자재 유형이다.
• KMAT - Configurable Materials : 기본 자재(Material) 코드 하나로 다양한 변형 제품을 생성가능 (Customizing 가능)
• NLAG - Non-Stock Material : 무형의 자재들을 나타냄, 대표적으로 소프트웨어와 라이센스, 접근권한(구독 등)이 있음.

1.1.1 Material Master Views

Material Master는 앞서 이야기했듯, 여러 조직단위로 나뉜다. 각 단위별로 나뉜 단위별로 할당받은 데이터 집합 각각을 view라고 한다. 아래와 같이 여러 view가 있다. Basic data는 말 그대로 기본적인 정보이며 모든 부서가 공유하는 공통 데이터이다. view 이름에서 알 수 있듯 Sales views는 영업 관련 부서, Purchasing과 MRP는 구매, 자재관리 모듈, Accounting은 회계 등 각각의 부서에서 직접 마스터 데이터를 관리한다. 해당 부서의 담당자들이 각 마스터 데이터 뷰의 데이터를 정하고 유지보수한다.

• Maintenance status : 자재가 어떤 view가 유지보수되었는지(확장되었는지) 나타내는 필드값(MARA, MARC table 등에 있다)

예를 들어 KVBXZ 값이 필드에 있다면 해당 자재를 각 VIEW로 확장했다는 뜻이다.

1.1.2 Basic Data 1, 2

• Material (Material number) : 내부적으로(자동으로) 채번되거나 외부적으로(수기) 채번되도록 지정할 수 있다.
• Descr : 자재의 이름을 나타내는 필드
• Base Unit Of Measure : UoM은 재고를 관리할 때 쓰인다. 얼마나 재고가 있는 지 나타낼 때 쓰는 단위. 재고를 쓸 때 쓰는 단위를 SKU(Stock Keeping Unit)이라고도 쓴다.
• Material Group : 비슷한 자재끼리 그룹화할 수 있는 필드. 앞서 조직 구조에서 Division이나 자재 생성시 설정하는 Material Type처럼 자재를 구분하는 기준이 되는 여러 필드 중 하나이다.
• X-Plant Mat.Status(cross-plant material status) : 자재의 생명주기(lifecyle) 단계를 나타내고, 그 상태가 모든 plant에서 공통적으로 적용될 지 여부를 나타내는 필드값. 
• Prod.hierarchy(product hierarchy) : 자재계층구조, 자재를 레벨별로 나누어 분류할 수 있는 필드. 최대 9레벨까지 계층 구조를 설정할 수 있다. 

• Division : SD모듈 조직구조에서 배운 Division을 뜻한다. Sales view가 아닌 basic data view에 있는 일반 데이터이다. Sales Organization과 Distribution Channel과 함께 사용되어 매출형태를 정하는 데 사용된다.
• GenItemCatGroup :  Sales 관련 트랜잭션에서 Item Category를 결정하는데 사용되는 값이다. Sales View에도 같은 이름의 필드가 있으며 Sales 트랜잭션에서는 Sales view의 값이 우선순위가 더 높다. 즉 Sales Area별로 다른 값이 적용가능하다. SAP 전반적인 모듈에서 사용되는 값은 이 값이 적용된다.
• Net weight and Gross weight : 출하/운송 모듈 트랜잭션에서 주로 사용되며, 순중량(제품 자체 무게), 총중량(제품+포장 무게)이다. 
• Material Is Configurable : 체크되어 있으면 변형 제품 생성이 가능하다. 고객 맞춤형 제품에서 사용된다.

1.1.3 Sales: sales org 1, 2

• Sales Unit : Sales Order에서 사용되는 UoM
• X-distr.chain status(cross-distribution chain material status) : cross-plant material status와 비슷한 기능. 모든 distribution channel에 대한 상태값 
• DChain-spec-status(distribution chain-specific material status) : 특정 Dstribution Chain에만 적용
• Delivering Plant : 기본으로 제안되는 Sales Order의 Delivery plant 값. Sales order 생성 시 제안되는 값이라 바꿀 수 있음
• Tax data : tax category와 tax liability를 나타냄. Tax Classification은 output tax(매출세, 부가세 등) 결정 절차에 사용된다. 이 데이터는 Sales Area별 데이터가 아닌 국가별 데이터이다. MVKE 테이블이 아닌 MLAN 테이블에 그 데이터가 있다.
• Min.order qty(minimum order quantity) : Sales Order 생성 시 최소 수량
• Min. Dely Qty(minimum delivery quantity) : Delivery 생성 시 최소 수량
• Acct Assmt Grp Mat.(account assignment group for material) : 빌링처리 동안 회계전표를 생성할 때, 이 필드를 이용해 수익 계정(revenue)이나 deduction account(공제 계정)을 결정하는 데 이용된다. 공제 계정은 리베이트, 매출할인 등의 계정을 뜻하는 듯하다.
• Item Category Group : Basic Data에 있는 필드와 같은 기능을 한다. 다만 Sales 프로세스에서는 이 값이 우선순위를 가진다. 
• Product hierarchy : Basic data에 있는 필드와 같은 기능을 한다. 다만 Sales 프로세스에서는 이 값이 우선순위를 가진다.

1.1.4 Sales: General/Plant

• Availability check : 재고 가용성 점검 방식을 정하는 기준값. MRP와도 관련이 있다.
• Batch management : 모든 plant에서 배치 단위로 관리를 할 것인지 나타내는 값. 이 값이 한 번 설정되면 재고가 현재 혹은 이전 기간에 존재하는 경우 바꿀 수 없다.
• Batch management(Plant) : 선택된 플랜트에서만 배치 관리를 것인지 나타내는 값. 이 값이 한 번 설정되면 재고가 현재 혹은 이전 기간에 존재하는 경우 바꿀 수 없다.
• Trans. Grp(transportation group) : 운송 관련 기준값. 모든 플랜트에 적용되는 값
• LoadingGrp(loading group) : Shipping condition과 deliverying plant값과 함께 사용되어 Shipping point를 정하는 데 사용된다.
• SerialNoProfile(serial number profile) : 일련번호로 제품을 관리하기 위한 설정. 제품 일련번호의 체계를 지정하는 것임.

이외에 Additional data 탭에 들어가면 추가적인 기능이 더 있다. UoM의 변환 규칙을 정하거나, 여러 언어로 Description을 설정하거나 할 수 있다. 

삭제를 위한 flag를 조직 단위 별로 설정할 수도 있다.

2. Customer-Material Info Records

쉽게 말하면 상대방(고객)의 Purchase Order(구매오더)의 자재코드와 자신의 SAP 시스템의 자재 코드를 매핑하는 마스터 데이터이다. 특정 Customer의 특정 Material을 자신의 SAP 시스템의 자재코드를 미리 매핑시켜놓는 마스터 데이터이다.

• Sales Order 생성 시 Customer Material Number에 Cust. Material 코드를 넣으면 시스템이 매핑된 Material을 찾아온다. 판매처의 구매주문을 토대로 바로 Sales Order를 생성하는 데 쓰일 수 있다.

3. Condition Master Data for Pricing

Sales 프로세스에서 중요한 부분을 차지하는 Pricing(Price Determination), 즉 가격 결정에 사용되는 Conditon Master를 살펴본다. 한국어로는 조건으로 번역되지만 흔히 현업에서는 판(매)가, 거래조건 등으로 불린다. 여기서는 간단하게만 살펴보고 후에 자세히 학습한다.

Pricing Condition Records 형태로 시스템에 저장되어 있으며, 이 마스터 데이터들은 Sales 프로세스 중 Customer, Material, Quantity, Condition type, Org.unit 등 여러 기준을 통해 어떤 값이 채택될 지 결정되어 각 문서에 반영된다. 이런 식으로 여러 기준으로 가격 결정 절차를 수립하는 방법을 Condition Technique라고 부른다.

• Pricing Condition Record를 생성할 때 Condition Type을 반드시 지정해야 한다. 이 Type 값은 해당 레코드가 나타내는 값이 gross price인지 net price인지, 혹은 discount, freight charge, tax 등 어떤 가격 결정 요소인지를 타나난다. 

예시)

아래와 같은 컨디션 레코드들이 있다고 가정한다.

위 레코드의 뜻은 Sales Org이 1000이고 Material이 XYZ일 때 합계금액은 $600라는 뜻이다.

위 레코드의 뜻은 Sales Org가 1000이고 Customer가 B이고 Material Group이 M020인 경우 5%의 할인율을 갖는다는 뜻이다.

위 뜻은 Sales Org가 1000이고 Customer가 A고 Material이 XYZ면 세전가격(부가세 계산 전)은 $450이라는 뜻이다.

단, PN00은 PR00보다 나중에 적용되어지는 값이다. 즉, PR00이 결정되고 PN00이 결정되면 PN00이 최종적용가격이다.

*보통 Gross Price라는 용어는 부가세 포함가격, Net Price는 부가세 제외한 가격을 뜻하지만 여기서는 부가세는 없다고 가정하고 Gross Price는 이런저런 할인 등이 적용되지 않은 최초 적용되는 기본 가격, Net Price는 최종가격으로 생각한다.

TODO

머리말

1. Sales and Distribution 모듈 기본 흐름 학습한다. SD 모듈에 대한 학습 전 SD 모듈에서 다루는 문서들의 흐름을 미리 암기하고 있는 것이 좋다. 이 글에서 배울 SD 모듈의 조직구조도 결국 Sales Order를 비롯한 SD 모듈의 비즈니스 프로세스에서 생성되는 문서들을 생성하기 위한 사전 세팅 값에 해당하기 때문이다.
2. Sales and Distribution 모듈의 Organizational Structure(조직 구조)를 학습한다. SD 모듈 조직구조 전 SAP의 Client 개념, FI모듈의 Company Code 개념 등을 배운다.

 1. Sales and Distribution 모듈 기본 흐름

• Sales and Distribution(SD; 영업유통) 모듈은 기업의 영업 및 제품 출하부서의 업무를 지원하는 모듈로서 사전 영업활동, 판매 주문처리, 출하관리, 대금청구 및 매출분석에 이르는 프로세스를 지원한다. 제품의 판매주문부터 현금화까지의 과정을 다룬다고 보면된다.(Order-to-Cash)

1.1 SD 모듈 문서 흐름

SD 공부를 위해 아래 5개의 문서의 흐름을 암기하고 시작하는 것이 좋다. SD 모듈은 아래 문서들을 발생시키기 위한 기능들의 집합이라고 할  수 있다.

• Sales Order(SD)
  • Sales Order(영업주문)은 영업 조직(sales organization)과 판매처(sold-to party) 사이의 재화와 서비스 제공에 대해 가격, 수량, 시간에 대한 합의를 기록한 문서.
  • SD 모듈의 핵심 문서로 이 문서를 만들기 위해 여러 설정값들을 사전에 세팅하고, 이 문서를 바탕으로 Delivery 및 출고, Billing(대금청구) 등의 후속 작업이 이루어진다.
  • 관련 테이블 : VBAK(Sales Order Header), VBAP(Sales Order Item), VBKD, VBEP, VBAP
• Delivery(SD, LE, TM)
  
  • Delivery(출하, 납품문서)는 재화의 운송(Shipment)과 서비스 제공 과정(피킹picking, 포장packing, 출고good issue 등)을 지시하고 모니터링하는 문서.
  • 주로 Sales Order를 바탕으로 생성됨. 후속문서로 운송과 관련된 Shipment, Loading 등 및 자재 문서(Material Document) 등이 있다. 
  • 관련 테이블 : LIKP(Delivery Header), LIPS(Delivery Item)
• Material Document(MM)
  • 자재의 이동(입고, 출고, 재고이동, 재고 조정 등)을 나타내는 문서. SD모듈에는 주로 판매를 위한 출고를 나타내는 자재문서가 발생한다.
  • 관련 테이블 : MKPF, MSEG
• Billing(SD)
  • Billing(대금청구)는 출고처리가 완료된 후 Sales Order와 Delivery 데이터를 근거로 송장(invoice)를 생성하여 고객에게 대금 청구를 위해 생성하는 문서.
  • SD 모듈 비즈니스 트랜잭션의 마지막 단계로 Sales Order와 Delivery가 처리되면 Billing 생성이 가능해진다. 
  • 주로 Delivery가 완료되면 Delivery를 참조하여 생성하지만 서비스 매출과 같이 재화의 이동이 없어 Delivery가 없는 경우 Order를 참조하여 생성한다.
  • Billing 생성 시 자동으로 회계 모듈과 연계되어 Accounting Document(회계전표)가 생성되는 전기(posting)가 이뤄진다.
  •  관련 테이블 : VBRK(Billing Header), VBRP(Billing Item)
• Accounting Document(FI)
  • 재무회계(FI) 모듈 문서. 기업 활동으로 일어나는 모든 거래는 회계 전표를 발생시킨다.
  • SD 모듈에서는 주로 물품의 출고로 자재문서(Material Document)와 고객에게 발생한 대금청구문서(Billing)가 전기(Posting)되어 생성되는 2가지의 회계전표가 대부분이다.
  • 출고로 생긴 회계전표는 매출원가를 나타내는 회계전표이며 대금청구문서는 고객에게 발생한 채권을 기록하는 회계전표(AR전표라고 주로 불림)다.
  • 관련 테이블 : BKPF(Accounting Document Header), BSEG(Accounting Document Item)

 1.2 Others

• 위 그림은 SD 모듈을 중심으로 가장 중요한 문서들만을 나타낸 것이다. 
• Sales Order 전 단계로는 문의(inquiry), 견적(quotation), 계약(contract) 등의 pre-sales 과정이 있다.
• Delivery 와 Material Document 사이에도 LE, TM, TD, WM, eWM 등 물류 모듈에서 Shipment, Loading 등의 과정을 다루는 문서들이 발생할 수 있다. 또한 이 과정에서 또 다른 비용이 발생하여 관련 회계전표가 생길 수 있다.
• FI 모듈의 회계전표 이외에도 CO 모듈에 속하는 PA, COA 전표 등이 Delivery, Billing 과정에서 생성된다.

2. Sales and Distribution 모듈의 Organizational Structure(조직 구조)

2.1 SAP의 기본 조직 구조 - Client

Client는 데이터베이스를 논리적으로 나누는 조직 단위

 SAP의 Organizational Structure는 주로 현실에 존재하는 기업의 조직 구조를 반영한다. 예를 들면, Company Code는 현실의 법인과 1대1 대응을 이룰 수 있다. 즉, 제무제표를 발행하는 단위와 1대1 대응이 가능하다. Plant는 각 공장이나 물류센터, 혹은 사무실 등을 나타낼 수 있다. 하지만, 대부분의 SAP 책에서 조직 구조를 설명할 때 Client를 소개하는 데 이는 현실에 존재하지 않는 단위이다. 쉽게 말하면 Database를 논리적으로 나눌 때 사용하는 단위이다. 

 하나의 데이터베이스를 Client라는 필드(컬럼)를 이용해 나눌 수 있다. Client라는 필드가 있는 테이블들은 주로 기술적인(Technical) 데이터가 있는 테이블이 아닌 비즈니스(Business) 관련 테이블들이 대부분이다. 예시로 Sales Order 데이터가 담긴 VBAK 테이블과 프로그램 소스코드가 담긴 TADIR 테이블을 살펴보자.

Sales Order 와 같은 비즈니스 데이터를 담는 테이블에는 MANDT라는 Client를 나타내는 필드가 잇지만 SAP 시스템의 오브젝트같은 시스템적인 데이터를 담는 TADIR 테이블에는 MANDT 필드가 없다. Client 필드는 주로 하나의 SAP 시스템에서 비즈니스 데이터를 나누는 기준이 될 수 있는 필드이다.

 하지만, 실제로 운영 환경에서 client를 여러 개 만들어 하나의 SAP 시스템 내에서 비즈니스 데이터를 나누는 경우는 거의 없다. 그렇다면 왜 client 개념이 존재하는 걸까? 그 이유는 운영 환경이 아닌 개발과 품질 서버에서 사용하기 위해서다. SAP 개발 서버에서는 프로그램 개발만 작업할 수 있는 Client, IMG 세팅만을 작업하는 Client, 단위 테스트를 진행하는 Client 등으로 나누기도 한다. 또한, 품질 서버에서는 통합 테스트를 위한 client, 학습을 위한 client 등으로 나누는 등 여러 경우가 있다.

위 그림은 SAP의 공식문서에서 가져온 그림이다. 왼쪽부터 각각 개발서버, 품질서버, 운영서버에 해당하고 각 네모 칸이 Client에 해당한다. 서버 자체는 3개 뿐이지만 개발서버는 3개의 client(커스터마이징, 테스트, 샌드박스)로 나눴고, 품질은 2개의 클라이언트(품질테스트, 트레이닝)로 나눴고 운영 환경은 하나의 Client만을 사용하고 있다. 

 따라서, 모듈에 대한 학습을 진행할 때는 Client 밑 단계인 Company Code 부터 신경쓰면 된다. 모듈 학습은 비즈니스 데이터의 처리에 대한 학습이지 SAP 시스템 구조에 대한 학습이 아니기 때문에 Client가 있다는 정도만 알면 된다.

2.1 SAP의 기본 조직 구조 - Company Code

앞서 간단히 언급한 것처럼 Company Code는 일반적으로 현실세계의 회사와 1대1 대응된다. SAP는 재무제표를 생산하므로 회사 코드는 계정과목표(Chart of Accounts)를 가진 법적인 실체(legal entity)를 나타낸다. 기업집단(그룹사)이라면 각각의 계열사들이 Company Code를 가지게 된다. T-CODE SPRO에서 IMG 세팅을 통해 회사코드를 정의할 수 있다. 회사 코드는 FI 모듈의 최상단에 있는 조직 구조이다. 타 모듈의 조직 구조도 대부분 Company Code 하위에 속한다. 예를 들면, SD 모듈의 최상단 조직 구조인 Sales Organization도 Company Code에 하위에 속한다. 

*IMG란 Implementation Guide의 약자로, SAP 시스템의 각종 설정들을 하는 프로그램을 의미한다. Company Code와 같은 기업을 나타내는 데이터부터 Pricing 절차와 같이 매출 발생 시 판매가를 결정하는 세세한 절차까지도 미리 설정할 수 있다. 

2.2 SD 모듈의 기본 조직 구조 - Sales Area

• Sales Area(영업 영역) = Sales Organization(영업 조직)+ Distribution Channel(유통채널) + Division(제품군)
• Sales Office , Sales group

SD 모듈의 핵심적인 기능은 주로 Sales Area를 기준으로 동작한다. Sales Area의 3가지 요소를 간단하게 설명하면, "Sales Organization은 '누가', Distribution Channel은 '어떻게', Division은 '무엇을' 파는가?"라고 할 수 있다. 즉, 3가지 구성 요소의 조합으로 매출의 유형을 나눠 각 경우마다 어떤 방식으로 매출을 처리할 지(예를 들어, 가격은 어떻게 설정할지, 세금은 어떻게 처리할지, 어떤 회계계정을 매출수익계정으로 쓸 지 등)를 결정하거나 유도한다. 

2.2.1 Sales Organization(영업 조직)

재화와 서비스의 판매와 유통을 담당하는 법적 실체를 나타낸다. Sales Org.는 SD모듈의 최상단 관리 기준점이 되므로 최대한 적은 가지 수로 편성하는 것이 좋다. 그래서 여러 Sales Org를 Company Code에 할당할 수 있지만 보통은 1:1로 관리한다.

• 하나 이상의 plant를 Sales Org에 할당할 수 있다.(정확히는 Distribution Chain. 밑에서 설명)
• 주소(address)가 세팅되어야 한다. SAP에서 법적 실체를 나타내는 조직 구조 단위는 대부분 Address 정보를 가진다.
• material이나 customer를 Sales Org 기준으로 구분할 수 있다. cross-Sales Org. 마스터 데이터는 불가능하다. 즉, Sales Org.별로 마스터 데이터를 확장해야 한다.(정확히는 Sales Area 별로 확장해야 한다. Division 까지 설명 후 다시 설명)
• Sales Org 각각에 특정 Sales Document Type만을 허용하도록 할당할 수 있다.
• Sales Office를 Sales Org에 할당할 수 있다.(정확히는 Sales Area에 할당하는 것)
• 모든 Sales Document의 아이템들은 하나의 Sales Org에 속한다. 즉 Sales Document의 헤더에는 항상 Sales Org가 있다.
• 각각의 Sales Org는 표시통화(Currency for statistics, 재무제표 작성용 통화, 반대말은 기능통화)와 고유의 달력(Calendar)를 가진다. 달력은 Delivery date 결정,  ATP(Available to Promise, 재고 가용성) 점검 등에 사용된다.
• 여러 회사 코드를 가지는 시스템을 사용한다면, 관계사 간 거래를 위해 각 회사의 영업조직을 나타내는 Customer를 Intercompany Billing을 위해  정의해두어야 한다.  

2.2.2 Distribution Channel(유통 채널)

앞서  Dist Ch.은 '어떻게'라고 설명했다. 예를 들어, Online, Wholesale(도매), Retail(소매), Direct(회사직판) 등으로 나눌 수 있다. 재화와 서비스가 팔리는 방식에 대해 정의한다. 내수/수출로 나누는 경우도 있다.

•  Dist Ch.은 여러 개의 Sales Org.에 할당될 수 있다. Sales Org. + Dist Ch. 조합을 'Distribution Chain'이라고 부른다.
• 하나 이상의 plant가 Dist Ch.에 할당될 수 있다. Sales Org.에도 하나 이상의 plant가 할당될 수 있는데, 사실 plant가 (Sales Org. + Dist ch.)에 할당되는 것이다. 이 할당 작업은 특정 Sales Org. + Dist ch. 조합을 사용할 때 허용되는 plant 목록을 할당하는 것이기 때문에 재고가 빠져나갈 plant라면 반드시 특정 Sales Org. + Dist ch. 조합에 할당해야 한다. 신규 Plant 생성 혹은 신규 Dist Ch. 생성 시 반드시 해야하는 작업 중 하나이다. 참고로 다른 회사 코드 아래에 속한 Plant도 할당할 수 있다.

• 위와 같이 다른 회사 코드 아래의 Plant가 Distribution Chain에 매핑된다는 것의 의미는 다른 회사의 플랜트(B101)에 있는 재화를 우리 회사(1001)가 판매한다는 뜻이 된다. 즉, '1001'이 '1002'에게서 재화를 구매한 뒤 그 재화를 고객에게 판매하는 프로세스가 이뤄지는 것이다. 그렇게 되면 '1002'입장에서는 재화를 '1001'에 판매하는 것이 된다. 이 방식의 매출이 이뤄지면 '1002'가 '1001'에 대금청구를 하게 된다. 나중에 Third Party Order에서 Vendor가 Inter Company인 경우를 배울 때 자세히 배운다.

• material이나 customer를 Dist Ch. 기준으로 구분할 수 있다. 즉, Dist Ch. 별로 마스터 데이터를 확장해야 한다.(정확히는 Sales Area 별로 확장해야 한다. Division 까지 설명 후 다시 설명)
• Dist Ch.  각각에 특정 Sales Document 유형만을 허용하도록 할당할 수 있다.
• Sales Office를 Dist Ch. 에 할당할 수 있다.(정확히는 Sales Area에 할당하는 것)
• Sales 와 Billing document의 모든 아이템은 같은 Dist Ch.을 가져야 한다. 즉, Sales doc과 Billing doc의 헤더에 Dist Ch.이 있고 모든 아이템은 이 Dist Ch.에 속한다. 하지만 Delivery의 경우 아이템 레벨에 Dist Ch.가 있다(LIKS가 아닌 LIPS에 Dist Ch. 필드가 있다). 즉, 같은 Delivery 문서에 여러 Dist Ch.이 존재할 수 있다. 실제 현장을 예로 들어 설명하자면, 물류 센터에서 출하할 때는 어떤 재화가 소매로 팔리든 도매로 팔리든 정확한 목적지로 정확한 양을 보내기만 하면 되니 출하를 관리하는 Delivery 문서에서는 Dist Ch.을 기준으로 문서를 관리하지 않고 아이템 레벨에 Dist Ch.을 두는 것이라 생각하면 이해하기 편하다.

2.2.3 Division(제품군)

'무엇을'에 해당하는 Div(제품군)는 Material Master의 General(Basic) 데이터에 있다. 어떤 종류의 Material인지 나타낸다. Material Master에는 Material Group, Product Hierachy 등 Material을 구분하는 다양한 필드들이 있는 데, Division 또한 마찬가지로 Material을 나누는 기준이 되는 필드 중에 하나이다. Division은 SD 모듈 입장에서 분류하는 데 쓰인다. 

예를 들면, 자동차의 전장 부품 A001(승용차용 배터리), A002(트럭용 배터리)가 있을 때, 두 Material 모두 Material Group은 '2000 : 전장 부품'으로 같은 필드 값을 갖지만, Division은 A001은 '10 : 승용차', A002는 '20 : 트럭'이라는 값을 가질 수 있다. Material Group은 자재 관점(MM), Division은 영업  관점(SD)에서 바라보기 때문에 MM 시점에서는 같은 종류이지만 영업 관점에서는 다른 종류로 판단할 수 있다.

• Division은 하나 이상의 Sales Organization에 할당될 수 있다. 
• Division은 하나 이상의 Distribution Channel에 할당될 수있다. 즉 Sales Area의 마지막 레벨이다.

• 위 그림에서 가능한 조합의 개수는 2*3*5 = 30 이다. Sales Org는 주로 회사코드와 1대1 매핑으로 회사 당 15개의 조합을 정의할 수 있다. 즉 15개 형태의 매출 형태를 Sales Area레벨에서 정의할 수 있다는 것이다. 

1000-10-01, 1000-10-02, ..... 1000-30-04, 1000-30-05

• Sales Office는 여러 Division에 할당될 수 있다. 즉 여러 Sales Area에 할당된다.
• Sales Document type을 정의할 때, 해당 문서의 모든 item들의 division이 같도록 강제할 수 있다. 즉, 생성할 문서의 Sales Area의 Division에 해당하는 material들만 해당 Sales doc에 넣을 수 있는 것이다. 이 말은 VBAK나 VBAP 두 테이블 모두에 Dvision 필드(SPART)가 있다는 뜻이 된다.
• 이와 반대로 Delivery나 Billing에는 서로 다른 Division 값을 가진 item들이 들어갈 수 있다. Delivery는 창고에서 물건이 나갈 때 굳이 승용차용 배터리, 트럭용 배터리를 나눠 따로따로 출고하는 것이 비논리적임을 생각하면 이해가능하고, Billing도 마찬가지로 고객에게 대금을 청구하는 것이 목적이므로 Billing 문서의 item들의 Division이 굳이 같아야할 필요는 없다. 다만, 데이터 관리 편의를 위해, Sales Order - Delivery - Billing이 모두 1:1:1 관계를 갖도록 강제하는 경우에는 Delivery, Billing에도 같은 Item만 오는 것이 가능하다. 참고로 Delivery의 헤더 테이블 LIKP에는 Division이 없고 LIPS에만 Division 필드가 있다. Billing 테이블 VBRK, VBRP에는 모두 Dvision 필드가 있다. 

2.2.4 Sales Area 추가 설명

FI의 중요 요소인 Business Area를 결정하는 Rule에 Sales Area가 사용되는 경우가 잦다. 추가적인 CBO나 User Exit 등을 불필요하게 추가하지 않으려면 타 모듈과의 연결고리인 조직구조를 잘 구성해야 한다. 

Business Area란 실적 보고 및 분석 등을 위한 기준이 되는 FI 조직 구조 단위 중 하나이다. SD와의 접점으로는 어떤 매출이 어떤 Business Area 값을 가질 지 Sales Area를 통해 설정할 수 있다.

2.2.5 Sales Office, Sales Group

• Sales Office는 물리적인 위치를 기준으로 나눈 조직 단위이다. 예를 들면 서부지사, 동부지사, 해외사무소 등으로 나누어 Sales Document를 생성한, 즉 매출을 발생시킨 부서를 나타내는 조직 단위이다. Sales Area에 할당될 수 있다.
• Sales Group은 Sales Employee들은 묶는 단위이다. Sales office에 할당된다.
• 이 2개의 조직 단위는 그 자체로 특별한 기능이 있지는 않다. 하지만 매출 발생처를 나타내는 중요한 역할을 맡을 수 있다. SD관점에서 매출 분석의 세부 기준이 될 수 있다. 이 두가지 조직 단위는 FI와의 접점이 따로 없어 Sales Office, Sales Group의 조합으로 Business Area를 결정하도록 CBO 테이블을 만들고 Sales document 생성 시 user exit에 해당 테이블에서 BA를 가져오도록 하는 경우가 종종 있다.

2.3 SD 모듈의 기본 조직 구조 - Logistics

SD의 메인 문서인 Sales Document 생성 시 입력되거나 결정되는 값이지만, 물류에 관련된 값들이라 Delivery와 그 이후의 과정에서 사용되는 값이 대부분이다. TM, LE, WM, TD 모듈 등에서 주로 사용되는 값들이다.

2.3.1 Plant

Plant는 SAP에서 자재 평가, 자재소요계획(MRP), 생산, 재고 관리, 비용 등 다양한 기능에서 핵심적인 역할을 수행하는 조직 구조 단위이다. 한국어로는 공장,설비,시설 등으로 번역되지만 그 보다는 더 넓은 의미에서 쓰인다. 예를 들어 공장, 물류센터, 본사 건물, 각 직영 판매장 등이 있다.

• Address, Language, Country 정보를 가진다.
• 하나의 회사 코드에만 매핑될 수 있다.
• 여러 storage location을 가질 수 있다.
• 여러 개의 shipping point를 가질 수 있다. 즉, Shipping point를 결정하는 데 사용된다.
• 여러 Distribution Chain에 매핑될 수 있다.
• Sales Order 생성 시 Deliverying plant(출고되는 plant)를 뜻한다.
• 재고 가용성 점검(ATP)에도 사용된다. 출고되는 plant를 뜻하므로 당연히 가용한 재고를 검사 수행의 단위가 된다.
• Material Master 데이터의 몇몇  view는 plant 레벨에서 생성된다.

2.3.2 Storage Location

Storage Location은 자재관리(MM)의 조직 단위로 여겨지며 항상 plant에 대해서 생성된다. 즉 plant 하위 조직 구조이다.

• 여러 개의 storage location이 하나의 plant에 매핑된다.
• Material Master 데이터의 몇몇  view는 storage location 레벨에서 생성된다.
• 하나 이상의 storage location이 같은 warehouse number의 매핑될 수 있다.
• 재고 실사(physical inventory)를 Storage Location 레벨에서 수행할 수 있다.
• 재고 평가(valuation)은 Storage Location 레벨에서 이루어질 수 없다. Plant 레벨에서 이루어진다.

2.3.3 Warehouse Number

WM 모듈 영역에서 사용된다. 재고 이동, 피킹, 패킹, 재고 최적화를 위한 조직 단위이다. Storage Location은 재고 저장을 위한 단위이다. 즉 WM 영역에서 사용하기 위한 조직 단위. 여러 Storage Location을 하나의 Warehouse에 매핑할 수 있다.  즉, Warehouse Number는 plant와 stroage location의 조합과 연결되는 개념이다. 

2.3.4 Shipping Point

Delivery Document를 생성하기 위해 요구되는 조직 단위이다. 이 조직 단위가 고객에게 가는 배송을 관리하는 기준이 되기 때문이다. 각각의 Delivery는 하나의 Shipping point에 의해 처리된다. 

• Shipping Point는 여러 plant에 매핑될 수 있다.
• Shipping(운송,배송)에 있어서 Shipping의 최상단 조직 구조이다.
• Delivery 문서의 모든 item은 같은 Shipping point를 갖는다.
• Sales Document에서는 item 레벨의 plant, loading group, shipping condition을 기반으로 결정된다.

복습문제

1. SD모듈 문서 흐름 (Material Document를 제외한 4개 문서 흐름) 작성하기.
2. Sales Order(영업주문)은 ________과 _______ 사이의 재화와 서비스 제공에 대해 가격, 수량, 시간에 대한 합의를 기록한 문서. 
3. Billing(대금청구)는 출고처리가 완료된 후 Sales Order와 Delivery 데이터를 근거로 송장(invoice)를 생성하여 고객에게 _______를 위해 생성하는 문서.
4. _____는 Database를 논리적으로 나눌 때 사용하는 단위이다. 
5. Sales Area = _______ + _______ + _______  
6. Sales Area의 3가지 요소를 간단하게 설명하면, "Sales Organization은 '___', Distribution Channel은 ' ___ ', Division은 ' ___ ' 파는가?"라고 할 수 있다.
7. __________는 SD모듈의 최상단 관리 기준점이 되므로 최대한 적은 가지 수로 편성하는 것이 좋다. 그래서 여러 Sales Org를 Company Code에 할당할 수 있지만 보통은 _____ 로 관리한다.
8. material이나 customer를 Sales Org 기준으로 구분할 수 있다. _____ -Sales Org. 마스터 데이터는 불가능하다. 즉, Sales Org.별로 마스터 데이터를 _____해야 한다.
9. Sales Org. + Dist Ch. 조합을 '___________'이라고 부른다.
10. 다른 회사 코드 아래의 Plant를 자신의 Distribution Chain에 매핑가능하다 ( O / X )
11. '무엇을'에 해당하는 Div(제품군)는 _________의 General(Basic) 데이터에 있다.
12. FI의 중요 요소인 _______를 결정하는 Rule에 Sales Area가 사용되는 경우가 잦다.
13. Sales Office와 Sales Group은 ______를 나타내는 중요한 역할을 맡을 수 있다.
14. Plant는 하나의 회사 코드에만 매핑될 수 있다. ( O / X )
15. Sales Order 생성 시 ______  plant(출고되는 plant)를 뜻한다.
16. ______ 는 Delivery Document를 생성하기 위해 요구되는 조직 단위이다. Shipping(운송,배송)에 있어서 Shipping의 최상단 조직 구조이다.

정답 및 해설

1. Sales Order - Delivery - Billing - Accounting Document. Accounting Document는 회계모듈 영역이지만 매출과 관련된 전표는 사실상 SD모듈에서 대부분의 내용이 정해지므로 SD모듈영역이라고 볼 수 있다.
2. Sales Organization, Sold-to-Party
3. 대금청구. 하지만 한국에서는 세금계산서가 대금청구 기능을 하는 경우가 많으므로 실제 기업의 활동에 있어서 대금청구 역할을 하는 것은 Billing 문서가 아닌 세금계산서이다. SAP내에서 한국 세금계산서 관련 기능이 따로 없으므로 주로 회계 문서와 연결점을 만든 CBO 오브젝트(테이블 등)를 생성하여 세금계산서 데이터를 관리한다.
4. Client
5. Sales Organization(영업 조직)+ Distribution Channel(유통채널) + Division(제품군)
6. 누가, 어떻게, 무엇을
7. Sales Organization, 1:1
8. cross, 확장(extend). SAP에서 데이터를 확장(extend)한다고 했을 때는 주로 General 정보만 있는 마스터 데이터를 모듈 고유의 데이터를 가지도록 확장한다는 뜻이다. 예를 들어 Material '1004002'의 Sales View를 확장한다는 말은 특정 Sales Area에 대해서 고유한 영업 관련 데이터를 가지도록 추가한다는 것이다. 
9. Distribution Chain
10. O
11. Material Master
12. Business Area
13. 매출 발생처
14. O
15. Deliverying
16. Shipping point

USR02 - 마지막 로그인 일자, 유저타입, 클래스, 잠금 여부 등 

USR06 - 사용자 유형(라이센스 타입)

USER_ADDR - 사용자 주소데이터(코스트센터, 부서 등)

CSKS  - 코스트 센터 정보

참고 URL

https://community.sap.com/t5/technology-blogs-by-members/difference-between-role-authorization-object-s-and-profile/ba-p/13537880

참고 문서

Analysis of Authorizations in SAP R/3 Untersuchung des Berechtigungskonzepts im SAP R/3 System
by Manuel Lamotte(2008)

Role, Profile, Authorization object 각각의 개념에 대하여

Role이란?

- SAP를 사용하는 USER가 시스템에서 특정 업무를 하기 위해서는 필요한 Role을 할당 받아야 한다.

- Role은 Profile을 생성하고 그 Profile 안 에는 여러 Authorization object가 있다.

- Role은 유저에게 권한을 부여하는 수단이다. Role을 사용자에게 부여하면 자동으로 Profile도 할당하게 된다.

Profile

- Profile은 권한 데이터를 저장하는 Object이다. Standard와 Generated 2가지 형태의 타입이 있다.

- Standard Profile은 유저에게 직접 부여가 가능하다.(역할에 독립적이다.)

- Generated Profile은 유저에게 부여하기 위해서는 Profile을 가지고 있는 역할을 부여해야 한다. 

A_ALL은 SAP에 미리 정의된 Standard 타입의 Profile이라 문제없이 독립적으로 부여되지만

T_BY690121 Profile은 SAP_AIO_COSTACC-S이라는 SAP가 가진 기본 Role에 딸린 Generated Profile이기 때문에 독립적으로 부여가 안된다.

Authorization(권한)이란?

- Authorization Object 에 의해 구별/식별된다( Authorization이 Authorization Object를 포함하고 있다.)

- Object class 는 권한 오브젝트 영역을 나타낸다.

- Authorization Object 는 최대 10개의 권한 필드로 이루어져 있다.

Profile이 여러 Authorization을 가질 수 있다. Authorization은 Authorization Object를 가진다.

- 위와 같이 한 profile에 여러 Authorization가 있는 경우에는 Union되어 권한 체크가 수행될 것이다. SAP의 권한 통제 방식은 access를 금지하는 것이 아니라 허용하는 것이기 때문이다. 

"Authorizations can only grant access to transactions/functions/data but they can’t forbid the access. Therefore, conflicts resulting from the union cannot occur because the union of access grants implies again access grants and never the denial to access something." - Analysis of Authorizations in SAP R/3 Untersuchung des Berechtigungskonzepts im SAP R/3 System
by Manuel Lamotte(2008)

- SU21 T-CODE에 들어가면 모든 Authorization Object를 볼 수 있다. 크게 Object class로 Authorization Object를 분류하고 있다. Authorization Object를 클릭하면 어떤 Authorization Field들이 들어있는 지 볼 수 있다.

- 위와 같이 관련 권한 필드들을 조회할 수 있다.

- 추가로 아래와 같이 Authorization Object에 필드가 없는 경우도 있다. 

- 자재 마스터 생성 Authorization Object를 보면 권한 필드에 일반적인 필드가 아니라 Dummy가 있다.

- 이는 권한을 필드로 통제하는 것이 아니라 권한 오브젝트 자체로 컨트롤한다는 의미이다. 따라서 profile이 이 Authorization Object를 담고 있느냐 아니냐에 따라 자재 생성 권한이 있느냐 없느냐가 갈리는 것이다. 

- SU24에서는 T-CODE에 필요한 Authorization Object들을 관리할 수 있다. 단점은 CBO로 만든 프로그램들은 권한 체크가 없는 경우가 대부분이다. 이런 경우 SU24에서 Custom T-CODE에 권한 오브젝트를 넣고 해당 프로그램의 소스코드에  

authority-check object 'V_VBAK_VKO' 과 같이 권한 점검 함수를 넣어주어야 한다.

- 권한 통제 목적으로 T-CODE와 Authorization Object를 따로 관리하고 싶다면 접근가능한 T-CODE를 위한 ROLE과 Authorization Object들을 모아놓은 ROLE을 서로 다른 명명규칙을 사용해 관리하면 되지 않을까 한다.

TODO : SU22와 SU24의 차이는 무엇인가 

 얼마전에 1년 간의 급여 대장을 조회하는 프로그램이 1시간이 지나도록 실행이 안되는 문제가 생겨 work process 런타임을 늘려달라는 요청이 왔음

RZ11에서 해당 파라미터를 수정할 수 있을 것 같아 찾아보니 rdisp/max_wprun_time 라는 변수를 조정하면 될 것이라 생각했다.

다만 런타임 변수를 시스템 재기동 없이 조정할 수 있을까에 대한 의문이 있었으나 RZ11에 매개변수 정보에는 동적으로 변경할 수 있는 지 없는 지 여부를 나타내는 필드가 있었다.

Can be changed dynamically.

If this field is selected, the value of the parameter can be changed dynamically, while the system is running.

-> SAP 도움말은 이 컬럼이 선택되어 있으면 파라미터가 시스템이 동작하는 중에도 동적으로 변경가능하다고 한다.

For all servers :

If this field is selected, the check will get the value of the parameter on every server and check whether the values are the same.

-> 그 밑의 필드는 CI와 DI 모두를 한 번에 적용할 것 인지 여부를 체크하는 필드인 듯 하다. 일단은 체크하지 않고 CI와 DI각각 변경해주었다.

Default value

Default value of the parameter as defined in the kernel or default.pfl.

-> 커널 레벨(운영체제)에서 정의된 파라미터 기본값이거나 프로파일 기본값

Profile value

Value of the parameter as defined in the instance profile. If the parameter is not defined in the instance profile, the default value is used.

-> 인스턴스 프로파일에 지정된 값(RZ10에서 정의)

Current value

Parameter value currently used by the system. The value can change while the system is running. (See "Can be changed dynamically)

-> 시스템이 현재 사용중인 값. 변경 가능한 경우 동적으로 변경할 수 있음

*EASY ABAP설명

T-CODE - RSPFPAR 에서 프로파일 매개변수를 조회할 수 있음

아래는 time 관련 변수들 조회한 것

profile 파일은

AL11에 들어가거나 OS 레벨에서

/usr/sap/SID/SYS/profile 경로에서 볼 수 있다.