同城小程序开发 里，用户说餐已送到，商家端还显示待接单。同一笔单在两端各显示到哪，要事先写清，否则客服只能让两边互相截图。显示可以不同句，依据必须是同一笔记录。
一、两端看的是同一单号的不同句子
用户关心进度，商家关心该不该做。所以句子可以不同，单号、金额、下单时间必须相同。用户端看到「骑手已取餐」时，商家端应能看到同一时刻之后的制作已完成或已交出，而不是仍停在待接单。
若两端单号相同、走到的档次不同，就是展示读错了档，不是两笔订单。先按单号在后台把档次读出来，再分别看两端用了哪一句。不要为了让某一端好看，单独改那一端的记录。
二、每一档两端各说什么
下面这段把同一笔记录拆成两端文案。它用来验收展示有没有超前或落后，不用来给财务出账。
text
待付款：用户端显示待支付；商家端不出现在待制作
已付款：用户端显示已付款；商家端显示待接单
商家已接：用户端显示商家已接；商家端显示制作中
骑手已接：用户端显示骑手已接；商家端显示待交出
已送达：用户端显示已送达；商家端显示本单完成
金额两端都读订单记下的应收商家端在待付款时不出现，是为了避免后厨做一份还没付钱的餐。用户端在已送达之前不要显示已完成。哪一端超前，就改哪一端的句子，记录本身仍按真实动作往后走。
三、金额和商品名称不要各算各的
用户端展示的应付，应是下单时记下的金额。商家端看到的也应是这一笔，不要用当前菜单价再乘一次数量。商品名称若后来在菜单里改了，已下的单仍显示下单时的名称，两端一致。
备注、餐具份数写在订单上，两端都能看到。只在某一端改备注，另一端不知道，配送会出错。备注的修改也记在同一单号下，并留下修改时间，方便客服复述。
四、取消和退款不要只改一端
用户取消时，若款项未付，两端都变成已取消，商家端从待制作里消失。已付款后的取消，用户端显示处理中的退回，商家端显示停止制作。不要出现用户已取消、商家仍在制作的空档还不提示。
退回的结果写在同一单号上，两端用各自的句子说明，但金额和是否退完以后台记录为准。系统侧不抽成客户平台订单，两端都不要再显示一笔由系统扣下的费用。商家结算由客户自己定，不写进展示句子里。
五、骑手端不要变成第三套数
骑手看到的取餐地址、应收，也应来自同一订单。有的实现给骑手另存一份，结果改备注只改了用户端。骑手读订单上的字段，不读一份复制出去的旧说明。复制只适合当次通知，通知发出后仍以订单为准。
派给骑手的时间记在订单上。用户端说骑手已接，就要能在订单上查到这个时间。查不到，就是展示句子没有对应记录，验收不算过。
六、统一后台能把两端句子对在一起
客服不应分别登录用户端和商家端才能对一笔单。统一后台按单号同时看到记录档次，以及两端将要显示的句子。私有化源码交付后，这套记录在客户自己的库里，后台账号交给客户。
两端句子可以固定在三个时刻看：刚付款、商家刚接、骑手刚接。每个时刻把用户端、商家端和后台档次放在一起。三个时刻都没有超前或落后，才算展示跟着记录走。只看最终送达，中间断档会被漏掉。商品若在已付款之后无法继续做，两端都要提示，金额仍是下单时的数，不要改成零，以免用户以为这单没有下过。
光合同城按同一订单给用户端和商家端不同的句子。验收抽一笔已付款未接单的：商家端看得到，用户端不是待支付；再抽一笔待付款的：商家端待制作里没有它。两笔都符合，两端才算对齐。