财务自开发系统的一些想法（实现篇）

财务系统自开发的一些理解（实现篇）

Thursday, October 27, 2016

11:30 AM

 

  理论篇论述了几类财务系统的概述和问题，那么在关于这几类财务系统如何开发实现将在本文中论述。

  

  首先，本人大部分实现的经历是基于SAP，或者用友，工作初期是ERP系统自开发经验，也有些小众系统使用过。这个也是现在现状，因为现实中大部分公司都会使用已有的财务系统，上文也论述过，财务系统的是有统一规范（财务准则），统一要求（三大标准输出），统一操作（复式记账，借贷项），所以对于大部分常规公司来说，的确没有必要重复造轮子，在市面上随便卖一个U8就可以了，而去大部分会计都熟悉使用，用不着专门培训。

 

  但是，但是，随着现在大量互联网公司出现，尤其是新的业态和新的公司类型。大量网上交易和复杂的收付款结算点，使得传统的通用+定制的财务软件有的无以为继。比如之前一段时间，苏宁云商互联网商场的大量订单，对以SAP为核心的系统巨大压力，现在苏宁也准备往自开发方向转移。从现在来看，对于互联网公司金融公司，自开发系统可能是一个现在方向。

 

一、自开发财务系统和通用定制财务系统比对论述

   现在我们在论述下财务系统的自开发之前。首先说下财务系统开发的几大基础。

·        基本操作：复式记账，一借一贷，必须相等

·        基本规则：财务准则；一般必须满足国内财务准则，主要在资产折旧，期间结算，报表出局方面。强大的

·        基本实现要求：能争取出局三大报表，有些地方不需要现金流量表，但是至少必须出具资产负债表和损益表。负债表是相关资产负债科目余额合计等到，损益表是损益类科目余额合计而成，表结法是现在比较流行结算方法。具体实现逻辑网上很多。

·        必须存在的主数据：会计科目表，公司货币，财务年度，凭证类型设定等。

     满足上面需求，基本就可以算是一个合格财务系统。

     自开发财务系统和通用财务系统都是一样，必须满足上面提到的几大基础。满足以后，基本就是满实现了最基础财务系统的要求。

      综合来说，自开发财务系统就是通用定制系统最大区别集成程度，如果对于报表行财务系统却别不大，但是对于系统集成型和管理型财务系统会有很大区别。对于如果使用用友SAP作为财务系统，而外围系统使用其他自我开发系统。必然存在以下情况：

·        集成度不高：接口多，数据库和数据表分离：因为多个平台需要进行数据传输，而且往往因为使用不同数据库，需要频繁传输数据；而外围单据实时生成财务凭证，往往这些接口成为系统瓶颈。甚至如果在大型促销阶段，由于很多订单回转（确认后取消）会对集成度有很高要求。

·        分析数据孤立：因为多个系统，当进行综合分析时候，需要跨数据表查询时间；查询时间长，因为跨多个系统，如果涉及到财务系统和其他系统数据

·        管理型财务系统难以实现：因为管理型财务系统是对于公司内部进行管理，其实已经深入各个分支业务系统；传输不单单是财务凭证，也包括成本数据，KPI数据，工时数据，产成品数据；由于传输的数据更多，难以显示。

 

       额外的话，对于SAP来说，基本都是整体实施，就是SAP的财务模块和采购，销售，人力管理模块和生产模块一起上线；这样才可以实现真正的管理型财务系统。如果单纯使用SAP作为财务系统，外围系统使用其他系统，这样只能达到系统集成型的阶段；如果外围系统和SAP的接口并没没有到实时产生财务凭证，而且简单的在每日制定时间传输；这样的SAP财务模块只能发挥比报表型财务系统略高阶段。

 

二、各个不同类型财务系统自开发设计论述

1、报表型财务系统开发

        报表型财务系统的自开发和通用区别：自开发和通用差别不大。却别就是具体实现方式，通用财务系统可能在一个C/S传统架构，或者是B/S架构，但是底层处理比较传统。自开发更为随意，可以直接在Excel表加入VBA和宏实现；或者直接数据库加WEB前段进行表操作。甚至可以不用MySQL/Oracle这样后台，直接在文本上进行处理。

·        核心内容：报表型财务系统主要涉及财务操作人员，可以说是把基本财务操作通过计算机进行记录，出具财务报表。较为简单，开发实践也很简单。

·        调查对象：财务部门会计经理，记账人员

·        工作流程：调研财务人员需求，确定财务主数据，科目表，日常常见操作，是否有接口需要，是否需要进行多个公司管理等；然后进行开发上线。

