财务会计与财务报表.docx

(ProfitabilityAnalysis)
首先,并不想在此白费笔墨讲一堆关于PA的理论,COPA的介绍的文章读者到处都可寻到.COPA可简单理解为利润分析顾名思义确实是根基你要如何样进行利润分析,从而为决策提供依据,在下面本人将就如何配置和原理栓释COPA,毕竟夸大和歪曲曲折折曲曲折折折折曲曲折折曲曲折折折折折折一个模块的作用和难度是不明智的,而且此书的目应该实是根基揭开FICO的棉纱让更多人能轻易理解FICO.
要是不上此模块可进行利润分析吗?因此能够的,自定义报表,然而得面对海量数据,比方要抓SO,Billing等数据,巨大的数据量使报表的性能受到碍事.
类似的咨询题还有要是不上物料分类帐能有效地分配差异吗?因此,自定义程序,因为上ML多出咨询题的缘故本人反而倾向于不使用ML.
从某种程度上讲,COPA是一个相当轻易的模块,因为它设计的逻辑理解相对简单,要是情愿,ABAPer吃饱了没事做完全能够不用SAP的COPA而自己写出一个COPA来,事实上许多没上COPA的企业实际上确实是根基如此多的.
从设计逻辑上,启动了利润分析,依据设置动态一些相关表,结构和程序(SAP许多模块的设计理念根基上如此,启动会产生相关ABAP对象),然后实时或后续Post数据到CO-PA相关表格,同时SAP提供了相关报表,如此比自写程序更简单而且能提供更多的相关报表而已.

在解释利润分析配置前,再此理解下什么是OperatingConcern(以下简称OC).
IMGPath:Enterprisestructure->Definition->Controlling->CreatingOperatingConcern建立
IMGPath:Enterprisestructure->Assignment->Controlling->AssingControllingArea
tooperatingconcern分配OC给Coarea,在分配前OC必须差不多产生了datastructure.
OC被翻译成(业务关联区,或康采恩)是获利能力分析中的核心组织结构，一个OC可包含多个controllingarea，一个controllingarea只能指派给一OC。
OC用来监控及分析各获利分析段ProfitSegment。获利分析段通常是销售组织(销售办公室,销售人员),产品(组,Model)、客户(组)等的灵活组合,具体视企业的实际需。可按照各获利段为依据生成获利分析报表，考核其获利能力。
7.1Structures
IMGPath如图7.1-1.
.
MaintainCharacteristics
T-code:KEA5SE16:
如图7.1.1-1,[1]进进KEA6维护值子段,[2]所有的OC用到的特征,[3]具体OC所用到的特征,[4]所有OCs中都未用到的特征.[5]自定义特征,特征必须是WW开头的4至5位,在自建特征时要是从客户主数据表KNA1,KNB1,KNVV,物料主数据表MARA,MARC,MVKE,SOheader和itemtableVBAK,VBAP等读取字段,建立的将并不是你所需要的WW***特征.

如图7.1.1-2,如在建立WW099时你选择了VBAP表,同时选择了MATNR和CHARG字段,特殊明显,维持后WW099特征并未建立而是将VBAP-MATNR和VBAP-CHARG建成了特征.

要是想建立自己的特征,请选择Userdefined,如图7.1.1-3,[1]用户自定义特征,[2]在此特殊介绍下第一种选择withownvaluemaintenance,它会产生一个T25**的checktable,要是使用了checktable,这些特征在使用前必须使用KES1定义自己的特征值.

在特征可使用前必须激活它,原理特殊简单,WW099创立了一个dataelement|domainRKEG_WW099(所有的自定义的特征都会产生类似RKEG_特征名称的dataelement|domain)和表T2503|T25A3(可使用Se11查瞧),因此的abap字典对象在可用前都必须被激活.在建立checktable之前读者甚至可手工选择checktable名称.

