货到付款电商库存管理系统如何设计合理的销售退货表结构

你原有使用is_delivered布尔字段的设计缺陷在于只能覆盖「已交付/未交付」两种状态，无法适配退货场景下的多状态、多数量变更需求，针对你不想冗余存储字段的需求，提供两种可落地的优化方案：

方案一：改造现有sales表，无需新增表（适合当前业务规模） #

日均1000单的业务量级下，直接改造原表完全可以满足需求，不会有性能问题，实现成本最低：

• 删除原有的$table->boolean('is_delivered');字段，新增status tinyint类型字段，标记销售全流程状态，可预设值为：
  • 1 = 待出库派送
  • 2 = 已派送待签收
  • 3 = 已完成（用户签收，交易结束）
  • 4 = 全部退回
  • 5 = 部分退回
• 新增return_quantity int类型字段，默认值为0，存储对应销售单的累计退回商品数量，实际有效销售数量可直接通过quantity - return_quantity计算得到
• 额外提示：你当前的表结构里$table->interger('product_price');存在拼写错误，正确写法为integer

方案二：新增returns表关联sales表，无冗余字段（适合后续业务扩展） #

如果后续需要记录退货原因、退件物流、入库时间等专属退货信息，新增returns表完全不需要重复存储warehouse_id、product_id等字段，直接关联sales表主键即可，表结构参考：

$table->id();
$table->foreignId('sale_id')->constrained('sales'); // 关联原销售单主键，所有商品、仓库、用户、单价信息直接从关联的sales表读取，无冗余
$table->integer('return_quantity'); // 本次退回的商品数量，支持同一销售单多次退货
$table->tinyInteger('return_reason')->nullable(); // 可枚举存储退货原因，如用户拒签、质量问题、发错货等
$table->string('return_tracking_no')->nullable(); // 退件物流单号
$table->timestamp('warehouse_received_at')->nullable(); // 仓库确认签收退件的时间
$table->timestamps();

该方案的优势是灵活性高，支持同一销售单多次部分退货，且所有销售主数据只在sales表存储一份，没有数据冗余问题。

落地注意事项 #

无论选择哪种方案，涉及库存变更的操作都要加事务处理：比如退件入库时，需要同步更新销售单状态/退货数量，同时回加对应仓库的商品库存，避免出现数据不一致的问题。

内容的提问来源于stack exchange，提问作者Othmane