·        调研关注点：科目表制定，国内大部分公司都有标准的科目表价格，8位到10位，具体可以百度查询之，但是各个公司会有自己特点。同时就是常见凭证类型，比如收款凭证，采购凭证，这些常见凭证可以快速拉出，减少工作量。

·        开发设计：报表型财务系统开发较为简单。前台分为凭证输入界面，科目余额查询界面，主数据维护界面和报表生产界面，现在大部分都是通过WEB页面实现。后台主要是科目数据表；凭证表，一个凭证可以是一个统一编号多条信息，凭证号为统一凭证索引，有借贷项，金额，科目号，备注等字段；然后每个科目可以按照借项和余额纪录金额，方便快速查询。

·        设计难点：主要难点在科目表，和默认科目。还有就是这个比较简单，因为是操作人员直接输入，可以加入约束条件，以防不实际的数据输入。或者进行多次确认。

·        开发难点：基本无难度。

·        接口和扩展：

o   凭证导入接口：操作人员可以通过Excel或者TXT批量制作财务凭证输入，提供工作效率

o   报表导出：生成的报表可以导出Excel，这个没有什么问题好说

o   多个帐套：如果一套财务管理软件需要管理多个公司，在这里有个局限性，有两个方式，一个是加入公司代码栏位，在每次凭证和查询时候需要输入。或者使用帐套功能，每个公司一个帐套，这样设计比较简单。个人建议使用一个帐套，多个公司代码，这些如果进行集团公司出具合并报表时候，可以进行定制。

o   集团公司合并报表：这个就很有意思了，包括科目组设计，同时公司间交易需要对冲。其实原理上来说资产负债表就是按照科目余额相加合并，如果部分控股按照百分比进行计算。损益表需要扣出相关公司间交易金额。

 

2、系统集成型财务系统开发

        报表型财务系统主要通过手工记录财务凭证，产生法定法务报表；随着公司信息化深入，大量财务凭证和主数据可以通过外围系统触发传入，通过接口或者直接集成方式，可以大大提高工作效率。同时由于业务单据需要对应财务凭证验证，财务凭证有业务单据为源头，也提高了业务凭证和财务凭证的可靠性。

集成型财务系统的自开发和通用区别：就像上文所说，主要区别就是集成程度，大多数单独财务系统产品通过接口或者数据池来进行交互，数据量较小时候通过接口，当有多个系统交互时候，使用一个独立数据库作为数据池。财务系统定期扫描数据池中数据表是否更新，如果更新财务系统根据标识符读取时采购订单，还是销售订单还是其他什么订单；财务系统根据之前配置约定，生成对应的财务凭证，如果需要回写凭证号回到业务订单。

 

       而自开发财务系统可以采用两种方式：

·        由财务系统创建凭证：财务系统独立，当业务系统的订单可以触发财务凭证时候，业务系统传递财务凭证创建需要数据去财务系统组件，财务系统创建财务凭证并回写到业务订单，财务凭证信息统一在财务系统数据表中记录。

·        业务系统直接创建财务凭证：业务系统安装自己系统中约定的财务凭证创建规则和财务凭证编码，直接自行创建财务凭证，财务凭证在业务系统中建立。这样的免去数据交互过程，但是财务凭证分摊在各个自系统，各个系统有自己独立小账套。在进行查询和报表生成时候，财务系统要便利所有小账套并集合。当然，现在很多财务系统也会把金额对应科目等核心信息传递给财务系统，用于快速查询和报表生成；详细信息则保持在业务系统自身。

 

·         核心内容：

o   业务系统的财务规范：涉及财务凭证产生的业务系统，可以产生的凭证类型，凭证编码，各个事务可以触发的借贷科目。这些都需要规范，有些可以在财务系统规范，有些在业务系统规范。定义号业务系统订单和财务凭证的映射关系。

o   订单流转：业务系统中涉及财务凭证的业务订单流转，如果业务订单流转到可以生成财务凭证状态；业务系统触发生成财务凭证信息；当订单取消时候，也要出发财务凭证的冲销。

下表列出一些常见订单流转和触发财务凭证

