项目支持总结普洛股份syPPT课件.ppt

施勇2013年01月,项目支持总结,目录,浙江普洛股份中国移动,浙江普洛股份,现场支持时间：2012-12-17至2012-12-21项目所在地：浙江金华市东阳市横店镇拟使用版本：NCV61，一期上线模块：UAP、总账、固定资产、企业报表、合并报表、合并账簿等。未来逐步使用资金、资产、管理会计、预算、税务会计等产品支持人及内容：施勇，辅导顾问学习V61版本新内容，解答问题，帮助顾问编写实施方案，确定组织建模和会计科目，协调开发资源解决项目问题。项目情况简介：普洛股份有限公司（证券简称：普洛股份；股票代码：000739）是一家主要从事医药中间体、化学原料药及制剂、天然药物的生产、经营、研发的上市公司。它隶属于横店集团下的一个子集团，横店影视城就属于横店集团下的产业。普洛股份有三个系列，康裕、得邦、医药科技（具体组织单元见下表），属于先有二级公司再有一级公司的范畴。相比之下，子公司更强势。公司现拥有浙江普洛康裕制药有限公司98%的股权、浙江普洛得邦化学有限公司86%的股权、浙江普洛医药科技有限公司95.7%的股权，浙江普洛康裕天然药物有限公司90%的股权，上海普洛药物研究有限公司62%的股权。,浙江普洛股份,公司组织结构,浙江普洛股份,项目特点从上述组织结构可以看出，该项目的公司地址分布在浙江（不仅是金华）、山东、上海，目前绝大部分公司在使用U8，分别使用u852、U861、U890、u890sp1、u810.0，由于各个分公司的信息化程度不一样，管理水平也不相同，且子公司更强势，所以集团无法强制推行都上NC，只能先建立普洛股份统一的财务会计平台，让各个公司在U8里先做凭证，然后再上传到NC上来进行下一步的查询与合并。内部由于职业经理人的考核需要，客户资源相互保密，各自有各自的市场、客户；供应商的信息保密性不强；普洛进出口公司同时与其他三个系列存在大量的内部交易。,浙江普洛股份,项目遇到的问题目前普洛股份下各公司在用的不同版本U8的凭证生成到NCV61。由于我们只提供了U811.0的凭证生成到NCV61，所以这是项目遇到的最头疼的问题，一开始要协调集团资源协助，但后来由于各个公司使用U8的科目都不一样，需要分别做与NC科目的对照，所以后来项目决定还是他们自己进行二开。NC57支持集团级客商分配给不同的公司，未被分配的公司不可以使用。而V61的客户档案只支持三级向下共享，分配与原来的含义及功能完全不一样，满足不了普洛股份既要满足在不同公司下的共享、而对其他公司保密的要求。在NC57版本，顾问更多的使用项目类型做为自定义档案来使用，其中一大特点就是项目档案也支持分配，即分配给的公司可以使用集团档案，未被分配的公司不可以使用，这样也可以变相解决自定义档案部分共享的要求，而到了V61项目类型及档案专业化了，建议顾问使用用户自定义属性来进行扩展，但V61的自定义属性也是简单的三级共享模型，无法满足用户扩展属性的要求。,浙江普洛股份,项目遇到的问题由于总账没有支持按照银行账户的银行类别和银行档案的属性进行查询，必须让用户按照银行类别建二级明细科目，而用户不同公司分别在不同的银行开立的账户，导致二级科目需要建很多，利用率不高，同时也没有发挥V61会计科目表的模型优势，已经答应顾问提供V61的补丁。给用户销售的产品中，合并报表与合并账簿均在一期上线，而这两个产品是互斥的，这是由于一线顾问对合并账簿产品不了解的原因导致的，后来通过给顾问讲解合并账簿的思路与流程，顾问比较认可并账的思路，认为合并账簿的做法更好一些，并决定先给用户使用合并账簿模块。V61的推广：一线顾问难以及时得到集团的培训资料，最近一次的培训课件我去现场时给顾问带了一部分，顾问很感兴趣。但其他的课件从实施创新平台上下载很慢，我在集团里通过FTP给顾问上传也很费劲。wmv的格式比较受欢迎。,中移动,现场支持时间：2012-12-26至2012-12-27项目所在地：天宁寺桥使用版本：NCV57上线时间：2012年9月份支持人：施勇、赵诗耀、李成恕支持内容：用户在使用了NC几个月后，发现其应收应付的余额与总账的余额不相符，共相差90亿，需要我们把这些差异找出来，让用户确认并对明年年初数据的调整。根据顾问的要求和描述，一开始计划把总账和应收应付两个模块不相符的数据找出来提请用户进行修改。但在用户系统里实地查看，发现这样做意义不大，而且工作量巨大，原因在于用户在会计平台生成凭证时进行了大量的合并凭证和分录，一张凭证上千条分录很正常，根本找不到线索和对应关系，而且会计平台的配置还进行过修改。经研究并征得顾问的同意，我们直接通过后台按每个客商的维度查询出总账科目的期初余额和年末余额，和应收应付按每个客商的期初余额和年末余额，并把余额不相等的数据找出来，提交给用户，由用户决定如何进行调整。,中移动,项目问题分析：在项目现场跟顾问进行了简单的沟通：这个项目当时上线非常仓促，完全是根据用户高层的行政命令进行的安排，而实际上用户方和我们实施方很多工作都还没有准备好，时机并不成熟。同时上线的全国共22个省，我们实施方每个省配备了一名实施顾问，由于用户的ERP信息化水平并不高，再加上顾问的水平与参差不齐，时间有限，相关的配置也没有做到位，导致用户在使用过程数据非常混乱。我们在现场已经发现的问题有：一、开发直接在后台改数据用户发现数据不对了，我们又找不出原因，只好让开发直接在后台改数据，但改的又不完整，所以就产生了差异。二、二开人员随意修改一个顾问向我咨询现金流量自动分析的一个场景：想反方向分析现金流量，实际上我们的通版产品已经支持了这样的功能。但顾问不知道，于是就让开发放开了现金流量的科目关系设置的控制，而放开这个控制不仅不能达到要求，而且还会造成我们自动分析算法的混乱,中移动,三、顾问对产品不熟悉体现在顾问在查找两个系统不相符的数据时，用的是单据查询节点查询，直接查单据，单据查询没有统计汇总的功能，无法保证数据是正确的，后来我用的是应收应付的“余额表”节点按客商和其他维度（已开票和未开票等）进行查询，并让开发按照这个思路写SQL语句后台查询。四、期初初始化时两个模块的数据就对不上我们在查找不相符的原因时，发现用户在上线前的期初初始化时，两个模块的期初数就已经对不上了，一方面说明用户上线比较匆忙，另一方面也体现了我们的产品不足：1、相关数据在NC系统里的复用。针对中移动的具体问题，是否可以有这样的解决方案：1）总账相应科目的期初余额可以通过应收应付的期初余额单据可以直接得到，即直接从上下游系统的推拉生成。2）当有复杂情况也可通过会计平台转换生成。2、总账与业务系统的对账应提供期初余额的对账，做为一种补救措施。,中移动,五、用户随意在总账里进行调账我们查看用户的正式系统时，发现很多只应该是从会计平台生成会计科目、但又是手工录入的凭证，这样势必会导致两个系统的数据不相符。解决办法：1）会计平台在设置分类定义和转换模板时，应回写会计科目的受控系统，避免因为会计科目的设置考虑不全而产生的错误数据。2）或者在安装产品时，我们在预置的会计科目档案里直接根据所安装的产品要生成的会计科目里直接写入相应的受控系统，比如安装了应收应付的，则把应收账款、应付账款等往来科目的受控系统改为应收应付模块；安装了存货核算的，