电商平台开发需求文档

1、 I 版本信息 版本号更改内容简介更改人日期 1.0.0 于武贵 2015-07-21 文档名称慧购电商平台二期开发需求文档 所属部门 文档负责人于武贵 部门负责人 文档提交日期 1 目 录 一一. 背景概述.3 3 1. 调研背景.3 2. 平台现状及本期目标.3 2.1 平台现状 .3 2.2 平台整体目标 .4 2.3 本期目标及分工界面 .4 二二. . 开发功能需求描述 .5 5 1. 用户系统 .6 1.1 会员类型及会员等级 .6 1.2 用户注册及登录方式 .8 2. 个人中心 .8 2.1 缺货登记及提醒（优先级高） .8 3. 商品展示及购买 .9 3.1 商品支付及充值（

2、优先级高） .9 3.2 商品订单（确定目前 ec 状态和前端的对应关系） .9 3.3 购物车 .9 3.4 商品搜索功能 .10 3.5 商品套餐（优先级高，需要考虑 sku）.10 4. 活动及促销相关 .11 4.1 红包功能（先出一个从发红包，到使用，到传播的全流程） .11 5. 界面及用户体验优化 .11 6. 后台管理功能 .12 6.1 配送 .12 2 7. 商品的来源问题（） .13 8. 商品 sku 问题 .13 9. 统计查询功能 .13 9.1 订单来源 .13 9.2 订单统计 .13 9.3 订单查询 .14 10. 卡管理接口 .14 11. 用户体验 .1

3、4 3 一一. 背景概述 1. 调研背景 经过不断的建设及优化，目前慧购电商平台已经形成了基于互联网、微信、 手机客户端的互联网电商平台，但随着业务进一步扩展以及市场和运营的推进， 现有的平台功能已渐渐不能满足市场和运营的需求。 目前慧购电商平台遇到的主要问题包括： （1）用户系统的扩展：需要对企业用户、员工用户等特殊用户的支持。 （2）商品展示及管理功能：基于原有 ecshop 平台，对商品订单、购物车、 搜索、支付、评论、咨询、退换货、活动促销等各项功能的完善。 （3）界面及用户体验优化：由于前期网站是在 ecshop 模板的基础上搭建、 客户端是在 ectouch 模板的基础上搭建，界面

4、及用户体验不能满足运营需求，需 要逐步优化。客户端部分功能需要向原生+html 混合模式转型。 2. 平台现状及本期目标 2.1 平台现状 网上商城 微信商城 手机app ECSHOP+ECTOCH+UCenter 商品管理 门店1门店n 前置机前置机 用户管理 业务中心 卡中心 配送管理 物流管理 卡管理 库存管理 业务BI 门店 仓储管理 仓储系统 码管理 采购 4 现有慧购电商平台依托于现有线下的门店系统、卡系统、业务系统、仓储系 统进行建设。 2.2 平台整体目标 从平台长期来看，平台主要分为三层架构： （1）基础服务平台：主要为 ERP、财务系统、物流系统、客服系统、CRM 系统 等

5、基础服务系统的建设，这部分为保证人、财、物的统一规划和管理，需要在集 团层面进行统计规划和建设。 （2）电商平台控制中心：控制中心承载电商平台的核心功能承载。主要分为 3 部分： 1）对整个电商平台的用户、商品、资金、门店、营销进行统一管理。 2）与基础服务平台形成统一对接。 3）制定标准的 API 接口模式，对各个平台的用户、数据、展示进行统一调用。 （3）电商平台前端展示：包括 web 端网站、微信公众号、手机 APP、线下门店 （含自提柜）等。 2.3 本期目标及分工界面 考虑到目前的运营目标及实际开发实现的周期的限制。本期目标定位及分工 界面如下： 5 （1）基础服务平台层面由集团统一