1需要如何样的特征取决于你的CO-PA毕竟要分析到多细?上面差不多介绍可从哪些表中取字段就可,通常的特征无非是|物料组|销售办公室|销售人员|billingto..等,实际上哪怕用户在维护OC的datastructure中只使用了一个特征,对最常用的特征字段比方公司代码,工厂,利润中心,客户,销售组织,分销渠道,division等最常用的分析字段都差不多在CO-PA相关表中了(请瞧7.1.3MaintainOC),这些是所谓的FixedCharacteristics,SAP差不多提供了客户|销售订单等表的相应字段可做特征,如有需要加上这些字段做特征字段,同时用户还可定义自己的特征withChecktable或withoutchecktable,这些特征并不基于上述SAPtables.
2尽量优化使用特征和值字段,毕竟大量使用他们会对系统性能造成碍事,尽管道理特殊明显越多的特征和值字段可能使分析更细,你需要在两者间平衡.
3在建立特征时,读者必须明白这些名词.
[一]Fixcharacteristic指固定的特征,比方客户,controllingarea,等,可如此理解确实是根基这些字段在COPA的相关表固定存在,不管你有没有将其设置成特征字段.(注:你设置的特征字段将会形成COPA相关表的字段).
[二]特征的comboundDependencies,意思是一个特征必须同时依靠另一特征,典型的比方你选择了地区KNA1-REGIO做特征,同时KNA1-LAND1也必须选上,另一个例子确实是根基选择了本钞票中心,Fixed特征Controllingarea确实是根基combounddependencies特征.(为了节约一字段,因此通常自定义一特征,然后KES1维护地区值和KEDR做个derivationrule取REGIO的值就可).
4关于dataelement,domain等名词请瞧附录应该把握的ABAP知识.

MaintainValueFields
T-code:KEA6SE16:
初始画面和选择全然和维护特征一样,再此着重介绍下如何依据需求维护自己的值字段.
关于特征字段,通常并不需要许多自定义的字段,相反,视想Co-PA分析多细,读者可定义许多自己的valuefields,特殊地,甚至可定义自己的PA传输架构(T-code:KEI1),全部使用自定义的valuefield.(如图7.1.2-2)

如图7.1.2-2,全部使用自定义的valuefields,这是采纳Costing-basedPAtype的好处(关于costing-based和accouting-baseCOPA的采纳请瞧下面讨论).

Valuefields是costing-basedPA的最小分析单位通常它有销售数量,销售输进,销售本钞票,销售折扣,各种差异等组成,必须考虑哪些值字段是需要的,比方需要将差异传到COPA吗?需要将差异更小层次细分吗?要如何细分?需要建立什么样的valuefield等.

1Valuefield有俩种类型,Amount和QuantityAggregation都会选择SUM,在选择LAS,AVG必须认真考虑.
2要是需要,全部使用自定义的valuefields,然后自定义描述,值字段在接下来来的FlowsofActualvalues配置中将用来对应科目(实际是本钞票要素),MM,SD的条件类型.
3.是否需要区分主营业务收进(本钞票)和其他业务收进(本钞票)?如需要,要建立4valuefield然后往和SDcondition对应(condition也要建立4种往区不).
4要是需要,预留出几个valuefields给今后不可预见业务,毕竟当OC被全部激活后要更改COPA数据结构是不轻易的情况,假设企业陡然需要某种费用进进COPA而且还需要和其他费用区不,如有预留字段,需使用只要将其map到此费用科目就可.
5.读者考虑:
特征通常可理解为有固定数据的字段比方产品->物料,值字段的data通常可变的,比方产品的销售数量,单价和金额,这特殊轻易理解,咨询题是要是将一些数量字段强行设置成特征会有什么结果?

MaintainOperatingConcern
T-code:KEAOSE16:

如图7.1.3-1,[1]输进OC名称STOC,维持后开始建立datastructure,[2]可使用SampleOC参考创立,在中也可参考创立一OC,[3][4]两种类型的PA分析.
图中表示STOC可采纳两种PA类型,甚至在激活CO-PA(Tcode:KEKE)中可同时激活俩者,特殊惋惜,在SetOC时(Tcode:KEBD)你只能使用其中一种CO-PA类型,关于使用costing-based依旧account-basedPAtype在下面有讨论,通常会试验区使用costing-based,因为其分析更加灵活.[5]建立datastructure(接下来会重点介绍如何建立datastructure).[6]在属性页中可定义Co-PA使用的币不和会计年度变式,只有定义了这些,在Environment才可激活Client-specificpart.

建立datastructure,如图7.1.3-2,[1]依据实际业务选择datastructure需要的特征字段,为了便于讲明,在选择了相关字段后按changeview,[2]可选择需要的valuefields字段用于建立datastructure,[3]为了便于讲明,加上了俩自定义的特征(同时定义时->请参照:MaintainCharacteristic选择了withownvaluemaintenance),因此此俩表分不对应到checktable是T2503|T2504.