系统	业务订单	状态	财务意义	对于财务凭证	备注
采购系统	采购订单	货物入库		借：库存 贷：GR/IR（暂估应付）
采购系统	采购订单	收到供应商发票		借：GR/IR（暂估应付） 贷：应付账款-供应商
财务系统	采购订单	销售单付款完成		借：应付账款-供应商 贷：资金银行存款	通常付款在财务系统处理，此处为销售订单回写到业务系统，确认订单完成。
销售系统	销售订单	订单取消		财务凭证回转	通常按照对应状态，回转财务系统财务凭证
销售系统	销售订单	货物发出		借：销售成本 贷：库存
销售系统	销售订单	给客户开票		借：应收账款 贷：销售收入
财务系统	销售订单	客户付款		借：银行存款 贷：应收账款	通常付款在财务系统处理，此处为销售订单回写到业务系统，确认订单完成。
OA系统	报销单	审批通过		借：管理费用 or 销售费用 贷：应付账款-员工
OA系统	报销单	付款完成		借：应付账款-员工 贷：银行	通常有财务系统处理，回写到OA系统
生产系统	生产订单	投入原材料		借：在制品 贷：原材料
生产系统	生产订单	产生品出口		借：库存-产成品 待：在制品	此处较为简单描述
资产管理系统	采购资产	资产资本化日开始		借：固定资产价值 贷：应付账款	假定通过采购获得固定资产
资产管理系统	资产折旧	月末资产折旧运行		借：管理费用/销售费用 贷：累计折旧	需要确保单个资产折旧金额之和，等于财务累计折旧金额
资产管理系统	资产报废	确认资产报废		借：资产处置损失 借：累计折旧 贷：固定资产价值	此处假定资产处置后，是损失

 

o   调查对象：各个业务部门中，操作业务系统的操作人员和经理。和对接财务人员。

o   调研关注点：业务订单和财务凭证的映射关系逻辑；回传逻辑；客户/供应商/资产的财务数据表示等。

·        开发设计：在开发设计时候，可以安装报表行财务系统建立报表行财务系统，然后考虑对外围系统对接方法。首先要确定是财务系统进行财务凭证出局，还是业务系统可以出局财务凭证。然后是对于业务订单对应的财务系统映射逻辑，触发阶段，回写逻辑，回转规则。还有订单多个合并一个财务凭证，或者一个订单拆分为多个财务凭证的逻辑。同时各个业务系统也要考虑自己主数据的财务字段加入等。

·        开发建议：以报表型财务系统为基础。保持财务系统独立性，同时要考虑的可以得复用性，接口稳定性，和订单暴增堆积后，是否会出现在订单为生产对于财务凭证问题。

o   以报表型财务系统为基础；

o   以业务数据可传递财务数据到导线

o   定义自动触发逻辑，对应产生的财务凭证的科目，借贷

o   如果回写，回写逻辑等

·        难点：

o   映射逻辑；拆分逻辑；订单取消后，财务凭证回转；数据量极大后如何保证传输稳定。

o   中间状态财务凭证：相对报表型财务系统中财务凭证是经过人工确认后输入，自动凭证中很多是处于中间状态，需要创建很多中间状态科目，比如

·        库存采购，采购品入库金额不等于将来收到供应商发票金额，所以入库产生的财务凭证中对应项为应付暂估；

·        生产产品，投入原材料，但是产成品还没有完成，需要进入WIP在制品中；

·        给客户提供服务，服务以及提供，但是没有收到发票，收入只能计入收入计提等

这些中间科目，都必须按照期间，进行清空，转移到确定科目。这些逻辑需要定义。

o   财务凭证回写到业务系统：大多数情况，数据传输时有业务系统传输到财务系统，业务数据影响财务。但是也存在回写的情况，主要一个是凭证号回写，一个是财务凭证回转影响业务系统，中间逻辑需要进行考量。

o   税务处理：税务系统可以是一个独立的系统，也可以集成到财务系统中。税务系统由于其特殊性，在集成时候会涉及外网销售系统，金税系统，财务系统三方互联。

·   进项税：采购订单生成时候，参照供应商、采购信息和事前约定，确定税率和可否抵扣。逻辑实现可以在采购系统，也可以在财务系统开发。那么直接传入进项税金额和对应增值税－进项税科目，或者进入成本。

·   销项税：销售订单产生，安装客户、销售信息，确定税率，此时传入财务系统，生产贷：增值税－应付销项税。但是开局发票需要从财务系统传入到发票打印系统，根据客户主数据，一般纳税人还是小规模纳税人，开局专用增值税发票或者一般增值税发票。而且发票号和开票信息需要回传到财务系统。而且该开票信息还要回传到销售系统。

·   期末报税：期末报税需要申报表，包括销售信息，财务信息，和开票信息等很多数据，这些数据通常按照财务系统为核心，从各个分系统查询后集合。

