|
为配合系统升级至多品牌管理版本，本次首先针对条码缓存功能进行一次改进，改进后服装收银系统的性能将提升近5倍，占用CPU资源更少，服务器响应的速度更快。下一步是将系统升级成高性能兼容多品牌管理功能的改进。 服装管理软件网络版重要更新：1、条码缓存，对条码功能进行最大优化，收银系统响应速度加快5倍。2、离线数据缓存，防止由于各种原因数据上传不成功难以核对数据。 3、更新系统增加执行固定文件不经压缩下载的脚本。 12-12：严重问题：当离线数据上传发生错误（如日期不在进销存期间），再进行帐目平衡检查，就出现帐目不平 衡，然后把离线全上传，再检查，就平衡。该问题对数据准确没有影响，会影响数据核对及软件设计时参考。这个问题需要仔细检查。技术人员解决方法备注：原因 为在平衡检查时去除了上传未完成的标志，但服装版单据保存成功帐目即生效，不存在完成与未完成之分，所以造成这种数据暂时错误，上传成功后标志清除即正确 的显示。修正该问题需要更改脚本。 12-09：由于经常针对某客户进行单独数据库更新脚本，为不影响更新包及每次都要压缩传送较麻烦。更新系统增加一个接口，可以单独检测执行目录下的 U.SQL，如发现即执行更新，完后即删除该文件。防止再次执行更新操作，因为有时这个文件存放的更新脚本只能执行一次。注意重复更新可能会造成数据错 误。(更新系统1.0.0.21版本以上有这个功能) 12-14：商品资料款号编辑框为20位长，款式编辑器为16位长，这两个地方的编辑框全部定长为数据库长度17位。 12-14：款号选择器在录入款号后回车，检索时为SELECT 1800.* 这样会把图片也带出来，优化后去除图片列，这样会快一些。(条码标签制作模块同理也要进行优化)  12-10：【经营分析】的SQL语句太长了，该存储过程要处理一下，把一条语句分成两条，再放到存储过程里合并。否则在某些版本的SQL中可能会因为语句太长而报错。  12-10：优化：款号检索原先为50笔记录，更改为30笔，检索时分两种情况，从款号检索（采购进货时用），从某仓库里的存货检索（销售开单，出库业务等），进货类检索时不需要分组，出库类检索需要分组。款号增多时会有少少的性能提升。  12-12：类别基本资料和仓库基本资料的相关汇总数汇总最新制作的条码表，得出分色分码的汇总数将更加准确。 12-11：条码增加缓存表，进货单保存成功即生成条码，该功能在前台处理好后再交服务程序，服务程序无需更新。 12-16：针对条码缓存后的性能测试报告（款号2193个 条码：3199个)： 服装收银系统条码框录入 13 回车，即检索包含13 前50笔。 未缓存前：68.77（百分比） 缓存后带促销方案：14.80 不带方案：13.95 。最终优化前占资源81，优化后占资源19 12-15：原条码标签制作模块是根据参数计算，因更改成缓存的方式，如条码即款号和手动录入的条码是不能计算的。所以所有标签都要从数据库取，会有未进过货的尺码，颜色会有不存在条码的情况，制作的过程要作提示。 12-16：条码的存储方式有变动，离线库的结构需要作调整，对已使用当班及离线功能的用户，需要手动替换离线库。  12-16：香港客户要求：服装收银系统可以设定【离线销售单据】与【离线交班明细】上传成功后保留XX天。防止上传不成功丢失的话不好找回数据，也不好核对数据。 12-16：由于条码增加缓存后，数据库增加会对正版检测有影响，去除D1809的检测，超市收银系统通用批发进销存软件不需要增加D1809表，不会影响到。 12-16：交班明细表的【正常交班】列更改成【离线上传】，原过滤T=1 为上传标志，现无需加任何条件，因为离线【交班】增加了缓存功能。T 列增加默认值为0=非上传，1=离线上传。 |