合并数据建模-SAP相关学习文档

第三章合并数据建模关键词：源数据基础|数据基础|合并角色|合并范围同旧的报表合并系统ECCS相比,BCS一个重大的改变就是可允许用户自由地灵活地建立合并数据模,这项改进能非常容易满足集团各种复杂合并报表的需求，下面简单比较一下两个合并系统。BCS和ECCS合并系统的简单比较:ECCSBCS合并数据来源i.Ledger09->TableGLT3|Ledger1C->TableECMCT,可将ERP的财务数据实时过帐到合并帐ii.非ERP数据可通过文本,Excxel,Access按约定格式上载,可使用Tcode:FILE设置逻辑路径定期自动上载数据i.从数据流加载,合并数据从源数据基础立方体加载到总计数据基础立方体ii.灵活加载,数据可采用文本,Excel等DSO或总计数据基础立方体运行服务器ECCS模块通常和ERP运行在同一服务器上,增加服务器负荷BCS模块通常建立在专门的BI的数据仓库服务器上,除了抽数时段不影响ERP服务器性能与财务模块交互和ERPFICO数据可以实时交互,也可期末抽取合并所需要的各种财务数据定期从ERP或non-ERP中抽取或上载,如有必要,BI也可通过RFC直接和ERP连接建立查询合并数据模型熟悉ERPSPL的就知道用户最多只可额外附加5个自定义字段,ECCS的Cons.Ledger1C使用SummarytableECMCT表,让用户自由发挥的空间不大在BCS中，ECCS的Ledger1C已被Databasis代替,ECMCT被数据基础信息立方体代替也就是说BCS数据模型受业务驱动,建模灵活,只要满足了系统所要求的必需角色(关于合并角色下面会有详细描述),理论上可以任意自定义所需要的信息对象合并单元ECCS提供了基于公司->company,业务范围->BA,利润中心->Prct的合并方法,基本可以满足法定和管理合并,用户可以定义了Dimension->合并维度,在法定合并和管理合并切换由于引入合并角色的概念,合并单元设置更加灵活,只要将不同的组织结构赋予合并单元这个角色就行,比如你甚至可以将工厂->Plant赋予合并单元这个角色就可以做基于工厂的管理合并,用户还可以使用混合合并单元例如以company+Prct或company+BA组成混合合并单元合并功能从提供的合并功能方面实质上变化不大,只是ECCS的配置比较凌乱,从上图ECCS合并的Ledger设置应该是”fixed”,合并维度等设置算是”partiallyflexible”,BCS宣称其蕴涵了以价值为本的管理思想(ValueBasedMngt.),本人愚拙没大领悟到价值为本,倒是觉得新产品极其实施价格倒是不菲监控台ECCS提供了数据监控台和合并监控台,每个监控台包含系列相关任务BCS将两者整和在合并监控台(Tcode:UCMON),数据监控成了统一成合并监控台的一个任务组合并报表出具SAP的合并模块从FI-LC(LegalCons)->EC-CS->SEM-BCS(BusinessCons),合并功能和设计理念发生了很大变化,其实看看ECMCT这表有哪些字段就知道,基本上只能出一些标准的合并财务报表,灵活度不高,这点和国内的相关产品类似受需求驱动的合并模型的自行建模,理论上可以出多种类型报表,为了防止合并总计数据基础信息立方体过大,建议不需要合并的财务报表依旧在BI中出具BCS数据建模包括三个主要步骤:组织源数据,建立合并总计数据和建立合并数据模型,下面将一步步详细介绍。第一节组织源数据基础Tcode:RSA1简单地讲,源数据基础就是合并的数据源头,可以根据企业业务需求和报表建立源数据基础信息立方体收集合并所需要的财务方面数据。集团合并的数据来源通常来自R/3系统，其它非R/3系统，其它数据库甚至是其它数据仓库，数据可以在BI层次就进行收集然后统一加载到BCS，BCS模块本身提供了灵活的直接的数据收集方法，可采用从数据流加载(Loadfromdatastream)方法或所谓的灵活上载(FlexibleUpload)的方法将数据直接加载到BCS总计立方体或相关DSO。图1是一个合并源数据基础的信息立方体的简单示例,在STSDBBCS这个InfoArea下组织了总帐余额帐应收应付行项目信息,和标准的R/3数据源对应(R/3Tcode:RSA5,信息源->0FI_GL_1,0FI_GL_4,0FI_AP_4,0FI_AR_4),能基本满足一般的合并报表需求，当然,实际项目中的数据模型会比这复杂。1.根据2006年新准则<<企业会计准则第33号-合并财务报表>>第三条,合并财务报表至少应包括合并资产负债表,合并利润表,合并利润分配表,现金流量表,合并所有者(股东)权益变动表和相关附注,BCS仅仅出具这些标准报表数据建模会相对简单，这些合并报表的报表项一般都能很容易从合并科目上取得。2.企业涉及的合并报表可能还有诸如合并资产减值明细表|合并货币资金分类汇总表|合并交易性金融资产变动表|合并长期股权投资变动表|合并可供出售金融资产明细表|合并持有至到期投资明细表|合并在建工程明细表|合并长期借款增减变动表等,这些报表除了从合并科目上获取信息外还需要一些进一步的附加核算信息,BCS有一个专门名词叫子分配,子分配包含着一些细分合并项目的特征，比如说长期借款需要细分年初数|本期增加数|本期减少数等，BCS用移动类型这个特征区分这些数据；比如说长期投资项目必须带投资单位这个特征，简单理解,它类似中国财务会计的专项/辅助核算或R/3的字段状态组，子分配的应用实际和R/3字段状态组应用类似，下面会有详细介绍。尽管有些合并报表也只是或只能是简单汇总而已，在BI中完全可以处理这些报表,因为合并源数据首先就在BI中，但数据汇总在BCS中出的报表,给企业的感觉就不一样,从BCS出的报表少了企业就会纳闷怎么才这么点,出的报表多了,领导一高兴,竖起大拇指就夸:厉害，这么多合并报表,全！3.在R/3中,成本费用表就涉及多个模块,报表信息不能单从会计科目中获取,对于这些报表,为了不使塞进BCS总计立方体的数据过大,还是应该从BI中去出具.4.BCS项目通常并非在年初上线，所以涉及首次合并问题,同一般ERP项目类似,比如8月份上线,财务模块如何处理本年1-8月份数据。5．同一般的合并系统不同的是,BCS采用的是帐并法,国内同类软件一般采用表并法,即由企业在期末上报个体财务报表,再弄个合并工作底稿,编制抵消分录来实现,这种设计思路非常僵化,加大了财务用户工作量，帐并法又是如何实现的，下面将详细分析。第二节建立合并数据基础Tcode:RSA1源数据基础建立完毕后,接下来需要为BCS建立一个总计数据基础信息立方体,源数据立方体的数据将统一加载到该立方体中,合并的数据是基于该立方体的,同样建立一个名叫”STDBBCS”的InfoArea,在该InfoArea下建立总计信息立方体ZST_BCS,如图2。图2-[2]：总计数据信息立方体对特征和关键值有一定要求,即对合并角色->Role是有要求的,记住角色这个概念,下面的篇幅会更详细为你描述,简单地说,从ECCS的Ledger1C的固定SummarytableECMCT到BCS的业务驱动的总计立方体,从固定的二维表格到灵活的三维立方体,建模的灵活度大大提高,但是并不是任意折腾一个立方体就可以,这个总计立方体依旧必须最少有合并版本,合并期间,合并单元,合并集团货币金额,本币金额等特征和关键值,虽然是三维,信息立方体也得有一套帐的样子。实际上,用户可以很方便从0BCS_10/11/50Copy就行,在此基础上再自定义特征或关键值就行。ZST_BCS就是从0BCS_11copy而来。图2-[3]：总计信息立方体一定要选上“RealTime”这个标志,BW35管这叫”Transactional”,从”交易的”到”实时的”,真能实时吗?挺能忽悠的。BCS需要一个信息立方体做合并数据基础,你可以Copy标准的信息立方体,SAP的项目实施通常不就是配置+拷贝吗?*如果不小心“RealTime”标志忘了选上，可以使用SE16:RSDCUBE将标志字段'TRANSACT'设置为'X',可能的话,再建立位图索引,参见相关Note210888.如果系统显示找不到0BCS_11,表示该信息立方体未激活,新安装的系统可能会遇到这个问题，可到BIContent下去激活它,如图3，在BIContent页面下的InfoProvidersbyInfoArea下的StrategicEnterpriseManagement下的BusinessConsolidation下找到相关立方体，然后按图3-[4]的Install按钮激活，激活信息立方体同时激活相关的信息对象，需要一定时间。相关，信息立方体建立完毕，下面就是在BCS模块中去建立模型了。第三节合并数据模型相关Tcode:UCWB|UCWB01|UCMP0建立合并数据基础输入Tcode:UCWB,在总计记录->TotalRecords栏输入刚建立的立方体ZST_BCS,Copy0BCS_C11后的ZST_BCS已经根据业务需求增加了一些特征,开始建立数据基础->DataBasisST,如图4。图4-[1]:在TotalRecords输入ZST_BCS,将该选的不该选的Datatarget和VirutalInfoProvider全部选上,系统会为这些所谓的数据流->DataStream自动产生对应的名称,这些数据目标的作用请参考表一。图4-[2]:按此图标生成数据基础,将自动产生相应的DSO和虚拟信息立方体(找到一个专门处理此业务的Tcode:UGWBCM),当然,正确生产数据基础和各数据流的前提是在”DataModel”Tab页的各必需的合并角色都指派了相关特征或关键值，如图5。图4-[3]:AddlFin.Data,特别地,如果将来合并范围随着企业组织变更,请到FieldName->InvestmentData->AdditionalFields下选上OrganizationalChangeNumber.图4-[4]:可以选择哪个信息特征和报表授权相关,当然在建立这些特征(Tcode:RSA1,RSD1)时在BusinessExplorertab页必须选上AuthorizationRelevant标识。集中的合并系统报表查询权限重要性不言而喻，没有哪家企业喜欢把财务报表给非授权用户看。图4-[5]:为各特征定义报表时所显示的标题。.表一：数据基础中各数据流作用数据流必须/可选备注Totalsrecords必须该立方体中需包含合并模型中的各特征和关键指标Documents可选

