SAP 需求分析与作业流程报告

/需求分析与未来作业流程报告TOC\t"标题1,2,标题2,3,标题3,4,标题0,1"第一局部绪论 GOTOBUTTON_Toc3962851196一.M2专案综述 GOTOBUTTON_Toc3962851206二.需求分析及未来系统设计的出发点 GOTOBUTTON_Toc3962851216三.未来系统的运作框架 GOTOBUTTON_Toc3962851227四.流程图图例 GOTOBUTTON_Toc3962851239第二局部财务会计 GOTOBUTTON_Toc3962851339一.总帐系统 GOTOBUTTON_Toc39628513591.综述 GOTOBUTTON_Toc39628513692.与其它模块的集成 GOTOBUTTON_Toc39628513793.主要业务流程 GOTOBUTTON_Toc39628513893.1.会计科目表建立 GOTOBUTTON_Toc39628513993.2.传票录入及入帐处理 GOTOBUTTON_Toc39628514093.3.期末处理 GOTOBUTTON_Toc39628514194.报表需求 GOTOBUTTON_Toc39628514295.未来可能改进 GOTOBUTTON_Toc3962851439二.应收帐 GOTOBUTTON_Toc39628514491.综述 GOTOBUTTON_Toc39628514592.与其他模块的集成 GOTOBUTTON_Toc39628514693.主要业务流程 GOTOBUTTON_Toc39628514793.1.客户，员工主数据建立 GOTOBUTTON_Toc39628514893.2.员工差旅费预支 GOTOBUTTON_Toc39628514993.3.员工差旅费报销 GOTOBUTTON_Toc39628515093.4.员工差旅费报销催单及冻结处理流程 GOTOBUTTON_Toc39628515193.5.员工明细帐帐龄分析处理流程 GOTOBUTTON_Toc39628515293.6.预收款处理 GOTOBUTTON_Toc39628515393.7.发票处理 GOTOBUTTON_Toc39628515493.8.收款处理 GOTOBUTTON_Toc39628515593.9.客户催款及冻结处理流程 GOTOBUTTON_Toc39628515693.10.客户明细帐帐龄分析处理流程 GOTOBUTTON_Toc39628515794.报表需求 GOTOBUTTON_Toc39628515895.未来可能的改进 GOTOBUTTON_Toc3962851599三.应付帐 GOTOBUTTON_Toc39628516091.综述 GOTOBUTTON_Toc39628516191.1.现状 GOTOBUTTON_Toc39628516291.2.未来的设想 GOTOBUTTON_Toc39628516392.与其他模块的集成 GOTOBUTTON_Toc39628516493.主要业务流程 GOTOBUTTON_Toc39628516593.1.供给商类主数据建立 GOTOBUTTON_Toc39628516693.2.预付款处理 GOTOBUTTON_Toc39628516793.3.担保的处理 GOTOBUTTON_Toc39628516893.4.发票处理 GOTOBUTTON_Toc39628516993.5.保存尾数处理 GOTOBUTTON_Toc39628517093.6.付款处理 GOTOBUTTON_Toc39628517193.7.产生其它付款的处理 GOTOBUTTON_Toc39628517293.8.其它付款的付款处理 GOTOBUTTON_Toc39628517394.报表需求 GOTOBUTTON_Toc39628517495.未来可能的改进 GOTOBUTTON_Toc3962851759四.固定资产管理 GOTOBUTTON_Toc39628517691.综述 GOTOBUTTON_Toc39628517792.与其它模块的集成 GOTOBUTTON_Toc39628517893.主要业务流程 GOTOBUTTON_Toc39628517993.1.资产类别建立 GOTOBUTTON_Toc39628518093.2.资产卡片建立 GOTOBUTTON_Toc39628518193.3.在建工程结转 GOTOBUTTON_Toc39628518293.4.资产购置 GOTOBUTTON_Toc39628518393.5.固定资产的转移 GOTOBUTTON_Toc39628518493.6.资产计提折旧 GOTOBUTTON_Toc39628518593.7.固定资产清理 GOTOBUTTON_Toc39628518693.8.资产盘点 GOTOBUTTON_Toc39628518793.9.资产租赁 GOTOBUTTON_Toc39628518894.产生的报表 GOTOBUTTON_Toc39628518995.未来可能的改进 GOTOBUTTON_Toc3962851909五.法定合并 GOTOBUTTON_Toc396285191Error!Bookmarknotdefined.1.综述 GOTOBUTTON_Toc396285192Error!Bookmarknotdefined.2.与其它模块的集成 GOTOBUTTON_Toc396285193Error!Bookmarknotdefined.3.主要业务流程 GOTOBUTTON_Toc396285194Error!Bookmarknotdefined.3.1.合并报表项的维护 GOTOBUTTON_Toc396285195Error!Bookmarknotdefined.3.2.局部调整结帐 GOTOBUTTON_Toc396285196Error!Bookmarknotdefined.3.3.数据的采集 GOTOBUTTON_Toc396285197Error!Bookmarknotdefined.3.4.合并步骤 GOTOBUTTON_Toc396285198Error!Bookmarknotdefined.4.主要报表 GOTOBUTTON_Toc396285199Error!Bookmarknotdefined.5.未来改善的可能 GOTOBUTTON_Toc396285200Error!Bookmarknotdefined.六.资金管理 GOTOBUTTON_Toc39628520191.综述 GOTOBUTTON_Toc39628520292.资金管理与其它模块的集成 GOTOBUTTON_Toc39628520393.资金管理主要业务流程 GOTOBUTTON_Toc39628520493.1.自动付款处理 GOTOBUTTON_Toc39628520593.2.收到支票处理 GOTOBUTTON_Toc39628520693.3.付出支票处理 GOTOBUTTON_Toc39628520793.4.银行未达帐处理 GOTOBUTTON_Toc39628520893.5.应收汇票处理 GOTOBUTTON_Toc39628520993.6.应付汇票处理 GOTOBUTTON_Toc39628521093.7.对信用证的支持 GOTOBUTTON_Toc39628521193.8.现金状态及流量分析 GOTOBUTTON_Toc39628521293.9.短期借款/短期投资管理 GOTOBUTTON_Toc39628521393.10.利息计算 GOTOBUTTON_Toc39628521494.产生的报表 GOTOBUTTON_Toc39628521595.进一步改善的可能 GOTOBUTTON_Toc3962852169七.本钱会计－费用管理 GOTOBUTTON_Toc39628521791.综述 GOTOBUTTON_Toc39628521892.费用管理和其它模块的集成 GOTOBUTTON_Toc39628521993.费用管理主要业务流程 GOTOBUTTON_Toc39628522093.1.现状和需求综述 GOTOBUTTON_Toc39628522193.2.解决方案 GOTOBUTTON_Toc39628522294.产生的报表 GOTOBUTTON_Toc39628522395.进一步改善的可能 GOTOBUTTON_Toc3962852249八.本钱会计－获利性分析 GOTOBUTTON_Toc39628522591.综述 GOTOBUTTON_Toc39628522692.获利性分析模块和其他模块的集成 GOTOBUTTON_Toc39628522793.获利性分析主要业务流程 GOTOBUTTON_Toc39628522893.1.现状和需求综述 GOTOBUTTON_Toc39628522993.2.解决方案 GOTOBUTTON_Toc39628523094.产生的报表 GOTOBUTTON_Toc39628523195.进一步改善的可能 GOTOBUTTON_Toc3962852329第三局部供给链 GOTOBUTTON_Toc3962852339一.库存 GOTOBUTTON_Toc39628523491.现状及需求综述 GOTOBUTTON_Toc39628523591.1.对于XX集团库存管理现状及其需求简述如下: GOTOBUTTON_Toc39628523691.2.对于XX集团的营管系统与库存接口及其需求简述如下: GOTOBUTTON_Toc39628523792.未来系统解决方案 GOTOBUTTON_Toc39628523892.1.综述 GOTOBUTTON_Toc39628523992.2.与其它模块的关系 GOTOBUTTON_Toc39628524092.3.收货 GOTOBUTTON_Toc39628524192.4.发货 GOTOBUTTON_Toc39628524292.5.转储 GOTOBUTTON_Toc39628524392.6.预定 GOTOBUTTON_Toc39628524492.7.盘点 GOTOBUTTON_Toc39628524592.8.报表需求 GOTOBUTTON_Toc39628524692.9.未来可能的改进 GOTOBUTTON_Toc3962852479二.采购 GOTOBUTTON_Toc39628524891.现状及需求综述 GOTOBUTTON_Toc39628524991.1.对于XX集团采购现状及其需求简述如下: GOTOBUTTON_Toc39628525091.2.对于集团采购现状及其需求简述如下: GOTOBUTTON_Toc39628525192.未来系统解决方案 GOTOBUTTON_Toc39628525292.1.综述 GOTOBUTTON_Toc39628525392.2.与其它模块的集成 GOTOBUTTON_Toc39628525492.3.采购申请及分配处理流程 GOTOBUTTON_Toc39628525592.4.采购订单的处理 GOTOBUTTON_Toc39628525692.5.供给商评估和管理 GOTOBUTTON_Toc39628525792.6.采购订单的收货处理 GOTOBUTTON_Toc39628525892.7.发票校验 GOTOBUTTON_Toc39628525992.8.报表需求 GOTOBUTTON_Toc39628526092.9.未来可能的改进 GOTOBUTTON_Toc3962852619三.生产管理 GOTOBUTTON_Toc39628526291.综述 GOTOBUTTON_Toc39628526392.生产管理与其它模块的集成 GOTOBUTTON_Toc39628526493.生产管理主要业务流程 GOTOBUTTON_Toc39628526593.1.生产量预估处理 GOTOBUTTON_Toc39628526693.2.需求管理 GOTOBUTTON_Toc39628526793.3.物料需求方案 GOTOBUTTON_Toc39628526893.4.能力平衡 GOTOBUTTON_Toc39628526993.5.生产排程 GOTOBUTTON_Toc39628527093.6.生产备料/领料处理 GOTOBUTTON_Toc39628527193.7.生产确认及入库处理 GOTOBUTTON_Toc39628527394.报表处理 GOTOBUTTON_Toc39628527995.进一步改善的可能 GOTOBUTTON_Toc3962852819四.本钱会计－产品本钱管理 GOTOBUTTON_Toc39628528291.综述 GOTOBUTTON_Toc39628528392.产品本钱管理和R/3其他模块的集成 GOTOBUTTON_Toc39628528493.产品本钱管理主要业务流程 GOTOBUTTON_Toc39628528593.1.标准本钱的制订和修订 GOTOBUTTON_Toc39628528693.2.实际本钱的核算和分析 GOTOBUTTON_Toc39628528793.3.差异处理 GOTOBUTTON_Toc39628528894.产生的报表 GOTOBUTTON_Toc39628529195.进一步改善的可能 GOTOBUTTON_Toc3962852929五.营管系统与R/3的接口 GOTOBUTTON_Toc39628529391.现有系统及未来需求综述 GOTOBUTTON_Toc39628529492.与接口有关的主要业务流程及功能简述 GOTOBUTTON_Toc39628529592.1.接口的整体架构 GOTOBUTTON_Toc39628529692.2.订单出货和发票开立作业 GOTOBUTTON_Toc39628529792.3.缴款作业 GOTOBUTTON_Toc39628529892.4.公司内成品调拨 GOTOBUTTON_Toc39628529992.5.从关系企业调入成品 GOTOBUTTON_Toc39628530092.6.向关系企业调出小料和精料 GOTOBUTTON_Toc39628530192.7.退货作业 GOTOBUTTON_Toc39628530292.8.换货作业 GOTOBUTTON_Toc39628530392.9.盘点作业和库存流转 GOTOBUTTON_Toc39628530492.10.制面厂成品库生产入库及其它 GOTOBUTTON_Toc39628530592.11.运费结算 GOTOBUTTON_Toc39628530692.12.清户退款 GOTOBUTTON_Toc39628530793.组织机构和关键数据定义 GOTOBUTTON_Toc39628530893.1.组织机构 GOTOBUTTON_Toc39628530993.2.关键数据 GOTOBUTTON_Toc3962853109

