(企业利润管理)利润中心清帐_第1页
(企业利润管理)利润中心清帐_第2页
(企业利润管理)利润中心清帐_第3页
已阅读5页,还剩15页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、 实例图解利润中心层的应付处理于讨论企业分权管理和责任会计时 ,就不得不提到利润中 心,SAP 提供了强大的利润中心业务处理功能,于该 ERP 系统 中,你能够方便地制定企业的利润中心制度 ,建立以利润为中 心的综合考核评价体系,出具利润中心资产负债表、利润中心 损益表、利润中心资金预计表及利润中心成本费用分摊表等 如何实现利润中心模块呢?以利润中心资产负债表和损益表 来说,为了达到目的,则于实际业务中必须将每笔业务均对应 正确利润中心,然而,这且不容易,下面以应付帐款的几个实例 壹俩个利润中心对应壹笔应付帐款。于上图采购发票校验时间(Tcode:MIRO) ,同壹工厂下的采购 订单45000

2、00044采购了俩个物料,不幸的是,这俩物物料 分别对应到俩个利润中心 9188010000 和 9188020000,注 意到于”细节”页,我故意输入了业务范围 3000,发票校验后 产生的会计凭证如下:注意:上面的凭证反应出应付暂估 (GR/IR)对应的业务范围/利润中 心 2000/9188010000|9188020000 3000/SINO-DUMMY,帐户 50000001 是供应商名称它对应 的即是应付帐款,SAP 认为应付帐款科目是统驭科目,供应商强调壹下应付帐款的业务范围 3000 和利润中心 SINO-DUMMY理论上,上同壹工厂既可对应不同利润中心(直接维护于物料 主数据

3、),仍可对应不同业务范围(Tcode:OMJ7 可设置工厂+ 产品组决定业务范围) ,假设之上俩个采购物料连业务范围也 不同,发票校验产生的凭证如下,注意应付帐款我故意输入 了另壹业务范围 A001。引申的问题是: (1).为什么于确定应付帐款时能够输入业务范围而不能输入 利润中心?系统考虑可能会出现本例中同壹应付跨利润中心的问题 ?那 么包含多个采购项目的同壹采购单显然也可能跨多个业 务范围,凭什么业务范围就记录于会计凭证 ?而且,假设同 壹供应商为多个工厂供货,而且假设 MIRO 是根据供应商 进行发票校验即多个采购单项汇总产生壹笔应付 ,跨业务 范围不很正常吗?(2).为什么应付帐款(注

4、意供应商帐户 50000001行)不带采购 订单?企业通常是比较严格控制付款的 ,试想将钱大把掏出腰包谁 能痛快?壹位 CFO就给我提出要求,预付应付均要落实到采 购单,特别是使用采购单付工程款给承包商 ,这个要求且不过份,事实上,用户任何需求均不为过,当然也包括 BT的让你 头疼的需求,把用户侍侯的爽歪歪不正体现了顾问的价值 所于吗?设想壹下 ,如果预付和应付能根据采购订单互相 对清,壹目了然,那用户心理估计比喝了蜜仍爽。可是,从上图中应付帐款显然见不到采购单,从技术实现角度 来见,我能够举出俩个简单理由:如果需要于应付帐款中记录 采购订单和行项目,壹个采购单多个行项目你说记录采购单 尚可行

5、项目记录哪个 ?有人说那就只记录采购单 ,当下是第 二个理由,SAP提供了多种发票校验方式,假设发票校验不是 根据采购单而是根据供应商或其它就可能会出现多个采购 单汇总对应到壹笔应付帐款,这道理类似应付帐款对应利润 中心的问题,所以,系统干脆让应付帐款不带利润中心和采 这样的设计思路我很理解,可惜的是,这样的思路郁闷的差点 让很多 FICO 顾问含冤而亡,他会告诉你我发票校验只是根 据采购订单,况且同壹采购单中只为壹个工厂采购,且且该工 厂绝对唯壹对应到壹业务范围和利润中心 ,我要的就是让应 付帐款实时带上利润中心和采购订单 ,至于行项目不要也 罢,为什么这个小小愿望就不能实现呢?如果应付帐款