o   与银行银企互联：财务系统和银行系统互连，与金税系统类似，付款，收款，资金池归集的操作都要涉及与银行进行数据交互

·   供应商付款：接到业务凭证传来供应商发票，到达可付款日期后，财务系统提示需要付款；财务系统生成付款信息，包括金额，付款对象等传入银企直连平台付款；银行返回付款成功信息，财务系统产生贷：银行 借：应付账款的清账凭证。并传入采购系统。

·   客户收款：定期查询银行金额，按照标志位，收到客户收款后，财务系统更新应收款清账，并传入销售系统。

·   资金池归集：与银行商议，定期进行分子公司资金归集处理，银行完成后，传入财务系统，产生对于财务凭证。

·        接口和扩展：

o   接口：已经说了很多，保证接口实施稳定反应及时。

o   资产管理/客户/供应商主数据同步：当业务系统创建了主数据时候，有必要在财务系统建立对应的主数据信息，方便进行财务视角的管理，如资产折旧惯例；客户信用管理，供应商价格管理

o   多个账套：考虑的基础系统复杂性，通常不会实施多个独立账套进行多个公司管理，而是采用一个账套加公司代码区别

o   多个会计准则：可以采用平行帐模式解决；实现是业务系统出发凭证是时候，根据不同映射规则，同时生成两个凭证，写入不同账套。

o   集团公司报表合并：此处差别不大。

 

3、管理型财务系统开发

        传统的财务系统主要目的是通过记录日常财务凭证，生成提供给政府公众的三大财务报表。而管理型财务系统则在完成政府报表出局这个要求后，更多关注通过财务系统，进行企业内部管理，优化运营，提升企业效益。

        而且由于财务系统相对于其他业务系统更为标准，更为严谨，可信度高，所以通过财务数据作为支持进行公司管理，比较合理。

        由于管理型财务系统需要于己于系统集成型财务系统之上，加上更多的数据和业务系统交互，所以对于实现比较好的管理型财务系统，必须是和业务系统紧密结合，甚至必须是一个紧密结合的系统。所以单个独立的财务系统和外围系统结合的方式比较难以满足管理型财务系统要求，一个整体统一系统必须的。不论是自开发或者通用。

集成型财务系统的自开发和通用区别：

       现在能比较好实现管理型财务系统的通用系统都是多个功能组件一体的，比如销售模块，采购模块等一起。而去要完善的订单管理系统。通常来说即便是通用平台也要通过大量的自开发或者定制增强，来时具体情况实现，某种意义上来到管理型财务系统，自开发和通用平台功能上区别已经不大。更多情况时在海量数据情况下，自开发平台因为底层实现的自主化，有更高的增强机会。

·        核心内容：

3.1 成本管理：

成本管理，其实是指目标就是把所有企业运营生产的成本，经过各个层级考核分析，从费用采购录入，分配到部门，再通过部门服务方式，按照工时，产成品数量的因素，传递到业务部门的每笔销售的销售成本，生产部门的每件产品的产成品成本，和项目部门的项目成本上去。

成本管理可以实现查询到某个部门，某个业务，某项项目的成本。给公司费用管理提供支持，同时可以为转移定价提供基础。

o   主数据：

·   成本中心：产生费用的单位，主要是部门，也可以是销售门店，或者其他单位

·   费用类订单：这里包括内部生产订单，给客户销售订单，和项目订单，通过费用都是最后转入这些成本上去，并输出到销售。

o   分配逻辑－这里用电费举例

·   每月电费费用通过费用类财务凭证过帐形式进入系统，费用付款部门时财务部，作为费用第一级承担部门

·   财务部按照对于后台部门按照人数，对于生产部门按照机械工程数量，对于销售部门按照销售门面面积，这些指标，通过加权标准把电费分摊到各个部门。这里要说明的事情分摊比例通过时按照期初管理部门讨论确定的计划定制的。

·   IT后台部门按照填报给生产部门销售部门的工作时间，把这些费用转入到他所服务的生产和销售部门中去，此时工时费用可以是电费和人工费，后台部门设备，场地租金等打包后的服务单位时间费用。如果没有工时记录的整体服务，公司整个网络维护，也可以按照受益部门门店安装预先设立好的分摊规则，进行分摊；也可以按照生成部门或者销售部门的产出品，反方向估算。

·   电费到了生产部门后，生产部门电费作为成本投入生产成本，加上后台服务部门转入的工时费用，和自己设备折旧费，人工费，还有原材料费用，集合算出每月生产费用。按照生产订单，除于每月产出品数量，计入到每一件产品成本。

