POS 订单模型:

属性名称	描述
POSOrder.status	Totaled (订单完成,销售或退货) TransactionVoided (终止交易, 未支付) PostVoided (取消交易，已支付) Suspended (挂起)
POSOrderLine.voidFlag	true/false 订单行是否被删除
POSOrderSummary.typeCode	Sale      销售,金额为正 Return  退货, 金额为负
POSOrderLineProduct.orderLineType	Sale      销售商品 Return  退货商品 退货或换货单中出现
RetailPriceModifier.amountAction	Subtract Add Replace
RetailPriceModifier.level	Row   单行折扣 Total  整单折扣分摊
RetailPriceModifier.discountItemLink	折扣价格对应的促销，指向DiscountInfo.discountId
DiscountInfo.discountBenefit	Customer Staff
DiscountInfo.discountTypeCode	促销类型，如单行一口价，单行百分比折扣，会员价，买N赠一，会员券
TaxInfo.typeCode	Sale      销售,金额为正 Return  退货, 金额为负
Tender.typeCode	Sale Refund
Tender.tenderType	支付方式，如mobilePayment (移动支付), cardPayment (卡类支付),  cash 现金
Tender.subTenderType	子支付方式, 如移动支付下有微信(wechat)，支付宝 (alipay) 等

订单属性:

订单编号 orderId:

POS系统: 由日期 YYYY/MM/DD，门店编号shopId,  收银台号 tillId,  收银台序列号 sequenceNo 四维构成一个唯一订单编号， 且门店编号，收银台号，收银台序列号是POS特有属性.

电商系统: 一般由系统自动生成

收银员识别号 operationId: 表示订单录入和操作是由哪个收银员完成的. 为POS特有属性

添加商品: 

加购方式:

POS系统: 通过扫描商品标签上二维码读取商品GTIN 或者是手工输入标签上商品编号 的方式来添加商品到购物车.

电商系统: 通过浏览商品点击”添加到购物车”按钮来添加商品到购物车.

库存:

POS系统: 添加购物车一般是客户已经选定了实物商品之后到收银台完成支付环节，所以不必考虑商品库存问题.

电商系统: 添加购物车之前一般需要检查并锁定库存.

商品识别码:

POS系统: 商品一般是一物一码(每件商品都有唯一标识码sgtin), 销售完成后和门店的防盗系统联动，确保商品离店时是已售出的状态.

电商系统: 一般不区分同类商品的每一件.

购物车订单展示:

POS系统: 购物车如果有多件相同商品一般不合并展示，而是每一件展示为购物车中单独的一行

电商系统: 相同商品合并或分开展示都有

不合并展示有一个好处是尽管商品相同，但是促销分摊后的金额每件商品可能会不同，分开展示更加清晰，同时从购物车移除单件商品会更加简单.

购物车操作:

POS系统: 会有特殊的购物车操作，比如挂起/恢复: 在门店某个收银台外设发生故障时可以挂起订单暂存订单中的商品然后在别的收银台恢复

POS系统: 店员操作的购物车整单取消和单行删除会被认为有潜在的欺诈风险，比如飞单 (取消订单但是商品被客人拿走)，需要追踪操作或权限控制.

电商系统: 购物车整单取消和单行删除由用户自己完成，一般没有欺诈风险

促销/折扣:

促销计算方式:

POS系统: 采用混合方式, 优先按照事先配置在促销引擎中的规则计算，但也可以应用手工折扣到单品和订单，覆盖促销引擎计算结果或者与之叠加.

电商系统: 折扣纯粹按照事先配置的规则自动计算

促销复杂度: 

POS系统: 不太建议太复杂规则，面对客户的可解释性和计算性能是需要考虑的点.

电商系统: 促销一般规则复杂玩法多.

POS促销引擎设计需要考虑的点:

需要适配手工促销和自动促销混合的场景，按照以下五个层次计算,  单品自动促销，单品手动促销，商品组自动促销,  整单自动促销，整单手动促销.

将购物车传入促销引擎进行计算的时候，可以传入商品或者商品+折后价格, 如果传入商品，那么促销引擎会自动计算单品促销的折后价格，商品组促销和整单促销之后整个购物车的最终价格.  如果传入商品+手工调整后的折后价格，那么促销引擎不再计算单品自动促销的折后价格，只会自动计算之后的层次: 包括商品组自动促销,  整单自动促销.

促销引擎的计算可以作为中台微服务接口，可以把促销规则推送到POS终端进行计算，更好的兼容离线模式和消除单点瓶颈. 或者单品促销规则推送到POS终端进行计算, 而商品组或者整单促销通过中台促销引擎.

支付方式:

POS系统: 支付方式会包括移动支付和现金支付

电商系统: 一般为移动支付不会包括现金

现金处理为POS系统带来额外的复杂度，主要包括四舍五入和资金管理需求，后面将详细描述

四舍五入:

产生原因: 

目前POS端最小的现金单位为”角”, 包括单品金额和接受顾客支付的最 小金额单位.

销售交易的整单折扣计算产生了小数2位(分)的交易金额, 计算顾客支付金额时需要四舍五入. 比如: 交易金额79.9元， 再打75折 折后总价为59.925元.  四舍五入后为59.9元.