6、进行规划和建设，随着基础服务平台的建 设，需要逐步形成基础服务平台与电商平台控制中心的标准对接模式。 （2）电商平台控制中心的建设工作量大，时间周期长，本期工程在平台整体 目标的前提下，分阶段实现。本期工程在商品流程层面继续沿用原有 ecshop 的 架构下，先搭建平台控制中心的基础框架，将用户管理、配送管理、权限管理、 业务 BI 对接的功能在平台控制中心实现。由于原有的 UCenter 用户系统难以满 足用户分类、等级系统、配送人员管理的要求，预计需要搭建用户系统平台，为 后期用户中心做准备。 （3）电商平台前端部分，需要基于新的功能需求及框架进行调整。 1）web 端（http:/ 网站

7、）包括：基于 ecshop 模板的新 功能的开发、展示界面的调整、原有业务 BI 是直接写在前端的，需要调整为 API 接口模式、原有用户系统需要调整为接口模式。 2）手机 APP 端（Android 和 ios 系统）包括：原有基于 ectouch 的 webview 方式存在展示速度慢、用户体验不好的问题，需要逐步调整为原生模式， 另外需要考虑新功能的开发、展示界面的调整等。 3）客户端引入支付宝 sdk 快捷支付、网站引入支付宝网页支付。需要新增 相应原生页面的接口功能。 4）微信商城和门店触屏系统由于建设模式还有不确定性，本期工程暂不考虑。 6 二二. . 开发功能需求描述 基于上面章

8、节本期目标及分工界面，本期开发功能的需求如下。 1. 1. 用户系统 1.1 会员类型及会员等级 功能需求：设定会员类型及会员等级功能。 现状：目前 ec 平台有根据积分设定会员等级功能，但是会员享受的权利不满 足要求，另外没有特殊会员功能。 本期功能描述： 平台会员按照会员类型划分为普通会员和特殊会员两种类型： （1 1）普通会员： 即目前的网站和客户端会员，普通会员根据积分再划分为不同的会员等级，不 同等级的会员可享受不同的会员商品折扣及权限。 本期普通会员保留积分功能，积分兑换及等级为预留功能，下期实现。 会员 等级 积分可享受优惠政策 会员商 品购买 会员促销 折扣等级 积分 兑换 红

9、利商 品 生日礼 包 包邮价格 （待讨论） 每年扣除 积分 L10-10000L1480 L210001-50000L2480 L350001-100000L34810000 L4100001-500000L43850000 L5 500001 以上 L528100000 1）会员等级与积分挂钩，每个等级的积分区间可以通过后台设置。 2）商品可以根据会员等级分别设置折扣，需要单独对每一个商品设置价格折 扣，并可将设置的商品形成一个单独的页面显示（如淘宝的会员商品），按照会 员级别只显示相应级别应该看到的商品（1 级会员只能看见 1 级会员商品，看不 7 到 2 级以上商品；2 级会员能看到 1

10、 级会员和 2 级会员商品，看不到更高级别的 商品，以此类推）。如果商品特价、促销或团购不享受折扣价格。 3）达到一定会员等级可以享受积分兑换商品。积分兑换是全用积分兑换 4）达到一定会员等级可以享受红利商品：红利商品采用一部分钱加一部分积 分联合支付的方式支付。 5）生日礼包：达到一定会员等级可以享受生日礼包：生日礼包是虚拟物品， 不设立商品，不上架，只是一个后台提醒。例如李四 8 月 2 日生日，在 8 月 2 日 当天在后台会有提醒，礼包由运营确定礼品并由当天配送。会员达到一定等级， 需要用户补充生日信息。后台具备自动统计及提醒会员生日的功能。 6）不同会员等级可以享受不同的邮费价格。

11、7）达到一定级别的等级，每年要扣除相应的成长值，年底按照级别扣除相应 成长值。扣除后从新评估用户的积分等级在哪个档次。 （2 2）特殊会员： 特殊会员按类型可分为企业会员、爱心帮扶会员、员工会员等不同的特殊会员 组。每个组可单独制定商品政策（可见商品不同，价格不同，打折条件或打折力 度不同）。 1）特殊会员根据其所在的会员组可指定可见特殊商品及制定特殊折扣，特殊 商品为后台指定（方式可作为一个专题或其他方式），后台可设定多个特殊会员 组，每个特殊会员登录实现特殊界面。 2）特殊会员的注册流程：特殊会员用户无法直接注册，通过线下进行申请， 需申请方提供营业执照复印件、法人身份证复印件，递交给我司