关于valuefields,全部采纳自定义的valuefields,如图7.1.3-3,通常GrossSales和COGS是应该用于分析的,在接下来将介绍这些valuefield如何和SD,MMcondtions,PA传输架构等相对应.(Tcode:KE4I|KE4IM|KEI1,具体请瞧7.4Flowofactualvalues配置).

建立完datastructure后,必须激活,然后退回OCAttributeTab页维护币不和年度变式,在Environment中激活client相关和client不相关的COPA部件.

1什么是client相关和client无关?读者可自行考虑.
2在建立datastructure时,SAP做了什么动作?
在建立OC->STOC时,系统会产生如此一个结构CE0STOC(注重COPA自动产生的结构和表名称命名规那么是CE0-4+OC名称).
CE0STOC:结构,用于COPA程序中定义内表/
CE1STOC:维持actuallineitems.
CE2STOC:维持planlineitems
CE3STOC:维持PSGinfo.
CE4STOC|CE4STOC_ACCT|CE4STOC_FLAG|CE4STOC_KENC意义读者可自己往研究.
一般地,要是细心的读者使用SE11查瞧,
[1]会发觉在CE1XXXX|CE2XXXX表中的COPA_AWSYS|TIMESTMP的字段确实是根基你定义的特征和值字段(视实际情况可能有出进).
[2]销售组织,分销渠道,客户,公司等必须字段尽管你在特征中未定义在这些表中也差不多存在,这特殊轻易理解,利润分析连这些最常用的字段都没了还谈得上什么分析?因此就做成default字段了.
3激活Environment时SAP做了什么动作?
事实上讲白了,CO-PA确实是根基启动了它,建立了几个表在SOcreation,Billinggeneration或FI记帐等时(请瞧FlowsofActualValues配置)将相关数据写进COPA而已,正如上面所讲,要是你不上CO-PA可使用report,然而庞大的数据和复杂的逻辑可能会是report运行失败,要是有了CO-PA,直截了当从那个表抓数据多快.在这层意思上,COPA倒是和信息结构系统,BW的逻辑一样.
同样地,读者发觉COPA在设计上和SPL也特殊相似,COPA通过维护特征和值字段产生一些列表,SPL通过建立tablegroup产生一系列表.两者同样会动态产生一些相关程序.
4.一个建议,为了研究COPA逻辑,KE4I维护FI的PAstructure,然后FB50记一笔帐选个PSG,然后瞧瞧CE1XXXX和CE3XXXXSO,产生billing瞧其俩表内容.
7.1.4SampleOperatingConcerns
T-code:SE16:
从SAP的sampleOC中Copy所需的OC,同时将相关IMG也Copy过来,通常不建议如此做,毕竟每个企业有不同的实际业务需求,CopySAPSampleOC显然难于到达需求.
读者可自行测试如何使用此功能.
DefineprofitabilitySegmentChar.
T-code:KEQ3SE16:V_TKEOE
定义PSG所用到的特征,只有为OC定义的特征和值字段在利润分析段(PSG)才可使用,你还可决定客户,销售订单等固定特征是否可在PSG中使用(SAP默认是不用的).
SetOperatingConcern
T-code:KEBD|KEBI|KEBASE16:
在SetOC时OC需要差不多被完全激活(Tcode:KEA0),一个OC一次只可使用一个类型的COPA(Costing-basedorAccouting-based)
从程序来将,这动作只是是赋给parameterID一个default值而已,类似的Tcode还有AM 中的OAPL:SetchartsofDepreciation和OKKS:Setdefaultcotrollingarea.

7.2MasterData
IMGPath如图7.2-1.

7.2.1MaintainCharacteristicValues
为用户自定义的特征维护特征值.
在图7.1.3[3]中我专门强调了datastructure采纳的这俩字段,WW098,WW099在定义时使用了checktable,要是在PSG中要用到此两特征,顾名思义,特征的value必须checktableT2503|T2504.
1假设在实际应用中WW098是表示产品brand,然后PSG中使用了WW098,逻辑就会检测WW098的checktable是否维护了品牌,要是没寻到就会有错误.
2关于那些自定义的特征没有采纳checktable这步不用做,只要使用KEDS维护derivationrule就行.

