✔ 3.1 Document Flow (문서흐름)
3.1.1 Document Flow Overview
SD 모듈은 Initial Customer Inquiry Processing (고객문의처리) 으로부터 시작하여 quotation(견적), sales order(판매문서), shipping(납품), billing(빌링, 대금청구문서) 등의 단계를 수행하며, 이러한 Business Transaction은 시스템 문서의 형태로 표시된다.
Sales Activity(판매활동), inquiry(문의), quotation(견적), order(주문), delivery(납품), billing document(대금청구 문서)는 각각 해당 transaction과 관련된 모든 정보가 기록되어있다.
SD 모듈의 Business Transaction의 일반적인 흐름은 다음과 같다.
① 영업사원이 정기적으로 고객을 방문하고 그 방문 결과를 Sales Activity Document에 기록한다.
이러한 고객 방문의 결과로 고객으로부터 문의(inquiry)가 생성되고 고객이 제시된 Quotaton을 수락하면
지정된 일자까지 납품이 되도록 Sales Order를 작성한다.
② 제품이 가용한 날짜를 맞춰 적합한 운송수단을 수배하고 일정계획을 수립해 제품을 출고시킨다.
이 단계에서 Materal Management와 Accounting 모듈에서 재고 수량과 금액이 조정된다.
③ 출하된 제품내역을 기초로 하여 고객에게 대금을 청구하고 이에 대한 데이터를 회계에 넘겨 외상매출금을 기표한다.
이러한 전체 프로세스는 시스템에서 각 단계별로 서로 다른 문서로 생성되어 처리된다.
현재 근무중인 회사에서는 SAP에 영업사원이 응대내역이나 문의 등을 따로 기록하지않고, 레거시 시스템을 통하여 기록하는 기능이 구축되어있다. SAP와 연동되어 정보를 굳이 가져오지는않는다. 아마 개인정보관리 등을 위하여 그런것으로 보인다.
그리고 주문(Sales Order)도 영업사원이 SAP에서 직접 넣을수도있지만 주문시스템이 구축되어있어 해당 시스템에서 주문을 하면 INTERFACE(인터페이스)를 통해 주문이 들어오는 방식이다.
주문을 하는 고객이 직접 주문을 넣기 때문에 요청과 다른 주문이 들어갔다는 문의가 최소화 될 수 있다.
3.1.2 Document Flow의 기능 (문서흐름)
Document Flow를 조회하여 해당 Business Transaction에 대하여 어떤 선행문서 및 후속문서가 생성되었는지를 확인할 수 있다.
예를 들어 Sales Order가 어떤 Quotation을 참조하여 생성되었는지, 혹은 어떤 Sales Order를 참조해 어떤 Delivery Note가 생성 되었는지를 확인할 수 있다.
✔ 3.2 SD의 Interface
위에서 말한 레거시 연동과 비슷한 맥락으로 SD모듈은 다른 모듈과 유기적인 관계를 가지면서 통합적 운용된다.
3.2.1 MM(구매)/PP(생산) Interface
Sales Order 생성 시 시스템은 가용성점검(Availability Check)을 수행한다.
이때 현재 가용한 제품의 수량은 MM모듈로부터 데이터를 가져오게 된다.
On-hand stock(보유재고)이 고객이 요구한 수량보다 적은경우 구매오더나 생산오더를 위한 Requirement(요청)를 생성하게 된다.
구매를 하는경우,
Sales Order를 통해 Purchase Requestion(구매 요청)을 생성하고 MM 모듈과의 Interface가 발생한다.
생산을 하는경우,
Sales Order를 통해 생성된 Requirement가 PP모듈의 MRP에 반영되어 생산이 일어나고 PP 모듈과 Interface가 발생한다.
SD Shipping Process를 수행하여 제품이 출고(Goods Issue)된 경우 MM과의 Interface가 발생한다.
3.2.2 FI(재무회계) / CO(관리회계) Interface
SD Billing Process를 수행하는 경우,
매출금액에 대해 FI 모듈과의 Interface가 발생한다.
Sales와 Shipping, Billing process가 수행되는 동안 매출원가에 대해 CO 모듈과의 Interface가 발생한다.
✔ 3.3 SD Document Structure
각 Sales Document는 하나의 Header와 하나 이상의 Item으로 구성된다.
하나의 Item은 하나 이상의 Schedule Line(일정라인)을 가질 수 있다.
3.3.1 Document Header (문서헤더)
Document Haeder에는 문서 전체에 적용되는 일반적인 데이터가 기록된다.
Header Data에는 다음과 같은 것들이 있다.
항목 | 의미 |
Sold-to Party | 판매처 |
PO date | 구매 오더일 |
PO number | 구매오더번호 |
Payment terms | 지급조건 |
Inco Terms | 인코텀스, 무역거래조건 |
Texts | 텍스트, 메모, 고객전달사항 |
Sales Area | 판매구역 |
Header Business Data | 사업영역 등 |
Header Condition | 조건 |
Partner | 파트너 |
Etc. | 기타 |
3.3.2 Document Items
Document Item에는 고객이 주문한 제품 및 서비스에 대한 데이터가 기록된다.
Item Data에는 다음과 같은 것들이 있다.
항목 | 의미 |
Item Number | 품목 번호 |
Material Number | 자재 번호 |
Material Quantity | 자재 수량 |
Item condition | 상태 |
Item business data | 구조 |
Item Payment terms | 지급조건 |
Item incoterms | 인코텀스 |
Item Partner | 파트너 |
Etc. | 기타 |
Item Level의 데이터는 특정 Order Item이 특별한 조건을 제공하는 경우 Header Level의 데이터와 달라질 수 있다.
또한 Header Level과 Item Level의 데이터가 항상 같도록 Customizing 할 수도 있다.
3.3.3 Schedule Lines ( 일정라인 )
Sales Document의 각 Item은 여러개의 Schedule Line을 가질 수 있으며,
각 Schedule Line은 그에 해당하는 수량과 납품일자를 가진다.
Schedule Line에서는 출하 및 조달에 관련된 데이터를 기록하게 된다.
✔ 3.4 Sales Document의 Control
3.4.1 Sales Document Type
각 Sales Document는 특정 Business Transaction Type의 요구사항을 만족시키기 위해 정의된 기능들을 가지고 있다.
아래 그림은 Sales Document Type이 가지는 기능들을 보여준다.
Sales Document Type을 이용해 다음의 사항을 제어할 수 있다.
- If a customer material information record exists, is it to be taken into account?
: 고객 중요 정보가 존재하는 경우 이를 고려해야하는가?
- Is a delivery date to be proposed automatically in the document?
: 문서에 납품일이 자동으로 제안 되는가?
- Is a credit limit check to be carried out?
: 신용한도 조회가 이루어지는가?
- Is delivery scheduling to be carried out?
: 납품에 대한 예약이 진행 되는가?
- Is transportation scheduling to be carried out?
: 운송 일정이 잡혀있는가?
- From which number range is the document number to be selected?
: 선택할 문서 번호는 어느 번호 범위에서 선택되는가?
3.4.2 Sales Document의 Item Category
Business transaction type별로 sales order, delivery의 item에 대한 item category를 다르게 정의할 수 있다.
이러한 item category를 사용함으로써 다양한 business transaction type에 대한 세밀한 관리가 가능하게 된다.
Item category를 이용하여, item에 대해 pricing을 수행할 것인지, 가용성점검이 필요한지, 납품 가능한 item인지 여부를 item의 종류를 토대로 시스템이 결정한다.
Item category을 이용해 다음의 사항을 제어할 수 있다.
- Does an item refer to a material, or is it a pure value item, or text item?
: 항목이 제품을 참조하는지, 아니면 제품 자체인지, 아니면 텍스트항목인지?
- Is the item included in pricing?
: 제품의 가격을 포함하는지?
- Is an item relevant for delivery?
: 배송과 관련된 제품인지?
- Is billing to be carried out for an item?
: 제품에 대금청구가 이루어지는지?
- Is a billing block to be set automatically for the item for credit or debit memo requests, for example?
: 예를들어, 대변 또는 차변 메모요청 항목에 대해 대금청구에 대한 보류가 자동으로 설정 되는지?
- Are schedules lines permitted for an item?
: 제품에 대한 일정라인이 허용 되는지?
3.4.3 Shipping Document의 Item Category
Shipping document에서의 item category는 다음의 사항들을 제어하기 위해 사용된다.
- Is the system to check whether the minimum quantity for an item has been reached?
: 제품의 최소 수량 여부를 확인하는 시스템인지?
- Is the system to check whether overdelivery is permitted for the item?
: 제품의 초과배송 허용여부를 확인하는 시스템인지?
- Is an availability check to be carried out?
: 가용성 확인이 수행 되는지?
- Is the item relevant for item의 item category와 해당 picking?
: 품목의 품목 카테고리와 해당 피킹과 관련된 품목인지?
- Is a storage location to be specified?
: 저장위치를 지정해야하는지?
✔ 3.5 Incompletion Log ( 미완료 로그 )
Sales order를 저장했을 때 시스템은 sales document type에 의해 미리 지정된 incompletion procedure를 체크한다.
예를 들어 quotation을 저장하는 경우, 해당 sales document가 complete한 경우에만 문서를 정상적으로 저장할 수 있게 된다.
만약, 문서가 complete한 상태로 저장되지 못한 경우에는 해당 quotation을 참조하여 후속 문서인 sales order를 생성할 수 없게 된다.
위 그림은 sales order를 생성하는 단계에서 Purchase order 번호와 route가 입력되지 않았다.
이때 문서를 저장하려하면 incompletion log가 화면에 나타나 미 입력된 사항을 알려 준다.
Log 화면을 참조하여 정상적으로 화면에 입력을 마치면 sales order는 저장되어진다.
'SAP > SD' 카테고리의 다른 글
[SAP/SD] 빌링 - 6장. 빌링문서 (2) | 2024.09.24 |
---|---|
[SAP/SD] 납품 - 5장. 납품문서 (1) | 2024.09.24 |
[SAP/SD] 판매 - 4장. 영업문서의 기능 (2) | 2024.09.19 |
[SAP/SD] 조직 - 2장. 마스터데이터 (2) | 2024.09.06 |
[SAP/SD] 조직 - 1장. 영업조직구조 (2) | 2024.09.04 |