ERP项目

一． 项目常被问及的问题【进销存ERP】

1. 说说你最近做的这个项目的背景？

这个项目是为××（名称自己构思，为防止同学们面试期间撞车，此处不提供公司名称，但是此名称需要同学们调查一下这个公司是否真实存在，在百度上搜索一下，例如武汉商贸公司，列出来一些名字，不要找第一页的名字，最好向后翻几页）商贸公司做的，公司原有的项目是一个覆盖地区为省的平台，现在公司规模扩张，全国各地建分公司，省内管理相对来说比较有局限性，加上全国全联网，采购、销售、货运、仓储、配货、财务核算各方面发生了很大的变化，所以重新起了一套新的平台。

这个项目可以说算是二次开发，但是业务里程变化蛮大的。尤其是加上了一些数据分析，数据挖掘的东西，而且报表的统计数据量也比之前的大很多，复杂度高很多。这个项目开发主要是从CRM、进销存、仓储、财务四个方面做了大的改动，基础平台方面多添加了一些功能，比如像合同啊，报销啊这些东西不再以网点为单位了，改成全国统一编排。

2. 你的表结构是如何设计的？为什么这么设计？

表结构方面初期受原始项目的影响，一直想着在原始项目基础上进行修改，后来发现原始项目的库设计有问题，进行改造相对来说工程量很大，而且关联关系新设计中发生了比较大的变化，最后推翻了重做的，原始数据做了个数据迁移。

比如说省内业务时，供应商A处采购，到货运中心后，然后发货给B客户，但是改造成全国业务后，供应商A处采购如果再到货运中心可能会造成成本的提升，需要直接发往B客户处，这个过程中运单就在走单过程中原始项目无法处理了。这里供应商A的单号是采

购单号，但是到客户B那边应该是供货单号，需要做单号的更改处理。最后设计的将原来的分销业务扩展成了分销和直销两种。表结构方面也做了调整，将原始的业务扩展成分销表与直销表，分开管理。同时也会后期数据挖掘降低一些工作难度。

设计方面比较独特的几个地方我说一下

第一个是供应商采购价格这个字段，原始设计中是一个商品对一个价钱，基于原材料涨价，人工涨价导致的价格变化直接对商品采购价格进行修改。做成全国项目后，采购来源就更多了，为了辅助后期的数据挖掘，比对价格涨幅与预计增长量，配合货运成本计算，需要对所有的价格变化波动进行数据分析，所以添加了价格波对表，同时原始表中也存储目前的最终价格。虽然数据微量冗余，最后价格两个表中保存，但是整体运行性能方面得到了很大的提升，而且这样设计才能配合多组数据，计算采购差价，核算最终成本。简单来说，A地的货物便宜，但是到达客户的运输成本高，B地的货物贵，到达客户的运输成本低，总体核算需要配合很多数据。但是又不能单纯的从价格方面放弃某一个供应商，所以需要监控其价格波动量，必须做相应的表设计调整。

第二个是采购运输方面的调整比较大。省内项目的中的设计允许出现一次采购途径A,B,C,D四个地方，一次完成若干个运单，也就是车务调度与采购单是一对多的关系，但是全国项目中，由于发车地点多了，若干个采购任务可以从不同地点发车，运输成本反而降低了，毕竟第一个采购完成的货物在路上跑了很久。再有，不同地点的车务组规模不同，不一定能完成一个采购任务。所以设计方面做了很大的调整。一个采购单可以允许拆分成若干的子任务单，而每个车务调度只对应一个子任务单。简单的说就是原始车务调度对采购单是一对多，改成了采购单对子任务单一对多，车务调度对子任务一对多。降低了原始任务中一个运单运输时间成本过高的问题。

第三个是采购执行单的修订。原始设计中采购计划单与采购执行单就是一个单据，审核中就执行。全国项目中，一份采购计划对应的采购如果一个供应商不能满足，需要从多个供应商处进行调配，这样采购执行单对采购计划由原始的一对一，变成了多对一。实际执行时，所有的采购单说的都是执行单。

还有很多此类的设计更改，我就不一一说明了。

3. 这个项目为用户提供了哪些服务？包括哪些模块？

从大的方面来说包含有4个系统，CRM系统、进销存系统、财务系统、基础平台。公司的基本办公在基础平台中，CRM系统做供应商管理、客户管理、委托运输客户管理和政府部门相关管理，进销存系统包含采购、销售、库存、合同、任务委托、还有几个我涉及的不多，记不清了，财务系统包含内部结算、外部结算两大块。本来建议客户买一套用友的财务系统的，后来没有谈成，最后这一块外包出去了。其实系统中让我来看比较特色的是风险评估和数据挖掘后的预算决算处理。但是这一块不是我所在的组做的，了解不是特别多，就知道个大概，就是数据分析后，为客户直接出多个方案，供用户选择最终的执行方案。