12、后由我司审核并 保管，审核通过后由后台操作人员手动创建特殊用户（支持通过导入的方式批量 添加特殊用户），并通过短信或电话通知企业用户。密码为初始密码，用户可自 行修改。 3）特殊会员购买商品同样获得积分，与普通会员规则相同，本期特殊会员保 留积分功能，积分兑换及等级为预留功能，下期实现。 8 4）特殊会员组，管理员可以更改其会员名称，会员自己不能修改。特殊会员 主要是大客户商家，购买东西多，周期结款，所以在配送时长统计功能中，需要 把这类结款方式的会员剔除出去，才能得到相对准确的数据。 特殊会员的优惠类别可通过专题实现或增加商品品类实现即可。 现需要特殊会员种类初定优惠类别 企业会员生鲜、粮油

13、副食、酒、饮料 爱心帮扶会员粮油副食、生鲜、日用品 员工会员根据每期活动分类 1.2 用户注册及登录方式 现状：web 端采用邮箱注册、客户端采用手机号注册。 本期功能描述：在原有基础上增加用户名注册， 用户名：必填 密码：必填 密码确认：必填 手机验证：必填 提交 手机验证维持现行原则，填写手机确认是否注册过，填写验证码，接收手机 验证码，获得手机验证码，确认手机验证码。 注册成功后，通过用户名密码登录，用户名为数字字母混合，不支持汉字。 2. 2. 个人中心 2.1 缺货登记及提醒（优先级高） 本期功能描述：商品售罄或数量到达阈值时提示缺货登记按钮，用户点击后， 后台管理员可在缺货管理中收

14、到一条登记信息，内容为商品名称、条码、库存数 和登记用户名。 业务流程： （1）用户发现商品不能购买，可点击缺货登记按钮； （2）后台收到信息，查看，并自动回复用户一条已查看信息。 9 （3）到货后，通过客户端推送向客户账号发到货信息提醒实现。 功能目标用户：后台管理员、普通用户、特殊用户 3. 3. 商品展示及购买 3.1 商品支付及充值（优先级高） 现状：目前互联网网站和客户端支持到付、支付宝网页支付两种方式，没有 充值。 本期功能描述： （1）互联网增加支付宝（支付宝快捷、支付宝网银） 、余额支付（增加充值 功能） 。 （2）客户端增加支付宝（支付宝快捷、支付宝网银，用 sdk 方式）

15、、余额支 付（增加充值功能） 。 （3）增加充值功能，可以通过支付宝支付充值到用户账号中。没有提现功能。 （4）后台可以对支付功能进行开关控制。 功能目标用户：后台管理员、普通用户、特殊用户。特殊用户为线下支付。 不需要进行单独的线上管理。 3.2 商品订单（确定目前 ec 状态和前端的对应关系） 现状：现在订单状态三种都显示：订单状态（未确认、已确认） 、付款状态 （未付款、已付款） 、送货状态。 本期功能描述： （1）用户看到的订单状态太多，修改成只显示当前一种状态即可，多余的状 态不显示。后台同样简化订单状态处理流程。 （2）客户可选择商品送达时间。 具体状态待定，需求详细讨论，预计按京

16、东的显示流程来。 3.3 购物车 现状：加入购物车的商品只能全部加入订单，不能选择部分商品加入订单支 付。用户加入购物车商品退出客户端后，再次进入会清空购物车 10 本期功能描述： （1）用户可选择购物车的部分商品生成订单。 （2）用户加入购物车商品退出客户端后，再次进入会清空购物车。需要不清 空购物车，存数据库一直保留。 功能目标用户：普通用户、特殊用户 3.4 商品搜索功能 搜索功能优化，提升搜索结果的优先级，比如搜索香蕉，结果显示排在前边 的应该是水果香蕉，而不是与香蕉有关的其他商品。需要提供一个搜索匹配算法。 比如：商品名称、商品类型、商品描述、商品分类的关键词进行匹配搜索。 功能目标

