第五章 内部订单(最全)word资料

第五章内部订单
ERP中内部订单用来规集费用,费用控制,成本分析等,其主要功能包括：
（1）.预算功能:可使用ERP的内部订单(或PS项目模块)监控企业包括支出预算结算等投资活动,预算功能也常用于粗略地控制部门的一般管理费用，用户可以方便地增加减少预算额度, 如果采用跨年度预算，系统可以方便地将当年预算余额结转到下年（预算结转-）Tcode:KOCO，承诺结转->Tcode:KOCF)。

（2）.计划功能:内部订单的费用成本计划功能可和MM模块和生产能力计划集成,用于监视实际成本并和实际成本对比分析，从而为管理决策者提供依据。

（3）.分析功能: 可以随时分析内部订单的计划/实际发生额对比,各不同期间的实际/实际对比,按月/季指标分析,分析内部订单发生的行项目,对订单的未清项等进行分析。

( 4 ). 期末处理：可将日常内部订单规集的成本费用在期末进行重分配(Tcode:KSW1/KSW5)或结算(Tcode:KO88)到目标成本对象,这些成本对象包括订单/项目/成本中心/网络/资产/Co-PA的获利段/费用科目等。

内部订单应用非常简单,下面先谈谈订单主数据的建立。

第一节订单主数据
内部订单主数据配置如图1。

图1-[1]：激活订单管理(Tcode:OKKP)
想使用内部订单功能,需要在OKKP在控制范围内将内部订单模块激活。

图1-[2]：定义订单类型(Tcode: KOT2|KOT2-OPA|KOT2_FUNCAREA)
在此定义所需要的订单类型。

图2-[1]：系统提供的订单种类（Order Category）包括内部订单，CO成本订单，成本收集器，质量订单，PP生产工单，流程订单，PM维护订单等，订单种类由系
统预选设定，订单种类用来组织订单的业务功能，在下面会详细分析。

图2-[2]：需要建立什么样的订单类型（Order Type）视企业实际需求而定，图2-2设置了资产/在建工程的投资订单类型，一般费用统计订单，可结算的实际费用订
单和专门的维修费用统计订单。

订单类型的作用有：
1．号码分配，可给不同的订单分配不同的编号范围，可以使用无意义的外部编号也可使用有意义的外部给号，比如投资订单外部编号可在其中包含项目号，
维修费用统计订单分大检修和日常普通维修，一个外部给号分别为DX/PX+
成本中心号，费用计入相应的成本中心同时输入维修费用统计订单做统计用
以此来区分费用归属，统计性订单此时就成了一个类似中国会计上的辅助核
算字段，这样从编号就能直接分辨出费用归属。

2．通过订单类型参数控制该类订单是否允许计划，允许预算，是否允许计入收入，允许状态控制等，请看图3，在图3中详细描述了这些控制字段。

记住三个重要术语：
1．对象种类/类型（Object Category/Object Type）
系统将状态管理中有相似处理功能的对象组合在一起，叫Object Categor或Object Type，请看Tcode：BS12。

2．订单种类（Order Category）
订单种类算是对象种类的一种，下图是BS12和KOT2的一个合成图，可看到的右边是KOT2的订单种类（Order Category）01/02到70，分别对应BS12中的对象种类/类型（Object Category/Object Type）ORC/ORD/ORF/ORG等，双击BS12，就能为每个订单类型分配允许的业务交易状态，在接下来还会就此问题详细阐述。

3．订单类型（Order Type）
订单类型有自己的编号和控制参数，用来区分出内部订单的实际用途。

这3者关系是，系统默定了对象种类，订单种类是其中一种，对象种类可控制该对象是否允许什么业务交易，系统都有一定的默认设置，除非特殊需求，一般并不建议修改，比如系统默认不允许使用分摊循环将费用分摊到目标对象CO 订单（Tcode：KKF1建立），这样需要BS12设置对象种类ORF允许业务交易RKIU。

4．对象类（Object Class）
对象类也用来根据业务交易来组织成本对象并分析成本流，对象类有四种：
INVST:投资/OCOST:间接费用/PRODT:生产/PROFT:利润分析
在内部订单主数据中可选择一个内部订单的对象类，我们知道在CO模块常用的成本对象包括内部订单,成本中心,获利分析段,WBS元素等,象成本中心这个对象默认就属于对象类OCOST:间接费用。