绪论一. M2专案综述国际集团为了利用现代先进资计技术辅助，提高企业的管理水平，以完善自身的机制和增强企业的市场竞争力，在集团最高层领导的倡导和推动下设立了M2专案。作为一个管理水平的标志，其最终目的是在每月的第二天完成集团公司的法定合并报表和管理合并报表的工作，到达这一目标的前提是集团拥有一套整合的企业管理应用软件系统，支持各职能部门的日常业务，同时准确及时地记录各公司、各职能部门中发生业务信息，传递到其它部门分享并由各级公司、总公司分折汇总。因此，SAP公司有幸地被选为软件供给商和实施伙伴。二. 需求分析及未来系统设计的出发点以顶新集团的企业规模以及其业务的多样化而言，M2专案的实施应该是阶段性的。在实现M2专案最终目标的过程中，每一阶段都应该有明确的目标，第一阶段的主要目标应该是：以XX集团公司为样板，实施一个整合的企业管理系统，支持供给链上的操作及财务会计和管理会计统计和监控。在设计样板过程中，充分考虑到其它事业群生产经营模式的特殊性，保存样板的灵活性，以便将来推广。统一集团内各公司的会计科目，标准财务会计的业务流程。在所覆盖的范围内为各子公司实施一个强有力的财务系统，以根本解决集团报表合并的问题。

针对M2专案的目标，依据整体工程实施的方案，SAP工程小组在完成以XX集团为样板的财会系统及供给链系统现状调研后。在顶新集团M2专案设计组，M2专案应用组的大力支持和协助下，在预定时间内完成了需求分析及对未来系统的初步设计。

后续章节中对需求的描述及未来系统解决方案的建议，根本上按企业的职能及系统的应用模块划分。财会方面的需求分别考虑了以XX集团为代表的子公司财务处理，以方便面为代表的事业群经营分析，以及总公司的财会处理和合并业务，在供给链方面的需求则根本上，以XX集团的方便面产、供、销模式为主，并在讨论中参考了其它事业群的一些特性。三. 未来系统的运作框架以财务合并的角度看，未来系统在第二阶段完成后的动作模式，如：以下图所示 当集团完全采用了R/3系统之后，总体系统的接口将简单化甚至单一化。作为第一个样板公司，XX集团将启用的不仅是财务系统，而且包含了供给链系统，两者在R/3的环境下是实时集成的。以XX集团的角度看，未来系统对其物资流的支持如以下图所示： 在系统的内部，其数据资料的流动根本上如以下图所示：这种模式将逐步地推广到各事业群、各子公司。在后续阶段的实施方案中，我们考虑引进SAPR/3的人事资源管理模式，解决人事薪资，差旅报销与财务系统的接口。当国内的通讯水平以及网络系统的根本性能到达要求时，建议用SAPR/3的销模块（SD）取代现行的营管系统，以最终到达完全的整合性。财务会计四. 流程图图例