7.2.2DefineCharacteristicsHierarchy
Tcode:KES3

将特征分层,这也好理解.要是需要,可将特征分层次.
7.2.3DefineCharacteristicDerivation
Tcode:KEDRDerivation(那个估量要请Xuebi翻译才比立正确,毕竟Xuebi在美国扫过几年垃圾,我想英文应该不错).
Derivation的意思是一些特征的值猎取可依据另外一些和它逻辑相关的特征的值,尤其在自定义的特征设置Derivation十分必要.
下面介绍如何建立一个derivation,稍有编程经验的人瞧一眼都明白,如图7.2.3-1,[1]Derivationrule,图有个WW099对应到Salesoffice的rule,[2]Tablelookup的条件和derivationrule不同的tablelookup可使用多条件,[3]使用move可直截了当直截了当依据条件从一个COPA特征字段或SAP字段给另一个COPA特征字段赋值,[4]可依据条件将一些特征字段的值清晰,假设定义了一derivationrule,在一些公司中如想让这些derivation不起作用,就可在此设置条件等于此公司的将Derivation的特征值给Clear[5]可写用户出口给特征赋值(SMOD:COPA0001->函数EXIT_SAPLKEDRCOPA_001->ExitinDerivationRule),要是实际业务前面四种方法都不难到达用户需求,小写一个userexit也非难事,毕竟程序是最灵活的.

如图建立了俩characteristicDerivation.

如图,这是一个derivationrule的例子,[1]要是PSG中salesoffice=3100(对应[3]的KMVKBU字段),那么[2]Region的值记到COPA表中是EUROPE(对应的字段是[4]自定义的特征WW099,在此将销售office瞧成Salesregion),因为WW099有checktable,因此所有的region值必须在KES1中维护.
这确实是根基Derivation,要是WW099在建立时没选择使用checktable,Region值就可随意输进(没有checktable),现在用户应明白什么缘故要checktable,事实上是防止不合理的数据进进COPA而已.

在维护Derivationrule后,你可做个特殊简单的测试,确实是根基FB50手工记笔帐选择PSG,你输进salesoffice3100后,按Derivation按钮瞧是否RegionEUROPE能否带出,你还可测试设置一Clear,Condition是salesoffice=3100和plant=3101,RegionEUROPE给清空(其他的plant依旧有效).
除了derivation可给自定义特征赋值,move,tablelookup等都可.图是一个使用move的例子.

如图7.2.3-4,[1]move名,[2]Productionname,源字段,[3]目标字段是自定义的特征WW003,[4]给予整个值给目标字段,[5]ARTNR的值从第11字段开始取后5个字符给予局部值给WW003.
关于tablelookup,userexit读者自行考虑.

本章小节:
1.决定采纳什么类型的利润分析?
costing-base和accounting-based区不前者采纳valuefield,可对应到cost/Revenue本钞票要素,MM|SD的条件类型,而后者采纳的只能是本钞票要素.在对应关系上,valuefield可对应一到多科目(本钞票要素),而后者特殊好马上一个本钞票要素和会计科目必须是一一对应.居于前者更灵活,通常企业会选择前种类型.

Costing-basedCO-PA有些缺点.
[一]时差.
一个实例是SD,已发货然而没biling,(销售本钞票COGS只有当billing时才到CO-PA),现在COGS被post到FI,然而CO-PA却没有.(这是针对采纳手工billing的企业,通常企业采纳自动的后台Job生成billing这咨询题就不存在)
[二]应计:
比方在传输salesorder到CO-PA时,一些应计费用通过SO的condition传到CO-PA模块,但从财务角度,这些费用并没发生因此在FI中也不存在..
[三]货币转换小数差和汇率差.
一个OC中(企业用俩OC的估量特殊少)可能使用多个controllingarea(有的企业使用了两到多个),这俩差异在其它模块也会有类似的不可防止的咨询题.
2.什么是利润分析段?
PSG是特征的一个唯一组合,比方可将产品号,产品组,客户,销售组织,分销渠道做为一个利润分析段
3需要为收进类科目建立costelementcategory11本钞票要素吗?
通常要是没上CO-PA和CO-PCA能够不建立,要是只上了CO-PA同时类型是costing-based也可不建立因为采纳的是值字段,要是上了CO-PCA利润中心,就必须为收进科目建立本钞票要素.要是采纳的是accouting-basedCO-PA也必须建立为收进类科目建立本钞票要素.
4.CreateDatastructure系统产生了那些表和结构?
在激活OC时,下面这些表和结构会产生.CE0STOC(结构)CE1STOC|CE2STOC|
CE3STOC|CE4STOC|CE4STOC_ACCT|CE4STOC_FLAG|CE4STOC_KENC.
其中CE1STOC维持PA实际行工程(类似ledger中的actuallineitems),CE2STOC是plan行工程,CE3STOC维持的是PSG数据(类似Ledger中的Summarytable).
5如何删除OC?
首先删除分配KEKK,后才可使用KEA0删除一个OC,删除OC将所有相关的表,结构,动态程序(Environment)全部删除了.还必须进进删除表才会完全删除洁净.
7.2.4ValuationStrategies

