礼保通®
提货产品介绍
一款成熟的软件需要经过不断的打磨而成为产品。
什么是提货系统?
提货系统也叫提货卡系统、礼品卡系统、提货软件。它只是一个简称。提货系统主要是为了解决商家(Business)与顾客(User)之间兑换的方便性。系统提供一个供顾客可以进行卡券兑换的页面,我们一般称为"前台兑换页面",当顾客买到商家的提货卡,顾客可以找到卡上提供的提货网址或者商家在卡上印制的提货二维码.通过电脑输入网址或者手机扫提货二维码,这个时候会显示商家的兑换页面,顾客输入卡上的卡号,刮开用刮刮乐覆盖住的卡密码,系统验证通过之后,顾客输入个人收货信息(包括收货人名称、手机号、省市县及地址、选择预约发货时间)提交订单,商家在提货系统的后台订单模块中可以查看订单的数据,包括待发货、已发货、已完成的订单列表。
核心价值
提货系统通过数字化手段，简化了传统礼品兑换流程，实现了商家与顾客之间高效、便捷的兑换体验，节省双方时间与成本。
传统礼品兑换的方式
A公司需要购买月饼发放给自己的员工,他找了一家生产月饼的食品公司(B公司),B公司有两种选择,第一种：他按传统的方式,在中秋节前一天，用货车将所有的月饼送到A公司,A公司再接收货之后,将月饼发放给自己的员工。第二种：B公司将好的提货卡发给A公司,A公司到B公司门店或者指定的提货点自己去提。
1 第一种模式
B公司需要组织人力、物力将实物运送到A公司,A公司还需要同时安排人员卸货,然后召集员工来拿礼品。在如今的快节奏社会,浪费大量的人力、物力及时间是双方都不愿意看到的,如果B公司在中秋销售月饼有很多家的情况下（一家3000人的工厂、另一家1000人的工厂）,显然B公司无力无心进行如此大的人力调拨进行发货。
2 第二种模式
虽然与第一种相比,无需再直接配货到A公司,但顾客如何自提呢,如果B公司有自提的门店,还要考虑顾客到本店是否方便,路程是否很远。如果B公司没有门店,B公司还需要与本地的合作商家进行沟通,将货分配到不同的合作商家,让就近的用户进行兑换。
适用商家类型
除了终端的生产企业商（如上面描述的食品公司）,还有很多依托互联网而衍射的电子商务公司、中间代理商品销售的贸易公司、家乡卖土特产的一般企业、海鲜、生鲜类等各种不同行业的商家。
生产企业
食品、生鲜、土特产等各类产品生产企业
电商公司
各类依托互联网销售的电子商务企业
贸易公司
中间代理商品销售的贸易企业
企业痛点与解决方案
企业痛点
传统的兑换方式,无论是从购买方还是销售方,都面临着实效、方便、快捷。双方都希望能有一种方式解决双方的痛点。
提货系统如何解决双方的痛点
为了解决销售商家与购买商家双方的痛点,提货系统以互联网依托,与线下实体卡相结合,通过SaaS模式的软件架构,向商家提供提货软件,购买商家买了销售商家的卡之后,将购买的提货卡发放给自己的员工,员工通过自己的手机号扫描卡上的二维码，输入卡号和卡密码（密码要刮开涂层）,系统验证通过之后录入个人收货信息，提交订单。
销售商家收到了订单信息之后,按顾客预约的发货时间进行线下发货。销售方只需要将制作好的提货卡卖给购买方。购买方将卡发给自己的员工,员工只需要按自己的预约发货时间进行订单提交即可，一切都是在电脑上或者手机操作完成,商家只需要按用户提交的订单预约发货时间进行发货即可。
针对电子商务公司,发货仓库可能与运营中心不在同一地方,此时提货系统可以创建独立的账号,发货方可以用自己的账号管理发货,运营中心负责线上销卡及卡券管理。
提货系统有哪些优点?
让商家更专注于管理卡券及订单核销
系统控制卡可以兑换哪些商品
可以随时定制卡对应的商品
提供数据统计明细，已兑换、已激活、已发订单数量清晰可见
防止因现实中兑换造成的挤兑
可以分离人与货的强纽带，提升效率
商家可以根据企业的定制要求在系统中直接绑定不同的商品
产品历史与迭代
产品历史
礼保通第一版于2015年6月开始研发，同年8月发行礼保通第一版。（运行一年多左右，申请软件著作权，第一版软件著作权于2017年取得，软件著作权登记号: 2017SR524836）, 经过不断的产品改进，成功迭代了四代。
软件迭代
产品自2015年开始至2018年共经历三次大型迭代，但软件架构及代码结构已经不符合当前软件发展的需求，为了提高市场竞争力，同时为了商家能用到更好用的软件产品，于2018年6月开始进行了全新的研发，即抛弃了前三代的所有代码，重新打造全新的软件框架及业务逻辑。
历经一年的技术架构，在2019年2月11日正式切换新版本，新版本采用SaaS模式开发的分布式系统，SaaS模式下的技术架构采用了多服务器、多系统及中央数据管理系统协作运行。
同年又开发了面对多维度需求企业的企业级软件，企业级软件更注重于企业多需求的功能，例如：ERP对接、批量电子面单发货、POS系统的第三方平台的开放能力及对接能力、知名ERP(旺店通)的已知对接等。
SaaS网络架构
公司自研发的SaaS，由中央控制系统、前端兑换系统、商家后台管理系统、图片服务器、API数据网关系统、备份服务器（内部通道）、短信网关、全数据管理系统协同运作的一套分布式架构的体系。
提货系统运营模式
当系统开通后,默认会分配一个管理系统的后台。商家在后台创建好卡数据,比如388,588规格的卡,每款1000张,生成好之后,从系统分批导出来,去印刷好,印刷好的卡寄到你们公司,你们公司通过自己的销售渠道销售出去卡,就可以耐心等待客户提货了。
顾客买了你们的卡,他用自己的手机扫这个卡上的二维码进入提货平台（如果卡上的二维码是印刷的公众号二维码，则顾客可以先关注公众号，再进入商家公众号菜单点在线提货）,然后输入卡号,刮开密码,系统核验通过之后,顾客输入个人收货信息(姓名,手机号,省市区及家庭详细地址)提交订单。
你们收到顾客的订单信息,在线下将货发给顾客,在系统中录入运单号进行订单核销。
应用场景
标准版(N选1)场景
场景一：一选一模式
商家做水产大闸蟹，王总有388规格，588规格，888规格共计3000张卡，王总开通本系统后，在系统中创建了388规格的卡1000张并绑定了要兑换的商品[388型],588规格的卡1000张并绑定了要兑换的商品[588型]，888规格的卡1000张并绑定了要兑换的商品[888型]，顾客买到了王总的588规格的大闸蟹提货卡,顾客用手机扫提货卡上的二维码，并输入卡号密码进行提货,由于本卡只绑了一个兑换的商品[588型],顾客默认只能提[588型]这个商品，顾客录入个人收货信息并提交订单。
场景二：多选一模式
商家是礼品公司，一张卡会对应多个商品，例如，一张588的提货卡，可能对应ABCDE五款商品。顾客买到这张588的提货卡，他输入卡号和卡密码之后，可以自由选择兑换这五款中的任意一款，然后录入个人收货信息并提交订单。
供应商一键代发场景
系统已集成了供应商一键代发的能力。
场景：商家作为平台方，与各个发货供应商进行合作，当顾客提交了订单。系统自动识别订单是由哪个供应商发货。
• 用户1提交了兑换订单，兑换的商品是苹果，则由A供应商负责发货。
• 用户2提交了兑换订单，兑换的商品是海参，则由B供应商负责发货。
• 用户3提交了兑换订单，兑换的商品是茶叶，则由C供应商负责发货。
• 用户4提交了兑换订单，兑换的商品是大闸蟹，则由D供应商负责发货。
门店场景
总部有自营门店及加盟门店，总部负责管理各门店的卡券分配及订单数据
场景:总部在后台创建ABC三家门店
• A门店分配200张券
• B门店分配300张券
• C门店分配500张券
各门店自己卖了券自己激活，总部可查看每个门店券售卖了多少，当券卖出去后，客户到不同的门店提货，各门店根据券号密码核销，处理到店提货的客户，总部可以在订单列表中查看不同的门店核销的数据（每笔订单中券所属哪个门店，核销是由哪个门店的哪个员工）。
总部可以自由控制各门店的操作权限（例如A门店可以激活，B门店不能自己激活）。
产品技术指标
本指标适用于大部份礼保通软件介绍
1 通讯安全
基于SSL加密传输协议，访问地址以HTTPS开头。目前大部份网站及系统都逐步已过渡或即将过渡到HTTPS协议中。在HTTPS协议中传输数据，可以保证数据不被网关或者中间层进行窃听、修改指令、修改传输值、伪造数据包等。
2 券号密码前端暴力破解防护
为了优化用户体验，正常的客户，他们不可能连续三次输错卡号和卡密码，但又为了防止黑客暴力破解，前端为了兼顾这二者，系统采用了以下方案：
- • 当顾客输入正确的卡号和卡密码，不显示验证码。
- • 当顾客第二次输错了卡号和卡密码，不显示验证码。
- • 当顾客第三次输错了卡号和卡密码，系统弹出验证码。（防止软件暴破）又能让正常的用户不用输验证码。（正常情况下，顾客本身也不会连续输错三次）
3 请求拦截
卡号和卡密码的猜测，通过一些软件或者写入一段POST报文，就能进行不断的猜测，服务器端通过技术手段限制了在5秒内只能发起一次请求。现实举例：我去售票厅机器买票。如果没有请求拦截，伪造者可以通过不断的尝试来猜票的数量。但售票厅机器设置了拦截，每5秒我都让你查一次，在5秒的任何请求都被定义为无效请求，服务器会直接抛弃请求。
4 无规则盐值加密保证数据缓存
通过情况下，我们需要在不同的页面传递数据，同时希望保留一些数据在页面进行共享，我们常规会采用SESSION来存放数据，比如账户登录后，在服务器端生成了session数据。在卡号验证通过后，我们没有采用常规手法进行数据缓存，而采用加密手段，通过盐值参与加密来缓存一些关键数据。并且通过时间来控制缓存数据的时效。防止缓存数据伪造。因为系统没有采用传统的session，以减少高并发量的session问题，你可以理解为 你出示付款码，支付宝也一样只让验证码1分钟有效,过期失效。
5 数据伪造防护
当用户提交订单，伪造者他修改了提交的参数数据，比如正常你这张卡只能兑换A商品，但他能截取提交的参数，修改了商品的ID，导致我有100元价值的卡，兑换了1000元的商品。如此，服务器后台做了数据对比，会直接在系统中对比，顾客提交的这张卡，他绑定的商品中，是否存在这个商品。防止前端进行数据篡改。
6 上传文件安全检测
攻击者可通过上传漏洞在图片中插入一段木马程序。伪造图片进行上传。系统会分析图片文件，将图片直接转成16进制文件，通过对比分析是否带有一句话木马命令。从而识别木马，以保证上传安全。
产品特性
在公司推出第一代系统以来，来自全国五湖四海的商家不断的给产品提出来了很多建设性的意见，以帮助我们系统不断的成长，并最终成为了在此行业中具有竞争力的一款产品。具体描述如下
商品设置了兑换时间
很多礼品公司他们有很多商品，并且这些商品有很多是季节性的，比如大闸蟹只有每年的9月底到12月才有，月饼每年只有中秋节前后一段时间才有，如果在客户提货的时候，没有这个特性，有的顾客可能在3月就下单要提大闸蟹，但因为3月不可能有大闸蟹这个商品，所以就会造成客户下单，商家无法进行发货的情况。
为避免这种情况，我们加入了这个商品特性，当商家设定了ABC三款商品，其中针对C商品设置了兑换时间范围:每年的9月25－12月31号，此款商品才可以兑换，那么当顾客拿到商家的卡进来提货，他可以看到这张卡对应的ABC这三款商品，但他要么选择A,要么选择B,他不能选择C（会看到C商品标明了只有每年的9月25－12月31号才可以兑换），这样的设计模式极大的解决了礼品公司或者有此需求的商家的难题。同时顾客也很清楚的知道为什么这个商品无法让他兑换。
券商管理
商家有一些合作的渠道商，当卡销售出去之后，商家希望知道此卡是属于哪个渠道商代销的，当顾客提交订单之后，此订单能直观显示这笔订单的券商（代销卡的渠道是谁）。一些电商企业，在很多电商平台开了很多店铺，有的在一淘，有的在京东，如果定义了券商，在顾客提交订单之后，订单中会显示对应的券商是哪家平台。
创建卡券
很多商家对于软件的使用想法是越简单越好，越一目了然越好，在创建卡券中，以直观的方式，商家可以直接按照自己想要设定的创建卡的规则生成相应的卡数据，如果卡是兑换一种商品，则在对应商品这一栏绑定一个商品，同理，如果商家是希望创建的这批卡是3选一或者5选一，商家可以勾选3种商品或者5种商品。这样就完成了卡与要提货的商品之间的绑定功能。
很多商家希望能按自己的想法创建卡号，例如有的商家希望我的卡号要从10000开始，那么第一张卡是10001，我们也给出了相应的解决方案，在创建卡规则，其它属性中，有一项，自定义起始号，在这里设定字符10000,系统会认为商家是希望以自己设定的卡起始号开始生成卡数据。
卡核心问题（商家重点关注）
当商家创建了卡数据，比如商家创建了388型卡2000张、588型卡3000张、888型卡5000张。商家在系统中操作最多的功能是在卡数据这里。
商家会遇到一批卡要激活、有的激活错了要取消、有的卡不用了要作废、有的卡要重新绑商品。
关于批量查找要操作的卡
商家今天388型卡卖了50张，他需要将这50张卡激活（只有激活的卡才能提货），商家需要从系统中一次找到这50张。为解决顺序生成和随机生成的卡带来的技术问题，我们设计了卡序号这个字段，你可以理解为系统中为每一张卡作为映射关系
顺序生成的卡
批量查找（按卡序号45901-45903）找到对应的A10001，A10002, A10003这三张卡
随机生成的卡
批量查找（按卡序号23233-23235）找到对应的随机卡号A60986、A53789、A14562这三张卡
卡属性变动
一批卡创建了之后，一张卡会有多个属性，例：
一张A1000的卡，这张卡有属性
卡名称：388提货卡
卡对应的提货商品：苹果A礼盒、苹果B礼盒、苹果C礼盒
卡的有效期：2017-01-01至2029-01-01
卡所属券商：上海xx渠道商
卡面值：388
卡备注:
当商家创建了卡，商家因实际运营的过程中，会不断的调整一批卡或者一批卡中的一部分的属性，比如:
情景1：今天A公司要我公司给他们200张卡，这批卡是定制的，我们重新做一个礼包商品，这200张卡全部提这个礼包。商家在后台通过筛选找到这批卡的中这200张卡，修改卡属性－重新设定对应的提货商品。
情景2：这批卡之前设置了有效期，需要延长这批的有效期，修改卡属性－重新设定有效期。
情景3：之前这批588的卡绑了AB这两款商品，现在新进了一款同价值的C礼盒。需要将这批卡要把C礼盒也绑上，顾客从之前的2选１调整为可以3选１。
情景4：之前这批888的卡绑了FD这两款商品，现在D款商品没货了，商家可以重新设置卡对应的提货商品，或者直接在提货商品将这个D款商品下架处理。
卡券批量执行的风险
当商家对卡券数据进行批量操作，比如要批量激活这200张或者对一批2000张的卡进行绑新的提货商品这样批量操作的时候，很多时候，商家在批量的时候容易出现数据没有经过条件筛选就执行了，结果就是导致系统中的所有卡都执行了，这样的结果就是商家数据全部乱了，为杜绝风险（在我们系统实际运行过程中发现）我们提出来阻断措施，所有需要针对卡操作的批量操作，系统都要强制商家必须要先经过条件筛选才能执行，商家在没有经过筛选过程进行的操作，系统都会拦截并强制提示：必须要先经过查询。
卡券导出与导入
卡券导出
重构了模块，重新引用了一款开源输出Excel表格的插件，可一次导出8万张卡数据，在输出时间上不超过10秒。
卡券导入
商家如果自己已经印刷好了卡，印刷厂会将卡数据excel文件(卡号和卡密码)交给商家，商家此时可以通过本系统中提供的卡券导入功能，将外部卡数据导入本平台。
订单核销(传统核销)
传统的订单核销，可能更多的操作是当订单进来之后，一般在订单列表需要点：发货这个按钮，弹出发货的界面，再选择发货的快递公司，输运单号，再点“发货”按钮。
为了解决这种传统的方式，我们引入了直接在列表就可以操作数据（类似于操作excel表格一样的，可以在单元格直接操作），为什么要这样设计：因为在产品体验中，传统的操作会让顾客经过多次的鼠标操作，在新的操作模式下，商家只需要在列表单元格直接输运单号就可以核销（一步完成）
订单列表显示
当订单数据特别多的情况下，列表要显示全部的数据，用户需要拖动横向滚动条查看。当用户拖动滚动条发现不知道对应的是哪个订单，基于以上问题，我们冻结了表头，类似于excel表格中的冻结表头一样，当用户横向拖动，关键的列不会变动。
快递对接
很多时候，商家进行订单核销发完货之后，需要查看物流轨迹，我们直接将物流轨迹同步到我们系统，商家不需要在第三方平台查看。
订单数据快速定位
当订单越来越多，商家需要快速甄别哪些订单要今天发货，哪些订单需要明天去备货。我们改进了产品体验，在订单列表显示这里，作出了更为细致的筛选。商家今天要发哪些可以直接从菜单栏进入即可。
订单排序优化
当订单进来，此时订单是待发货订单，订单的排序是按谁最后一个进来，最后一个显示在最前面。但当订单已发货，排序按发货时间来优先排序，方便商家查看最新发货订单。
ERP同步
当商家有用到ERP进行统一发货，订单需要统一推送到商家的ERP系统中。系统支持订单统一在商家ERP发货，然后本平台同步物流状态，并回发给ERP，让ERP清除物流池。
订单批量核销
商家如果出现订单量非常多，常规的传统发货方式是无法满足快速进行订单核销的。系统支持第三方批量导入核销和ERP统一发货导入核销两种模式。
登录日志
系统会记录所有登录后台的账户信息，即记录什么账户在什么时间登录了后台。包括账号输错密码的日志记录。以方便商家核查系统后台是否被探知。系统会自动清理超过90天的日志记录。
行为操作日志
系统会记录所有针对卡券的核心操作，如激活、修改属性、下载数据等，便于商家追踪误操作行为。系统会自动清理超过180天的日志记录。
数据统计报表
系统从商品、卡券、天及月份多个维度统计数据。支持动态统计，可自由定义统计时间段，如2018年1月至6月的商品兑换数据。
商品排序
商家可在后台修改商品排序值，调整顾客在兑换页面看到的商品显示顺序，满足不同的营销需求。
提货区域限制
商家可在后台定义全局的区域设置，限制省市区不同级别的机构显示。同时支持针对部份卡设置特定的提货区域限制。
电子面单
商家可直接通过本平台调取电子面单打单功能，系统与快递公司数据对接，自动生成电子面单并写入系统。
单元格操作
为减少过多的鼠标操作，系统提供了可以直接在列表单元格快捷操作的途径，如直接修改商品名称、上下架商品、编辑订单信息等。
预约发货时间设置
商家可设置多种预约发货模式：指定天数后发货、特定时间段内选择、不允许预约（下单即发货），满足不同行业需求。
架构分离
系统支持分离部署，可将客户兑换系统与商家管理后台系统分别部署在不同服务器，提升高并发场景下的系统性能和安全性。
自动计划
系统在执行批量自动核销、ERP订单推送等自动任务时，如遇中断，再次登录时会自动检索并继续执行未完成的任务。
自动清理
系统定期自动清理数据库表及文件空间，包括自动标记已完成订单、清理过期缓存和日志数据，保证系统长期稳定运行。
权限管理
系统将用户账号与权限直接绑定，由统一的权限拦截程序进行甄别和鉴权，确保不同角色只能访问和操作其权限范围内的功能。
客户案例
上海广电集团
上海丰收日
河南航天豫南基地
深圳粮食集团
安徽鸿润(集团)股份有限公司
黑龙江龙和集团
大连渔公码头
中国民生投资集团
武汉梁子湖水产集团
广东荣诚食品
上海面包新语
广西新农商集团
结束语
软件从2015年6月起，经历了四次大型产品迭代，自第四代以来，全部代码重新重写。
在软件发展的大道上，需要不断的提升产品能力，才不会被历史的车轮辗过。