财务会计一. 总帐系统综述财务组织机构定义：公司代码:为每个帐务实体定义一个公司代码，各个公司有自己法定报表。业务范围：将一个产品或一类产品定义为一个业务范围，各个业务范围可以产生自己的利润表，以供管理层使用。财务基础数据：会计年度：国际集团采用日历年度。会计期间：国际集团会计期间为12，从1月份到12月份。传票类型：未来的系统按照业务性质详细划分传票类型。传票编号：按年、传票类型及传票录入日期进行自动编号。国际集团要求传票按月、传票类型进行编号。按照我们的经验，SAP的编号方式对外部审计，内部管理都不存在任何问题。SAPR/3的中国用户已有10多家通过财政部的评审，所以对外部审计而言，不存在任何问题，对内部管理而言，SAPR/3提供了多种分类方法，用户可以方便地查找传票，对传票进行归档处理。为了最大程度地满足国际集团的要求，SAP中国的郑锐先生已向SAP总部发出二个修改申请：系统提供传票按月、传票类型进行编号的功能，修改申请号为762357。预制传票、正式传票采用不同的编号，修改申请号为762416。币种及汇率：由集团总部负责币种代码定义和汇率表的维护，各分公司使用总部维护的汇率。权限控制：在原型测试阶段，将按照国际集团要求定义各种权限。未来的总帐系统包括会计科目定义，传票录入，外币评估，暂估处理，科目余额重组，科目余额结转，报表处理。未来的总帐系统与其他子系统是紧密集成的，许多数据由业务发生子系统写入总帐系统，无需手工重复录入数据，无需会计做审核（除供给商发票），提高帐务处理速度。未来的总帐系统有一系列功能加速期末结帐，如外币自动评估，暂估自动处理等。外币评估将采用期末评估，期初冲回方式。自动收付款，汇票管理在现金管理中处理。关系企业往来走应收、应付流程，所以，关系企业往来的帐务处理在应收、应付中描述。与其它模块的集成总帐子系统与应收，应付，固定资产，库存，采购，销售，本钱会计，资金管理有实时数据交换。主要业务流程会计科目表建立现状及需求综述顶新集团采用自己的会计科目表。目前集团公司下各公司采用各自科目表，集团公司有方案－－将来实现统一的科目表。现有会计科目编码是不等长的，会给传票录入带来不便。客户、供给商、员工编码作为会计科目的一局部，造成科目极其庞大。解决方案建议国际集团采用统一会计科目表，由总部会计部确定会计科目表编制原则，协调各分公司要求，负责会计科目编号确定，解释各会计科目的性质。各分公司根据需要，选择有关科目使用。通过会计科目表统一，有利于数据确认、合并、内部审计，总帐、分类帐余额统一，分类帐控制。建议国际集团采用等长会计科目编码，以方便帐务处理。建议国际集团将客户、供给商、员工管理放在应收/应付子系统中管理，客户、供给商、员工的编号不再作为会计科目一局部。集团总部会计负责维护会计科目集团级数据，各分公司按照需要，维护会计科目公司级数据。建议国际集团总部成立专门职能小组负责这项工作，各分公司建立相应职能小组。建立新科目流程功能说明“决定是否建立新科目〞：由集团总部会计小组依据会计科目表编制原则，已有科目表，决定是否建立新的会计科目。“维护新会计科目集团级数据〞：由集团总部会计维护会计科目编号、名称、性质等数据。“维护新会计科目公司级数据〞：由公司会计维护会计科目公司级数据，包括货币、明细项索引、自动过帐标志。流程组织结构定义公司：法定财务实体关键数据公司代码币种传票录入及入帐处理现状及需求在现有系统内，由于各应用局部缺乏集成，传票由接口系统或手工导入总帐。大量手工收付款处理，导致工作量大。解决方案采用SAPR/3集成系统，大局部传票由业务发生点传入总帐系统。关于收付款处理，大局部通过应收、应付子系统自动收付款处理，仅仅小额零星现金收付款在总帐系统内处理。传票录入及入帐流程a)转帐处理b)小额现金付款处理c)小额现金收款处理功能说明“前置系统业务处理〞：是指与会计系统相关子系统进行业务处理时，自动产生会计传票并入帐，无需人工录入传票，入帐。例如：仓库发料时，仅须在库存管理系统录入发料数据，系统根据发料数据，材料价格，自动生成会计凭证，并入帐。“输入传票〞：依据原始凭证，输入传票类型、公司代码、传票编制日期、入帐日期、借贷科目、借贷金额、后续帐务分配如输入本钱中心，业务范围。并且检查公司代码是否存在，记帐期间是否允许入帐，借贷科目是否存在，本钱中心、业务范围是否存在。“入帐〞：系统自动检查借贷金额是否平衡，传票检查通过后，系统将更改科目余额及其它文件，自动分配传票编号，存入传票文件。“传票预制处理〞：是指输完传票后，传票存在系统内，但并不入帐。这类传票称为预制传票。“预制传票入帐〞：是指将预制传票记入帐册，预制传票转成正式传票。关于凭证审核，目前系统仅提供一级审核功能，建议第一阶段打印出预制传票，在SAPR/3系统外审核，通过后，由专人将预制传票入帐，或者编制手工传票，多级审核后，将手工传票输入系统入帐。第二阶段采用〞Workflow〞方法，在系统内进行多级审核。作业功能组织示意公司：法定财务实体业务范围：将一个产品或一类产品定义为一个业务范围，各个业务范围可以产生自己的利润表，以供管理层使用。本钱中心：收集费用的责任单元关键数据 会计期间，会计科目，传票类型，币种，公司代码，业务范围，本钱中心期末处理期末处理现状及需求综述月末关帐在下月8号，年末关帐在来年二月底，在现有系统，期末有大量手工处理，工作量极大。结帐比较迟，为了保证M2专案目标的实现，必须加快结帐速度。解决方案未来的系统改进现有的本钱结算体系，减轻期末本钱结转的工作量未来的系统有自动的外币评估，自动的科目余额重组，自动的暂估处理等功能，加快期末结帐。处理流程功能说明“资产负债类科目外币评估〞：评估已实现汇兑损益。如银行外币存款，外币现金评估。“未清项外币评估〞：评估未实现汇兑损益。如应收，应付外币评估。“余额重组〞：调整应收，应付统驭科目。例如一个客户明细帐余额在贷方，期未结帐时，指定调整到负债方统驭科目，下个期初系统自动冲回。报表需求未来的总帐系统可以提供以下报表：资产负债表损益表财务费用明细表营业外收支明细表增值税申报表科目余额表传票明细汇总表每日日计表及每日传票编号未来可能改进B级功能工作流（Workflow）功能

第二阶段将引入工作流功能，以解决系统内传票多级审核的问题。C级功能科目方案

