改完菜单价，在送的单会不会跟着变，取决于价格记在哪。私有化源码交付部署到自己的机器之后，订单上的价格和菜单上的价格要分开放，改菜单不应扫到已经在送的那一笔。
一、两个价格不要放在同一处
菜单价格放在商品记录里，给新的下单读取。订单价格放在每一笔订单上，在提交时抄下来。两处都在业务库这台机器上，但是不同的记录。页面机器只展示，不保存唯一的那份价格。
若订单不抄价格，只记下商品编号，每次打开都去读菜单现价，那么改价会立刻出现在所有未送达的单上。用户下单时看到的数，和送达时的数会不一致。所以提交时必须把金额写进订单自己的记录。
二、写入订单之后，菜单变更碰不到它
商品记录更新时，只更新商品那一行。程序不应再按商品编号去改所有未完成订单。需要核对时，在业务库里看：商品行是新价，某一笔在送订单行仍是旧价。两行不同，才是正确的存放。
已经完成的订单同样保留旧价。出账读订单行，不读商品行。这样按城或按日导出，都不会因为昨天改了菜单而把历史金额搅乱。备份业务库时，两行一起在，恢复后仍能看出当时卖多少、现在标价多少。
三、页面缓存不能当成价格来源
页面机器可能把菜单缓存下来，加快浏览。缓存过期前，用户可能仍看到旧菜单，这只影响还没提交的浏览。一旦提交，以写进业务库的订单金额为准。不要用某一台页面的缓存去改库里的订单。
多台页面必须读同一业务库。若某台页面自带一份商品库，它上面的改价不会进入正式订单，或者只改到它自己产生的单。私有化之后应关掉这种分叉，商品和订单都只认主库。
四、怎样检查改价有没有扫到在送单
改价前后各看一次业务库。改前导出未送达单号和金额，改的是商品行，改完再按同样单号读订单行。金额集合应完全相同。有差异的单号就是被扫到的，要先停掉改价入口，把这些订单行改回改前导出的数，并查清是哪一次保存带上了订单。
不要在页面上目测。页面可能缓存旧画面，看起来没变，库里已经变了；或者相反。以业务库的订单行为准。统一后台的详情也应读这一行，而不是临时拼菜单价。
五、备份与恢复不能只留菜单
只备份商品、不备份订单，恢复之后在送的单会丢，或者金额变成恢复时刻的菜单价。备份整座业务库，商品行和订单行都在。恢复到备用机器后，抽一笔改价前就在送的单，金额应仍是旧的。备用机器不接新单，避免和主库各写各的。
源码放在客户的目录，后台账号能登录看到这两行。三样都在客户这边，才谈得上自己核对接没有接错。交接说明写明主库在哪一台。
六、新单读取商品行，旧单不读
新下的单在提交瞬间读取商品行，把金额抄到新的订单行。抄完就不再跟随。在送的旧单一直读自己的订单行。这个方向不要做反：不要让旧单每次打开都读商品行。
改价保存若花的时间很长，先看是不是在扫描全部订单。正常只更新商品那一行，应很快结束。长时间占住库，新下的单会写不进去，用户看到失败。这种保存要停掉，改成只写商品行。订单行上的金额一旦抄下，备份、出账、送达都读它。任何从商品行回写订单行的安排，都不要放进每天自动要做的事。每天自动只做备份和出表。出表读到的金额应和订单行一致，抽一笔对一下即可。