·   转移销售部门后，销售部门按照类似的比率，进行分割，结算到每一笔销售中去，并按照销售金额分配，算出单笔销售的成本。

·   如果有些独立的项目，比如某个独立系统开发，可以作为一个部门这样类似处理，不断把投入费用进行计算，等出最后改系统的成本，如果内部使用可以转为固定资产，如果销售给客户，可以做项目的成本。

           下图作为举例：但是并不是简单三个层级，有些真对项目的采购，就一个层级，有些费用需要经过四五次分摊流转。

输入费用类型		第一次层级	按照各个标准进行分摊	第二层级	按照各个标准分摊	第三层级
固定资产折旧费用		采购部门	部门人数	IT部门	工作时间/或者分摊规则	销售订单
水电煤管理费用		财务部门	部门使用数量	生产部门	工作人员级别	生产订单
房租场地费用		业务部门	费用采购时制定项目	销售部门	销售价格	项目订单
人力成本				行政部门	产成品数量
生产设备折旧费用
运输费用
其他杂费

3.2 利润分析：

相对于成本管理类似，利润分析有是把运营获得利润，进行分析。和成本管理数据入口是费用，利润分析的数据入库是收入。

有两大类分析方法，一个是按照各个维度和数量把利润进行报表分析，第二是设立利润中心，可以是销售部门，也可以是某个产品类，甚至是某个后台部门，对于每个利润中心进行利润考核。

o   主数据：利润中心是考核利润的指标，通过利润中心

1.按照地区设置利润中心

2.按照功能设置利润中心

3.按照产品导向利润中心

4.商业考虑设置利润中心

o   利润分析的典型案例：

              i.   获利分析：首先，获利分析是可以看做一个多维度表查询，比如某个产品的利润，某个门店的利润。根据销售订单中的标记字段进行分析。

之后可以看着标记字段可以二次提取，比如销售订单里面记录了客户信息，客户信息包括了客户的属性字段，在按照这些属性字段进行二级分析。

如果这些属性字段还有其他信息，可以进行第三次分析级别。

输入收入类型		分析维度（一级）	分析维度二级	对应金额
销售收入		按照客户类型	客户中的属性，如客户是国有，海外还是个人
服务收入		按门店类型	按照门店数据进行二次分析，如实体店，会员店，专卖店等
其他收入		按销售地区	安装销售地区
		按参与品牌	品牌信息，品牌属性等

通过这些分析，可以获得

1. 单独市场段贡献 获利分析

2.销售单体的利润目标

3.市场活动是否成功

4.收入和成本的构成  

 

              i.     利润中心分析：就是通过利润中心设置，把以前门店，部门，某类产品，甚至某个后台部门如IT部门，做成一个独立分析单元，分析这个部门的收入。如果该部门同时是成本中心时候，可以对于部门进行收入和成本分析。甚至可以按照部门为单位出具部门的资产负责表，损溢表等，当然需要进行一定的数据增强。

 

利润中心分析还有个功能，就是提供转移定价服务时候，提供评估基础。

利润中心采购数据举例

利润中心类型		收入	费用	备注
门店		销售收入	由成本管理流入门店费用/门店资产折旧费用/门店人员人工费用
IT部门		提供给别的部门或项目服务工时	由成本管理流入部门费用/部门人工成本/人员费用	后台部门有利润统计方式有两种，一个是按照填写的服务工作时间*市场公允价格；第二是按照成本分摊规则回溯；业务部门把利润反向分配给后台部门
某类产品		该类产品销售收入	该类产品生产费用/如果采购采购费用/运输费用/销售订单其他杂费
某项研发		研发产品的销售或者计入财务报表价值	投入研发项目的各个成本

3.3其他管理预测

 成本管理和利润分析是现在财务系统主流的管理视角。对于自开发系统，完全可以通过调研公司管理层需求，对于通过可以财务系统进行管理和对未来预测。下面列出其他的通过财务系统进行管理和公司运营优化功能。

o   客户信用管理：主要评估客户信用，并且按照客户信用在财务应付操作中对于销售金额，付款优惠，可逾期时间进行定制等。评估标准是客户过往付款逾期情况，如果信用没有预期情况，可视为信用较高。

o   流动性管理：对于公司的可用资金进行管理，销售订单付款跳跃，采购订单支付条约，工资支付时间，公司借款还款时间，定期利息，外借资金还款等等，推算出之后一段时间，公司需要支付的资金和收到资金，和沉积的分子公司的资金归集。保证公司资金流动性稳定。