二. 应收帐综述未来的应收帐子系统将包括客户主数据建立，预收款请求，预收款处理，发票处理，手工收款，自动收款，预收款清发票，客户催款，收款通知，对帐单处理。未来的应收帐处理将考虑与国际集团营管系统的集成，预收款处理，发票处理，缴款处理将通过批处理程序由营管系统录入SAPR/3系统。在SAPR/3系统内进行销售处理，将按正常的应收帐处理流程进行。在人力资源子系统未实施前，员工差旅费放在应收帐子系统处理，利用应收帐客户管理功能，帐龄分析，催款功能，清款功能对员工差旅费实施严格管理。与之相对应，为员工建立编号及有关数据。未来的系统中，其他应收款走应收帐流程，与之相对应，财务部门替其他应收款的欠款方建立编号及有关数据。未来的系统将为客户、员工、其他应收款的欠款方建立不同的编号范围。未来的系统中，通过SAPR/3的特别总帐处理来区别关系企业的应收货款、应收设备款、应收融资款。自动收款，利息计算及汇票管理将在现金管理局部描述。与其他模块的集成应收帐子系统与销售，总帐，资金管理，盈利分析有数据交换。主要业务流程客户、员工、欠款方主数据建立现状及需求现阶段客户主数据在营管系统中管理，整个帐务系统没有客户数据管理，客户作为二级科目，编入会计科目。员工编号作为二级科目，编入会计科目,整个帐务系统没有员工数据管理。解决方案在未来的系统中，建立集中客户、员工、欠款方主数据，由营管决定客户编号，营管，帐务输入各自数据，帐务部门仅输入帐务控制有关数据。为了保证员工编号一致性，尽管人力资源现阶段未实施，建议人事部门负责员工编号，财务部门负责帐务有关数据。财务部门负责决定其它应收款的欠款方的编号及帐务数据。建议有关部门设置专门小组/专人负责客户、员工、欠款方主数据建立。建立主数据流程功能描述“决定客户帐务控制数据〞：依据营管提供客户数据，决定客户组，统驭科目，付款条件，信贷限额等数据。纳入营管系统管理的客户，付款条件，信贷限额在营管系统内输入。“决定出差员工编号及有关数据〞：依据各部门出差员工表及人事部员工编号表，决定出差员工编号，以及员工组，统驭科目，借款限额等员工个人数据。“建立主数据〞：利用应收帐子系统中建立主数据功能，建立客户，员工，欠款方帐务数据，以方便管理和控制。作业功能组织示意图关键数据公司代码，统驭科目员工差旅费预支现状与需求综述现有系统将员工定义为一个对冲会计科目，制作预支差旅费传票时，输入一个索引码，制做清款传票时，输入一个索引码，利用《冲销对照表》冲销了索引代码相同，借贷相反的会计交易，并且利用《冲销对照表》列印帐上有余额的会计科目。解决方案正如综述所言，采用SAPR/3先进应收帐子系统有效管理员工差旅费。替每个员工在系统内建立一个编号，支取差旅费时，会计部门输入员工出差付款请求，审核通过后，批准出差付款请求。运行自动付款程序，对员工支付预支差旅费。预支差旅费处理流程功能说明“审核是否合法〞：按照预支差旅费规定，审核单据是否齐全，签名是否合法。“输入付款请求〞：按照预支差旅费申请单输入付款请求，付款请求仅是一张请款单据，并不产生任何帐务处理。“批准付款请求〞：同意付款。作业功能组织示意图关键数据公司代码，员工编号，币种员工差旅费报销现状与需求综述参见2.3.2.1解决方案用清帐功能，输入所有发生费用，费用与预支差旅费间的差额挂在帐上，由自动收付款程序进行收付款处理。员工差旅费报销处理流程功能说明“审核报销清单〞：由会计部依据“差旅费报销原则〞；决定原始凭证是否齐全，是否有效，报销金额是否正确。“清帐处理〞：清员工差旅费预支金额，借记费用等科目，预制差旅费与费用的差额，挂在帐上。作业功能组织示意图关键数据员工编号，币种，会计期间，公司代码员工差旅费报销催单及冻结处理流程现状与需求综述没有电脑化的催单、冻结处理。解决方案未来的系统将利用SAPR/3应收帐子系统催款功能，设定报销期限，对超报销期限未报销的预支差旅费产生报销催单，通知员工前来报销，并冻结员工明细帐。解除员工明细帐冻结标志由手工处理。处理流程功能说明“运行催款程序〞：系统每天运行催款程序，以产生员工差旅费报销催单，并且自动冻结超过报销期未报销的员工明细帐。作业功能结构示意图关键数据员工编号，报销期限，预支金额日期员工明细帐帐龄分析处理流程现状与需求综述参见1.3.2.1解决方案未来的作业流程，通过帐龄分析列出未报销的预支差旅费的借款期。处理流程功能说明“运行帐龄分析程序〞：定期运行帐龄分析程序，得到未报销的预支差旅费帐龄清单。作业功能结构示意图关键数据员工编号，公司代码。预收款处理现状及需求分析关系企业间销售，没有预收款要求，集团外客户，一类不需预收款，一类需要预收款，需要预收款客户，它的预收款必须覆盖供货金额，否则不给发货。通过营管系统的销售，预收款在营管系统内处理，通过接口程序导入总帐系统。预收款按部门归集。解决方案为了解决营管系统缴款与财务实际到款的时间差，设置在途款科目；营管系统内预收款通过批处理程序导入SAPR/3应收帐子系统，暂记在途款科目，然后由财务部门依据银行到帐单，在总帐系统中把预收款从在途款科目转入银行存款科目。预收款与客户欠款方挂钩。对不纳入营管系统的销售，预收款处理在SAPR/3中处理。处理流程功能说明“启动批输入程序〞：系统自动启动批输入程序，预收款从营管系统导入SAPR/3应收帐系统。“检验日志〞：指派专人负责检查日志，如有错误，按错误性质，分送不同部门解决。“下达预收款请求〞：批准预收款请求，通过自动收款程序收款。作业功能组织示意图关键数据公司代码，客户代码，欠款方编号，会计期间，币种发票处理现状及需求分析对外产品销售发票，由营管系统通过接口程序输入帐务系统。关系企业间的销售，发票由手工输入帐务系统。零星发票（包括总部费用分摊）由手工输入帐务系统。解决方案通过营管系统的销售，发票由营管系统通过批输入程序导入SAPR/3系统。关系企业间销售及未纳入营管系统的销售，在SAP销售子系统处理，销售发票由销售子系统导入应收帐子系统。零星发票由手工输入应收帐子系统。其它应收款由手工输入系统。对于换货处理，营管系统并没有重新处理发票动作，需要在总帐中输入一个凭证，更改销售收入：借：甲产品销售收入贷：乙产品销售收入处理流程零星发票/其他应收款手工输入处理功能说明“生成销售系统的发票〞：系统自动定时启动批作业程序将营管系统的销售发票导入SAPR/3的销售子系统，作业功能组织示意图关键数据客户代码，欠款方编号，公司代码，币种，会计科目，会计期间收款处理现状及需求分析通过营管系统的缴款用缴款单代传票方式，通过接口程序将缴款处理传入帐务系统，其余收款由手工输入帐务系统。缴款入帐日与实际达帐日不一致。解决方案为了解决缴款入帐日与实际达帐日不一致，设置在途资金科目，缴款入帐时，借记在途资金科目，然后依据银行到帐单，在总帐系统中将缴款从在途资金科目转入银行存款科目。通过营管系统的缴款，用批输入程序将缴款导入应收帐子系统。然后通过清款程序清客户发票与缴款，预缴款。不通过营管系统收款直接在SAPR/3系统通过自动收款处理，在现金管理中描述。自动付款将覆盖应收帐款和其它应收款。处理流程作业功能结构示意图关键数据客户编号，欠款方编号，付款条件客户、欠款方催款及冻结处理流程现状与需求综述没有电脑化的催单及冻结处理。解决方案未来的系统将利用SAPR/3应收帐子系统催款功能，进行催款处理，对超过付款期限的客户、欠款方生成催款通知书，通知客户、欠款方付款，按催款等级自动冻结客户、欠款方明细帐。解除客户、欠款方明细帐冻结标志由手工处理。处理流程功能说明“运行催款程序〞：系统定期运行催款程序，以产生客户、欠款方催款通知书，并按催款等级自动冻结客户、欠款方明细帐。作业功能结构示意图关键数据客户编号、欠款方编号，付款条件客户、欠款方明细帐帐龄分析处理流程现状及需求综述国际集团需要及时清楚地了解客户、欠款方的欠款的详细情况及欠款期。解决方案未来的作业流程，通过帐龄分析列出客户、欠款方明细帐的帐龄情况。处理流程功能说明“运行帐龄分析程序〞：定期运行帐龄分析程序，得到客户、欠款方明细帐帐龄表。作业功能结构示意图关键数据客户编号，欠款方编号报表需求客户、员工、欠款方余额表客户、员工、欠款方帐龄分析表应收帐与营管系统客户帐款余额调节表（顶新要求增加）未来可能的改进一旦HR系统实施后，员工差旅费管理将得到进一步加强。可以有效方便地控制员工借款，报销期限，可以方便地和费用管理整合起来。

三. 应付帐综述现状国际集团有多种采购模式，现描述如下：国内采购