销售交易整单折扣分摊后单品的实付金额产生了小数2位（分), 如果客户部分退货，计算退款金额时需要四舍五入. 比如购入3件商品每件100元，折扣券10元，分摊到每件商品最终实付金额分别为96.67, 96.67, 99.66,  如果退一件就需要四舍五入，实际退款金额为96.7元.

正负规则:

定义销售交易五入为正（实际收入大于期望), 四舍为负（实际收入小于期望).

定义退款交易五入为负(实际退款大于期望，实际收入小于期望)，四舍为正  (实际退款小于期望，实际收入大于期望).

举例:

顾客购入3件商品，金额为79.9, 79.9, 59.9元.  整单折扣25%. 总计219.775% = 164.78.   商品实际折后金额分别为79.9 * 75% = 59.93    79.975% = 59.93   164.78 – 59.93 – 59.93 = 44.92.

顾客支付方式为现金, 实际支付金额五入后为 164.8.  0.02 记作订单五入.

退货单1: 顾客退货79.9元商品, 按照商品折后金额退款，实际退款四舍后为59.9元, 0.03记作退货单四舍.

退货单2: 顾客退货59.9元商品, 按照商品折后金额退款，实际退款四舍后为44.9元, 0.02记作退货单四舍.

退货单3: 顾客退货79.9元商品,  由于是最后一件商品, 退款金额应该等于总支付金额的剩余值: 164. 8 – 59.9 – 44.9 =  60     59.93 – 60 = -0.07 记作退货订单五入.

资金管理:

资金管理需求包括门店收银台申报，对账，差异处理，主要是现金收银可能会导致钱箱中现金数目和销售交易产生的期望值不符. 店员需要在每天关店时清点每个收银台钱箱的现金并输入，每天早上开店时也要再做一次.

退货处理：

无论是POS系统还是电商系统，对订单部分退款金额的计算都是基于促销分摊进行的，促销分摊的金额比例一般是基于单品折扣之后的最终价格

但是POS系统对于退货会有一些额外的特殊场景需要考虑, 包括:

修改退货商品对应的退款金额:

顾客可能会对退款金额有异议，比如原订单总价格400元，享受满300减30的促销优惠，客人退了一件商品50元，剩下的金额仍然满足促销条件, 但是如果按照促销分摊逻辑，那么客人获得的退款金额会少于50元. 这时店员可以上调退款金额满足客人的诉求.

相反的一种场景是顾客为了享受折扣凑单多买了某件商品然后再退掉. 由于促销分摊相当于退货之后依然能享受到部分折扣，这时候店员需要下调退款金额将全部折扣从退款金额中扣除.

修改退款金额允许上调或者下调，上调的限制不能超过商品原价和订单剩余价格的较低者.

离线退货:

离线退货是指客人携带小票, 但是因为网络原因或其他原因无法获得订单详情，这时需要店员根据小票上信息手工录入退货商品, 再选择退款支付方式进行离线退款并录入退款凭证.

无小票退货:

作为退货兜底方案, 无小票退货是指客人未携带小票但是有办法证明确实是在门店买过，比如出示移动支付凭证等, 这时需要店员根据退货吊牌信息录入退货商品, 再选择退款支付方式，根据移动支付凭证退款. 

离线模式:

POS系统: 需要在网络波动的情况下尽可能的让客户完成购物流程，对于网络异常无感知.

电商系统，网络波动

为了支持离线模式，POS系统设计需要额外考虑以下一些点:

配置数据和门店的员工数据在POS启动时自动加载到客户端. 

商品和促销规则尽量加载到客户端 (取决于两者的数量，某些快时尚品牌可能商品非常多). 优先加载商品，促销如果无法完全加载可以通过手工促销代替.

支付环节: 一般会配置一个额外的网络环境，比如默认是门店局域网, 额外配置一个手持设备用4G网络进行支付. 减少网络波动带来影响

订单同步: 一般情况下支付完成后订单数据会同步加载到云服务端，如果在离线状态下，订单需要先在POS终端保存，网络恢复后再批量上传到云端.

监控: POS和云中台维持一个心跳, 能让离线/在线状态在POS终端正确展示. 云中台需要对所有POS终端在线状态监控并告警. 

操作追踪和反欺诈:

POS系统: 为了应对门店可能产生的欺诈交易或异常状况, POS终端会记录上传一些额外的信息到云端，主要包括:

收银台序列号: 对于每个收银台应该是一个连续递增的数字,  如果在服务端发现收到的序列号有缺失，那很有可能是收银台的订单没有发送到服务端

购物车商品加入方式: 扫商品标签二维码添加还是手输商品编号添加

取消订单或者删除的订单行

退货单号输入方式: 扫小票上的订单号还是手输小票上的订单号 (客人退货时是否携带小票)

退货商品选择方式: 扫商品标签二维码添加还是手输商品编号添加 (退货商品是否有标签)

电商系统: 一般不具有以上所述信息

订单配送:

POS系统:  一般客人都是选择当场取走所购商品, 所以购物车和订单流程不会记录配送相关信息. 当然寄送到家可以作为一项不错增值服务(主要看商家是否愿意承担运费). 这时店员需要在POS终端帮客人录入或者选择配送地址 (作为会员画像的一部分). 将商品装入包装袋打包并由门店统一配送. 

电商系统：寄送到家一般都是默认选项，客人需要输入配送地址，选择配送时间, 配送服务商等. 系统需要计算是否免邮及相应运费等.