你看到Object Category，Order Category， Order Type， Object Class这些术语一定会想起Valuation Level，Valuation Category， Valuation Area， Valuation Class，有了这些术语ERP系统才能答建的庞大从而实现强大的功能，这种设计理念是这样的：固化订单种类（Order Category）的情况下，实际上也就固化了订单的业务处理逻辑，但是，为了迎合各企业的复杂流程下，允许自配置一定的订单类型（Order type），在其中再定义一些参数，实际上，整个ERP的配置逻辑大抵如此而已。

图3是订单类型定义的一个画面。

图3-[1]：设置订单编号（Tcode：KONK），可为外部或内部编号。

图3-[2][3][4]：注意订单的几个profille:
settlement profile：订单的结算参数文件，可控制该订单是否允许结算，允许结
算接受方的个数，允许结算到何种目标成本对象，详细请参
考相关章节。

planning profile：控制订单的计划参数。

budget profile：控制订单的预算参数设置。

status profile：控制订单的状态，可用来做订单的审批流程。

图3-[5]：表示订单的数据保存多久后才能被archive。

图3-[7]：如果选上，则表示允许post 收入/销售抵扣要素(cost element category 11/12), 和成本中心一样，系统默认是不允许过帐收入要素的，比如某生产企业使用内部
订单归集企业的非主营生产业务，该内部订单将同时归集其它业务收入（收入）
和配比其他业务支出或成本，就需要选上允许收入过帐。

图3-[8]:状态参数文件可用来做订单的审批流程，请参考接下来的第二节订单审批。

图3-[9]:表示订单一建立就被release,订单如果没有释放是不能用于记帐的,有的企业不喜欢玩审批，有的企业却喜欢整审批，特别是预算订单，一般不整个3-5级审批那
是死不罢休，哎，企业多了，什么样的鸟儿都有，如你想使用订单审批流程,当然
这勾就不选上。

图3-[12]：你可定义个print form打印订单。

图3-[13]：屏幕字段选择,和会计科目的字段状态组(Tcode:OBC4),记帐码字段状态(Tcode:OB41)或移动类型字段状态(Tcode:OMJJ),你决定订单主数据的字段是隐藏,显示,可输还是必输。

图3-[14]：可为某类型订单设置一个默认的功能范围，比如为CO成本订单设置默认的“生产成本“功能范围，以免用户输入错误。

图3-[15]:在“Model Order“栏可输入一个模板订单,这个订单起参考作用也可是普通的内部订单,这样在新建立此订单类型的订单时可将此模板订单的主数据字段复制到
新订单,即类似参考建立。

图4-[1][2]:将统计性订单的统计指标设置为必输,选上高亮则表示默认在主数据里选上。

图1-[3]维护订单编号范围(Tcode:KONK)
维护订单的编号范围，可以是外部编号，也可以是内部编号，可以走菜单->传输传输编号。

图1-[4][5][6][7]：订单审批配置，详细请看第二节。

内部订单使用实例
在前面已经介绍过内部订单模块功能，下面举几个实例说明如何使用内部订单
1．实际费用归集
和成本中心通常用来归集部门发生的费用不同，（实际）内部订单通常用来归集某个专项的费用，这个专项可以是公司的一次春游，一次年会甚至某个建设项目，通常这个专项是跨成本中心的，比如年会，可以建立一实际内部订单，可以将组织这次年会所有的费用全部记入该内部订单，在期末根据一定规则再结算到成本中心，同样也可将各项费用计入一个项目订单，待项目完成后在统一结算至各个资产。

在一个ERP项目中，项目组有30多个成本中心，职工薪酬差旅费等从HR自动过帐，还有些劳保费用，期末需要将这些成本中心的费用按照职工薪酬资产业务类型，差旅费资产业务类型等转入待摊以便统计资产的各项费用（使用资产业务类型做统计），如果需要将这30多个成本中心一一转平，工作量大，所以事先使用分配将30多个成本中心的各项费用先分配到一实际内部订单，再从内部订单统一根据各中资产业务类型转走费用（注意，兼顾报表需求，暂时不能使用结算功能结算到资产，因为结算只使用一个资产类型），工作量减少30倍。