采购订单，发货

发票，付款

各子公司直接对供给商下订单，供给商对各子公司发货，供给商开发票给各子公司，各子公司匹配发票、订单、收货记录，核对无误后，向供给商付款。海外采购

采购订单，发货

发票，付款

各子公司按照需求，向顶益(BVI)、顶杰(开曼岛)提出采购请求，由顶益(BVI)、顶杰(开曼岛)向海外供给商下订单。海外供给商直接向各子公司发货，各子公司将验收单提交顶益（BVI〕、顶杰（开曼岛〕、海外供给商开发票给顶益（BVI）、顶杰（开曼岛），顶益（BVI）、顶杰（开曼岛）开发票给各子公司、各子公司付款给顶益（BVI）、顶杰（开曼岛），顶益（BVI）、顶杰（开曼岛）付款给海外供给商。海外采购涉及担保业务 未来的设想未来的应付帐子系统将包括供给商主数据定义，预付款请求处理，预付款处理，发票处理，发票清预付款，手工付款处理，自动付款处理，对帐单处理。未来的应付帐子系统与其它子系统是紧密集成的，与采购有关的供给商发票由采购模块导入应付帐子系统。未来的业务处理，对于海外采购，将把海外公司作为国内各采购公司的供给商，把海外供给商作为海外公司的供给商，都走应付帐流程。将顶新工程看作普通供给商，走关系企业往来交易程序，顶新工程本身采购、应付帐处理在顶新工程专案中解决，不列入本报告。在未来作业处理中，与采购作业无关的非备用金付款都将走应付帐流程，如薪资付款，与之相对应，由财会部替各受款方建立主数据。应付帐系统内，所有付款都采用自动付款处理。未来的系统中，通过SAPR/3的特别总帐处理来区别关系企业的应付货款、应付设备款、应付融资款。未来的系统中，在途和暂估会计作业月末由系统自动评估，下月初系统自动冲回。自动付款、利息计算及汇票管理将在现金管理局部描述。与其他模块的集成应付款在系统与采购，总帐，资金管理有数据交换。主要业务流程供给商类主数据建立现状与需求综述供给商数据存放于MFG/PRO，帐务系统不能共享。每个供给商作为一个二级分类帐，编入会计科目。其它应付款所涉及受款单位作为二级科目，编入会计科目，并没有建立供给商主数据。解决方案未来的系统将建立集中供给商主数据，由品保部门决定供给商编码，采购、帐务分别维护各自数据，帐务部门仅维护与帐务控制有关数据。在未来的系统中，帐务部门负责受款方的编号，帐务主数据的维护。处理流程功能说明“维护主数据〞：财务部维护供给商，受款方的统驭科目。付款条件，银行帐号等数据。作业功能组织示意图关键数据公司代码，统驭科目。预付款处理现状及需求综述预付款科目按请款部门划分，并不按供给商划分。预付款清款由请款部门控制。会计部门缺乏严格控制。国际集团希望与采购有关的预付款与采购订单挂钩。解决方案预付款和供给商、受款方挂钩，为采购订单所付的预付款，在预付款请求，预付款传票中输入相应采购订单号，以方便预付款与发票间清帐。预付款请求部门输入预付款请求，由财务部门审核预付款请求，审核通过后，下达预付款请求。由自动付款程序作预付款付款处理。处理流程功能说明“维护预付款请求〞：预付款请求仅仅是一种票据，并不产生帐务处理，维护预付款请求就是将预付款请求输入系统。“下达预付款请求〞：批准预付款请求，使它能被后续处理，如付款等。“冻结预付款请求〞：冻结预付款请求使预付款请求不能被后续处理，如付款等。担保的处理现状及需求综述集团总部帐务处理有担保的业务。解决方案将担保处理与供给商、受款方挂钩，但与供给商、受款方明细帐其它业务处理区分开，仅仅反映或有负债，并不后续收付款处理。处理流程功能说明“挂入供给商/受款方明细帐〞：将担保单作为一种特别业务处理挂入供给商明细帐，它仅仅是注释。说明或有负债，并无后续收付款处理。作业功能组织示意图关键数据供给商编号，受款方编号，公司代码发票处理现状及需求综述与采购处理相关的供给商发票，由请款单位开出请款单，本钱会计审核后，将请款单连同发票送至会计部门，会计部门审核后，进行发票处理，付款处理。折扣由采购部门决定，制作请款单时考虑。解决方案未来的系统是一个集成系统，它提供一套完整控制方法。建议国际集团采用如下方法：采购部门接到供给商发票后，由发票输入小组成员输入供给商发票进系统。此时供给商发票仅是预制传票，并不产生任何帐务处理，然后由会计部门的发票审核小组成员匹配采购订单，收货记录，供给商发票，决定是否下达供给商发票，一旦下达供给商发票，供给商发票将入帐。付款条件（包括折扣，付款期）存放在发票上。财务部门运行自动付款程序，完成付款处理，自动付款程序将考虑折扣，决定建议付款额。处理流程功能说明“输入供给商发票〞：将供给商发票输入系统，作为预制传票，暂存于系统，并不产生任何帐务处理。“审核供给商发票〞：

对有采购订单订单发票的处理：匹配采购订单，收货记录，供给商发票，以决定供给商发票是否正确。

对无采购订单订单发票的处理：审核发票及有关单据，以决定供给商发票是否正确。“下达供给商发票〞：批准审核通过发票，产生帐务处理。作业功能组织示意图关键数据公司代码，供给商编号，统驭科目，会计期间保存尾数处理现状及需求综述海外采购及设备工程款帐务处理涉及保存尾数业务，所谓保存尾数是指收货验收后，按照合同保存一定比例金额作为尾数暂不付款，待后续进一步检验后，按情况决定是否付尾数。解决方案对于涉及保存尾数业务的采购、工程工程，输入发票时，将合同规定尾数作为冻结应付款，暂不付款，后续检查完后，决定是否付款。输入供给商发票时，将应付帐分成二局部，对应于尾数局部作冻结处理，例如：一笔壹万元采购，该合同有10%尾数，输入发票时作如下分录：借： 对应科目 10000 贷： 应付帐 9000 应付帐 1000（冻结）处理流程发票输入流程参见3.3.3.2.1保存尾数的后续处理流程：付款处理现状及需求综述国内付款采用手工付款方法，海外采用自动付款。付款方式有：支票，现金，汇票，信用证，电汇，银行承兑汇票。解决方法采购部门及帐务部门输入发票时，在备注中注明清那笔预付款，财务部门审核发票时，以此手工清预付款、发票。采购部门可以查询预付款资料。付款采用自动付款方式，在现金管理中描述。付款入帐后，将产生的付款通知单用传真发送给对方。信用证存款，银行本票等将通过专设科目管理。处理流程功能说明“预付款清发票〞：用对供给商预付款抵消应付款。作业功能组织示意图关键数据供给商编号，公司代码产生其它付款的处理现状及需求分析现有系统中，其它付款在总帐中手工处理。国际集团有加强付款管理的需求。解决方案正如综述所言，在未来的系统里，其它非备用金付款走应付帐流程，用SAPR/3应付款各种处理功能处理其它付款。处理流程功能说明参见前面业务功能组织示意图关键数据受款方编号，公司代码，会计期间其它付款的付款处理现状及需求综述国内付款采用手工付款方法，海外采用自动付款。付款方式有：支票，现金，汇票，信用证，电汇，银行承兑汇票。解决方法帐务部门输入发票时，在备注中注明清那笔预付款，财务部门审核发票时，以此手工清预付款、发票。付款采用自动付款方式，在现金管理中描述。付款入帐后，将产生的付款通知单用传真发送给对方。处理流程功能说明“预付款清发票〞：用对受款方预付款抵消应付款。作业功能组织示意图关键数据受款方编号，公司代码报表需求供给商、受款方余额表预付款报表帐龄分析表供给商、受款方余额明细表未来可能的改进B级功能付款通知自动传真发送C级功能供给商催款供给商付款请求