7.2.5SetUpValuationUsingMaterialCostEstimate

7.2.6SetUpConditionsandCostingSheets
这步设置可建立CO-PA专用的condtion和本钞票核算单(关于condition的配置请瞧附件光盘)用于分析使用原始凭证不能做到的边际效益分析,比方用于计算salesorder的销售折扣和运输费用等(未发生的虚拟值).鉴于篇幅,读者请自行研究.
7.3Planning
IMGPath:如图

7.3.1InitialSteps
7.3.1.1DefineNumber RangesforPlanningData
7.3.1.2MaintainVersions

7..3.1.3AssignQuantityFields

PlanningFramework
7.3.2.1SetUpPlanningFramework

7.3.2.2CreatePlanningLevelfroPlanningLayout

7.3.2.3DisplayPlannerProfiles
ManualEntryofPlanningData
7.3.3.1DefinePlanninglayout
7.3.3.2DefineValueFieldAssignments
7.3.3.3DefineDistributionProfiles

7.3.3.4CalculatedValuesasReference
IntegratedPlanning

PlanningAids

Reorganization

7.4FlowsofActualValues
IMGPath:如图7.4-1.

7.4.1InitialSteps
7.4.1.1DefineNumber RangesforActualPostings
T-code:KEN1SE16:
如图7.4.1.1-1,SAP使用了document那个名词,因此有FIdoc.BillingDoc(VF02),InvoiceDoc.(MIRO),Mat.Doc等,然后这些document都会给出编号范围.在此是只PAdocnumberrange,在COPA表CEX+OC中表示为BELNR字段(SE16可检查).
[1]Groups可瞧到Co-PA使用的recordtype,假设读者将recordtypeB的numberrange给删了,在FI记帐就会有图的错误,[2]OC名称,[3]可查瞧并更改当前的number,[4]查瞧更改numberrange

SAP准许使用外部编号.什么情况下使用,读者自行考虑,

MaintainCharacteristicGroups
T-code:KEPASE16:

如图7.4.1.2-1,[1]定义一个特征组[2]行号而已[3]字段[4]从图中能够瞧出,BUKRS和KNDNR将是必输字段,VKORG是只读字段,而MATKL是可选字段.
注重:
1特征组包含自定义的多个字段及其输进状态,要是在输进利润段时,用户可能需要一些特定的个性值(比方在利润分析段屏幕上需要限制某些字段必输,要是不使用特征组,在输进利润段将显示所有的可用特征->KEQ3定义的特征),就可建立特征组.
2这些特征字段状态是用户利润分析段选屏的,和一般科目使用的fieldstatusgroup是两个概念.
AssignCha.Grp.forAssignmentScreen
T-code:KE4GSE16:
如图7.4.1.3-1,[1]业务交易类型RFBU指的即是财务记帐,[2]在上一步定义的特征组,(注重Z003不能在此使用,因为特征组字段有BUKRS公司代码字段),[3]可模拟瞧到今后记帐时输进PSG时的subscreen和特征组所设置的字段及其输进状态.

1什么是businesstransaction(请参照特殊总帐的activity),在此就不再解释.
2FB50,F-02等记帐的Bus.Trn确实是根基RFBU,在配置完后读者可马上测试.
3从程序的角度瞧,为RFBU等定义特征组后,在程序中LKEAKF30中有如此的判定确实是根基要是带?的必选字段未输进,就有错误消息messageid'00'type'E'number'055'.
AssingChar.Grp.ForLineItemScreen
T-code:KEVG2SE16:
如图7.4.1.1,给recordtypeB给予特征组Z003,Z003组中必须包含必输状态的字段BUKRS(公司代码).

