百货购物广场信息管理系统文档格式.docx
《百货购物广场信息管理系统文档格式.docx》由会员分享，可在线阅读，更多相关《百货购物广场信息管理系统文档格式.docx（58页珍藏版）》请在冰豆网上搜索。
3.2.2.储值卡使用规则-17-
3.3.电子券和纸券管理-17-
3.3.1.电子券发放规则（返值规则）-18-
3.3.2.电子券使用规则-18-
3.3.3.纸券使用情况-18-
3.4.新旧系统会员卡、面值卡与电子券切换问题-18-
3.4.1.会员卡切换事项-18-
3.4.2.储值卡、电子券切换事项-18-
3.5.企划部大型促销方案-18-
3.6.退货与分摊问题-19-
3.7.总务部库存管理-19-
3.8.企划部需求调研疑问回复-19-
3.9.5.20-5.22会议企划部新增加需求-20-
3.9.1.增加需求-21-
3.9.2.系统需求细项-21-
5.营业部需求-22-
5.1.营业部日常管理用到的功能-22-
5.1.1.营业部日常管理用到的功能-22-
5.2.合同签订流程-22-
5.2.1.合同录入流程-22-
5.2.2.联营合同常签订的条款-22-
5.2.3.租赁合同条款-22-
5.2.4.特卖促销与临时特卖合同-23-
5.3.合同变更和续签流程-23-
5.3.1.合同续签和变更流程-23-
5.4.前台销售流程-23-
5.4.1.营业员开单管理-23-
5.4.2.租赁柜收款流程-24-
5.5.前台销售退货流程-24-
5.6.收银员和营业员管理-24-
5.6.1.收银员交款对账流程-24-
5.6.2.专柜日销售对账-24-
5.6.3.促销分段扣率与专柜对账问题-24-
5.7.常用的促销方案-25-
5.7.1.专柜申请的促销方案-25-
5.8.销售报表-25-
5.8.1.实时销售报表-25-
5.8.2.历史销售表-25-
5.8.3.分析类报表-25-
5.9.招商营业部需求调研疑问回复-25-
6.自营营运部需求汇总-27-
6.1.自营商品基础信息管理-27-
6.1.1.需求描述-27-
6.1.2.需求分析-27-
6.2.各自营部类别管理-28-
6.2.1.需求描述-28-
6.2.2.需求分析-28-
6.3.自营商品定价规则-28-
6.3.1.需求描述-28-
6.3.2.需求分析-28-
6.4.商品售价变价处理-29-
6.5.营运部合同管理-29-
6.5.1.需求描述-29-
6.5.2.需求分析-29-
6.6.进货管理-29-
6.6.1.需求描述-30-
6.6.2.需求分析-30-
6.7.调拨管理-30-
6.7.1.需求描述-30-
6.7.2.需求分析-31-
6.8.返仓和返厂处理-31-
6.8.1.需求描述-31-
6.8.2.需求分析-31-
6.9.盘点-31-
6.9.1.需求描述-31-
6.9.2.需求分析-31-
6.10.自营商品前台销售管理-32-
6.10.1.需求描述-32-
6.10.2.需求分析-32-
6.10.3.自营柜商品销售流程-33-
6.11.自营柜促销方案-33-
6.11.1.需求描述-33-
6.12.自营部门促销活动-34-
6.13.结算处理-34-
6.13.1.需求描述-34-
6.14.报表-34-
6.14.1.进销存报表-34-
6.14.2.各部门提出的需求报表-35-
7.财务需求调研-36-
7.1.合同管理-36-
7.1.1.合同签订管理-36-
7.1.2.合同变更和续签管理-37-
7.2.结算管理-37-
7.2.1.结算付款流程-37-
7.2.2.促销期间财务常用的分摊方式-37-
7.2.3.VIP会员加扣处理方案-38-
7.2.4.专柜会员打折商场不承担折让金额处理-38-
7.2.5.前台补录销售处理原则-38-
7.3.面值卡管理-38-
7.3.1.储值卡发售流程-39-
7.3.2.储值卡回收与核对机制-40-
7.4.凭证接口-40-
7.5.自营营运部合同管理-40-
7.6.自营部进货管理-40-
7.7.库存管理-41-
7.7.1.调拨流程管理-41-
7.7.2.盘点管理-41-
7.7.3.库存切换方案-41-
7.7.4.退货管理-41-
7.8.预付款及核销处理-41-
7.9.销售发票控制-42-
7.10.自营部门人员薪酬业绩考核-42-
7.11.报表-42-
7.12.自营财务部增加意见-42-
1.执行阶段
xx项目目前处于需求调研阶段。
现已分别同各业务部门进行了访谈，本文档对前一段时间的需求调研进行了汇总，形成分部门的需求调研报告。
2.信息部需求
2.1.系统网络架构
2.1.1.系统网络架构图
Ø
系统网络结构讨论：
●门店与总部连接方式。
各门店通过深信服VPN与总服务器建立远程连接，大店有硬件设备可以直接自动进行拨号连接内网，而小店需要手工拨号连接上网，而后手工拨通内网VPN连接到内网服务器。
对深信服VPN网络状况进行检查。
●服务器操作系统。
操作系统使用CentOS6.3版本；
●数据库使用Oracle11g64forLinux64位版本；
●数据库服务器。
笔者认为目前确认需要两台数据库服务器，一台作为正式服务器，另一台为测试机（192.168.1.95）。
●POS服务器。
各门店（除了xx店）都需要增加一台POS服务器。
配置要求为：
CUP2GHZ以上，内存2G以上，硬盘40G以上，网卡：
100M/1000M自适应。
目前方案：
除涵江店外，其他门店都使用直连方式。
通过最近使用情况，两种连接方式都很稳定，等xx这边进一步测试使用稳定性和准确性后，再决定是否所有门店都用直连方式。
●服务器硬件配置。
xx将使用XCP虚拟平台搭建数据库服务器，笔者认为建议直接使用物理机。
xx也已经按照笔者认为的建议，同时建立在性能更好的服务器，对比两者的性能最后再择优服务器配置方案。
●系统是基于C/S结构进行设计，门店要安装客户端，直接连接总部服务器。
用途
操作系统
数据库与库设备
CPU频率
内存大小
硬盘大小
有无做RAID
是否为虚拟机器
核心数据库服务
中间件
2.1.2.数据备份
系统日处理。
系统提供自动日处理和手工日处理方式。
日处理的当天，待所有门店的销售数据都上传后，系统便对各门店同时进行日处理，系统不允许对单个店独立进行日处理。
系统备份策略：
系统oracle备份策略。
根据项目业务量的情况，推算系统每天数据增量不会太大，因此采用如下备份方案：
使用计划任务功能，调用oracle数据泵出备份命令，系统在每天凌晨1点钟自动对整库进行完整性热备份，备份数据存放在磁盘柜，信息部应及时将数据复制到本地磁盘上或者备份到光设备上去。
将开启oracle归档日志模式，由信息部提供脚本来严格控制归档日志保存的数量及时间，以防止由于日志空间满导致oracle事务停止的情况发生。
人工备份。
安排人员每周将服务器中备份的数据导出，并刻录到光盘或者专用磁盘进行保存；
2.1.3.系统备份与灾难恢复
笔者认为：
笔者建议磁盘做RAID5处理。
如果其中一个磁盘出现问题，只用插入一块新盘就可以了，不会出现数据丢失。
双机崩溃后的解决方案。
准备一台备用PC机，安装oracle数据库，将此PC机设置为同服务器一样的配置，若服务器出现严重问题，就可以直接将网络切换到此备用PC机就可以了。
系统前台是可以支持断网进行销售，若由于切换服务器出现数据丢失，便要同过前台补录销售业绩，这样会对前台当天的日报表造成影响。
笔者认为提供一键手工补录或者自动补录的功能，在补录前，当天的日报表可能不准确。
后续高可用性方案，应当通过虚拟化平台来实现或者未来领先的技术，在第二期需求确认再具体商讨
2.2.系统组织结构
2.2.1.门店信息
信息部对各门店情况进行统计，并按照下表进行统计录入
门店号
门店名称
门店面积
门店位置
自营单品数量
自营柜数量
联营、租赁柜数量
xx各门店大致情况记录：
xx店：
●xx店内6楼有一个自营品牌卖场：
依库店。
按照财务要求依库店的销售业绩要可以记录到xx店，按照xx的一个柜进行管理；
●目前各门店的自营区域中划分专柜的目的为区分部门；
●对于xx店商场来说，其合作方式只有联营和租赁。
而对于各自营部门而言，同进货供应商签订有购销、代销和联营合同，同商场签订的为联营或者租赁合同。
●各自营部例如化妆部门，也存在有联营柜的情况，例：
化妆柜中的自然堂，实际签订的联营合同，但是由自营化妆品部进行管理，销售业绩是有化妆部进行管理。
●xx店也有一个依库自营卖场。
●xx店有租赁柜台，租赁柜目前采用两种销售模式，一种为自收款，另一种为商场全部或者部分（银行卡和储值卡）代收款。
xx广场店：
●xx店的自营柜的比例较高。
●xx店中花车特卖柜比较多，该柜台为品牌流动柜台，某一品牌在此处进行特卖的时间不固定，采用的收银方式为：
开大类码的小票，然后到中央收银台进行统一收银。
2.2.2.自营柜在各店的设柜情况
信息部统计出各店自营柜、联营柜的数量，并填写如下表：
柜号
柜名称
所属自营部名称
所属门店
合作方式（经/代）
SKU数量
供应商编码
供应商名称
2.2.3.系统架构设置
系统架构考虑点
1、百货按照楼层（区域）进行管理；
2、商场和自营部门权限划分；
3、报表统计。
可以直观统计出各店的销售业绩，同时各自营部门可以很方便统计出各部门的销售业绩
4、各自营部门可以先集中进行采购再向各店进行配货，也可以直接向各门店柜组进货；
5、依库综合服装超市自选卖场销售；
6、超市虚拟销售问题。
7、Xx、卖场的销售要可以直接体现到xx店或xx店中；
8、特卖柜（特卖区）销售问题，楼层、区域销售问题；
2.3.系统编码规则
对各种单据的编码规则进行讨论，尤其商品码的编码规则进行确定。
内容
系统编码规则
系统代码长度
当前使用的编码规则
示例
人员编码
系统提供参数设置。
0：
按流水码方式编码1：
自定义人员代码。
要求为数值类型
5位编码
5位流水编码
00100流水码,分广场流水编码。
系统自动编码。
组织机构
分级次定义，每级2位编码。
最多可以定义5级。
可以为非数值类型，也可以是字母。
最多10位编码
商品分类
分级次定义，每级2位编码,最多支持5级。
要求为数值编码
自营分类目前使用3级编码，联营使用一级分类，系统将在其上增加第一级编码99
例如：
080101男装.男正装.T恤。
9901表示商场联营类别中的女鞋，位数可以统一也可以不统一。
供应商
系统支持0:
流水码，1:
自定义码，提供系统参数设置。
6位
系统自动流水编码。
共6位
例：
000590，在使用时，前面的0是不能去掉，数字编码。
合同编码
8位数字编码。
经销、代销、联营和租赁合同
8位数字
系统自动处理，各门店统一流水编码。
以9开头的编码为历史变更合同
商品码
0:
自定义码。
要求为数值编码。
重点讨论确定：
2位大类码+2位中类+6位流水码
0101+123456男装
品牌
流水编码
最多10位
收款台
数字流水编码。
6位编码
使用6位数字编码，其中前3位为门店号，后3位为收款台号流水。
010101收款台。
店号+楼层+编号
会员卡、电子券、储值卡
数字自编码
最长16位
可以指定前导和后缀码
可以同银行做联名卡
其它单据
系统自动流水编码
最长可达10位
进货单，返厂退货单
2.4.系统基础资料
2.4.1.商品分类
自营部分类须由xx自营部门进行讨论之后进行确认。
（各自营部门已经提交）
联营部商品分类，将使用一级分类。
（资料已经提交）
2.4.2.系统权限管理
要求：
信息部提供人员信息清单
权限划分：
按照人员所在的岗位设置权限组，如：
自营营运部，财务主管等，而后指定人员所在的岗位即可。
要求可以从系统中将菜单权限目录导出来，供信息部对各部门人员的权限进行设置。
信息部提出如下情况：
一个管理人员，可能管理多家门店，需要系统能够实现对多家门店的权限划分。
2.4.3.登录管理
需求描述。
为方便对人员账户进行统一管理，要求系统可以支持使用“数字编码”和邮箱账户进行登录。
需求分析。
定义人员时，可以增加记录“邮箱账户”的地方，或者直接使用拼音码字段记录下人员字母编码（邮箱账户，统一为大小写）。
后台登录时，系统要同时支持数字编码和字母编码登录系统，字母不区分大小写。
2.5.POS收款台管理
2.5.1.各店收款台统计表
信息部要提供如下资料
门店
收款机台号
收款台型号
所在楼层
收款台IP地址
打印机型号
信息部应提供一台正在使用的POS样机和打印机（正在使用的各型号打印机均提供一台（宽纸小票、窄纸小票））供笔者认为测试。
需求：
系统要支持对小票格式进行自定义，可以按照门店来指定打印的数量。
2.5.2.收款方式及使用方法
商场将使用的收款方式清单；
名称
消费是否参与积分
是否多收不找零
收款类型（现金、纸券、电子券、面值卡、国内外银行卡、支票）
手续费
现金
参与
否
现金（记销售）
银联卡（国内）
国内银行卡（记销售）
1.5%
储值卡
储值卡（记销售）
3%
电子券
不参与
根据具体情况
电子券（记销售）
VIP返利
VIP折扣券
纸券（记优惠）
注：
化妆品部使用的“电子券”为返值金额券，只能在化妆品区进行使用，也可以做到发券与用券柜台可以分别设置，A柜发券，B柜使用。
且有指定的使用规则，例：
使用现金满100元时返5元VIP返利，而此5元券只有在该返券专柜消费满100时才能使用（配比使用）。
2.5.3.前台收款机使用到的接口
前台同银行接口。
流程：
（1）同银行人员进行技术方面对接。
（2）商务方面确定接口合同。
（3）银行布专线。
（4）笔者认为银行接口功能开发完成之后，同银行方面对接口功能共同进行联合调试。
（5）接口功能上线确定。
前台收银接口。
有部分租赁柜自收款（如：
味千拉面），但是按照扣点方式提成做租，要求前台使用接口自动将租赁柜销售业绩传回业务系统。
方案：
将考虑做成一个通用的接口格式，笔者认为方面同租户技术人员沟通后，再提交具体接口样式。
笔者认为会员系统数据同网站的接口。
提供方案：
将会员系统中的会员信息以txt方式完整导出，供网站进行读取，此会员接口只允许从会员系统中读取数据，而不支持将数据回写到会员系统中。
若需要将业务系统和网站系统的会员数据进行交互操作，则须签订接口开发合同。
若网站接口不用软件开发新功能，只是将系统数据导出，便不用商务方面介入。
2.5.4.收款台的日常管理
后台程序自动更新功能。
xx提供FTP功能，增加并配置好BFFTP用户和目录，各店后台系统都可以访问此机器取更新文件。
前台脱机数据自动更新。
POS服务器上要安装FTP功能，增加并配置好BFFTP用户和目录。
款台监控方案。
信息部自己安装远程监控软件，通过系统要可以查询到所有POS机是否在线。
小票格式与键盘格式。
要求：
信息部提供小票格式，以方便笔者认为进行设计。
（已经提供格式）
客显双屏显示。
保持现有的显示模式就可以了，客显只用显示出收款员操作界面就可以了。
前台断网时，如下情况须注意确定：
●会员卡在网络不通时，可进行消费、积分和会员折扣，但不能查询实时积分余额；
●促销活动、与会员卡相关的促销活动，在断网时仍然可以执行；
●断网情况下，与金额性质相关的卡无法使用，如：
储值卡、电子券、VIP返利券不可用。
●断网情况下，系统不支持选单退货，但是在管理卡的控制下，在销售数量处可以录入负数进行退货。
2.6.旧系统历史资料处理
2.6.1.无法导入新系统，需要手工录入的数据
基础资料类：
人员信息、组织结构信息、商品分类信息、供应商信息、合同信息、商品信息，会员类型和发放地点定义，收款方式，收款台信息；
各种历史单据。
订货单，进货单、返厂退货单，盘点表，结算单，付款/核销单。
历史销售数据。
单品销售数据，商品进行销存数据，商品历史库存数据，会员消费数据。
历史数据查询方案：
将历史资料库备份转移到新机器上，以方便对历史数据进行备查。
2.6.2.可以导入到新系统的数据
化妆柜的商品信息。
要确定导入的标准：
如最近两年有过销售或进货的商品才导入新系统中。
会员信息。
电子券。
储值卡。
VIP返利。
数据导入方案：
xx以EXCEL文档（具体文档格式同笔者认为进行沟通确定）的方式提交要导入的数据，笔者认为按照文档进行导入，相关部门（尤其是财务部）对导入的数据进行检查，并要签字确定。
2.7.信息部5.20号补充
对于联营合同，若分年度签订有个扣率，要求可以将各年度的扣率都录入系统中；
要可以体现出银行扣取商场的手续费，在录入合同时要求可以直接录入供应商分摊比例；
系统网络结构问题。
可以考虑直连总部的网络架构，同时保证断网情况下POS机可以正常进行交易；
小票上直接打印券的条码。
需求：
对于非VIP会员的顾客，享受消费赠券时，需在小票上打印券条码（笔者认为回复：
若打印条码，则对前台打印头的精度和打印纸的感光度有很高的要求，否则打印出的条码效果很差，扫描枪很难识别出来，同时也将给打印速度带来一定的影响。
建议：
小票上只是打印出“券号”而不要打印出条码）
来店礼品处理方案。
具体详见企划部5.20新增需求
3.企划部需求
3.1.会员卡管理
3.1.1.会员卡基础信息
会员卡类型：
白金卡、普卡。
2013年新增会员类型：
钻石卡。
目前有6种类型的旧卡，系统切换时将统一规范成3种类型的卡：
普卡、白金卡、钻石卡，卡切换时企划部提供导数资料时指定卡类型,会员卡类型是自定义的，自己增加和减少,会员卡名称也需要自定义。
会员卡采用的介质为磁条卡。
目前流通的卡都没有加密，卡片上的号码和卡磁道内容是一致的，新发行的卡将对会员卡进行加密。
会员卡由企划部自行加密写磁。
会员卡有效期。
卡面设计由企划部提交方案给总务，再由总务提交给制卡厂家制卡、写磁，目前会员卡没有设置有效期，系统默认10年有效期。
卡编码规则设置。
●需求：
在制卡时，系统可以控制对尾号为4的卡号是否需要跳过，默认情况下“尾数”为4不跳过。
会员卡的功用。
会员享受的服务：
积分、vip返利、积分赠礼；
会员卡没有折扣、没有会员价功能。
不同卡类型返利方式不同，积分规则不相同。
已提供目前还在流通的电子券、旧式普卡、新式普卡，未提供白金卡样式。
顾客资料登记表。
在表中增加“是否接受商场短信”的填写项。
系统要增加的内容：
●会员申请来源:
（朋友介绍,会员宣传单,报纸广告,电视广告,短信平台,商场内POP、LED,公司网站）
●购物需要商场提供什么样的优惠:
（商品打折,送购物券,送礼品,购物积分,立减,其它）
●期望什么行业的联盟商家的优惠:
（餐饮类,娱乐类,
升级会员 