保留合并凭证Inventorydata可选存货未实现利润,存货抵消Supplierdata可选存货未实现利润,存货抵消Investments可选用于投资合并Equity可选Result可选Goodwill可选Activitynumbers可选Sequenceofactivities可选Assets/Liabilities可选Assets合并NoncurrentAssets可选NoncurrentAssets合并NoncurrentAssets-consolidated可选TransferofNoncurrentAssets可选l*下面4个数据流是BCS6.0inBI7.0一个新安装的BCS系统，Tcode:UCWB进入合并工作台前会提示输入一合并范围->ConsolidationArea,合并范围有点类似ECCS的维(Demension),图5就是一个新系统的合并工作台的起初画面。图5-[1]:全新的BCS工作台暂时只能看到数据基础->Databasis和合并范围->ConsolidationArea两项,只有在正确生成了数据基础,并在合并参数中设置了合并,其它相关的配置菜单MasterData|ConsolidationFunctions|ConsolidationMonitor|才会显示出来,因为多数合并功能设置是基于合并范围的,设想这样一个业务场景,一个大型跨国集团,亚太各公司的合并业务在合并范围S1中进行,欧盟地区在合并范围S2进行,美洲地区则在S3中进行，那么，合并的设置是基于各不同的合并范围的。合并范围和数据基础的关系稍后会有更详细介绍。图5-[3][4][6]:在本例中，特征Company被设置属于ConsolidationUnit这个Role，如图5-[6],则Currency-BearingConsUnit是Company这个信息特征,即是基于Company进行合并。图5-[7]：特征合并科目表->ConsolidationChartofAccounts分配Role是固定的->FixedinConsArea,而象产品组->Productgroup,功能范围->FunctionalArea,移动类型->Movementtype等特征则被分配给Role子分配。图5-[5]:没有分配给Role的特征的信息特征自动挪到右边NotUsed目录下的废品收购站，如果将来这些特征将不再使用,可以从数据基础信息立方体中彻底移除它们。在数据建模->DataModel页面中,将总计记录立方体ZST_BCS的各特征和关键指标都对应到一合并Role,Role分CharacteristicRole和KeyFigureRole,BCS为一些基本特征和关键指标都设置了Role对应关系,我相信从某些UC*表中应该能找到这些对应关系,典型地：特征Fiscalyear对应role是Fiscalyear。特征PostingPeriod对应的role是Period。关键指标periodvalueintransactioncurrency(0CS_TRN_TC)对应role是ValueinTransactionCurrency。关键指标periodvalueinlocalcurrency(0CS_TRN_LC)对应role是valueinLocalCrcy。关键指标periodvalueingroupcurrency(0CS_TRN_GC)对应role是valueingroupCrcy。有些Role是必须指派特征或关键指标的，否则在生成数据基础时就会出现图6的错误。很容易理解,虽然从二维的Ledger到三维的TotalRecordsInfoCube,如果连集团货币,会计年度,期间,合并集团货币金额这样的信息都没有谈何合并?*总计记录数据基础信息立方体中究竟需要那些Infoobject,可以参考Note727776-RequirementsofSEM-BCSfordatamodel现在,来总结一下什么是合并角色。1．深入理解合并角色R/3中,ECCS合并系统可能用到的consolidationstagingledgerLedger09(Tcode:OCZ2->summarytable:GLT3)和Consledger默认是Ledger1C(Tcode:CXL3->Summarytable:ECMCT),使用SE11查看ECMCT的结构,这个表有ConsolidationUnit,ConsolidationGroup,Version,FiscalYear等字段，table字段基本固定也就意味承载的信息被限制,在处理复杂的管理合并报表需求上显然作襟见肘。BCS中体现的是业务需求驱动,使用了源数据基础和数据基础,这些立方体的信息对象允许根据企业的实际业务需求去规划,但是一个合并系统的数据并非想怎么整就怎么整，也应该有一定游戏规则,于是就有了合并角色(role)这个东西,无论信息对象如何组织,数据建模时必须保证将总计记录立方体的信息对象分配到一些必须角色。简单地理解,ConsLedger所必需的字段在BCS中被升级成必需的角色，这是一种比较前瞻的设计思路，合并单元字段到合并单元->ConsUnit角色，现在就可将Company，BusinessArea，Profitcenter特征或混合特征分配给该角色,以后的各种合并功能逻辑只要统一根据合并角色去编写就行,假设你将Plant/Segment分配给ConsUnit角色,那么合并逻辑就基于Plant/Segment,而不是使用如下逻辑:Case合并单元When‘company’基于company合并一套逻辑When‘Company+BA‘又一套逻辑。。。。。。Endcase.以上仅代表个人观点。国内合并软件基于企业报表上报的合并设计思路太模式化，显然不能满足大型企业复杂管理报表的需求，当然基于帐并则需要ERP设计时就考虑到一些细节问题，比如会计行项目中需要贸易伙伴（伙伴公司），业务范围和伙伴业务范围，利润中心和伙伴利润中心，如果我没猜错的话，国内ERP通常连根据利润中心出财务报表应该都困难，要做到这点，困难！2.Keyfigurerolekeyfigurrole,在Datastream的totalrecords中，支持4个Keyfigurerolevalueingroupcurrency,valueinlocalcurrency,Valueintransactioncurrencyandquantity,多个特征可以塞进一个相同的role,比如混合合并将公司和业务范围特征同属于合并单元这个Role，Keyfigurerole不同，一般主张Key