基于erp二次开发平台的落地结算流程的研究与实现毕业论文(编辑修改稿)

基于erp二次开发平台的落地结算流程的研究与实现毕业论文(编辑修改稿)内容摘要：

施过程中需要进行的逻辑修改很少，进行时也要采取非常谨慎的态度。 进行逻辑修改之前要先确认要进行的修改在逻辑上是合理的，在实现上是可 行的。 并且充分了解用户需求，设计出性价比最高的解决方案。 同时要注意所采用的解决方案及其程序实现可以满足需要的性能要求和健壮性，并且界面相对容易掌握。 因为要进行修改的是个大系统，所以要整体的看所要做的修改对系统的整体影响，不要顾此失彼，对整个系统的稳定运行造成影响。 另外，要建立详细的文档，以保证将来在需要对系统进行升级时，可以在新版本中重建这些二次开发的部分。 二次开发的管理重点 了解用户需求表面上看是很容易的，但实际上却需要很大的努力。 有些资深顾问认为，了解用户需求的时间往往超过 整个开发项目总时间的 1/4，甚至有时在小项目中可以超过总用时的 1/3。 其困难主要是有以下几点。 (1)用户无法用专业词汇、专业逻辑来表述其需求，而程序开发人员又缺少用户企业环境的背景，造成双方沟通的困难。 (2)用户企业组织不利，造成每个部门，甚至每个人都有对二次开发有不同的要求。 (3)用户总是在自觉不自觉中希望重复企业原有的，不合理的生产逻辑。 基于上述可能产生的问题，就需要在了解用户需求时本着真正对用户负责的原则，耐心、细致、科学、系统地了解用户需求。 ①针对困难 (1)就需要在进行二次开发设计之前，对用户进行教育、培训 ，至少使主要的核心用户不仅了解 ERP 软件的使用方法，同时也了解 ERP 的内在逻辑，真正懂得 ERP。 这样，供求双方才能使用共同语言，在共同逻辑基础上讨论 ERP 二次开发的需求。 ②针对困难 (2)要注意以下两点。 一是帮助用户建立合理的项目队伍。 只有项目队伍有合理的组织结构，才可能汇总、优化各个不同部门，不同个人的不同的需求。 二是要求所有主要核心用户都参加整个 ERP 培训，而不只是自己工作相关模块的培训，这样才能让他们树立全局的观点，自觉把自己的、本部门的需求与 ERP 项目整体的需求相结合，得到完整的、一致的需求。 ③针 对困难 (3)就需要负责二次开发的技术人员本着对用户对项目负责的原则，深入地理解 ERP 系统的整体逻辑，与项目的实施人员紧密配合，真正了解用户的需求。 这个工作有时甚至可能是一种极具挑战性的工作，不仅需要科学的态度，还要需要艺术的方法。 对于软件的二次开发有时是不可避免的。 但是，过多的修改又会影响 ERP 项目的顺利实施。 那么，二次开发是否要做的标准是什么呢 ?也就是说如何判断用户化要求是否合理，从而有效的防止过多的修改呢 ?有 3 个方面的工作可以防止过多的修改， 即教育、标准软件和管理。 、后阶段 在实际进行二次开发工作时，首要之事就是区分哪些二次开发是属于上线前一定要完成的，哪些二次开发是属于上线完成后才慢慢来进行的。 前者指的是那些“不改的话根本无法上线”的二次开发，后者指的是那些属于重要性不高，不会影响上线的二次开发。 如果不能对二次开发进行有效的区分，会模糊上线实施的管理重点，进而影响上线的进度甚至质量。 新增或修改原有的报表或查询程序，不会影响系、统的原有数据库结构，因此不会造成日后系统升级的困扰。 但是，如果二次开发牵涉到新增字段或档 案，就可能影响到原有数据库结构，此时，最好的方式就是尽量利用系统原有的“闲置”字段，不要轻易新增字段或文件档案。 如果有改动较大的二次开发，其规格应当请软件原开发厂商确认，以避免二次开发与产品发展方向重叠或冲突，以降低日后版本升级的困扰。 二次开发是一项庞杂的系统工程，决不是简单系统代码的增增减减，二次开发的文档应该由专人保管，而代码注释也必须清晰易懂，还必须有专人负责检查代码质量。 新扩充的字段命名、新建程序的命名都应该由专人分配，首先不能和现有系统冲突，同时还应预留一定的空间。 对于公 用元件一般不建议修改，因为公用元件被很多程序调用。 在程序的编写上应采用继承的方式，在保证不破坏原有功能的基础上做个性化的功能完善。 如要修改处理业务逻辑．则分两种情况：一是修改原有程序中的处理逻辑，将局部的继承去掉，重写新逻辑。 二是在原有功能基础上新增， 保留继承关系，在新的子文件中只完成新功能的实现即可，当版本升级时，二次开发的程序惟一要做的就是继承新版本的源代码作重新编译。 关于 ERP 系统用户化和二次开发的结论 ERP 系统用户化和二次开发具有十分重要的意义，本文旨在从中总结出一些普遍性的经验和 教训。 对提高 ERP 实施的成功率和实施效益具有参考价值，从而使得 ERP能够真正的发挥作用，提高企业决策体系和市场运作体系的反应水平，提高企业捕捉发展机遇、规避市场风险的能力，提高企业的核心竞争力、加快企业的市场反应机制，并最终推动企业的发展。 3.“落地结算”流程的设计与研究 简述 时下的摩托车和汽车配件行业，上下游企业间流行着一种“落地结算”的供销模式。 这儿所谓的“落地”并非通常所说的“到货”，而是实际进入“使用”才算成交。 具体而言，上家把零配件发到下家，双方的买卖还不算数，此时的货主依然为卖方，买方只承担为卖方“代为保管”的责任，不要说付款，连欠帐单也不用开具。 只有等买方实际使用了这些零配件，采购行为才算发生。 不用说，“落地结算”是一种下游企业控制库存，进而制约上游企业的生产，协调上下游关系的一种新型结算模式，是能够对指导性计划及时进行调整的有利工具。 “落地结算”的运行不 能不改变甚至颠覆原先某些管理的程序和理念，从而对 ERP提出了新的要求和挑战。 “不近情理”的合理效应 在专业生产汽车空调系统的领域的公司，显然是“落地结算”的受益者。 落地结算让他们实现了零库存生产。 因为没有了库存资金的占用，他们的账本也漂亮了许多。 谈及买方的“零库存”要以占用卖方的库存和资金为代价，对上游企业是否“不近情理”时，这就取决于你怎么看：只看单个环节还是看产业链的整体，只看一时还是看企业发展的长远。 图 3 ERP 工程项目管理系统功能 上图是一个企业对于公司 内部的统筹管理，而“落地结算听上去是有些问题”――明明拿到了货，却连欠账都不算，只算“代为保管”，硬是把库存的压力都转移给了上家。 不过，如果你真正的了解了我们这个行业，就会发现这种“不近情理”的条款，却是可以保证产业链健康发展的条款，长远看对上游厂商也有好处。 据了解，已成为摩汽配行业约定俗成的落地结算，其发明者却是远在东瀛的日本汽车企业，而后者推行这一模式的出发点也不是转移库存压力，而是为了“品质控制与敏捷制造”的需要。 表现上看，“落地结算”让“下家”不近情理地占用了“上家”的库存，但正是有了这种 “不近情理”，才有效地遏制了以往的无序供货。 根据该市场财务分析的资料，实行落地结算以前，货物送到下家便能实现销售，所以供应商总希望多送一些货过来。 有时需要 100，对方却送来 150，还求情说“收下吧，下次少送一些过来就是了”。 但下一次依然不少送。 就这样，仓库里的零配件越堆越多。 一般来说，我们每个月有几千件库存件就可以保证正常生产了，“但有一次清点仓库，居然有五六万件之多”。 这种海量无序的库存既把企业拖入了库存占用的泥潭，造成了资金压力和仓库管理上的混乱，更为品质管理带来了很大隐患。 而品质管 理上的隐患对这个行业是“致命”的。 这是因为，摩汽配行业的产品质量关系到司机和路人的性命，从而也关系到企业的生命，出一点隐患都要求“召回”，不仅零配件的验收极为严格，对使用时间也有“先进先出”的严格规定――先进来的产品先使用。 因为有些电子元器件和铝制品放置时间长了容易变形、氧化，造成泄漏或焊接不良。 又由于汽车更新换代快（骄车平均半年一代产品），一旦整机换代，老型号的零配件就派不上用场了。 而且，从产业链的角度来看，任一环节上的企业有了库存的负担，都会危及其上下游的伙伴。 有序、合理的库存都是保证这个产业 健康发展的必要条件。 霸王条款一般是买方市场的产物。 但在摩汽配行业并不存在纯粹意义上的买方市场，上下游企业大多是捆在一起的独家供货伙伴，他不供我货，我就无法生产，双方是长期的战略合作关系，一损俱损，一荣俱荣，所以落地结算并没有由谁出面强制推行就得到了普遍认可。 平台化 ERP 化解难题 “落地结算”好是好，但它的运行是一个复杂的系统工程，对 ERP 的依赖性很强。 而标准的 ERP 软件已难以适应这种新型结算模式的程序和理念了。 标准 ERP 由采购订单、销售订单和生产任务三大订单组成，而“落地结算 ”却取消了采购订单，采购的完成放在了实际使用零配件之后。 不仅如此，“落地结算”为有效控制库存，还增设了“虚库”（代保管仓库）和“挂帐付款”（下家实际使用配件之后所实现的“采购入账”和付款）两道程序，这是常规结算模式所没有的。 而标准 ERP 是货到后自动记帐，无法转入代为保管的“虚库”，也无法完成“挂帐付款”这一“不标准”的动作。 此外，汽配行业产业链涉及的企业非常多，仍以汽车空调为例，如果一家为福特、长安、铃木等汽车制冷系统配套的公司实行的是全球采购，国内外合作伙伴达上百家，管理起来十分复杂，牵一发动全身， 这也使得结算模式的转换成为企业和ERP 软件商的一道难题。 如果是前两年，汽车空调和其 ERP 软件服务商金蝶公司有可能被这种个性化的应用模式拖进软件修改和维护的泥潭中去，因为那时的软件修改需从代码做起，而 修改代码又涉及文档、维护，这对于程序量高达数百万行的软件系统来说可谓是一种不能承受之重。 以往不少让人望。