同城文件与大件的计费和下单报价怎样验收?除了计算金额,还要检查报价确认后能否被后来调价覆盖。文件与大件先分别校验承运范围,再把计价输入、分项费用和规则版本固定在确认记录中。本文以通用SQL设计解释报价过期、重复确认和旧价保留,用来准备采购验收,不代表具体产品现网实现。
微订官网产品与业务全景介绍,跑腿配送覆盖文件和物品配送,可设置骑手计费、配送区域、收益结算和提现规则。这是第一方产品范围;大件车型、尺寸、搬运与报价快照是否提供,仍需按所选版本演示。
模型只接受已完成承运判断的报价。物品超限、区域不支持或需现场核价时,不得生成可直接支付的确认价。文中的费用单位是分,距离是米,重量是克;费率都是自设示例,不是产品价格。
下面是PostgreSQL风格设计,尚未在数据库执行。报价行一旦生成不修改其输入和费用;确认表以quote_id和order_id分别唯一,防止同一报价形成多个确认订单。规则版本用于解释历史,不能只保存当前后台费率的外键。
CREATE TABLE price_quote (
quote_id text PRIMARY KEY,
input_digest text NOT NULL,
rule_version text NOT NULL,
kind text NOT NULL CHECK (kind IN ('document','bulk')),
meters integer NOT NULL CHECK (meters >= 0),
grams integer NOT NULL CHECK (grams > 0),
base_fen bigint NOT NULL CHECK (base_fen >= 0),
distance_fen bigint NOT NULL CHECK (distance_fen >= 0),
weight_fen bigint NOT NULL CHECK (weight_fen >= 0),
time_fen bigint NOT NULL CHECK (time_fen >= 0),
total_fen bigint NOT NULL CHECK (total_fen >= 0),
carry_approved boolean NOT NULL CHECK (carry_approved),
expires_at timestamptz NOT NULL,
CHECK (total_fen = base_fen + distance_fen + weight_fen + time_fen)
);
CREATE TABLE quote_confirmation (
quote_id text PRIMARY KEY REFERENCES price_quote(quote_id),
order_id text NOT NULL UNIQUE,
request_key text NOT NULL UNIQUE,
confirmed_at timestamptz NOT NULL DEFAULT clock_timestamp()
);input_digest由服务端按规范化起终点、物品、重量、尺寸、服务时间和区域生成。不能信任客户端传来的总价或自行声明的摘要。承运审核由鉴权后的业务逻辑写入,不允许用户自行把carry_approved设为真。CHECK保证结构,不替代权限。
应用开始事务,先锁报价行;然后查询已有确认。已有确认且order_id、request_key都与本次相同,则返回原结果。存在不同确认则返回冲突,不覆盖旧订单。只有尚未确认时才核过期和当前输入摘要。
BEGIN;
SELECT * FROM price_quote WHERE quote_id = :quote_id FOR UPDATE;
SELECT * FROM quote_confirmation WHERE quote_id = :quote_id;
-- 应用按上文先处理已确认重试,再核对当前输入与有效期。
INSERT INTO quote_confirmation(quote_id,order_id,request_key)
SELECT quote_id,:order_id,:request_key FROM price_quote
WHERE quote_id=:quote_id AND input_digest=:current_digest
AND expires_at>clock_timestamp() AND carry_approved
ON CONFLICT DO NOTHING
RETURNING quote_id,order_id,confirmed_at;
COMMIT;INSERT返回零行时,应用不能一律称成功;需要区分未找到、过期、输入变化或唯一键冲突。事务内获得确认后才能创建受约束的订单后续动作。支付调用应采用独立幂等键与状态,本文没有实现支付,也不宣称一次数据库提交解决外部支付的一致性。
设Q1为已审文件报价,摘要A、版本V1、基础800分、距离200分、重量100分、时段300分、合计1400分,有效期10分钟。首次用A和订单O1确认,应得到Q1/O1;同一请求再次确认,返回相同记录,不生成O2。
把终点修改后摘要变为B,即使客户端仍显示1400分,Q1也不能确认,应重新生成Q2并展示新费用。后台发布V2后,Q1仍保留V1及原分项;未过期报价是否继续有效由事先约定的业务策略决定。本设计采用有效期内继续有效,后台改价不静默改写Q1。
若大件缺少车型或承运审核,业务层拒绝建可确认报价;不能为了让流程继续而把carry_approved临时置真。过期的未确认Q1应要求重报,已确认Q1的相同请求重试则读取原确认结果。要区分“确认前过期”和“确认后查询”,避免成功订单在重试时被误判失败。
让交付方依次演示正常文件报价、改址后旧价、过期确认、重复请求、调价后历史查询和大件超限。每笔保留输入、版本、分项与用户确认。SQL只是设计说明,不能替代用户端、订单与支付联通验证;车型、搬运、退款以及费用争议的具体实现仍在交付清单逐项确认。
作者:微订(上海逊柯计算机科技有限公司)。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。