四. 固定资产管理综述AA模块即AssetAccounting，在SAPR/3中用于管理固定资产。与其它的模块一样，AA模块也具有很好的集成性。它把逻辑上相关的事物联系在一起，集成处理，从而将取代目前手工输入总帐的操作方式，重复工作和多余数据被取消，规程被优化。未来系统的固定资产管理将包括在建工程、有形资产、无形资产和低值易耗，对下述的业务将有较强的支持：资产类别建立资产卡片建立在建工程结转资产购置资产转移资产计提折旧固定资产清理固定资产盘点资产租赁与其它模块的集成固定资产管理与总帐、应收、应付、采购和本钱会计集成。主要业务流程资产类别建立现状及需求综述目前有形资产共分五类：房屋及建筑；运输设备；电脑设备；机器设备和其他设备。解决方案资产类别的建立十分重要，它是资产明细帐与总帐以及费用核算明细帐连接的纽带。未来系统将不仅对有形资产而且还将对无形资产、在建工程和低值易耗根据需要分别建立若干个资产类别。资产类别的建立将由集团总部会计统一定义。业务流程功能说明：建立新资产类别：由会计决定类别编号范围、折旧方式、折 旧年限、科目分配等属性。作业功能组织示意图集团总部关键数据编码范围、折旧方式、科目分配资产卡片建立现状及需求描述目前有两类资产卡片：一类是固定资产卡，主要用于固定资产管理；另一类是列管资产卡，主要用于低值易耗品管理。两类卡片内容完全一样，均一式两联，使用部门和管理部门各一联。解决方案未来系统资产卡片中除金额和购置日期以外的信息输入将由管理部来完成。金额将由会计记帐时输入。资产编号由系统内部给定，且不同公司的资产编号的范围可不同。业务流程功能描述建立资产主数据：主要输入资产的名称、使用年限、本钱中心、位置等信息，资产的购置日期和资产的金额由会计记帐时输入。对于特别列管的资产（如海关监管设备），将在实施过程中挑选备用字段存放与特别列管有关的数据，这类数据只能作为信息显示。作业功能组织示意图：公司：法定实体本钱中心：费用归集单位关键数据资产类别、折旧年限、本钱中心、开始折旧日期、折旧方式在建工程结转现状及需求综述在建工程结转固定资产，大多数公司采用转移方式，只有个别公司采用结算方式。解决方案业务流程功能描述在建工程结转固定资产提供两种方式：一种是转移方式；一种是结算方式。创立固定资产主数据：亦即建立固定资产管制卡清理未清的预付款：用收到的发票和预付款进行清帐创立结算规则：定义结算的百分比、接收者等等。作业功能组织示意图公司：法定实体关键数据资产主数据、结算规则、资产类别主数据、处理类型资产购置现状及需求描述目前购置的固定资产验收后即投入使用，而会计部门却只有当部门请款时才入帐，由于使用部门延迟请款，经常造成帐实不符。解决方案建议顶新集团建立一个完整的有关固定资产验收、请款的规章制度。业务处理流程功能说明固定资产入帐A：固定资产－中间过渡科目（GR/IR）间 记帐，记帐时必须填入订单号。记发票：供给商（应付款）－中间过渡科目（GR/IR）间记帐，记帐时必须填入订单号。GR/IR科目的清理，依据定单号来处理。集成记帐：固定资产和供给商（应付款）记帐同时完成。固定资产入帐B：在CO（Controlling）中内部订单结转时入固定资产帐。作业功能组织示意图公司：法定实体本钱中心：费用归集单位关键数据供给商、资产、采购订单号、处理类型固定资产的转移现状及需求综述目前固定资产在部门间转移时，填制固定资产转移单，以此修改固定资产清册和固定资产明细帐。解决方案业务流程功能描述确认两个资产的折旧方式一致性：是指被转移资产的折旧区域，折旧计算等必须在接收资产中有同样的管理。在建工程结转固定资产：详见1.3.3...作业功能组织示意图公司：法定实体本钱中心：费用归集单位关键数据资产主数据、处理类型、本钱中心资产计提折旧现状及需求综述目前有形资产共分五大类，采用线性折旧方式。每月底计提一次折旧。解决方案业务流程功能描述计提折旧：这是系统提供的标准程序，用户只需填入适当的参数即可。它采用批处理方式一次完成所有资产的折旧计提。作业功能组织示意图公司：法定实体本钱中心：费用归集单位关键数据：资产类别主数据、资产主数据、本钱中心固定资产清理现状及需求综述目前主要涉及的是由于出售、报废和毁损等原因造成的固定资产减少。由于清理而减少的固定资产原值记营业外支出，增加的固定资产原值记营业外收入。解决方案业务流程功能描述集成记帐：它将固定资产和应收帐款集成处理。记收入帐：固定资产和应收帐款不是集成处理的，在资产出售时只记收入，以后再由负责应收帐款的会计记应收款。无收入资产清理：将减少的固定资产原值记营业外支出。作业功能组织示意图公司：法定实体关键数据资产的有效日期、客户主数据、资产主数据、资产类别主数据、处理类型资产盘点现状及需求综述固定资产每年不定期盘点，每次盘点后均做盘亏、盘盈处理解决方案业务流程功能描述确定盘点范围：指明哪一个公司，哪一类的资产由谁负责去 盘点。盘亏处理：做资产报废处理，净值记营业外支出。盘盈处理：做资产购置，净值记营业外收入。资产盘点记录将以资料（Document）的形式保存在系统中，按照资产编码可以查找盘点历史记录。作业功能组织示意图公司：法定实体本钱中心：费用归集单位关键数据资产类别主数据、资产主数据资产租赁现状及需求综述目前租入的资产不记公司固定资产帐，只是每月交一定费用给对方；出租的资产属公司固定资产，每月要计提折旧，且收取一定的出租费，收入记营业外收入。解决方案若需在系统中列出租入的资产，则可为租入的资产单设一个资产类别，在该类别下创立租入资产主数据。根据租赁合同，可手工在系统中产生付款的周期性凭证，以后只需启动付款程序即可；出租的资产其购置、折旧等处理方式与非出租资产的处理方式是一样，只是需要在系统中可列出哪些资产是出租资产，为此只需在其资产主数据中的某一个域中加一标识即可。因其业务流程、功能描述、作业功能组织示意图和关键数据与以上业务的描述类似，在此不再重复。产生的报表资产类别清单财产目录表资产变动表未来可能的改进B级功能后续资本化固定资产重估折旧模拟/预测租赁合同修改C级功能特别折旧

五. 法定合并综述有关国际集团目前法定合并的描述参见《现状分析》第25页至27页。国际集团作为一个大规模跨国公司。在集团报表合并上有很大的需求。M2专案命名的本身涵意也在于提高集团内部的管理水平，加强各公司与总公司管理经营信息的整合性以最后到达大幅度加快集团报表合并的速度。目前顶新集团的合并采用分部合并的模式，由总公司（或事业群）采集下属各分公司的会计数字，逐层手工合并。这其中，最大的困扰是：业务资料的整合性业务资料的正确性和相容性业务资料的及时性业务资料的重复性……（详见《现状分析》第五章弱点分析。第87页至89页）。未来系统将是一个高度集成的体系。它的最大效益是在全集团各企业各方面业务都使用了此系统后充分表现出来的。SAPR/3的法定合并能够为各子集团层面提供合并支持，可以以不同的角度产生法定合并报表。而在管理层面上的对产品别损益，事业群损益的分析则可以在利润分析模块（CO-PA）中得到支持。相较分步合并与同步合并的优缺点，我们建议采用同步合并的方法，在应合并的子集团内一步到位将各子公司间的往来同时抵销。合并的主要过程是：根本数据的维护各分公司的局部调整与结帐各分公司的财务数据呈送或采集集团、子集团的合并步骤及合并报表生成

