一款成熟的软件需要经过不断的打磨而成为产品。
礼保通第一版于2015年6月开始研发，同年8月发行礼保通第一版。（运行一年多左右，申请软件著作权，第一版软件著作权于2017年取得，软件著作权登记号: 2017SR524836）, 经过不断的产品改进，成功迭代了四代。
产品自2015年开始至2018年共经历三次大型迭代，但软件架构及代码结构已经不符合当前软件发展的需求，为了提高市场竞争力，同时为了商家能用到更好用的软件产品，于2018年6月开始进行了全新的研发，即抛弃了前三代的所有代码，重新打造全新的软件框架及业务逻辑。历经一年的技术架构，在2019年2月11日正式切换新版本，新版本采用SaaS模式开发的分布式系统，SaaS模式下的技术架构采用了多服务器、多系统及中央数据管理系统协作运行。同年又开发了面对多维度需求企业的企业级软件，企业级软件更注重于企业多需求的功能，例如：ERP对接、批量电子面单发货、POS系统的第三方平台的开放能力及对接能力、知名ERP(旺店通)的已知对接等。
公司自研发的SaaS，由中央控制系统、前端兑换系统、商家后台管理系统、图片服务器、API数据网关系统、备份服务器（内部通道）、短信网关、全数据管理系统协同运作的一套分布式架构的体系。
当系统开通后,默认会分配一个管理系统的后台
商家在后台创建好卡数据,比如388,588规格的卡,每款1000张,生成好之后,从系统分批导出来,去印刷好,印刷好的卡寄到你们公司,你们公司通过自己的销售渠道销售出去卡,就可以耐心等待客户提货了。
顾客买了你们的卡,他用自己的手机扫这个卡上的二维码进入提货平台（如果卡上的二维码是印刷的公众号二维码，则顾客可以先关注公众号，再进入商家公众号菜单点在线提货）,然后输入卡号,刮开密码,系统核验通过之后,顾客输入个人收货信息(姓名,手机号,省市区及家庭详细地址)提交订单
你们收到顾客的订单信息,在线下将货发给顾客,在系统中录入运单号进行订单核销。
场景：（一选一模式）商家做水产大闸蟹，王总有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门店不能自己激活）。
一：通讯
基于SSL加密传输协议，访问地址以HTTPS开头。目前大部份网站及系统都逐步已过渡或即将过渡到HTTPS协议中。在HTTPS协议中传输数据，可以保证数据不被网关或者中间层进行窃听、修改指令、修改传输值、伪造数据包等。
二：券号密码前端暴力破解
为了优化用户体验，正常的客户，他们不可能连续三次输错卡号和卡密码，但又为了防止黑客暴力破解，前端为了兼顾这二者，系统采用了以下方案
当顾客输入正确的卡号和卡密码，不显示验证码。
当顾客第二次输错了卡号和卡密码，不显示验证码。
当顾客第三次输错了卡号和卡密码，系统弹出验证码。（防止软件暴破）又能让正常的用户不用输验证码。（正常情况下，顾客本身也不会连续输错三次）
我们的前台，正常情况下，只需要输卡号和卡密码（因为正常的用户不会做黑客攻击）,如果让他再输一个验证码（大部分网站注册是这样的）。对于体验来讲是不好的,所以在第四代我们改进了，即去掉了这个，只要输卡号和卡密码，又要解决黑客攻击，所以只要达到错误阀值（正常的用户不可能连续三次输错卡号和卡密码）。只有黑客才会进行暴破，当错了三次，就自动打开要验证码。既解决了用户的体验，又能有效有保护系统
三：请求拦截
卡号和卡密码的猜测，通过一些软件或者写入一段POST报文，就能进行不断的猜测，服务器端通过技术手段限制了在5秒内只能发起一次请求。现实举例：我去售票厅机器买票。如果没有请求拦截，伪造者可以通过不断的尝试来猜票的数量。但售票厅机器设置了拦截，每5秒我都让你查一次，在5秒的任何请求都被定义为无效请求，服务器会直接抛弃请求。
四：无规则盐值加密保证数据缓存
通过情况下，我们需要在不同的页面传递数据，同时希望保留一些数据在页面进行共享，我们常规会采用SESSION来存放数据，比如账户登录后，在服务器端生成了session数据。在卡号验证通过后，我们没有采用常规手法进行数据缓存，而采用加密手段，通过盐值参与加密来缓存一些关键数据。并且通过时间来控制缓存数据的时效。防止缓存数据伪造。因为系统没有采用传统的session，以减少高并发量的session问题，你可以理解为 你出示付款码，支付宝也一样只让验证码1分钟有效,过期失效。
五：数据伪造
当用户提交订单，伪造者他修改了提交的参数数据，比如正常你这张卡只能兑换A商品，但他能截取提交的参数，修改了商品的ID，导致我有100元价值的卡，兑换了1000元的商品。如此，服务器后台做了数据对比，会直接在系统中对比，顾客提交的这张卡，他绑定的商品中，是否存在这个商品。防止前端进行数据篡改。
六：上传一句话木马
攻击者可通过上传漏洞在图片中插入一段木马程序。伪造图片进行上传。系统会分析图片文件，将图片直接转成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张。为解决顺序生成和随机生成的卡带来的技术问题，我们设计了卡序号这个字段，你可以理解为系统中为每一张卡作为映射关系
顺序生成的卡
顺序卡号 卡序号
A10001 45901
A10002 45902
A10003 45903
A10004 45904
A10005 45905
批量查找（按卡序号45901-45903）找到对应的A10001，A10002, A10003这三张卡
随机生成的卡
随机卡号 卡序号
A67892 23231
A45891 23232
A60986 23233
A53789 23234
A14562 23235
A47686 23236
批量查找（按卡序号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统一发货，将发完货的订单导入本平台，由平台自动核销。
订单核销采用实时状态输出_基于命令行显示(ajax异步)
系统会记录所有登录后台的账户信息，即记录什么账户在什么时间登录了后台。包括账号输错密码的日志记录。以方便商家核查系统后台是否被探知。
注意，系统会自动清理超过90天的日志记录以保证表的空间可以循环使用。
在系统中，系统的核心数据为卡券数据，任何针对卡券的核心操作，比如谁在什么时间激活了哪张卡或者哪些卡，谁在什么时间修改了卡的什么属性，谁在什么时间下载了卡数据，下载了多少条，系统都会记录此行为，在实际运营过程中，商家系统开通后，商家在系统中创建了多个不同的账户，分别赋予不同的权限来共同运营系统，但由于使用者的操作，有可能在操作过程中误操作导致数据不对：比如本来要激活20张卡，结果不小心激活了50张卡（筛选条件没锁定具体的数据从而导致误操作实际修改了50条）。行为日志记录可以捕捉误操作的行为。
注意，系统会自动清理超过180天的日志记录以保证表的空间可以循环使用。
本系统中的数据统计报表分别从商品、卡券、天及月份多个维度来统计数据。不同的常规的软件统计策略，本系统中的统计报表可以动态统计。例如，你想要统计兑换的商品在不同的月份分别兑换了多少。你可以在统计报表中的（商品按月统计表）查看，同时你可以自由定义你想要进行统计的月份，比如你想统计2018年1月至6月的商品兑换数据（商品在每月），又或者你想统计2018年4月至10月的商品兑换数据。系统描述的统计可以进行动态统计，这与一般的软件有所区别。
在实际运营中，商家开始定义了卡要兑换的商品是ABC，顾客输入卡号密码进来兑换看到的商品列表显示也是按ABC进行显示的。此时商家希望调整兑换的商品显示顺序，比如有的商家希望是C在最前面，即CAB的显示，此时商家可以在后台的商品列表修改排序值即可以实现。
你可以在后台－区域配置中定义全局的设置，可以限制省市区不同级别的机构显示。
注意：这是针对全局配置的，如果你同时针对部份卡需要再限制其它的区域，你可以在卡券管理中去修改部份卡的提货区域属性即可。
当商家希望进行电子面单发货，（商家需要配有热敏打印机及与快递公司进行了产品签约开通了普通电子面单的功能），商家可直接通过本平台调取电子面单打单功能，当商家通过电子面单生成面单时，系统会通过与之对接的数据公司进行数据通讯，具体通讯流程是
本平台->面单数据公司服务器->快递公司服务器->快递公司API回复成功->下发电子面单运单号->面单数据公司->回发本平台->本平台写入系统－生成缓存的电子面单。
很多时候，为减少过多的鼠标操作，系统提供了可以直接在列表单元格快捷操作的途径。
例如：商品列表：商品名称直接修改
例如：商品上架与下架
例如：订单列表的收货人、物流号、手机号、管理员备注字段均可以直接在列表直接编辑
例如：物流配置的列表直接设置默认发货物流
商家可以在全局配置－提货设置 设置预约发货模式
A:有的商家希望顾客选择发货的时间必须在2天后，则可以选择“以当前时间xx天后”
B:有的商家希望顾客在某一个时间段选择预约发货时间，则可以选择“从xxxx年xx月xx日-xxxx年xx月xx日”
C:有蛋糕行业或者生鲜，需要顾客下单就可配送的，可以选择” 不允许预约时间,以提交时间为预约时间”，当顾客下单后，商家就可以马上安排配送。
在软件设计初期，我们就考虑到当商家从安全及性能角度进行延伸的问题，如果商家兑换量大的情况下，可以考虑将我们的系统一分为二，即进行分离部署，客户兑换的系统部署在一台独立的服务器中，商家管理后台的系统部署在另一台服务器中。
系统在批量自动核销（异步通讯）、ERP订单推送、ERP同步物流、ERP回写物流池、电子券合成(异步通讯)这些自动任务执行时，因网络通讯或者主动跳出系统导致系统没有完全执行完相关的任务，此时当使用者再次登录系统，系统会再次检索系统未完成的任务，自动开始执行。
系统在定期会自动清理数据库表及文件空间，以保证系统可以无限运行。
1：在7天内已发货订单自动标记为已完成。
2：自动清理本地缓存15天的电子面单的数据。
3：自动清理超过90天的短信日志。
4：自动清理超过180天的登录日志。
5：自动清理超过180天的事件（记录用户在系统中的核心模块操作）日志。
6：自动清理本地缓存15天的电子券数据。
系统直接将用户账号与权限直接进行绑定，由统一的权限拦截程序进行统一甄别并进行鉴权。
上海广电集团
上海丰收日
河南航天豫南基地
深圳粮食集团贝格厨房食品供应链
安徽鸿润(集团)股份有限公司
黑龙江龙和集团
大连渔公码头
中国民生投资集团
武汉梁子湖水产集团
广东荣诚食品
上海面包新语
广西新农商集团
软件从2015年6月起，经历了四次大型产品迭代，自第四代以来，全部代码重新重写。
在软件发展的大道上，需要不断的提升产品能力，才不会被历史的车轮辗过。
昆山甲乙丙丁网络科技有限公司旗下产品
礼保通®