6、产生时未带利润中心,那么付款和清帐如何对 Tcode:O7Z4S)O7Z4S 于付款(Tcode:F-53)或清帐(F-44|FB1K)时选择”编辑选 项”,于”未清项目”页的”用于结清事务的行格式变式”的 供应商栏选择行格式”ST”。做壹个测试,假设用业务范围 4000 利润中心 9188040000 的银行存款科目 1001010000 去付带了业务范围 3000没带 利润中心(即 DUMMY利润中心 SINO-DUMMY)的应付, 俩笔付款共 1100 元产生凭证如下,此时注意到应付帐款的 利润中心仍是 SINO-DUMMY。这1000元银行存款科目1001010000输入了业务范围40

7、00 利润中心 9188040000这 100元银行存款科目 1001010000输入了业务范围4000 付款凭证编号分别为 1500000000/1500000001。三期末调整(Tcode:F.5D/F.5E/1KEK) 调整凭证 1200000003凭证的第 5/6行正是上面俩笔付款的 调整凭证,理解为: 6100000000 即内部应付科目,实际上它不仅是调整跨业范 围,也调整跨利润中心甚至功能范围,哪位可爱的老兄将它 整凭证没有利润中心调整! F.5D/F.5E也失效的业务场景有以下几个: 2. 预付清应付时,假设预付也没有利润中心,俩个 DUMMY 就 彻底 DUMMY 了.3.

8、假设供应商同时为客户 ,系统提供应收和应付对清功能 ,而 应收应付壹样的道理,是产生时不带利润中心的,俩个 DUMMY有瞎到壹起了。设想壹下,如果连应收应付均遭成壹团利润中心资产负债表 仍能用吗?很多人说,能分清损益表马马虎虎就行了,资产 负债表项要分清确实不容易,比如管理部门的所有固定资产, 为各利润中心服务的公用物料怎么能绝对于各利润中心分的 总之,如果没有实时保证到每笔应付应收均带利润中心,然 后你说你家的利润中心应收应付绝对准确估计多半是自欺欺 四.只涉及壹个业务范围和壹个利润中心的业务。 OneProfitcenter。见上面 MIRO 后的这壹笔应付帐款,只涉及业务范围 2000

9、和利润中心 9188020000。F 5D/F.5E后,产生凭证如下,通过 6100000000将应付帐款 和税金的 SINO-DUMMY 调整平衡。 有个好友问,如果付款时银行科目也输入业务范围和利润中 注意到应付出始终找到发票校验时应付产生时的原始业务范 调整凭证 1200000011。五统驭科目的设置(Tcode:OBXM)使用 ECC6的于线分割实时保证每笔应收应付均带利润中心 (也包括业务范围) 围/利润中心派生到忘记输入或自动/后台过帐时不方便输入 的凭证行项目,二是分割,分割后实现零余额平衡,所谓的 零余额平衡就是保证每个完整的会计凭证壹定按分解特征平 衡,假设业务范围和利润中心