这些流程将在下表章节详细分述与其它模块的集成合并系统仅与总分类帐及报表信息系统直接集成，所有的与财务会计相关资料应收，应付，固定资产，银行帐等通过总帐转入合并帐薄。透过与报表/信息的接口，可将合并处理过的信息进一步传递到更高一层的报表/信息系统层（如：EIS执行信息系统）。主要业务流程根本数据的维护现状及需求综述合并过程的根本数据有：公司集团、子集团合并报表项及会计科目表公司是法定合并过程中的最小单位，为了开展合并，所有集团内的公司在整个集团中必须有一个唯一的代号。集团、子集团做为合并的主要结点是合并过程的关键组织结构之一。合并中须有一个集团表包含全体公司，来表示全集团，其它子集团的组成是全体集团内公司的任意组合，它可以是法定的观点来组成的，也可以是区域性的或具有内部性质的。合并报表项为合并数据汇总的结点，可以理解集团合并报表内的各个明细工程。可依据集团统一的科目表设定。当前集团内部科目表尚未统一，各分公司内部使用的科目表不完全统一。给合并过程增加了一定的工作量。为了更有效地管理掌握全集团的合计数据，加快集团合并速度，集团内部应有统一的会计科目编码。解决方案建议顶新集团建立统一的会计科目表，由总公司及分公司会计部门分层次控管，详见总帐局部相应描述。SAP的科目维护的结构支持这种模式。建议顶新集团结合集团内报表标准及集团会计科目表定义一套标准的合并报表项总目录，由集团会计部中心负责维护管理。业务流程组织结构的维护（集团、子集团、公司）会计科目表及合并报表的维护功能说明维护公司：由总部会计为集团内的每一公司定义基础数据，或在信息发生变动时维护已定义的公司。维护集团、子集团：由总部会计或子集团会计定义维护集团或子集团的根本数据，这包括集团（子集团）内的各公司，数据采集的方式，合并的频率等。输入投资表或投资变动表：通过此功能输入集团（子集团）中母公司对各子公司的投资关系及其变化。定义集团会计科目表：由总部会计科目维护小组将预先设计好的集团会计科目表（该会计科目表应包含所有各子公司用到的会计科目）输入系统。定义集团报表项：由总部会计科目维护小组将预先设定好的集团报表项输入系统。集团报表项可以由集团科目表产生。发布科目表及合并报表项：由总部会计科目维护小组将所确定的会计科目表，合并报表项及使用规则分布到下属各子公司财会部。各分公司财会部应严格依照此科目表及使用规则进行帐务处理，上报相应的财务数据。修改或补充集团会计科目表：由总部会计科目维护小组对集团会计科目表作必要的修改和扩充。修改或补充合并报表工程：由总部会计科目维护小组对集团合并报表工程进行必要的修改和扩充。作业组织示意图关键数据局部调整结帐现状及需求综述目前分公司（子公司）根本上是次月9日左右结帐，将报表传真到总公司（母公司）进行汇总合并，上报的报表常有错误。为满足M2专案加速集团报表合并的主要目的，分公司（子公司）应该更快地结帐，快速地将正确的数据传送到总部。解决方案在统一使用集团会计科目表的前提下各分公司（子公司）的会计资料统一性将得到很大的改善。公司间往来差异是目前集团内会计资料整合时的一大困难，针对这一特点，我们建议各分公司（子公司）在结帐前先相互进行一下往来帐预对帐，解决大局部差异。经讨论顶新集团初步决定，由应收方主动提出明细对帐单，对帐次数为每周一次。应付方未于期限内作确认回复，即认为默认。业务流程功能说明预对帐：对帐通常是应收款、应付款中的一项处理流程。因为我们为顶新集团设计的相关企业往来完全通过应收帐款和应付帐款来处理，而且也建立相关企业在结帐前先进行预对帐，故将此流程放到这边描述。对帐可以表现为如下几种不同的形式：余额确认：由甲方寄给乙方，乙方在甲帐上的余额，并要求乙方确认，如乙方在约定的时间段内不做出反应则认为是对余额默认。余额问询：由甲方向乙方问询甲方在乙方帐上的余额，甲方获得信息后与乙方在甲方帐上的余额相核对。明细对帐：由甲方寄给乙方：乙方在甲方帐上发生的各项交易明细，要求乙方核对并确认。系统支持上述各种模式，并打印出相应的预对帐信函。建议顶新集团选择其中一种或多种模式（每月进行余额确认，年末进行明细对帐等），并决定预对帐启动的方向（如：由应收方向应付方要求确认）。分析对照余额及明细：应确认方在收到确认请求后对余额进行对照。在发现差异时应通过交易的明细进行进一步的分析。互相调节：双方会计对往来的差异互相调节并进行相应的帐务调整。按照公司规定进行结帐：分公司（子公司）按照总公司（母公司）的会计准则进行结帐工作。在总公司统一发布的会计基础上对财务会计数据严格按总公司的会计制度进行处理。

如：帐户的归结、

折旧的计提、

本钱费用的分摊与核算、

外币兑换率

坏帐处理等等。呈送总公司（母公司）：分公司（子公司）将会计数据呈送总公司。这里可以有多种多样不同的形式，在下一流程数据采集中详细计论。作业功能组织示意图关键数据数据的采集现状及需求分析目前各子公司的财务数据根本上由传真形式寄到总部汇部，集团未来的最终目标应当是在一个整合的一致性环境中自动地将各分公司（子公司）会计数据收集到总公司（母公司）汇总分析。在到达最终目标过程中由于各公司的合计及资讯系统不能一步到位，同时上线采用一套统一的系统，而是一个逐步推广的过程，因此需要在过渡阶段从一系列截然不同的环境中获得财务数据进行汇总分析。解决方案R/3系统法定合并的数据采集支持多种不同数据源及不同采集模式的并存。我们建议为了简捷实施，对上线使用R/3的分公司采用直接记入，或数据自动传递。对未上线使用R/3系统的分公司选用表格录入方式或PC文件转换的方式。数据采集模式示意图直接录入：与中心合并系统使用同一系统公司，其财务数据可以实时地、直接地录入中心合并数据范围，参与合并。自动传递：在另外一套R/3系统上进行财务会计核算的公司，其财务会计数据可以经汇总后自动传递到中心合并系统。这种情况在集团内进行的分布式数据管理时出现。手工表格输入：对于仍然采用手工形式进行财务处理的公司使用没有开放式接口软件进行帐务处理的公司，最简捷的方式就是将各财务数据直接录入合并系统，合并系统提供相应的表格式输入形式。文件转换：对于使用带开放式接口软件进行帐务处理的公司可以考虑，由其产生附合R/3接口格式的文件并转换入R/3合并系统。合并步骤现状及需求综述目前系统用微机工具进行合并，大局部的抵销工作能够得到支持。未来系统在合并过程中应该对内部往来的抵销，投资的合并以及报表的产生各步骤均有更好的支持。解决方案SAPR/3的系统对合并过程的各个步骤都提供了完善的支持，对合并工作会有很大的减轻帮助。在所有合并步骤完成后可以产生完整的合并报表，也可以在合并过程中产生中介报表以便分析比较。如抵销前报表和抵销后报表。业务流程功能说明标准化：在必要时对各公司上报的会计数据按总部会计准则进行标准化调整。在合并系统中输入调整分录。往来帐调节：总部会计可以按需要决定是否调节往来帐间的差异，或将差异按照一定原则处理（如总的应收方或应付方的数据为准）并依此做一些调整分录。货币换算：在参与合并的公司使用一个不同于集团的货币为记帐本位币时，用此功能进行自动的货币换算。往来帐抵销：根据上报的财务会计资料，通过一一对应的关系冲销相关企业间的应收/应付，销售/费用的业务。用同步合并此方法，可以一次性地冲销全集团内的各子集团内的所有相关企业的往来。存货及资产利润抵销：由于存货核算价格的不同，以及由于资产转让时帐面价值的不同会产生公司间利润/亏损。这些利润和亏损在合并时应予以抵销，通过这一功能，可以到达抵销的目的。投资合并：参与合并的企业投资形式，投资变化都能通过这一功能处理得到解决。考虑到的不同资产合并情形有： －首次合并 －后续合并 －增资/减资 －内部转让/外部转让等支持的合并方法有： －权益法 －本钱法 －完全合并法等生成合并报表：在参与合数据及在合并步骤产生的调整分录的基础上可以用各种不同的报表工具产生所需要的合并报表。作业功能组织示意图关键数据主要报表资产负债表 按集团、子集团（如事业群）损益表 按集团、子集团投资关系表调整分录清单此外可以通过报表生成器在合并数据上产生所需要的其它报表。未来改善的可能未来系统应会是个联网的整合的系统，当各公司都推广使用了R/3系统后，数据的采集和交换将会大大加快并简化。当第二阶段实施执行信息系统时（EIS），可以将合并数据传到（执行信息系统）为执行管理层人员提供更好的报表和分析环境。在未来阶段，与办公室系统的接口投入使用后可以考虑自动通过电子邮件传递相应的预对帐单。对管理合并的报表需求（如事业群损益表考虑公司跨事业群的情况）将在管理合并模块开发完毕并投入使用后得到完全的满足，现阶段.产品别损益及事业群损益可以通过利润分析(CO-PA)给予解决。详细描述见利润分析有关章节。如不考虑有公司跨事业群的情况，则事业群损益完全可以在法定合并中得到解决。