2．辅助核算和统计过帐
内部订单的统计过帐实质上就是使用内部订单做辅助核算，和国内ERP不同的是，国外ERP 的成本对象实际上是扩展了的辅助核算，常用的成本对象有成本中心，内部订单，WBS元素，实际上类似3个辅助核算项目，再加上客户/供应商/物料随时可在字段状态组放开从而在记帐上选择，一般核算到这份上也就可以，我在相关章节已经讨论过成本对象和辅助核算的区别，系统中永远只有一个实际过帐的成本对象，当存在多个成本对象时，系统预先设置了
一个优先级，最典型的，如果某费用同时计入成本中心和内部订单，如果内部订单是实际的，则成本中心为统计过帐，如果内部是统计性的，则成本中心实际过帐，这样的最大好出是费用结算非常方便，例如成本中心的实际费用可以非常方便结转到其它成本中心。

内部订单建立非常灵活，比如，在ERP中，除了将员工建立成特别供应商/客户外，你甚至可将某些员工一一对应到一个内部订单。

如果不实施PP或不想使用BOM（有的企业需要配方保密，那就索性不使用BOM）的企业，可将各项目费用计入成本中心，期末将制造费用辅助生产成本中心费用结转到基本生产成本中心，最后再将各种费用按一定系数分摊到各产成品的工单。

重点：
I. 只设一个实际过帐对象,设计思路将非常简洁明了,费用结转方便.
II.其它辅助核算字段说白了只是做费用统计方便管理和报表需求而已，惜乎，很多系统将辅助核算字段实际上做成了“明细”科目，有这样的系统有理由相信在费用的分配分摊结算重过帐功能上可能就会大打折扣。

启示：ERP中科目只设一级，只有一个实际过帐成本对象，允许多个统计对象，ERP不是财务软件，在遵守会计准则的条件下，科目只是个记帐符号。

3．项目预算控制
同样，可以使用内部订单做粗略的整体预算控制功能，比如为每个项目建立一内部订单并给予预算就能控制该项目的整体预算，这种预算控制一般不到科目级别，ERP有专门的预算控制模块处理这些业务，请参考本书相关章节。

第二节订单审批
下面介绍如何使用状态参数文件做内部订单的审批，实际上包括使用状态参数的销售订单等各种订单的审批也可使用该功能，为了让读者更明白步骤，采用我一贯常用的分步法说明。

第一步：定义状态主文件(Tcode:OK02|BS02)
如图1,定义Status profile Z0000002，在状态文件中可定义各种用户状态。

业务背景：
假设内部订单必须经过STONE审批->接下来再经过部门经理审批->最后是总经理审批后才允许实际过帐。

图1-[2][3]:状态编号（Status no.）和状态名称，你也可使用无状态编号定义用户状态。

图1-[3]：根据业务需求建立4个用户状态分别是图1-[3]的RINT/REST/REJL/ RELZ。

图1-[4]：如果选上“Init.Status”标志则表示订单一建立的初始状态。

图1-[5]:可以为每个用户状态定义所谓的最高状态编号和最低状态编号（Lowest status no./Highest status no.）。

图1-[6]：定义了用户状态显示的位置排序位置和Priority,'位置'指定一个状态应显示在在状态行中的那个位置。

如果在同一个位置应显示几个活动状态，那么只显示具
有最高"优先级"的状态。

如果用户状态使用了状态编号，则位置（Position）和
Priority都是1。

