修改日志
# 2020-06-24
### 原 lable/ 路径接口名称变更
`.../label/class` 更名为 `.../lable/class`
`.../label/item` 更名为 `.../lable/item`
### 原 user/login 接口变更
1.返回参数中 [.../data/config/] 下所有 `label` 更名为 `lable`
2.返回参数中 [.../data/config/] 下增加以下新成员
```
lable_show_name (string)
触屏标签.商品名称显示(0:不显示/1[默认]:显示全称/2:显示简称)
lable_show_code (string)
触屏标签.商品编码显示(0:不显示/1[默认]:显示条码/2:显示编码)
lable_show_image (string)
触屏标签.商品图片显示(0[默认]:不显示/1:显示)
lable_show_price (string)
触屏标签.商品价格显示(0:不显示/1[默认]:显示原价/2:显示特价/3:显示原价+特价)
lable_show_spec (string)
触屏标签.特价标志显示(0[默认]:不显示/1:显示)
```
# 2020-06-28
### 原 order/cart 接口变更
1.返回参数中[.../data/list/]下 `amount` 更名为 `amt`
2.返回参数中[.../data/]下 `current_page` 更名为 `page_current`
3.返回参数中[.../data/]下 `current_row` 更名为 `row_current`
# 2020-06-29
### 原 order/page 接口变更
1.入口参数 [operate] 的可取值
由 `(0:上一页/1:下一页)` 变更为 `(P:上一页/N:下一页)`
### 增加新接口 order/row
1.用途：在购物车（当前小票）的当前页中滚动到指定行的商品（比如用户在触屏上点击购物区某行商品，或者在键盘模式下点击上下光标键）时需要调用此接口
`注：此接口仅用于将当前UI界面上的焦点行的行号，同步到后端缓存中（用户在UI界面上改变了焦点行之后，与后端缓存中记录的焦点行已经不一致了），不修改任何业务数据，因此前端如果能够自行处理当前行的焦点UI显示，则后续无需调用cart接口（即使多调用一次，返回值中也仅有row_current的值会发生变化）`
# 2020-07-03
### 原 order/cart 接口变更
1.增加出口参数 [data/list/control_price]
```
价格控制
[0]:该商品不允许手动修改价格和打折
[1]:允许手动修改价格和打折
```
`说明：`
`a.这个控制是在用户是否具有<改价><打折>权限之外的另一层控制，是跟具体的商品绑定的`
`b.权限控制决定<改价><打折>按钮是否显示（在权限体系内，改价和打折是2项不同的权限），如果该收银员没有权限，则对应的按钮在界面上不会显示，这与具体的商品无关`
`c.商品上的价格控制决定了<改价><打折>按钮的状态是否可用（与权限体系不同，这里的价格控制同时影响改价和打折两项功能），如果当前商品不允许手动修改价格，则对应的按钮在界面上显示为不可用的状态`
2.增加出口参数 [data/list/control_qty]
```
数量控制
[0]:该商品不允许小数销售
[1]:允许小数销售
```
`说明：`
`a.当用户在界面点击购物区某行商品时，如果该值为[0]，则表明该商品不允许进行小数销售，对应的修改数量的数字键盘上不能出现小数点`
# 2020-07-05
### 原 order/pay 接口变更
1.返回参数中 [.../data/] 下 `debt_amount` 更名为 `dibs_amount`，原因是与数据库命名保持一致
1.返回参数中 [.../data/list] 下 `delete_enabled` 更名为 `deletable`，原因是与数据库命名保持一致
# 2020-07-07
### 原 order/operate 接口变更
1.从入口参数中去除了 [row] 这个参数，即：对单行商品的操作固定只作用在当前行上，而不能随意指定某一行
`说明：`
`a.目前对单行商品进行操作的业务场景，都是针对当前行，因此[row]这个参数的应用场景不存在，而且这个参数导致了代码逻辑非常复杂。`
`b.另一方面，去掉了[row]这个参数，也就意味着当用户在界面上点击某行商品之后，调用[.../order/row]接口来同步当前行成为了必须的步骤`
# 2020-07-08
### 原 order/cart 接口变更
1.返回参数 [.../data/list] 下面
去除了2个参数:
`five_flag -- 赠送标志（0/1）（该商品是否已经赠送）`
`discount -- 折扣率（4位小数）（已打过折的折扣率，取值范围0-1，比如8折表示为0.8）`
新增以下参数:
`operate_flag -- 标注该行商品是否已进行过相关的手动操作（3:已手动改过价格/4:已手动打过折扣/5:已手动赠送/其它值无意义）`
`注：当operate_flag==4时，调用者需要根据sale_price/original_price的值自行计算单品折扣率(折扣率最大4位小数，以百分比格式表示，如90.15%)`
# 2020-07-09
### 原 order/cart 接口变更
1.返回参数 [.../data/list] 下
`sale_price` 更名为 `price`
`original_price` 更名为 `org_price`
变更原因：保持后端数据库字段及其它接口中相同字段的命名统一
### 原 order/detail 接口变更
2.返回参数 [.../data/list] 下
`amount` 更名为 `amt`
变更原因：保持后端数据库字段及其它接口中相同字段的命名统一
# 2020-07-22
### 原 lable/item 接口变更
1.返回参数 [.../data/list] 下增加以下2个字段
`fresh_type -- 生鲜标志(0:普通商品/1:生鲜商品[称重]/3:生鲜商品[计件])`
`price_type -- 管价标志(0:普通商品[有售价且不可修改]/1:可改价商品[有售价且可修改]/2:无售价商品[必须手动输入售价，比如联营不管价商品和租赁专柜商品])`
# 2020-07-23
### 原 order/input 接口变更
1.入口参数 [code] 增加了新的扩展格式
`通过该参数传递商品条码时，支持[条码{#}数量]的格式同时传递条码和数量(重量）`
`比如 6900053182880{#}2.01 会将{#}前面的值识别为条码，将{#}后面的值识别为数量(重量)`
2.入口参数 [flag] 修改了预定的含义
原有含义：
`0:标记code中记录的是称重的重量值[比如生鲜商品称重，前端程序已经明确知道传进来的是重量]`
`1:标记code中记录的是商品条码[比如在触屏标签区点击商品]`
`2:标记code中记录的是移动付款码[比如在结算界面点击了移动支付]`
`3:标记code的值是通过IC读卡器读入的会员信息/如果不是以上情况请赋空值`
本次修改过后，去除了0值的定义（经过讨论，该场景并不存在），仅保留1/2/3这三种预定值
# 2020-07-24
### 原 order/operate 接口变更
1.入口参数 [value] 的含义变更
`...营业员（格式：编码-姓名)`
变更为
`...营业员（格式：编码{#}姓名)`
变更原因是需考虑营业员编码中本身存在[-]的情况
# 2020-07-25
### 原 order/cart 接口变更
1.出口参数 [.../data/list/] 增加字段
`sales_no -- 导购员编码`
`注：原来的版本中只有sales_name`
# 2020-07-30
### 原 order/operate 接口变更
1.入口参数 [operate] 的含义变更（赠加可取值7）
`...4:打折/5:赠送/6:添加营业员`
变更为
`...4:打折/5:赠送/6:添加营业员/7:取消赠送`
# 2020-09-01
### 原 order/input 接口变更
==1.增加 [scene] 作为入口参数（适用场景增加）==
> `scene的含义为调用场景，可取值:`
`[1]:在销售主界面调用（商品/数量/重量/移动付款码/会员信息）`
`[2]:在结算界面调用（现金金额/移动付款码/会员信息）`
`注：其它值将会提示参数错误`
变更说明
`增加[scene]参数之后，意味着该接口的适用场景增加了，从原本适用于销售主界面，变更为同时适用于销售主界面和结算界面。`
`该接口的作用，是在这两个场景中，对用户输入的值进行解析（这些值可以是商品/数量/重量/现金金额/移动付款码/会员信息等），解析的结果通过[data.operate]返回给调用方，调用方根据该值来确定后续要进行的操作。`
`相关逻辑可参考下图中的描述:`
==2.将 [flag] 从入口参数中去除==
>`该参数的原本含义是在前端程序已经明确知道code含义的情况下使用，用来标识code具体代表什么，可取值:`
`[1]:标记code中记录的是商品条码，比如在触屏标签区点击商品`
`[2]:标记code中记录的是移动付款码（比如在结算界面点击了移动支付）`
`[3]:标记code的值是通过IC读卡器读入的会员信息`
`其它情况请赋空值`
为什么会去除这个参数
`在新版本中，input接口剥离了部分多余的功能，退化成了一个单纯的字符串解析接口，用于对用户输入的值进行解析并识别其含义，解析后得出的含义通过出口参数[data.operate]来返回给调用方，调用方gmf 根据这个返回值来决定自己后续要进行什么操作。`
`而[flag]这个入口参数原本的作用就是用来标识用户输入的值是什么含义，这与input接口的功能定义是矛盾的（既然已经知道这个code是什么了，为什么还需要解析呢，直接进行后续处理不就行了？），因此从接口定义上来说，这个参数已经没有了存在的基础。`
什么时候应该用input()，什么时候应该用operate()/pay()
`只有一条原则:`
`在无法明确知道用户输入的值代表什么含义的时候，才需要调用input接口来进行解析。`
`以在收银主界面输入商品为例，输入途径有很多:`
`（含义明确）在商品标签区点击某个商品`
`（含义明确）通过商品查询功能点击购买某个商品`
`（不明确）通过扫描枪扫描商品条码`
`（不明确）通过键盘输入商品条码`
`用户进行的这4种操作，程序获得的结果是一样的，都是一串数字字符（商品条码），但是在前2种情况下，程序通过用户的操作途径可以明确知道这串字符的含义是商品条码；而在后2种情况下，对于程序来说这串字符的含义是未知的（扫描枪和键盘是通用输入工具，用户输入的可能是商品条码，也可能是手机号，这个含义是未知的）`
`对于前2种情况，直接调用operate(operate=0, code=条码)即可`
`对于后2种情况，则需要调用input(scene=1, code=未知输入)，然后观察[data.operate]的返回值`
==3.入口参数 [code] 含义变更（增加对结算界面输入的支持）==
原本含义
> `该参数用于指明用户输入的内容，可以是以下任意值:`
`商品条码（对于生鲜称重商品支持[条码{#}重量]的格式同时传递条码和重量）`
`数量/重量`
`移动付款码`
`会员信息（手机号/刷卡值/会员电子码）`
变更后含义
> `该参数用于指明用户输入的内容（需要由程序识别其含义），可以是以下任意值:`
**`商品条码/秤码`**
`数量/重量`
`移动付款码`
`会员信息（手机号/刷卡值/会员电子码）`
**`现金金额`
`[空值]:参数错误`
`说明：在原本含义的基础上，增加了对结算界面输入现金金额的支持，并且明确禁止空值`**
==4.入口参数 [way] 含义变更==
原本含义
> `该参数用于指明[code]的输入方式，可取值:`
`[0]:手动通过键盘逐个字符输入`
`[1]:设备输入[包括扫描枪/磁卡读卡器/IC读卡器/点击商品标签等全自动输入的方式]`
`[其它值]:如果不能明确输入方式则赋空值`
变更后含义
> `该参数用于指明[code]的输入方式，可取值:`
`[0]:设备输入[包括扫描枪/磁卡读卡器/IC读卡器/点击商品标签等全自动输入的方式]`
`[1]:手动通过键盘逐个字符输入再按回车的情况`
**`[其它值]:参数错误`
`说明：在原本含义的基础上，对可取值作了进一步限制，不允许出现[0/1]之外的其它值`**
为什么要变更
`用户是以何种方式输入[code]的值，对于判断[code]所代表的含义和有效性至关重要，比如用户出于安全性考虑，会限制会员在进行储值支付的时候必须要刷卡，而卡上记录的内容本质上只是一串字符，那么程序需要知道用户是如何输入这串字符的，以此来判定本次操作的全法性，因此参数[way]必须要给出明确的值，不能省略。`
==5.出口参数 [data.operate] 含义变更==
原本含义（`本次输入对应的后继操作`）
>`可取值:`
`[0]:输入值为数量，后续调用cart接口`
`[1]:输入值为商品，后续调用cart接口`
`[2]:输入值为移动支付码，后续调用pay接口`
`[3]:输入值为会员信息，后续调用vip接口`
`其它值:无需后续处理[比如误扫了二维码网址，程序无需后继处理，也不需要提示用户，直接忽略即可]），调用者根据该值确定后继要调用的接口`
变更后含义（`返回入口参数 code 的解析结果`）
> `该参数用于返回 [code] 的解析结果（指明用户输入的这个code是什么含义），同时也指明了调用方后续应该要进行什么操作`
**`注意:`
`在新版本中，[0]和[1]这两个值的含义互换了，原因是为了在多个接口中保持[operate]这个参数的含义一致，前端程序需要检查相关调用的处理`**
> `可取值:`
`[0]:输入值为商品（销售主界面），在input内部会自动调用operate(0,条码)将该商品加入购物车，前端程序后续需要调用以下接口`
`.../order/cart`
> `[1]:输入值为数量（销售主界面），在input内部会自动调用operate(1,数量)修改当前商品的数量，前端程序后续需要调用以下接口`
`.../order/cart`
> `[2]:输入值为移动支付码（销售主界面/结算界面），前端程序后续需要调用以下接口`
`.../order/pay(operate=2)`
`.../order/cart`
> `[3]:输入值为会员信息（销售主界面），前端程序后需要调用以下接口`
`.../order/vip`
`.../order/cart`
> `[4]:输入值为会员信息（结算界面），前端程序后需要调用以下接口`
`.../order/pay(operate=4)`
`.../order/cart`
> `[5]:输入值为现金金额（结算界面），前端程序后需要调用以下接口`
`.../order/pay(operate=5)`
`.../order/cart`
> `[其它值]:忽略，无需后续处理。比如在收银主界面误扫了二维码网址，此种情况下input不会返回错误，但data.operate也不会返回有效值，表示程序无需后继处理，也不需要提示用户，直接忽略即可`
==6.出口参数 [data.assist] 含义变更==
原本含义
> `[data.assist]是对[data.operate]的补充说明，可取值:`
`[0.1]:数量`
`[1.1]:商品国标码`
`[1.2]:称重商品秤码`
`[1.3]:生鲜商品店内码`
`[2.1]:支付宝付款码`
`[2.2]:微信付款码`
`[2.3]:银联付款码`
`[3.1]:手机号`
`[3.2]:微会员编码`
`[3.3]:磁卡或IC卡刷卡值`
变更后含义
> `出口参数 [data.assist] 是用于对 [data.operate] 做进一步的补充说明。`
`比如:`
`当用户输入的 [code] 是代表商品条码的时候，[data.operate]会返回[0]值，但在有些情况下，程序除了需要知道这个输入是商品条码之外，还需要要知道这个商品条码是什么类型的(是国标码、还是秤码、还是生鲜店内码)，这个时候就可以通过这个额外的参数 [data.assist] 来进行判断。`
`再比如:`
`当用户在结算界面扫描顾客手机上的移动付款码的时候，[data.operate]会返回一个[2]值，表示用户这个输入是移动付款码，此时程序需要继续调用 [pay] 这个接口发起支付，但由于支付是一个耗时的过程，通常需要在前端交互界面上显示进度提示信息（比如显示：支付宝...请稍候），那么调用方如何知道顾客手机上的这个付款码是支付宝而不是微信呢，这时候就需要通过 [data.assist] 来进行判断。`
> **`注意:`
`在新版本中，[0.x]和[1.x]这两个值的含义互换了，原因与[data.operate]相同`**
> `对于出口参数 [data.operate] 的补充说明，可取值:`
**`[0.1]:商品国标码`
`[0.2]:称重商品秤码`
`[0.3]:生鲜商品店内码`
`[1.1]:数量`**
`[2.1]:支付宝付款码`
`[2.2]:微信付款码`
`[2.3]:银联付款码`
`[3.1]:手机号`
`[3.2]:微会员编码`
`[3.3]:磁卡或IC卡刷卡值`
### 原 order/operate 接口变更
==1.入口参数 [value] 命名变更==
由 `value` 变更为 `code`
为什么会有这个变更
`与其它接口保持命名一致`
==2.入口参数 [operate] 的含义变更（赠加可取值0）==
> `[1]:修改数量`
`[2]:删除`
`[3]:改价`
`[4]:打折`
`[5]:赠送`
`[6]:导购员`
`[7]:取消赠送`
变更为
> **`[0]:增加商品（code=商品条码，支持 [条码{#}数量] 的格式）`**
`[1]:修改数量（code=数量/重量，3位小数）`
`[2]:删除（code无意义）`
`[3]:改价（code=价格，4位小数）`
`[4]:打折（code=折扣率，4位小数，范围0-1）`
`[5]:赠送（code无意义）`
`[6]:导购员（code=导购员，格式：编码{#}姓名）`
`[7]:取消赠送（code无意义）`
变更说明
`在旧版本可取值[1-7]的基础上，加入了[0]值，其含义为增加商品，适用于以下场景：用户在收银主界面的商品标签区点击某个商品、或者通过商品查询功能点击购买某个商品，此时程序需要将用户选择的商品加入到购物车中。`
`在旧版本中是通过以下调用来实现的:`
`.../order/input(flag=1, code=条码, way=0)`
`在新版本中需要改为以下实现:`
`.../order/operate(operate=0, code=条码)`
为什么会有这个变更
`参考前面关于input接口的变更说明，在新版本中input的功能和含义有所变化（去掉了flag这个入口参数），变更后的input接口仅用于对用户的未知输入进行解析，对于已知的输入，应该直接调用对应的逻辑处理接口（比如operate和pay）。在上面的例子中，当用户点击商品标签的时候，前端程序获得了一串数字字符、并且明确知道这串字符是商品条码，因此也就不需要再通过input接口来识别这串字符的含义，直接调用operate(0, 条码)就可以了。`
`另一方面，从代码实现来说，在以flag=1作为参数调用input接口时，input内部的实现逻辑其实就是直接将code自动转发至operate接口来进行处理，也就是说这本身就是一个多余的步骤`
# 2021-03-12
### 原 order/pay 接口变更
==1.变更了入口参数 [operate] 的含义==
增加了[operate=100/200/300]这几个场景，变更后该接口的入口参数定义如下:
> `[operate=100]: 初始化结算(打开结算窗口)`
`*用于在打开结算窗口时，取得应付金额、尚欠金额等数据`
`code: 无意义`
`amount: 无意义`
`password: 无意义`
> `[operate=200]: 取消结算(关闭结算窗口)`
`*用于在关闭结算窗口时取消结算操作，清除所有已经录入的支付数据`
`code: 无意义`
`amount: 无意义`
`password: 无意义`
> `[operate=300]: 删除支付记录`
`*用于对已存在的某条支付记录进行删除操作`
`code: 支付记录行号(payment.[data.list.row])`
`amount: 无意义`
`password: 无意义`
> `[operate=2]: 移动支付`
`*用于发起移动支付`
`code: 付款码`
`amount: 支付金额，可取值(0表示支付剩余全部欠款；有效金额表示按该金额支付；无效金额则返回错误)`
`password: 无意义`
`注: [.../order/input]返回值[operate=2]的场景，即对应此处[operate=2]的调用`
> `[operate=2.6]: 移动支付子流程 - 手动确认`
`*支付流程超时后，收银员需要检查顾客手机上是否支付成功，如果顾客手机显示成功，则同时会有一个确认码，收银员需要在POS操作界面上手动选择[支付成功]，然后输入这个确认码`
`code: 确认码`
`amount: 无意义`
`password: 无意义`
> `[operate=2.7]: 移动支付子流程 - 取消支付`
`*支付流程超时后，收银员需要检查顾客手机上是否支付成功，如果顾客手机也没有成功，则收银员需要在POS操作界面上手动选择[支付失败]`
`code: 无意义`
`amount: 无意义`
`password: 无意义`
> `[operate=4]: 会员储值支付`
`*用于发起会员储值支付`
`code: 会员信息(会员码/实体卡密文/明文卡号/手机号)`
`amount: 支付金额，可取值(0表示支付剩余全部欠款；有效金额表示按该金额支付；无效金额则返回错误)`
`password: 支付密码(会员支付不需要密码时该值无意义)`
`注: [.../order/input]返回值[operate=4]的场景，即对应此处[operate=4]的调用`
> `[operate=5]: 现金支付`
`*用于发起现金支付`
`code: 无意义`
`amount: 支付金额`
`password: 无意义`
`注: [.../order/input]返回值[operate=5]的场景，即对应此处[operate=5]的调用`
> `[operate=其它有效值]: 自定义支付方式`
`*用于发起其它自定义支付(银行卡，自定义卡券等)`
`code: 支付凭证(银行卡的卡号，电子券的券码等）`
`amount: 支付金额`
`password: 无意义`
# 2021-03-15
### 原 order/cart 接口变更
==1.增加 [件数 data.total_qty] 作为返回字段==
> `在之前的版本中，只返回了当前订单的金额`
`data.tatal_amount--订单金额`
> `本次变更之后，同时返回金额和件数`
`data.tatal_amount--订单金额`
`data.tatal_qty--商品件数`
==2.增加 [优惠金额 data.list.promote_amt] 作为返回字段==
> `在之前的版本中，只返回了当前商品的金额`
`data.list.amt--金额`
> `本次变更之后，同时返回金额和优惠金额`
`data.list.amt--金额`
`data.list.promote_amt--优惠金额`
> `示例`
`商品A原价10.00，做促销特价9.00，购买数量5，返回值如下:`
`data.list.org_price: 10.00`
`data.list.price: 9.00`
`data.list.amt: 45.00`
`data.list.promote_amt: 5.00`
# 2021-03-17
### 原 order/pay 接口变更
==1.增加 [data.item] 作为返回字段==
> `在之前的版本中，只返回了支付记录列表，没有返回商品信息列表，本次变更后增加返回了商品列表，在当前版本中可用于生成小票打印数据`
`data.item的结果是一个集合类型，内部含有商品条码、名称、金额等字段，这些字段的命名与含义与[order/cart]接口完全保持一致`
### 原 order/cart 接口变更
==1.增加 [data.total_promote_amt] 作为返回字段==
> `该字段含义为本张订单优惠总额，用来和商品总件数一起，显示在销售主界面上`
# 2021-03-19
### 原 order/cart 接口变更
==1.返回字段 [data. previous_amt_mode] 含义变更==
> `该字段的用来控制销售主界面找零金额的显示样式`
`原定义`
`[1]:普通显示`
`[2]:着重显示`
> `本次变更后的定义`
`[1]:普通显示`
`[2]:着重显示`
`[0值或其它值]:不显示`
### 原 order/pay 接口变更
==1.增加多个返回字段==
`本次变更增加以下5个返回字段:`
> `一.[data.paid_amt]:已付总额`
`仅在结算完成(data.finished=1)的情况下有意义`
`用于小票打印时的实付总额`
> `二.[data.prom_amt]:优惠总额`
`仅在结算完成(data.finished=1)的情况下有意义`
`用于小票打印时的优惠总额`
> `三.[data.xdd_flag]:用来通知是否需要前端发起享钱支付`
`1:需要`
`0值或其它值:不需要`
`仅在结算未结束(data.finished=0)的情况下有意义`
`如果pay接口返回(data.finished=0 and data.xdd_flag=1)，则说明需要在前端发起享钱支付的操作，此时xdd_order_id/xdd_amt分别表示销售小票号和要进行享钱支付的金额`
> `四.[data.xdd_order_id]:销售小票号，用于前端享钱支付`
`仅在(xdd_flag=1)时有意义`
> `五.[data.xdd_amt]:需要用为享钱支付的金额(2位小数)`
`仅在(xdd_flag=1)时有意义`
`假设销售小票总金额为19.53，，享钱支付的流程如下:`
> `一.扫描顾客付款码后，请求[order/input]接口进行输入内容的识别`
`这一步跟上一版本一样，没有变动，返回字段[data.operate=2]`
> `二.请求[order/pay]接口，发起结算`
`入口参数没变，跟上一版本一样，传入参数:`
`operate=2`
`code=付款码`
`amount=0`
`出口参数变了，多出来3个跟享钱支付相关的数据给到前端:`
`finished=0`
`xdd_flag=1`
`xdd_order_id=销售小票号`
`xdd_amg=需要用为享钱支付的金额(2位小数)`
`注:`
`这一步只要检测到返回值(finished=0 and xdd_flag=1)，就说明需要前端发起享钱支付`
> `三.前端拿到上面3个xdd开头的字段后，真正向享钱服务器发起支付请求`
`这一步操作是前端和享钱之间的交互，跟kpossrv无关，支付成功后会获得一个线上订单号`
> `四.再次请求[order/pay]接口，通知kpossrv本次享钱支付已完成了`
`入口参数如下:`
`operate=400(这个400是新增的值，专门用来处理这个场景)`
`code=享钱服务器返回的线上支付订单号`
`amount=0`
`出口参数如下:`
`finished=1(说明结算完成，小票已经保存了，可以用返回的其它字段构造小票打印信息了)`
> `注意`
`只有享钱支付是需要请求2次[order/pay]接口，因为中间多了一步交互，需要前端自己去发起享钱支付、然后再把结果返回给kpossrv。如果是现金支付的话就只需要请求一次[order/pay]接口，这个是没变的`
# 2021-03-21
### 原 order/operate 接口变更
==1.手动打折时返回价格由4位小数变更为2位小数==
`上一版本中，根据[原价格*折扣率]计算出来的折扣价保留了4位小数，这在实际业务中不合理，手动打折产生的价格最多只能保留2位小数，新版本中已修改`*斜体*
==1.手动改价时限制输入的价格最多只能2位小数==
`上一版本中，只限制了手动输入的价格不能超过4位小数，但在实际业务中，前端交互环节需要控制收银员输入的价格最多只能有2位小数，新版本中已做了限制，如果输入结果高于2位小数，则会返回一个错误提示`
``