o   其他涉及财务的考核。

·        调查对象：于系统集成型财务系统调研各个部门操作人员，管理型需要于各个部门管理人员，公司管理人员，KPI制定者，还有各个业务线的管理进行讨论。制定常见成本和利润的分配方法，和归集流程。

·        调研关注点：

o   管理准则和考核逻辑：因为是对公司内部管理，并不想普通财务实务有存在标准，更为自由。可以安装财务的成本管理分析理论，和企业管理理论，企业ＫＰＩ体系的多个管理思路，结合财务可以提供挖掘的数据信息，在于公司管理部门，部门管理层充分沟通商议，制定管理增强准则和考核逻辑。

·        成本管理：关注点在于成本分配分摊标准，成本分配分摊是单元设置，分配分摊周期，和结算到订单，产品，项目的规则；

·        利润分析：利润分析的维度，分析表可以抓取的属性，生产报表格式；利润中心利润统计方法等。

·        客户信用管理：客户信用分组标准，和不同级别信用对应财务处置

·        流动性管理：应收账款，应付账款的清账时间，可能逾期概率；支付和接收金额的预估，按周期支付时间统计等

o   新增公司组织单元：由于是公司内部管理，常见的财务系统只有部门一些简单的组织。没有足够组织单元来支持，需要针对不同需求，增加多组公司组织单元。

·        成本管理：成本中心，公司项目

·        利润管理：利润中心

o   新增考核和分析指标或参数：管理是通过指标或者参数实现，这些指标或者参数不单单要在财务系统定义，同时也要在业务系统中填入。只有这样业务部门晚上这些指标和参数的数值，传入财务系统，财务系统根据这些指标和参数。来进行分析。

·        工时，工作人数，费用比的

o   分摊和分配规则：一个从粗到细的靠谱系统，比如要求费用／利润从粗分摊到细，每一级别的分配分摊，可能都要安装上面的指标或者参数进行分配。

 

·        开发设计：

o   设计建议：

·        与财务系统保持隔绝：现在有些通用财务系统，在已有财务系统上进行管理实现，甚至在成本分摊过程中出发财务凭证。但是由于财务凭证设计法定报表出局，而管理功能大多针对内部，往往会出现大量没有意义借贷科目相同的财务凭证。所以除了采购出发费用数据，收入触发利润数据，其他成本和利润分配转移不应该产生财务凭证；如果多个公司集团内部跨公司成本和利润转移，可以考虑安装严格约束产生财务凭证。

·        新增多个组织单元，这些组织单元作为利润和成本的归结点；这些内部组织单元和公司架构保持分离；可以再不更改公司架构情况下更新考核单元

·        分配分摊操作数据准备：按周期执行：由于费用利润很多数据，是需要进行分摊和分配，在执行分配分摊之前，为了保证分析数据完善，需要进行被各个分子系统数据统一。

·        报表设置：其实管理这么多，主要体现就是报表，需要有很强大报表系统把分析出来的数据体现出来。建议此次通过API接口，由各个部门和使用人员，通过Python或者视图化筛选，自行挑选需要数据。

·        开发建议：

o   开发基础：对于自开发系统，强烈建议在系统集成系统已经稳定运行后，再进行管理型增强开发。如果直接进行管理型系统开发并不实际。

o   新增报表：尽量通过新增报表或者功能组的方式，而不是在已有系统表中新增字段方式增强

o   报表自开发工具：对于由于大量报表存在，建议加入客户可以直接使用简单报表自定制工具。

·        难点：

o   主要难点：管理和分析的理论要求，如果信息化，体现为可开发的系统

o   数据源和归集点：管理型系统主要对财务数据进行二次分析，这些数据源要求清楚，归集点和流程要通顺，需要通过多次测试，避免中间断链。

·        接口和扩展：

o   主数据扩展：如上文论

o   业务系统接口：需要大量数据传输，对接口要求增强

o   BI系统接口:由于很多数据分析，包含于过去年度对比，需要在数据仓库或者BI系统读取数据

o   报表导出：和系统集成性类似

 

 

 

        总结，其实可以看出，财务系统自开发不是一步完成，通常是按照报表型、系统集成型、管理型逐步进化更新完成。当管理型实现后，下一步是通过大数据和财务历史来对未来业务进行预测也是一个从要方向，还就是云平台推广。这里不做论述。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22259926/viewspace-2127181/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22259926/viewspace-2127181/