Sales Document Type configuration detailed illustration.

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检查