六. 资金管理综述顶新集团总部财务部在资金管理方面的主要工作范畴是:资金调度资金管理国际金融而分公司财务部门的工作范围则主要侧重于简单的资金管理，大额的调度与操作日前仍集中在总部处理。对现阶段工作流程及其电脑化程度的描述参见《现状分析》第29页至第39页。目前资金管理调度各方面的处理多以手工作业加上EXCEL等简单PC工具支持为主。未来系统将对以下资金管理范围主要业务有有较强的支持。自动付款处理收到支票处理付出支票处理银行未达帐处理(包括兑现支票处理，银行对帐处理)应收汇票处理应付汇票处理对信用证的支持现金状态和流量分析短期存款/借款管理利息计算资金调度与国际金融方面的流程根本上可以保持目前手工式流程,传票转为在系统中直接录入。待将来系统开发到第二阶段做进一步的改善。信用证的功能在4.0版本后才能提供，鉴于进口业务较为频繁，我们将在现版本系统中借用汇票管理功能提供一个临时的中介方案，局部地支持信用证流程。总的来看第一阶段系统对资金管理的支持主要表达在：及时的信息采集和汇总目前所需的几个根本报表简单操作支持至于对投资敏感及风险的分析，投资模拟债券和融资管理。外汇避险操作等目前还没有充分的支持。资金管理与其它模块的集成资金管理以总帐，应收，应付帐中得到信息，并结合资金管理过程中产生的信息（收、付款，银行对帐单等）。为资金流量及现金需求预测提供分析基础。为满足跨公司进行资金流量分析的需求，我们将所有公司定义为一个财务管理范围。资金管理主要业务流程自动付款处理现状及需求综述目前付款作业及传票的录入多为手工形式，海外局部公司银行有电子银行接口。付款方式分别有：支票汇票电汇现金委托收款{总部每天现金量为12万左右}付款的审批过程相对严格，完整。解决方案为更有序地管理资金，利用资金，我们建议：尽可能减少现金付款的局部，降低企业备用金给现金付款设定一个上限除现金付款外，其余付款一律通过应付帐款/人事系统管理，并启用系统自动付款处理功能。需求局部分析要求的各种付款方式除了委托收款处理外，均能在系统中通过设定相应的付款方式得到解决。从应付帐款处理中产生的应付帐工程在付款期限到达后均被自动付款系统理解为应该付款的工程。除了正常的请款批准程序外（如采购流程中所描述），我们还可以按需要再加一层请款审批过程，即在相应的应付款工程中加上付款冻结，并由批准人“解冻〞，被冻结的工程在自动付款时将被排除在外。自动付款的过程就是考查所有应付帐款中的应付工程，并依据所定义的付款方式作出付款建议，经确认后正式付款。根据惯例可周期性安排付款处理。此外，如有临时需求（例如：发现某些应付款项被遗漏，或其它异常状况）。业务流程功能描述“应付帐款处理〞：通过应付帐款处理，产生应付款工程。“批准请款〞：手工解除应付款工程的付款冻结或将预制凭证过帐，并签字。“设定自动付款〞：在系统中定义一个付款任务，可以对供给商，银行付款方式等进行不同组合的选择，可定义启动时间。“产生付款建议书〞：运行自动付款程序，系统根据设定的付款方式，付款策略，供给商的应付款项产生付款建议书。“修改付款建议书〞：在线浏览付款建议书并进行必要的改动：可改变银行，帐户，付款方式，折扣率等。“正式运行付款〞：正式执行修改正的付款建议，系统自动产生传票并过帐。根据定义和设定还可自动打印付款媒介（纸面的或电子的）及付款通知。“产生付款媒介〞：在自动产生的付款媒介不被银行接受的情况下可以手工填写支票，汇款单等。作业功能组织示意图关键数据参与付款过程的主要数据是：收到支票处理现状及需求综述现阶段对收的支票没有特别管理。为更好地管理收到的支票，未来系统应对收到的支票在入帐的同时自动产生记录随时提供持有支票的总览及其处理状态（已清，已过帐）与未达帐处理连接解决方案使用R/3系统中收到支票处理功能可以满足上述需求。业务流程功能描述“输入支票信息及客户信息〞：依据所收到的支票输入：

支票号，货币，金额，及准备递交兑现的银行等信息。依据客户寄来的信息输入客户帐号或应付款项的凭证号等“查询〞：可在线显示输入暂存的支票信息，或打印相应的清单呈交检查。“检查〞：由会计部门检查并确认输入信息的正确性“修改〞：在输入支票信息未过帐前可对输入的信息进行修改调整。“过帐〞：启动过帐程序，系统自动产生相应的记帐，通常为：

借：支票结算的过渡科目

贷：应收帐

并产生相应的银行未达记录。收到支票的信息，也同时被更新（处理状态）“清帐〞：由会计在应收帐方面对未能够自动清帐的工程进行处理。组织结构。参见1.3.1.2.3关键数据付出支票处理现状及需求综述现系统对付出使用的支票没有特别管理。未来系统为了更好地管理使用支票，应提供如下方便：管理空白支票号码付出的支票与记帐凭证相连接付出的支票应先记银行未达帐当已兑现支票信息回馈时应相应处理未达帐并对支票做相应的标识。解决方案使用R/3中付出支票管理功能可以满足上述需求。业务流程功能描述“手工填写〞：手工填写支票，将来在与银行协调后可以让系统根据自动付款凭证信息，打印支票。系统能够套打支票格式，产生支票与付款凭证的连接信息。如果采用手工付款，在输入付款凭证时可以输入支票信息，这个过程保证了付款凭证与使用支票的连接。“查询〞：业务人员可用此功能在线查询支票信息。或打印出使用支票清单。查询与清单可以银行分别归类。查询方式可以付款凭证或支票号码为依据。“注销错误支票〞：当发生打印错误或其它错误时，用此功能可以将错误支票注销为无效。用户可以在注销时定义注销原因“审核〞：检查并审核支票各方面信息的正确性。“签发〞：签署支票并发送给