4. 你承担这个项目的哪些核心模块

我开始在CRM组，做了大概两个月左右，后来调到进销存那边去了。在进销存这边做了有将近4个月。进销存的主核心我都参与开发了。

我说说采购吧

首先采购发起可以从4个任务开始。1，需求采购，2被动采购，3，计划采购，4，预

警采购。需求采购就是主动提出的采购，由采购部业务人员主动发起，没有前置条件；被动采购是销售那边如果遇到库存不足，自动转入一个采购申请的流程，进入到采购主线上；计划采购是ERP系统运行过程中，根据历年的采购数据、销售数据、库存数据动态计算出来，生成一份采购计划，这个只是个采购建议，然后转入采购主线，就是交给采购部业务人员那边进行确认；预警采购是库存量超过当时的预设临界点后发出一个采购申请计划。不管哪一种最终都汇总到需求采购那边，只不过转入方式不同。

采购申请单下好后，根据采购内容划分2级审批还是3级审批。如果是公司内部使用消耗品采购转入采购主管审批，然后行政主管审批；如果是公司业务采购，走3级审批。订单如果超过设定值，比如50万，需要4级审批。

审批完以后生成任务单号，转入后勤。后勤主管根据采购内容分派跟单人，跟单人根据采购单据和发货方式选择联系对方发货或者转入车辆调度或者委派第三方完成。如果对方发货，记录传真号，语音信息，交货时间这些信息；如果使用第三方运输，根据采购单据选择航空、铁路，转入CRM系统进行运单跟踪；如果公司内部组织运输任务，转入车务组调车和司机还有随行人员。运输任务跟单人可以进行更换。

运输任务完成后转入验收流程，验收完成后，给每个批次的货物分配一个内部管理的货物编号。

如果这个货是第三方到第三方的，也就是不经由公司仓储的话，需要对货物再进行一个出货编号的分配，采购流程结束。如果不是第三方到第三方的运输，货物编号分配完转入入库流程，入库以订单为单位。一个订单中所有货物入库完成，采购流程结束。上面说的这个事分销的采购流程，还有直销的采购流程，就是在中间有一个分任务单的地方不同，然后就是入库结算方式不同，按子任务入库的，而不是整个订单入库。

5. 你碰到了哪些问题？你是怎么解决的？

最大的问题还是设计问题，实现方面都还好，设计比较头疼。如果没有前期的项目恐怕还好一些，受影响太大了。剩下的比较突出的问题就是页面的东西了，业务只要需求理解了问题都不大，页面的脚本控制应该说是消耗时间比较多的地方。整个项目做了半年多，现在的页面jquery比以前强多了。脚本方面就是多使用firebug这样的工具吧，次数多了慢慢就知道问题定位如何快速准确了。

6. 做完这个项目你有哪些收获？

应该说的比较日常的东西，就是脚本写的比以前好多了，剩下就是设计思路方面有了一个不小的提升，再有就是客户自定义字段以前没做过，这个项目的商品展示方面用了一次，感觉虽然很繁琐，但是很有意思。

7. 项目最大支持多少并发量

组内测试的时候并发大概到100左右还算稳定，到200丢包率很高，能达到40%，到300时丢包基本上在90%以上。这个项目的受众群体大概平均在线1000人左右，最大并发量大概在秒70到120左右，性能要求不是很高。

二． 项目中具体模块技术点抽取【进销存ERP】

1. SSH框架整合（如何整合）

首先整体系统架构基于Spring为基础平台

struts2负责页面展示，Action对象交由Spring管理，配置scope=”prototype”控制为产生的对象为非单例对象

Hibernate3负责数据持久化，使用Spring提供的hibernate模板完成数据持久化。Spring为其注入SessionFactory对象

平台实物处理交由Spring管理，使用注解事务完成，简单高效

2. 底层代码封装（各种封装）

表现层抽取基类，封装分页参数和各种常用方法，包括request与response对象的获取，session数据的操作，登陆用户数据的获取等

业务层封装通用操作接口

数据层封装通用底层持久化方法，使用反射+反射泛型完成。如果再添加反射注解，可以真正意义上做到数据层通用操作0代码

3. 权限系统（数据优化）

权限系统将所有常用数据使用web监听器思想进行初始化，避免大量数据库连接操作，也可以将其放入Mongodb，每次从内存数据库中读取。登录人信息权限相关数据缓存到个人信息session数据中，减少系统读取数据库次数。

4. 权限系统维护（Mongodb）（需要学习完毕后将思想融入）

权限动态维护数据加入Mongodb中，每次权限发生变更或角色发生变更时，从内存中读取当前操作人是否需要进行权限维护。

5. jquery动态树结构

6. Activiti工作流（需要学习完毕后将思想融入）

7. JXL导出报表数据

8. JFreeChart图形报表

9. 定时作业调度