10、均是零余额平衡,也就是说,每个会计凭证不仅仅是公司代码层平衡(借贷平衡三岁小孩 当下均知道也保证被设置为分解特征的业务范围层和利润 设计见起来很巧妙,实际应用存于什么问题呢?当下,于 ECC6 同样是发票校验,同样是壹个采购单的俩个行 项目涉及俩个利润中心 ,产生的凭证如下图,上部是分割前的 凭证,注意和以前版本壹样 ,应付帐款只有业务范围没有利润 中心,增值税业务范围和利润中心均没有。而下半部分是分割后的分割凭证,注意带应付帐款和增值税 均带上了业务范围和利润中心,分别按照不同利润中心给分 从中能够见出,分割凭证无论是公司代码层 /业务范围层/利 应付帐款2574元,不带利润中心那么如果使用

11、其它业务范围 /利润中心的银行存款付款会出 F-53 使用业务范围 3020/利润中心 PRCT1 的银行存款 1001010000对上面的应付帐款付款 1000元,付款方式: 你注意到即使于行项目格式中拉出利润中心,应付帐款2574 元,依旧不带利润中心,你很纳闷,不是已经分割了吗?怎 么不是俩笔分别带业务范围和利润中心的而依旧是壹笔总分析人士(杀猪的我)认为,壹是应付应收已清未清依旧保 留于表 BSIK/BSAK|BSID/BSAD ,SAP 仍没有来的及考虑这 些情况,二是它根本就不想考虑,你爱怎的怎的。起码到目前为止,对按利润中心分析应付应收依旧很不方便。 因为是采用剩余清帐,先全部清

12、2574元,再剩1574元为未清 USD ,1000 元/汇率 (保留 2 位)1574/汇率 (保留 2 位)-2574/汇率(保留2位),于USD层多出0.01USD,均是小数 位的原因,通常凭证打印的是原始凭证,0 元的行项显的非常 难见,ABAP 老兄于开发打印程序时也不过滤本位币的零行 , 真是懒的出奇!当下来见见分割后的凭证,如下图 1001010000 的 3020 和 PRCT1 是平衡的,同时系统找到原 壹个总的应付帐款系统如何知道按业务范围 /利润中心各清 多少?见似是按 MIRO 产生各业务范围/利润中心金额去清 测试: 付款 33元,业务范围 2010/利润中心 PRC

13、T1:实务中,如果想分按照业务范围付款这样的情形就大有问题, 为了防止这种情形产生,于之上三笔不同业务范围的费用确 定应付就应该分出三笔,可惜应付不能输入利润中心,如此 见来只能是是分业务范围做 3笔凭证了。 如果当时壹个业务范围的银行存款将 3笔 300元全部付了, 就直接全清除了 3个业务范围的应付。由于分割和凭证类型关联,可能你的机器测试会产生不同的 业务场景: 箱,向木器部下壹个内部加工单,直到完工入库,希望核 润中心对应产品,其中工厂 FRA4生产4种产品系列,对应 4个利润中心。假设系统设置如下:业务范围 2010 和 3010 属于旧 厂,2020和 3020属于新厂,使用段区分

14、,因为新工厂有地方税务优惠 ,所以分别出新旧业务范围 要求使用转移价格(比如参考市场价格)核算跨业务范围和 跨利润中心的转移业务,从而体现出业务范围和利润中心的内部利润 ,假设业务范围和利 润中心的组织结构如下表:FRA1,2010,3000(旧厂),9233110000FRA2,2020,2000(新厂),9233110001FRA3,3010,3000(旧厂),9233120001FRA4,3020,2000(新厂),9233120100FRA4,3020,2000(新厂),9233120200FRA4,3020,2000(新厂),9233120300FRA4,3020,2000(新厂),

15、9233120400*小小的回顾人们通常喜欢将事业部于 ERP系统对应到业务范围,国内有些集团采用不完全的事业不们制,有人说事业部这种管 理制度已经落后,也有人认为业务范围和利润中心是俩个 -Segment,据说说是用其来取代业务范围的, 段当下被设置于利润中心主数据中。有人说段就是分部,通常,当分部 营业收入/利润/亏损/总资产占总营业收入 /利润/亏损/总 资产总计 10%或之上时就需要出具分部方案。 2010/2020/3010/3020 而建立 3000/3001/2000/2001 四个段的话,这四个段分别加于利润中心主数据中,其实 就相当于于利润中心主数据层次里扩大了壹个组织单元的

16、 分析维度 ,这么壹个小改进大大简化了关联配置和操作, 叫嚷了多年的业务范围当下能够被段来替代,从而不用业 务范围和利润中心俩边去配置俩边去调整,道理就是这样。 如果于新总帐中,于废除利润中心模块,其实也建议这样 做,除非你想 Ledger8A 的垃圾数据充斥硬盘,这样利润 中心只要使用壹下起主数据就行。 凭证分割配置为了让你更明白凭证分割是什么玩意,剖析分割嘛,就要象 杀猪壹样,壹步步屠宰,当下, ST00000001。 ST ,于此分配业务范围,利润中心和段的默认值, 我们应该仍能记得旧系统设置默认利润中心的 新系统中则使用 Tcode:FAGL3KEH来替代,比如 壹个资产科目它没有填写

17、利润中心,则优先权分别 OBBH )FAGL3KEH凭证分割常量中利润中心 量,常量选择刚才定义的常量 ST,继承是什么意思 个组织单元做分解特征,举壹个简单的例子,有这 样壹笔会计分录:Dr :费用科目+成本中心(从成本中心主数据得出业务范围, 利润中心,于从利润中 Cr :某资产科目(业务范围,利润中心,段假设均未输入) 则系统将自动从费用科目继承业务范围,利润中心和段。你能够以同时选择俩者,如果继承起作用,则常量值自 动失效。 V_T8G03|V_T8G02|V_T8G29 估小概念绕壹下你:I.会计业务交易:决定记帐时可使用何种行项目项目类别。II.业务交易变式:壹个业务交易可有多个变

18、式 ,能够于变式中 对会计记帐业务使用的项目类别进行更进壹步的 限制,通过项目类别和会计科目挂钩比如将系统默 认的业务交易0200客户发票和应收帐款科目挂钩, 就可限制象 DR,DZ 这样的凭证壹定得使用应收帐 款科目(实际上就是壹定要输入客户)。 类别,最好也不要自定义项目类别,如果要定义就和 他们联系,当然如果要和他们联系,估计银子那就不 项目类别中的分割特征获得业务范围,利润中心和 如果您读到这里,估计基本已经不知道俺于自言自语说些什 么,当下自己来定义下这 3个东东,透视壹下凭证分割究竟是么子玩意,你需要使用 SE16 直 A.SE16:V_T8G03定义Z998,Z999俩个业务交易

19、,如图4。B.SE16:V_T8G02 定义 3 个项目类别 09999,A3838, A9999,如图 5。C.SE16:V_T8G29分配项目类别给业务交易Z999,如图 6。 D:为业务交易Z999定义壹个业务交易变式 Z001,如图 7。 最后回到图1-5定义业务交易变式画面,图7-1表示项目类别0300于此变式是强制的,你仍可定义某项目类别出现且 仅能出当下某业务交易变式中 壹 ST00000001, 假设为交易 Z999 定义了俩个变式Z001,Z002,理论上 你可为壹个业务交易设置 N个变式。业务交易变式有这么 些个作用,壹是如上图 7 包括壹些允许限制必输的项目类别,二是可为

20、每个交易变式定义不同的零平衡会计科目, 为同壹业务交易不同变式设置不同的分割用类型。 处理类别的用户类型有 0、1、2三种: 分录,那无业务范围利润中心和段的资产科目将使用固定值 ST 设置的业务 假设业务交易A9999和变式Z002使用固定值进行 凭证分割,零余额科目确定码 000 ,对应科目 970000。选择 1,则按设置的凭证分解特征且取基本项目类别科目特 征来分割凭证,也是那个分录,假设那个资产 假设业务交易A9999和变式Z001使用按分割特征 惊醒凭证分割,零余额科目确定码 000,对应科目 970001。 产科目似乎也使用了固定值 ST设置的业务范围 利润中心和段,可是,经过测

21、试,基于当前科目 余额分解的分割凭证估计只有神仙才能读懂。总结几点: 码层激活和业务交易变式中为每个项目类别选择用户类 定义壹个业务交易于整壹堆变式就可,于壹个交易变式因 入现金供应商客户等等项目类别,通常且不需要自定义项 目类别。系统不是有默认识的项目类别吗(对应图 10 的 分类 当下,假设将应收帐款科目分配 02000-客户, 将其它应收/预收科目分配给项目类别 02100-客户:特 别总帐交易,假设再为默认的业务交易 0200-客户发票 设置变式,实际上默认的业务交易0200默认的变式0001的项目类别02000就是强制的,如果于于图 11 中将凭证 类型比如 DZ设置业务交易 0200 和变式 0001,实际上就 表示该凭证行项目壹定要包括壹个应收帐款科目 ,也就是 包含壹个客户行项目,整了半天就这破东西,什么玩意? 分配项目类别A9999,我设置A3838/A9999项目类别是为了 反证凭证分割设计思路的可笑。图 9-2:将业务交易和变式分配给凭证类型,如图 11,假设将 业务交易 Z9999 的变式 Z001/Z002 分别分配给 SA,SB. 能够定义多个科目确定码且分配给相应科目,项目种类系统 默认是 01001。 图 13 表示财务凭证将同时根据业务范围利润中心和段进行零余额平衡,通俗地讲,就是壹 的零余额平衡中间科目于图 1

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论