17、用户：后台管理员、普通用户、特殊用户。 3.5 商品套餐（优先级高，需要考虑 sku） 现状：现在商品后台有组合商品功能，但是不能满足商品套餐的功能。 本期功能描述： （1）自选模式，套餐分档，在档内可自由选择套餐。前台：用户通过对套餐 内，每一组商品的选择，自主定义套餐内容，提交订单。 （2）推荐模式，已组合好的商品直接购买 功能目标用户：普通用户、特殊用户 11 4. 4. 活动及促销相关 4.1 红包功能（先出一个从发红包，到使用，到传播的全流程） 本期功能描述：按商品发放红包没有选择商品的地方，需要增加选择商品的 地方。 业务流程：如果按商品发放红包，需要选择该红包可以使用的商品，本期

18、只 考虑单个商品的红包，不考虑多个商品的情况。 功能目标用户：后台管理员、普通用户、特殊用户 5. 5. 界面及用户体验优化 （1）Pc 端余额使用复杂，需要在订单确认页面显示余额使用选项。建议调 整为进入订单确认页，在红包使用下面，加余额显示和使用勾选项。 （2）商品图片无法放大查看，信息看不到。点击商品展示图片或内容图片， 可进行缩放控制。 （3）网站端用户订单列表优化：直观的显示每笔订单商品，商品图片、单价、 数量、收货人、交易状态、下单时间。参考淘宝？ 12 （4）商品默认排序增加可按照销量进行排序。需要后台增加逻辑。 （5）商品浏览记录：浏览记录存成 session，用户退出后不消失

19、，采用缓存 方式存在服务器端。 （6）App 端配送地址优化：首次购买填写配送地址，并设置成默认地址； 更换地址时，在订单页面点选现有地址，进入地址选择页面；修改地址信息进入 收货人信息界面，点选需要修改的地址。 （7）平台 48 元免邮费，当顾客进入购物车时，购物总价不足 48 元时，提 醒顾客未够包邮价格 ，提示差几元，并根据差价推荐几款商品。 （8）我的红包序列号不能输入信息，点添加提示信息不正确（第一次操作界 面死机） （9）个人中心改名为我的，所有类别改为竖向排列，头像指向更改头像，分 别设立区域，区域 1：我的订单、我的余额、收货地址、我的红包。区域 2：我 的收藏、我的消息。区域

20、 3：客户服务、意见反馈、账户与安全、检查更新。区 域 4：使用帮助、给我评分、关于我们。区域 5：应用推荐。其中意见反馈指向 原留言系统。区域 4 和区域 5 在此版本不体现， （注，留言系统跟评价系统是两 个） 。类似京东（如下） （10）pc 端首页“慧购在您身边”每周推荐模块，改成固定位置推送。 （11）网站端：用户我的订单，鼠标 hover 状态下，显示订单商品的图片， 类似 ec 后台订单列表的功能。 6. 6. 后台管理功能 6.1 配送 6.1.1 配送人员数据统计（配送人员位置、订单、是否支付） 现状：没有配送人员管理及统计功能。 本期功能描述： （1）后台可以添加、删除、修

21、改、维护配送人员信息。 （2）可以为配送人员分配订单，需要确定是手工配单还是自动配单？配单规 则是什么？ （3）可以根据配送人查看配送订单及订单状态；如果已经分配是否可以调整 13 配送员？配送完成后谁来更改订单状态？ （4）可以根据订单及配送人统计配送时长。 业务流程：后台需要先创建配送人员，根据订单为配送人员分配订单（自动、 手工？） ，进行配送，配送完成后更改订单状态为已送达。配送完成的订单可以 统计配送时长。 功能目标用户：后台管理员 具体方式待定，需求详细讨论。 6.1.2 配送计费规则（优先级低） 现状：现在按照地区计算配送规则。 本期功能描述： 是否需要按照地区？用户等级？重量？商品类型（我看有