Order type 配置裡的溝溝坎坎

Sales Document Type configuration detailed illustration.

[@more@]

1. Sales Document Block:控制這個檔案型別是否已經被凍結。有三個選擇，如果該欄位為空則表明這個檔案型別沒有被凍結，如果為A，則表明這個訂單型別只能被自動建立，例如回扣的處理，如果選擇為X，表明這個檔案型別已經被凍結而不能再用了。
2. Sales Document Indicator: “只和表TVAK有關”，標準訂單型別中該欄位不為空的是：
LZM (SchedAgrt w/Dly Ord.) C
MAKO (Dely order correctn) E
RA (Repair Request) F
RAS (Repairs / Service) G
RK (Invoice correct. req) D
TAM (Delivery order) B
3. No.range int.assign: 確定該檔案型別的內部號碼段
4. No.gange ext.assign: 確定該檔案型別的外部號碼段
5. Item no.increment:行專案編號的增加量
6. Sub-item no.increment: 子專案編號增加量。
7. Reference mandatory: 強制參考。如果檔案型別對這點進行了配置，在建立銷售訂單時，系統會彈出視窗強制要求輸入參考號碼，並且指定是參考號碼的型別，如參考報價單，參考詢價單，參考銷售訂單等等。
8. Check division: 配置檢查訂單中行專案產品組和抬頭產品組不同時的資訊型別，如果這個設定為空則沒有資訊出現，如果為1，則有對話資訊出現，如果為2則有錯誤資訊出現，表明該檔案型別抬頭的產品組要和行專案的一致。
9. Material entry type: 物料輸入型別，如果這個欄位為空則一定要輸入物料號，“A”或“B”選項應猜想該是透過產品目錄等手段選取物料。
10. Item division: 決定訂單ITEM中的DIVISION的來源。如果這個選項打上勾，則表明ITEM的DIVISION是來自MATERIAL MASTER，如果不打上則來自訂單的抬頭。這一點和CHECK DIVISION構成了cross-division sales的配置點。
11. Probability: 用來確定成為訂單的可能性。這一個配置，對於訂單來說預設為100%並且不可更改，而對於詢價或者報價來說，系統都根據訂單型別的category來；預設了一個可能性，但這個可能性可以更改（在SD DOCUMENT裡）。這一個設定也決定了系統如何傳遞物料的需求。例如一個報價單的型別為QT，在建立報價單時物料A的淨價值是100USD並且Probability為50，而物料B的淨價值為200USD並且Probability為25%，因此整個報價單成為訂單的可能性為：
（100 * 50% + 200 * 25%） / （100 + 200） = 50%
如果物料A的Probability為50%，則報價中的100個A物料會產生50個需求量
在建立報價單時，系統也會把客戶主資料中的可能性考慮在內（見SOLD-TO PARTY客戶主資料中的SALES AREA DATA - Order probability of the item）。如果該訂單型別的可能性設為50，而客戶主資料的為80，則在建立報價單時，行專案的可能性為80 / 2 = 40，表明該報價單有40%的機會成為訂單。
12. Read info record：如果這個選項選定，則建立訂單時會讀取customer-material （TCODE：VD51）的資料。
13. Check credit limit:信用檢查。用來控制系統是否進行信用檢查和對檢查結果作出什麼樣的反應。這裡的選項有五個：
1/沒有進行信用度檢查
2/進行簡單的信用檢查並對超出信用額度顯示警告資訊
3/進行簡單的信用檢查並且對超過信用額度顯示錯誤資訊
4/進行簡單的信用檢查，如果超過信用額度則凍結交貨
5/如果系統實行信用管理，則自動執行相應的信用控制
自動的信用檢查具有不同的檢查方法，例如動態信用檢查和靜態信用檢查，或基於最大的訂單價值檢查。在動態檢查和表態檢查中，信用狀態是所有open orderopen deliveryopen 的應收款來統計出來的。如果需要執行自動信用控制，則在訂單型別裡選擇D.
對於簡單的信用檢查，系統用信用狀態和付款方的信用額度作比較。信用狀態是從所有open item的淨價值統計來的。
14. Credit group: 信用組。定義該檔案型別是屬於那個信用組的。這一個配置使你能夠根據信用組合並不同的檔案型別，從而使得信用管理更加有效。（固有三個選項：SO, DLV, PGI）
15. Check purch.order no： 檢查客戶的採購訂單是不是已經在其他的訂單中存在，如果是則有警告資訊出現。
16. Enter po nmber：用來配置訂單是否需要輸入客戶採購訂單號碼.
17. Output application： 輸出相關的應用程式分類，銷售訂單類的是V1。
18. Commitment date: 作用不明白
19. Screen sequence grp:用來定義該檔案型別的螢幕順序。
20. Display range: 定義行專案顯示方式。
21. Incomplete procedure: 定義當相應的SD檔案有些資料沒有輸入的時候系統的處理辦法。這個配置在檔案裡型裡是不能更改的，因為在basic function-log of incomplete item（VUA2）裡已經做了配置了。
22. FCode for overv.scn: 設定進入顯示憑證介面時的VIEW。如，選擇了UBST後，在顯示銷售訂單時，一走入去看到的就是ordering party這個VIEW。
23. Transaction group:定義這個檔案型別是那一種業務（報價，詢價或銷售訂單）。例如OR的transaction group是0，屬於訂單，因此只能用VA01來建立這型別的檔案，而QT是屬於2的，報價單型別，因而只能用VA21來建立。
24. Quotation message: 配置報價單和銷售訂單之間資料是如何檢查的。有下面幾個選擇
1/不檢查
2/在抬頭層面進行檢查，在建立銷售訂單時，系統檢查報價單，如果發現要抬頭資訊相同的報價單出現則會報資訊告訴使用者有報價單存在。抬頭資訊是指銷售區域、sold-to party, ship-to party, po等。
3/在行專案層面檢查。除了上面抬頭資訊外，也檢查訂單中的物料號是否和報價單的相同。
4/在抬頭層面檢查，如果發現唯一一個相同的則直接把報價單COPY過來。
5/在行專案上層面檢查，如果發現唯一的則直接把報價單COPY過來
6/在抬頭層面上檢查，如果發現多個則顯示一個LIST讓使用者選擇，如果只有一個則和上面第4點一樣。
7/在行專案上檢查，如果發現多個報價單則顯示一個LIST讓使用者選擇，如果只有一個則和上面第5點一樣。
25. Doc.pric. procedure:檔案的價格流程。任何一個銷售區域都要設定一個定價過程（可以在檢視t683v裡看到每個銷售區域的定價過程）。在建立訂單時，如果系統發現這個地方的配置和t683v不一樣，則會報錯誤資訊：No pricing producer could be determined.T683V可以在sales—sales document – contract –define and assign pricing procedure for value contract裡配置。
26. Outline agreement message: 和Quotation message大致一樣。但這兩個檢查點要一樣，因為系統會把Outline agreement message和Quotation message作為一個combination來看的。
27. Add ref. to all contracts partner is authorized to release：用來搜尋所有的合同。
28. Status Profile: 狀態檔案，用以自定義訂單狀態。
29. Message mast.contr.: 大概是在建立CONTRACT的時候控制對現有合同的查詢和比照用的。
30. Prodatt.message: 檢查錄入物料能否被ship-to接受，如可能是某種違禁品之神馬的，僅對手工錄入物料時做檢查。
31. Alternative sales document type 1 / Alternative sales document type 2：在檔案的處理中可能會會改變一些檔案的檔案型別。這個配置點這是作為更改檔案型別的限制條件。詳細的看F1。
32. Incomplete message:選中後，即不能儲存不完整的單據。
33. Variant: 設定Transaction variant變式.
34. Corr.delevery type: Delivery type for correction deliveries for scheduling agreement.
35. Delivery block: 在scheduling agreement的容差檢查中如果不透過則打上該凍結.
36. Use:物料的用途，只作用於scheduling agreement.
37. MRP for DelSch Type: 定義交貨計劃與MRP的相關性。
38. Delivery type: 運送型別
39. Immediate delivery: 馬上運送。有三個選項：
1/訂單和運貨單分開建立
2/訂單和運貨單同時建立
3/訂單和運貨單同時建立，但前提條件是送貨時間是當天
40. Delivery block: 預設凍結運送。
41. Shipping condition:預設運送條件，優先順序高於客戶主記錄裡的。
42. Shipcostinfoprofile: shipment cost 相關預設引數，如裝運計劃點，運費定價過程等。
43. Dlv-rel billing type:配置和運貨相關的發票型別（發票參考運送單）
44. Cndtype for line item: Condition type for copying costs from line items。
45. Order-rel.bill. type:：和訂單相關的發票型別（發票參考銷售單）
46. Billing plan type:發票計劃型別。分為定期性開票和milestone開票。定期性是指一些租金或者維護收入的發票，而milestone是指一些開票專案，例如和客戶訂立年度的銷售專案，半年時付40%，結束時付60%。
47. Intercomp.bill.type:公司間發票型別
48. Payment guarantee procedure: 付款程式監督。用來定義用那一個程式來監督付款。和Receivables risk management相關。
49. Billing block:預設開票凍結。
50. Payment card plan type:其作用不清楚。但凡是用到付款卡結帳的檔案型別，都需要定義這個配置，否則不對用卡結帳。
51. Checking group:付款卡檢查組。
52. Lead time in dates: 設定request delivery date比現在的天數多幾天。例如今天是20060118，如果這個設定為20的話，那麼系統會把request delivery date自動預設為20060215.
53. Propose delivery date: 定義系統是否建議一個運送時間request delivery date。如果打上勾則會根據Lead time in dates這個來建議一個時間，否則建立訂單時要人手輸入運送時間。
54. Propose po date:打上勾則系統會預設建淡今天是PO日期
55. Date type: 時間型別
56. Prop.f.pricing date:系統預設一個pricing date，但可以人手在訂單裡更改。
57. Propose valid-date: 定義該檔案生效的日期。有三個選擇：
1/不建議
2/建議今天
3/建議下個月第一天
58. PricProcCondHeader:定義CONTRACT的抬頭定價條件
59. PricProcCondItem: 定義CONTRACT的行專案定價條件
60. Contract data allowed:決定CONTRACT HEADER和資料會不會COPY到ITEM上。
61. Followup activity: 跟進動作的類別。定義屬於這類檔案型別的合同其後續動作是什麼，例如一個租金合同，後續動作可能是一個銷售信件等。Followup activity可以在CAS裡進行相應配置。
62. Contract profile: 合同的形式，包含部分預設值。
63. Subseq.order type:後續銷售訂單型別
64. Billing request:要求的發票型別
65. Check partner auth.: 檢查一個PARTNER是否有資格成為一個RELEASED CONTRACT的PARTNER。當你在釋放一個合同時，系統會檢查這個合同裡的PARTNER有沒有資格成為一個SOLD-TO PARTY。
66. Update lower level contract:更新低階合同
67. Group reference procedure:資料從主合同（MASTER CONTRACT）複製到層次較低的合同時的複製程式
68. Business transaction:和APO相關的ATP檢查