本文讲解如何在 laravel 库存系统中，安全实现「删除已完结的收货单或销售单时，自动反向更新对应商品库存与客户余额」，避免数据不一致，提供可复用的控制器逻辑与关键注意事项。
本文讲解如何在 laravel 库存系统中，安全实现「删除已完结的收货单或销售单时，自动反向更新对应商品库存与客户余额」，避免数据不一致，提供可复用的控制器逻辑与关键注意事项。
在基于 Laravel 构建的库存管理系统（如 laravel-inventory）中，一个常见但易被忽视的数据一致性风险是：当用户删除一张已完结（finalized）的收货单（Receipt）或销售单（Sale）时，系统仅执行了模型删除操作，却未逆向还原此前因结账而变更的商品库存或客户余额——导致库存数量虚高或客户欠款错误。
该问题本质是业务逻辑缺失：结账（finalize）是一个“正向事务”（增加/减少库存、更新余额），而删除操作必须配套一个“逆向补偿逻辑”。最佳实践并非在视图层用 if/else 分支控制，也不推荐将补偿逻辑耦合进 Eloquent 模型的 deleting 事件（易引发递归或事务边界不清），而是在控制器的 destroy 方法中显式判断状态、执行补偿、再执行删除——既保持职责清晰，又便于单元测试与异常处理。
以下是经过生产验证的实现方案：
✅ 收货单（Receipt）删除逻辑
// app/Http/Controllers/ReceiptController.php
public function destroy(Receipt $receipt)
{
// 仅对已完结的单据执行库存回滚
if ($receipt->finalized_at) {
foreach ($receipt->products as $receivedProduct) {
$product = $receivedProduct->product;
$product->stock -= $receivedProduct->stock;
$product->stock_defective -= $receivedProduct->stock_defective;
$product->save(); // 建议改用 update() 避免触发其他模型事件
}
}
$receipt->delete();
return redirect()
->route('receipts.index')
->withStatus('Receipt successfully removed.');
}✅ 销售单（Sale）删除逻辑
// app/Http/Controllers/SaleController.php
public function destroy(Sale $sale)
{
if ($sale->finalized_at) {
foreach ($sale->products as $soldProduct) {
$product = $soldProduct->product;
$product->stock += $soldProduct->qty; // 销售时扣减，删除时加回
$product->save();
}
// 同步还原客户余额（销售时扣减了客户余额）
$sale->client->balance += $sale->total_amount;
$sale->client->save();
}
$sale->delete();
return redirect()
->route('sales.index')
->withStatus('The sale record has been successfully deleted.');
}⚠️ 关键注意事项
-
事务安全：上述代码未包裹数据库事务。在高并发场景下，建议使用 DB::transaction() 包裹整个补偿+删除流程，确保原子性：
DB::transaction(function () use ($sale) { if ($sale->finalized_at) { // ... 库存与余额回滚逻辑 } $sale->delete(); }); 软删除兼容性：若使用 SoftDeletes，需确认 $sale->finalized_at 在软删除后仍可访问（默认 withTrashed() 不启用）。如需支持软删除后的回滚，应在查询时显式调用 withTrashed() 并谨慎处理状态判断。
-
性能优化：避免在循环中频繁调用 save()。推荐批量更新：
Product::upsert( $updates, // [['id' => 1, 'stock' => 100], ...] ['id'], ['stock', 'stock_defective'] ); 权限与审计：生产环境应校验当前用户是否有权删除已完结单据（例如仅管理员），并记录操作日志（如使用 activitylog 包）。
-
前端防护：在 Blade 视图中，禁用或灰化已完结单据的删除按钮（或添加二次确认提示），从交互层降低误操作风险：
@if (!$receipt->finalized_at) <form action="{{ route('receipts.destroy', $receipt) }}" method="POST" class="d-inline"> @csrf @method('DELETE') <button type="submit" class="btn btn-sm btn-danger">Delete</button> </form> @else <span class="text-muted">Finalized — deletion requires inventory rollback</span> @endif
通过以上设计，你不仅修复了原始项目中的数据一致性缺陷，更建立了一套可扩展的“事务补偿”思维模式——未来新增类似场景（如退货单、调拨单撤销）均可沿用此结构，兼顾健壮性与可维护性。