留给读者咨询题,上面RFBU指FIPosting,RecordtypeB也是纸directpostingfromFI,如两者都定义了特征组,谁在起作用?要是是RFBU,那么RecordtypeB毕竟什么时候在PostPSG时才会起作用呢?

7.4.1.5MaintainValueFieldGroups
T-code:KEVFGSE16:
值字段组和特征组同样道理,确实是根基在输进值字段时盼瞧自定义那些值字段为必输,就可采纳它(如某Bus.Trans没有值字段组,就显示利润分析段的全部值字段).
如图7.4.1.5-1,[1]自定义组ZVF1.

7.4.1.6AssignValueFieldGroupsforLineItemScreens
T-code:KEVG3SE16:
如图7.4.1.6-1,现在将此valuefieldgroup分配给recordtypeF和B,recordtype记录类型,只是是为了区分post到利润分析模块的数据来源而已.
回瞧图分配特征组给记录类型,现在又将值字段组分配给了记录类型,
为了便于读者理解,举个实例,在一些情况下我们可能需要直截了当postlineitem到利润分析模块.我们使用Tcode:KE21N,如图7.4.1.6-2.,KE21N将直截了当产生PADocumentwithLineitems.

KE21N用于直截了当产生PA凭证,如图,要是有实际业务比方需要手工调整COPA就可使用它,这些手工Post的数据只反映在PA中并可不能碍事财务.
[1]通常KEN1定义的编号范围是自动内部编号的,建议将这些手工建立的PAdoc使用外部编号(如图7.4.1.1-2),以便区分那些直截了当从FI,MM,SD等模块自动post到CO-PA的PAdoc.

读者Enter后,会发觉Characteristics和ValueFieldTab页显示的字段将是KEVG2和KEVG3定义的特征组和值字段组所包含的特征和值字段同时带有用户自定义的输进状态,这些正是用户所需要的,否那么瞧到的将是OC中定义的全部可用特征和值字段.

7.4.1.7SummarizeDataDuringUpdate
T-code:KE2SSE16:
如图7.4.1.7-1,[1]交易类型,前面差不多讲明特殊清晰,[2]如选了表示只会对外部来的数据才会汇总(比方iDoc,假设一大集团甚至有多client,毕竟client之间的数据是完全独立的,为了使跨client的利润分析成为可能,可能使用iDoc,数据从各client汇总),[3],数据是发生在derivation前依旧后面.

举一个简单的例子,如FIdoc有3个lineitem都对应到account10010101且相同的PSG10074(Amount分不是100,200,300USD),一般将有3lineitem写到COPA行工程表CE1****中,如使用了KE2S,那么只有总的600USD被post到CE1****.
7.4.1.8StoreQuantitiesInCO-PAStd.UnitofMeasure

T-code:KE4MSSE16:
SAP体贴中的一个例子是讲,VVISQ值字段对应到本世纪末FKIMG(Billingqty),现在要求明白Bill了多少KG,为此,需另外建立一字段VVIQT(描述是BillingKG,要是SO中使用了销售单位是吨,可库存单位是KG,如仅仅传输VVISQ将难于区分billedqty单位毕竟是Ton依旧KG),然后将转化后的billedKG维持在VVIQT中.
如图的,这是另外一个实例,确实是根基将Atrisk(可能的潜在的SOqty,这在做salesforecast和CO-PA方案版本中特殊重要)quantityVVQ03数量算进OrderqtyVVQ02中.

7.4.2TransferofIncomingSalesOrders
7.4.2.1AssignValueFields
Tcode:KE4I|KE4IMSE16:
这步将SD和MM的condition(通常对MM模块只用内部转厂PO->实际上可瞧成是将supplyingplant的SO和receivingplant的PO合并,因此有个intercompanysales的)和值字段对应上.
如企业要求将相关销售费用比方运输费保险费报关费产权费等分配到销售产品,可为每种费用建立condition和valuefield然后在此维护关系.
如图7.4.2.1-1,[1]Conditiontype[2]对应的值字段,因为分析的要求,所有的valuefield都使用了自定义.conditiontype和valuefield对应的关系是多个conditiontype可对应到同一值字段,通常这些值字段是Amount型的(值字段还有quantity型的)[3]传输的数据是否要正负号.