图1-[7]：可定义每个用户状态的授权权码(Authorization key）, 授权码由Tcode：BS52建立,这样在设置内部订单状态操作的权限对象 B_USERSTAT 通过授权码进一步
控制用户修改订单状态从而达到审批目的。

图1-[8]：如过你是新建一个status profile，而非copy SAP default的比如00000001,就需要点击“Object Type“（Object Type/Object Category/Order
Category/Order type在本章第一节订单主数据中已详细描述过）选上允许
内部订单使用该状态文件，如接下来的图2，实际上如果是Copy Status Profile
00000001则允许内部订单使用标志也被Copy了，所以才不用在次设置。

图1-[9]：定义好状态参数文件Z0000002后，使用Tcode：KOT2_OPA_STSMA|KOT2将它分配给某订单类型后，在建立新订单，将出现图1-[9]画面，可以看到设置的4个用
户状态，注意标题“Status with status no.”字样。

图2-[2]：可以看到所有的对象类型（Object Type），在第一节说了使用BS12可为每个对象类型定义允许的业务交易，在这里为对象类型定义允许的用户状态,系统状态是
ERP系统里预先内置的用来决定允许操作那些业务交易，自定义的用户状态同样是
用来决定所允许的业务交易。

回顾状态参数文件的几个概念：
1.系统状态(System Status)
系统预置的状态,预置的系统状态通常以字母I开头的5位码，使用Tcode：BS32可
以查看业务交易和系统状态的关系。

2.用户状态（User Status）
使用自定义的用户状态灵活决定该状态下所允许的业务交易。

无论是系统状态还是用户状态都和业务交易控制相关。

3.状态编号/无状态编号（Status no.| W/o Status no.）
用户参数文件中定义的用户状态也可使用状态编号或状态编号。

4. 最高状态编号/最低状态编号(Highest status no./ Lowest status no.）
状态编号用来控制状态的变更,最低状态编号和最高状态编号实际上控制着该状态
行允许变更的用户状态范围，注意下面几个原则：
I.最低状态编号不能大于大于该行的状态编号，同样最高状态编号不能小于该的状
态编号，如下图状态编号3 REJL的最低编号不能是4。

II.状态编号也控制着用户状态的变更,如下图状态编号4 REJL的最低状态编号和最高状态编号2和4,假设现在到了状态4->总经理审批,总经理觉得该订单有问题
应该重审,因为最低状态编号和最高状态编号3和4,则只能将用户状态改变为
3-4 范围中的一个编号.
上图表示状态编号2只能变更到1或3,对应实际业务即STONE审批后能交给部门经
理审批,状态3行的控制范围是2-4,部门经理审批成功后能将状态变成4,不通过则
变为状态2,不能变到状态1初始状态,状态4的控制范围是3-4表示如果总经理审
批失败后只能交给部门经理审批,不能直接变到状态1初始状态或由STONE审批状
态，这样保证审批和反审批流程都是按审批级严格进行。

和图1不同的是图1每个
用户状态的最低状态编号和最高状态编号都1-4。

PS：虽然多数ERP提供了强大的工作流模块，但是如果你正在构思一个简单的审批功能，从用户状态的设置中可以得到一些启示。

图3是一个使用无状态编号的例子，在建立订单时将看到用户状态在标题为“Status w/o status no.”的Tab页中。

第二步定义用户状态允许业务交易
多级审批和平行审批
通常审批流程是多级审批,假设IT工程师部要求采购部购买一些办公用纸,因为金额不大,只要IT主任或经理或采购主管或采购经理任何一位仁兄同意就行,就可设并行审批。

设置了用户状态参数文件并在参数文件中设置了用户参数行后，接下来定义各用户参数允许的业务交易，如图4。

REJL/RELZ状态时都不允许业务交易FI:记帐,即使订单的系统状态是Release也不行，只有等总经理审批完毕后状态RELZ是才允许FI:记帐，这样就起到订单审批目的。

如果是平行审批，则只要将REJL/RELZ/RELZ都设置允许业务交易FI:记帐就达到目的了。

第三步:定义授权码(Tcode:BS52/BS53)
第四步将授权码分配给用户或用户角色（Tcode：PFCG）
建立角色ZIOREL,将它赋给User ID STONEF,这角色包含KO01/KO02/KO03权限，进去后查看权限参数文件，如图6。

图6-[1][2][3]：可按Manually按钮手工加上授权对象B_USERSTAT，然后在该授权对象上增加授权码ZSTO，这样只有授权对象和授权码ZSTO的用户才允许更改用户状态REST。

到此用户状态和业务交易，授权对象都联系起来了，审批配置完成了，是我们真正需要的预算审批吗？不，这只是订单主数据建立的审批，预算功能请参考本章第四节内部订单预算，非常可惜内部订单预算却没有提供什么强大的审批功能，该有审批的没有，不该整的主数据审批又玩出花样，失败。

复习一下几个订单相关的Tcode，如下表。

常用实用的订单状态使用的Tcode：
BS02/BS03:建立/显示 status profile
BS12/BS13：维护包括各种订单在内的对象类型所允许的业务交易。

BS22/BS23:系统status维护/显示
BS32/BS33:维护transaction和status关系.
BS42/BS43:建立显示Status selection schema
BS52/BS53:建立Status对应的授权Key
BSVX:设置系统status限制
BSVY/BSVZ:设置System/user status限制
订单状态相关表格：
TJ03：Object Type（对象类型表）
TJ30：User Status（用户状态表）
JEST:Individual Object Status(输入OR00000+工单号可查询工单的所有状态Number) JEST/JCDS：Change Documents for System/User Statuses
JSTO:Status object information(可输入order type的status profile查询)
TJ02:System status
TJ02T:System status text(系统状态文本)
TJ01:user status(自定义status)
JJ01T:user status text(自定义status文本)
相关函数：
STATUS_CHANGE_EXTERN| STATUS_TEXT_EDIT| STATUS_TEXT_CONVERSION
在ERP系统中，订单状态的任何变更都是有记录的，如图7。

一道测试题，读者试着测试一下PP工单或销售订单包括系统状态和用户状态变更时以上各表变化的规律。

第三节订单计划
色即是空，人生到最后，那个冰冷的铁盒子才是咱们的最终归宿，所以应该将人生看的很简单。

省略。

第四节内部订单预算
在ERP系统中,内部订单计划是用来和实际发生数做对比用的(如Tcode:S_ALR_87012993可查看订单的实际和计划值对比),并不起实际控制作用,要做到控制作用,需要使用预算功能,但内部订单预算的控制功能比较粗糙,下面介绍预算是如何控制费用的.
一.配置部分
需要补充，内部订单年度总值的东西，细不到期间。

内部订单好象只有年度预算，而没有月度预算，能不能按成本要素分月度进行控制。

图1是内部订单预算和有效性控制的配置部分，配置非常简单.
图1-[1][3]:维护和分配预算参数文件(Tcode:OKOB|KOAB), 定义预算参数文件,在”时间框架”栏可设置做内部订单(Tcode:KO22|KO24)的预算时间范围,然后将预算参数文
件分配给内部订单类型,如图1-[3],订单使用系统已设置的参数文件000001.
图1-[4]:定义可用性容差限制,如图2,预算参数文件FRSY01中,作业组++表示针对所有的作业,操作1消耗85%表示预算到85%时出现警告,另一行操作3消耗100%表示预
算完全耗尽时系统提示错误信息,此时必须增加预算否则不能过帐.
如果需要还可设置一绝对公差值.
选择操作2带有寄给负责人的警告似乎也是
这个很容易呀,全面预算的设计逻辑你都说出了一大半, 这还算容易? 最近我总怀疑我的智商,你这样一说我就更不自信了,
为什么要做成为各各不同的事服务，直接修改表多好，你以为是玩技术呀，如果都很老实，如果都想俺这样老实，早跑步进入共产主义了，好象是自己挖个坑自己跳着玩自娱自乐。

需要将上年度的预算结转到下年吗？
内部订单预算操作：
建立原始预算（Tcode：KO22）
原始预算通常在年初制定,做为年终预算考核的依据。

追加削减预选（Tcode:KO24|KO26）
根据经营管理发展的需要，可以追加（削减）销售、采购、利润、资本等重大项目的预算。

除上述总体项目预算需要追加和追减外，各部门在预算执行过程中，由于新的经济业务的内容不在原预算之内或在预算之内但其实际余额超过了原预算金额，也需要申请追加补充和追减，通常各企业都会制定企业详细的预算制度,比如调整额度在5 万元以内的，由总会计师审批；超过5 万元的由总会计师核准，报董事长审批；２０万元以上的，由总会计师核准，预算管理委员会批准等等,就不吹了,谈下预算操作的逻辑。

预算逻辑表
KO22:BPGE(总计值的总计记录)
BPGE-OBJNR = ‘OR +订单号‘。

BPGE-WRTTP = ‘41’ (预算值)
BPGE-VORGA(预算类型)
KBUD(标志KO22原始预算
KBN0(标志KO24追加预算)
KBR0(标志KO26减少预算)
BPJA-GJAHR(预算年度相关值)
BPJA -VORGA
KBUD(标志KO22原始预算,WRTTP=41)
KBN0(标志KO24追加预算,WRTTP=41)
KBR0(标志KO26减少预算,WRTTP=41)
VORGA = BKFC WRTTP = 42 行,
BPJA-WTJHR|BPJA-WLJHR(已用年度预算值)
BPJA-WTJHF|BPJA-WLJHV(可用年度预算值)
如上图,可以非常清晰地反映出内部订单BUDGET(OBJNR:ORBUDGET)2007年度的可用预算值是1210(BPJA-WLJHR = KBN0 + KBUD +KBR0 = 6 + 1211 + (-7)
已用预算1104 RMB
根据系统设计理念，凡是任何业务交易，都产生凭证(广义的凭证并非指会计凭证)，无论是原始预算还是追加(削减)预算都会产生凭证。

预算凭证表
BPBK(凭证抬头)
BPEG(凭证行目总值)
BPEJ(凭证项年度值)
BPEP(凭证项期间值)
稍微熟悉了这些表读者就会知道设计一个简陋的预算是多么简单。

第五节结算规则自动生成
回顾PP生产工单,CO成本订单等生产性订单,其结算规则可自动生成,结算规则的自动生成包括两个主要设置,如图1,图1是结算参数文件设置和工厂订单默认参数设置的一个合成图.
(1).在订单的结算文件的”标识符”块必须选上”结算百分比”,如图1-[1].
(2).在SE16:V_T399X_PC|SE16:V_T399X或Tcode:OPL8定义工厂订单相关参数时,缺省规则选择PP1或PP2,对生产性订单(请参考Tcode:KOT2检查订单类别04/10等即为生产性订单)的系统默认规则只能是PP1或PP2,除非你增强.
有了上面两个设置,则生产性订单的结算规则自动产生,如果你查看结算的接受方,一般是MAT或
OIT,如果建立了BOM并且有联产品,则接受方是一组物料,对应接受方帐户分类种类是OIT. 那么,一般内部订单的结算规则如何自动产生呢?看相关配置,如图2,分析一下相关配置,十分简单.
第一步:配置
图2-[1]:系统默认真的一些结算规则自动生成策略,发送者类型ORC.
图2-[2]:此步可定义自己的结算规则自动生成策略顺序ST01,填写一个优先顺序号,输入一个策略假设是自定义的策略CSZ,结算类型是PER,定义策略配置见图2-[4][5].
图2-[3]:将ST01分配给顺序类型STIO(即内部订单类型,事务码KOT2定义订单类型),可修改的一栏选择”一直覆盖”,状态栏选择”CRTD 建立”表示在订单建立时结算规则就自动产生, 图略.
图2-[4][5]:在此编写结算规则增强和维护自定义的策略名称,图3中可看出定义了CSZ和CTR两个策略,自定义的策略以字母C开头.
图3中显示的数字策略是系统预定义的策略,配置到此基本完成,接下来是增强.
第二步:增强.
SMOD:COOM0003->EXIT_SAPLKOBS_001->在程序ZXKOBSU01写入下表中的参考代
CASE I_STRAT.
WHEN 'CSZ' . "如果策略是自定义的CSZ时
自动产生,显示的策略正是CSZ .
第五章 基本极限定理
【授课对象】理工类本科二年级 【授课时数】2学时
【授课方法】课堂讲授与提问相结合
【基本要求】1、理解切比雪夫(车贝晓夫)不等式；
2、了解车贝晓夫大数定理及Bernoulli 大数定理；
3、知道独立同分布的中心极限定理，了解德莫佛—拉普拉斯中心极限 定理。

【本章重点】车贝晓夫不等式，车贝晓夫大数定理及Bernoulli 大数定理。

【本章难点】对车贝晓夫大数定理及独立同分布的中心极限定理的理解。

【授课内容及学时分配】
§5.0 前 言
在第一章中我们曾提出，大量重复试验中事件发生的频率具有稳定性，随着试验次数n 的无限增大，事件A 在n 次试验中出现的次数n μ与试验次数之比n
n μ(即频
率)稳定在某个确定的常数附近（频率的稳定性），以此常数来近似作为事件A 在一次试验中发生的概率，并在实际中，当n 充分大时，用频率值作为概率值的近似估计。

对于这些，我们需要给出理论上的说明，而这些理论正是概率论的理论基础。

§5.1 切比雪夫不等式及大数定律
一、切比雪夫不等式
定理1 设随机变量ξ具有有限的期望与方差，则对0>∀ε，有
2
)
())((εξεξξD E P ≤
≥-
或2
)
(1))((ε
ξεξξD E P -
≥<-
证明：仅对连续的情形给予证明，设ξ的分布函数为)(x F ，则。