[암기로 시작하는 SAP SD] - 1강. Organizational Structure(조직 구조)

머리말

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 모듈은 아래 문서들을 발생시키기 위한 기능들의 집합이라고 할  수 있다.

간소화한 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 과정에서 생성된다.

728x90

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

2.1 SAP의 기본 조직 구조 - Client

Client와 Company Code

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

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

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

VBAK

TADIR

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

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

출처 https://help.sap.com/docs/

위 그림은 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에 하위에 속한다. 

Company Code Basic Data

*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의 마지막 레벨이다.

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를 통해 설정할 수 있다.

SD모듈의 BA 결정 IMG 메뉴

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