在KE4IM中,将转厂PO的Intercompanysales的条件类型和VV013联系上,在此不再贴图描述.
7.4.2.2AssignQuantityFields
如图7.4.2.2-1,典型地,将销售数量和开飘数量分配给值字段.

7.4.2.3ActivateTransferofIncomingSalesOrders

要是需要将salesorder数据传输到COPA,请激活传输SO,由于图使用了KWMENG,因此在此选择Inc.SO类型为2.
7.4.3TransferofBillingDocuments
ResetValue/QuantityFields
Tcode:KE4W

1.salesorder如何传输到COPA,数量改变在COPA如何反映?
假设SO的item20对应的WWC-001起初数量是100,在维持时,马上有数据在CE1****,CE3****等表,在此特殊提示下CE1****实际行项表,假设在KEA0的Attributetab页定义了俩currencies,一是OCcurrencies,一是companycodecurrencies同时两者不同,在COPA中一SOitem将会产生两条记录分不对应到currencytypeB0和10.(有多少不同的currencies就会对应多少条不同货币类型的记录)
假设现在SO的数量改成50,会产生两条记录,一条是SOqty-100冲前面的100,另一条是改正后的50.
当传输SO,对应的一些比方报关费运输费由condition传到valuefield,如开票不及时,造成FI和PA数据存在时刻差异,前面在分析costing-basedPA也强调过.
2.需不需要传输salesorder到COPA
视你COPA要分析到什么程度,要是连SO都不传,你的COOPA就太粗了,相信尽大多数企业会需要传输salesorder的.
使用Flexibleplanning加信息系统做salesforecast(Planverion),SO那么作为实际值,然后可比立销售方案和实际销售(SO值)的差异.
3什么缘故要Resetvalue/Quantityfields.
销售退回,运输保险保关费用差不多实现,在billing时只应冲减收进,回增库存,相关费用从condition带过往那么必须是0,不能冲差不多发生的数据.
注重:销售退回订单的SOqty传到CO-PA是负数,可冲PA实际发生的销售数量.
7.4.4OrderandProjectSettlement

7.4.5DirectPostingfromFI/MM

7.4.6SettlementofProductionVariances

7.4.7TransferofOverhead
以下请无知和Xuebi同志往搞定,然后Share一下班
名目
1. 全然业务原理 3
获利分析会计的目标和任务 3
获利分析会计的并行方法 5
用户自定义的报表对象 5
集成的数据流 6
分析性的销售和利润方案 7
灵活的报表功能 8
具有中心获利分析功能的分散的边际奉献会计 9
获利分析会计的流程 10
获利分析会计的分类特征 10
使用标准本钞票的销售本钞票会计(期中销售分析) 12
使用实际本钞票的销售本钞票会计(最终销售分析) 12
固定本钞票回属的期段分析 13
基于帐户和基于本钞票的获利分析 13
利润中心会计中的期间会计 14
2. 全然数据的定义 15
获利分析单元的概念 15
特征的定义 16
要害数字的定义 19
销售数量和利润方案的制定 21
利润方案根底 21
销售数量的方案 24
作毛收进和净收进方案 26
作销售本钞票方案 26
多种方案技术 27
方案的集成 28
促销预算的制定 29
编辑实际数据 31
通过均衡比例估算确定经营毛利 32
发票数据的传输 32
依据计算估算 33
用实际产成品本钞票估算 36
通过定单结果分析和结算确定经营毛利 37
通过比照直截了当计帐的收进和本钞票确定经营毛利 38
确定净经营利润 39
间接费用的分配 40
期间间接费用的分配 41
客户定单的转送 43
与外部发票处理系统的接口 43
获利能力分析 44
获利分析报表的类型 46
标准报表功能 50
表格报表 54
利润中心会计 58
全然原理 58
利润中心集成 58
有关利润的活动 60
商品和效劳/转移价格 61
资产负债表行项和要害指标 62
期间结帐 63
词汇 66

全然业务原理
获利分析会计的目标和任务
决策支持
企业各项活动的要紧目的是取得成功。单纯的关于客户、产品