Laravel 库存管理中删除已结账单/销售单时自动回滚库存更新

本文讲解如何在 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

通过以上设计，你不仅修复了原始项目中的数据一致性缺陷，更建立了一套可扩展的“事务补偿”思维模式——未来新增类似场景（如退货单、调拨单撤销）均可沿用此结构，兼顾健壮性与可维护性。