SAP 最详细的内部订单配置加操作Word下载.docx
- 文档编号:18886313
- 上传时间:2023-01-02
- 格式:DOCX
- 页数:19
- 大小:1.04MB
SAP 最详细的内部订单配置加操作Word下载.docx
《SAP 最详细的内部订单配置加操作Word下载.docx》由会员分享,可在线阅读,更多相关《SAP 最详细的内部订单配置加操作Word下载.docx(19页珍藏版)》请在冰豆网上搜索。
2.通过订单类型参数控制该类订单是否允许计划,允许预算,是否允许计入收入,允许状态控制等,请看图3,在图3中详细描述了这些控制字段。
记住三个重要术语:
1.对象种类/类型(ObjectCategory/ObjectType)
系统将状态管理中有相似处理功能的对象组合在一起,叫ObjectCategor或ObjectType,请看Tcode:
BS12。
2.订单种类(OrderCategory)
订单种类算是对象种类的一种,下图是BS12和KOT2的一个合成图,可看到的右边是KOT2的订单种类(OrderCategory)01/02到70,分别对应BS12中的对象种类/类型(ObjectCategory/ObjectType)ORC/ORD/ORF/ORG等,双击BS12,就能为每个订单类型分配允许的业务交易状态,在接下来还会就此问题详细阐述。
3.订单类型(OrderType)
订单类型有自己的编号和控制参数,用来区分出内部订单的实际用途。
这3者关系是,系统默定了对象种类,订单种类是其中一种,对象种类可控制该对象是否允许什么业务交易,系统都有一定的默认设置,除非特殊需求,一般并不建议修改,比如系统默认不允许使用分摊循环将费用分摊到目标对象CO订单(Tcode:
KKF1建立),这样需要BS12设置对象种类ORF允许业务交易RKIU。
4.对象类(ObjectClass)
对象类也用来根据业务交易来组织成本对象并分析成本流,对象类有四种:
INVST:
投资/OCOST:
间接费用/PRODT:
生产/PROFT:
利润分析
在内部订单主数据中可选择一个内部订单的对象类,我们知道在CO模块常用的成本对象包括内部订单,成本中心,获利分析段,WBS元素等,象成本中心这个对象默认就属于对象类OCOST:
间接费用。
你看到ObjectCategory,OrderCategory,OrderType,ObjectClass这些术语一定会想起ValuationLevel,ValuationCategory,ValuationArea,ValuationClass,有了这些术语ERP系统才能答建的庞大从而实现强大的功能,这种设计理念是这样的:
固化订单种类(OrderCategory)的情况下,实际上也就固化了订单的业务处理逻辑,但是,为了迎合各企业的复杂流程下,允许自配置一定的订单类型(Ordertype),在其中再定义一些参数,实际上,整个ERP的配置逻辑大抵如此而已。
图3是订单类型定义的一个画面。
图3-[1]:
设置订单编号(Tcode:
KONK),可为外部或内部编号。
图3-[2][3][4]:
注意订单的几个profille:
settlementprofile:
订单的结算参数文件,可控制该订单是否允许结算,允许结算接受方的个数,允许结算到何种目标成本对象,详细请参考相关章节。
planningprofile:
控制订单的计划参数。
budgetprofile:
控制订单的预算参数设置。
statusprofile:
控制订单的状态,可用来做订单的审批流程。
图3-[5]:
表示订单的数据保存多久后才能被archive。
图3-[7]:
如果选上,则表示允许post收入/销售抵扣要素(costelementcategory11/12),和成本中心一样,系统默认是不允许过帐收入要素的,比如某生产企业使用内部订单归集企业的非主营生产业务,该内部订单将同时归集其它业务收入(收入)和配比其他业务支出或成本,就需要选上允许收入过帐。
图3-[8]:
状态参数文件可用来做订单的审批流程,请参考接下来的第二节订单审批。
图3-[9]:
表示订单一建立就被release,订单如果没有释放是不能用于记帐的,有的企业不
喜欢玩审批,有的企业却喜欢整审批,特别是预算订单,一般不整个3-5级审批那
是死不罢休,哎,企业多了,什么样的鸟儿都有,如你想使用订单审批流程,当然这勾就不选上。
图3-[12]:
你可定义个printform打印订单。
图3-[13]:
屏幕字段选择,和会计科目的字段状态组(Tcode:
OBC4),记帐码字段状态(Tcode:
OB41)或移动类型字段状态(Tcode:
OMJJ),你决定订单主数据的字段是隐藏,显示,可输还是必输。
图3-[14]:
可为某类型订单设置一个默认的功能范围,比如为CO成本订单设置默认的“生产成本“功能范围,以免用户输入错误。
图3-[15]:
在“ModelOrder“栏可输入一个模板订单,这个订单起参考作用也可是普通的内部订单,这样在新建立此订单类型的订单时可将此模板订单的主数据字段复制到新订单,即类似参考建立。
图4-[1][2]:
将统计性订单的统计指标设置为必输,选上高亮则表示默认在主数据里选上。
图1-[3]维护订单编号范围(Tcode:
KONK)
维护订单的编号范围,可以是外部编号,也可以是内部编号,可以走菜单->
传输传输
编号。
图1-[4][5][6][7]:
订单审批配置,详细请看第二节。
第二节订单审批
下面介绍如何使用状态参数文件做内部订单的审批,实际上包括使用状态参数的销售订单等各种订单的审批也可使用该功能,为了让读者更明白步骤,采用我一贯常用的分步法说明。
第一步:
定义状态主文件(Tcode:
OK02|BS02)
如图1,定义StatusprofileZ0000002,在状态文件中可定义各种用户状态。
业务背景:
假设内部订单必须经过STONE审批->
接下来再经过部门经理审批->
最后是总经理审批后才允许实际过帐。
图1-[2][3]:
状态编号(Statusno.)和状态名称,你也可使用无状态编号定义用户状态。
图1-[3]:
根据业务需求建立4个用户状态分别是图1-[3]的RINT/REST/REJL/
RELZ。
图1-[4]:
如果选上“Init.Status”标志则表示订单一建立的初始状态。
图1-[5]:
可以为每个用户状态定义所谓的最高状态编号和最低状态编号(Loweststatusno./Higheststatusno.)。
图1-[6]:
定义了用户状态显示的位置排序位置和Priority,'
位置'
指定一个状态应显示在在状态行中的那个位置。
如果在同一个位置应显示几个活动状态,那么只显示具有最高"
优先级"
的状态。
如果用户状态使用了状态编号,则位置(Position)和Priority都是1。
图1-[7]:
可定义每个用户状态的授权权码(Authorizationkey),授权码由Tcode:
BS52建立,这样在设置内部订单状态操作的权限对象B_USERSTAT通过授权码进一步控制用户修改订单状态从而达到审批目的。
图1-[8]:
如过你是新建一个statusprofile,而非copySAPdefault的比如00000001,就需要点击“ObjectType“(ObjectType/ObjectCategory/OrderCategory/Ordertype在本章第一节订单主数据中已详细描述过)选上允许内部订单使用该状态文件,如接下来的图2,实际上如果是CopyStatusProfile00000001则允许内部订单使用标志也被Copy了,所以才不用在次设置。
图1-[9]:
定义好状态参数文件Z0000002后,使用Tcode:
KOT2_OPA_STSMA|KOT2将它分配给某订单类型后,在建立新订单,将出现图1-[9]画面,可以看到设置的4个用户状态,注意标题“Statuswithstatusno.”字样。
可以看到所有的对象类型(ObjectType),在第一节说了使用BS12可为每个对
象类型定义允许的业务交易,在这里为对象类型定义允许的用户状态,系统状态是
ERP系统里预先内置的用来决定允许操作那些业务交易,自定义的用户状态同样是
用来决定所允许的业务交易。
图2-[3]:
表示状态参数文件Z0000002允许应用于InternalOrder。
回顾状态参数文件的几个概念:
1.系统状态(SystemStatus)
系统预置的状态,预置的系统状态通常以字母I开头的5位码,使用Tcode:
BS32可
以查看业务交易和系统状态的关系。
2.用户状态(UserStatus)
使用自定义的用户状态灵活决定该状态下所允许的业务交易。
无论是系统状态还是用户状态都和业务交易控制相关。
3.状态编号/无状态编号(Statusno.|W/oStatusno.)
用户参数文件中定义的用户状态也可使用状态编号或状态编号。
4.最高状态编号/最低状态编号(Higheststatusno./Loweststatusno.)
状态编号用来控制状态的变更,最低状态编号和最高状态编号实际上控制着该状态行允许变更的用户状态范围,注意下面几个原则:
I.最低状态编号不能大于大于该行的状态编号,同样最高状态编号不能小于该的状态编号,如下图状态编号3REJL的最低编号不能是4。
II.状态编号也控制着用户状态的变更,如下图状态编号4REJL的最低状态编号和最高状态编号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。
结论:
如果你正在构思一个工作流审批的模块,从用户状态的设置中可以得到一些很好的启示。
图3是一个使用无状态编号的例子,在建立订单时将看到用户状态在标题为“Statusw/o
statusno.”的Tab页中。
第二步定义用户状态允许业务交易
多级审批和平行审批
通常审批流程是多级审批,假设IT工程师部要求采购部购买一些办公用纸,因为金额不大,只要IT主任或经理或采购主管或采购经理任何一位仁兄同意就行,就可设并行审批。
设置了用户状态参数文件并在参数文件中设置了用户参数行后,接下来定义各用户参数允许的业务交易,如图4。
REJL/RELZ状态时都不允许业务交易FI:
记帐,即使订单的系统状态是Release也不行,只有等总经理审批完毕后状态RELZ是才允许FI:
记帐,这样就起到订单审批目的。
如果是平行审批,则只要将REJL/RELZ/RELZ都设置允许业务交易FI:
记帐就达到目的了。
第三步:
定义授权码(Tcode:
BS52/BS53)
第四步将授权码分配给用户或用户角色(Tcode:
PFCG)
建立角色ZIOREL,将它赋给UserIDSTONEF,这角色包含KO01/KO02/KO03权限,进去后查看权限参数文件,如图6。
图6-[1][2][3]:
可按Manually按钮手工加上授权对象B_USERSTAT,然后在该授权对象上增加授权码ZSTO,这样只有授权对象和授权码ZSTO的用户才允许更改用户状态REST。
到此用户状态和业务交易,授权对象都联系起来了,审批配置完成了,是我们真正需要的预
算审批吗?
不,这只是订单主数据建立的审批,预算功能请参考本章第四节内部订单预算,
非常可惜内部订单预算却没有提供什么强大的审批功能,该有审批的没有,不该整的主数据
审批又玩出花样,失败。
复习一下几个订单相关的Tcode,如下表。
常用实用的订单状态使用的Tcode:
BS02/BS03:
建立/显示statusprofile
BS12/BS13:
维护包括各种订单在内的对象类型所允许的业务交易。
BS22/BS23:
系统status维护/显示
BS32/BS33:
维护transaction和status关系.
BS42/BS43:
建立显示Statusselectionschema
BS52/BS53:
建立Status对应的授权Key
BSVX:
设置系统status限制
BSVY/BSVZ:
设置System/userstatus限制
订单状态相关表格:
TJ03:
ObjectType(对象类型表)
TJ30:
UserStatus(用户状态表)
JEST:
IndividualObjectStatus(输入OR00000+工单号可查询工单的所有状态Number)
JEST/JCDS:
ChangeDocumentsforSystem/UserStatuses
JSTO:
Statusobjectinformation(可输入ordertype的statusprofile查询)
TJ02:
Systemstatus
TJ02T:
Systemstatustext(系统状态文本)
TJ01:
userstatus(自定义status)
JJ01T:
userstatustext(自定义status文本)
相关函数:
STATUS_CHANGE_EXTERN|STATUS_TEXT_EDIT|STATUS_TEXT_CONVERSION
在ERP系统中,订单状态的任何变更都是有记录的,如图7。
一道测试题,读者试着测试一下PP工单或销售订单包括系统状态和用户状态变更时以上各表变化的规律。
第三节订单计划
色即是空,假已真,人生不过30000天,到最后,那个冰冷的铁盒子才是咱们的最终归宿,所以应该将人生看的很简单,工作只做一个,象我就只干屠宰。
省略。
第四节内部订单预算
预算技术,包括零基预算、增量预算、弹性预算、滚动预算
支持多上多下,推荐采用典型的两下一上或两下两上的预算编制流程:
1、集团总部下达经营目标预算2、各级利润中心根据经营目标编制本级的全面预算3、各级预算向上汇总、平衡后形成全面预算草案4、经过质询会的讨论,调整后形成年度预算定案5、经过审批的个别预算调整更新各级的预算定案。
预算设置分解调整
预算分析
在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万元的由总会计师核准,报董事长审批;
20万元以上的,由总会计师核准,预算管理委员会批准等等,就不吹了,谈下预算操作的逻辑。
预算逻辑表
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=BKFCWRTTP=42行,
BPJA-WTJHR|BPJA-WLJHR(已用年度预算值)
BPJA-WTJHF|BPJA-WLJHV(可用年度预算值)
如上图,可以非常清晰地反映出内部订单BUDGET(OBJNR:
ORBUDGET)2007年度的可用预算值是1210(BPJA-WLJHR=KBN0+KBUD+KBR0=6+1211+(-7)
已用预算1104RMB
根据系统设计理念,凡是任何业务交易,都产生凭证(广义的凭证并非指会计凭证),无论是原始预算还是追加(削减)预算都会产生凭证。
预算凭证表
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写入下表中的参考代码.
CASEI_STRAT.
WHEN'
CSZ'
."
如果策略是自定义的CSZ时
E_KONTY='
SK'
."
表示结算的帐户分配类型是G/L
E_RECEIVER-HKONT='
5411010090'
.
E_RECEIVER-GSBER='
2010'
ENDCASE.
现在,如果使用KO01建立内部订单选择类型STIO时,一建立结算规则如图4的结算规则就自动产生,显示的策略正是CSZ.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SAP 最详细的内部订单配置加操作 详细 内部 订单 配置 操作