Getting Started

The 1.2 release adds updateQuantityProduct(), so the fastest path to value is to locate the class that exposes it and wire it into your existing product/inventory flow.

Find the implementation. Search the package source for the method name:
```
grep -rn "function updateQuantityProduct" vendor/<vendor>/<package>/src
```
Check whether it lives on a service class, a trait, or a facade-backed manager. That tells you whether to inject it, use the trait on your own model, or call it statically.
Confirm the contract. Read the method signature and any accompanying request/DTO. Note:
- Is the first argument a Product model, an ID, or a SKU?
- Does it accept an absolute quantity or a delta (+2, -1)?
- Does it return the updated model, a boolean, or void?

Publish config if available.

php artisan vendor:publish --provider="<Vendor>\<Package>\<PackageServiceProvider>"

First use case. The obvious day-one integration is an admin or POS adjustment: an operator edits the quantity of a product and you persist it through the package rather than touching the column directly. Start there before wiring it into checkout or stock reservation flows, because it gives you a low-risk read on validation behaviour and return values.
Smoke test in Tinker before writing app code.
```
$product = \App\Models\Product::first();
app(\<Vendor>\<Package>\<Service>::class)->updateQuantityProduct($product, 25);
```
Confirm the change lands where you expect and whether any events, logs, or cache invalidation fire.

Implementation Patterns

Inject the service, don't resolve it inline. If updateQuantityProduct() sits on a service class, bind it in a constructor or method signature so it's mockable in tests:

public function __construct(private ProductQuantityService $quantities) {}

public function adjust(Product $product, int $quantity): Product
{
    return $this->quantities->updateQuantityProduct($product, $quantity);
}

Wrap admin endpoints in a FormRequest. The package method is a domain operation, not a validator. Keep HTTP concerns in your app layer:

class UpdateQuantityRequest extends FormRequest
{
    public function rules(): array
    {
        return ['quantity' => ['required', 'integer', 'min:0']];
    }
}

Use it as the single write path. The main reason to adopt a package method instead of $product->update(['quantity' => $q]) is that it centralises side effects. Route every quantity mutation through it — admin edits, order fulfilment, returns, CSV imports — otherwise you'll get divergent state and inconsistent event firing.

Pair with a DB transaction for multi-step flows. If adjusting quantity is part of a larger operation (creating an order line, processing a refund), wrap the whole thing:

DB::transaction(function () use ($product, $qty) {
    $this->quantities->updateQuantityProduct($product, $qty);
    $this->orders->createLine($product, $qty);
});

Listen for events rather than post-processing manually. Many packages dispatch something like ProductQuantityUpdated. If it does, hook your cache busting, low-stock notifications, and audit logging into the event instead of the controller — that way every caller benefits:

Event::listen(ProductQuantityUpdated::class, function ($event) {
    Cache::forget("product:{$event->product->id}");
    LowStockMonitor::check($event->product);
});

Queue non-critical side effects. If the package dispatches events synchronously inside updateQuantityProduct(), an email or webhook in the listener will slow down every admin save. Implement ShouldQueue on listeners that do I/O.

Use it in seeders and imports too. Consistency matters more than saving a query. A ProductQuantitySeeder that goes through the method will produce the same event trail and validation outcomes as production code.

Test with a fake/spy. Assert the method is called with the right arguments in feature tests, and test the package's own behaviour once in an integration test against a real DB:

$this->mock(ProductQuantityService::class)
    ->shouldReceive('updateQuantityProduct')
    ->once()
    ->with($product, 25);

Gotchas and Tips

Check whether the argument is absolute or relative. The name updateQuantityProduct reads like "set to N", but packages sometimes implement delta semantics. Getting this wrong silently corrupts stock. Verify with a two-call test: 10, then 10 again — if the second call leaves it at 20, it's a delta.

Read the release note critically — it's thin. "Add the method updateQuantityProduct" tells you nothing about validation, return type, or whether it fires events. Diff the actual source against the previous tag:

git diff 1.1..1.2 -- src/

Look for changes to existing methods too; a new public API sometimes means existing quantity logic was refactored underneath, which can shift behaviour in code you already depend on.

Negative and zero quantities. Decide explicitly whether zero means "out of stock" or "delete the record". If the method rejects zero, you need a separate path for discontinuing a product. Test -1 too — whether it errors or silently writes a negative value is a real production risk.

Concurrency. A method that reads then writes is vulnerable to lost updates under concurrent requests (two admins, or admin + webhook). Check for pessimistic locking (lockForUpdate) or an atomic SQL increment. If there's neither, wrap the call in DB::transaction() with lockForUpdate() on the product row yourself.

Decimal quantities. If you sell by weight or volume, confirm the column type and whether the method casts to int. A common bug is (int) casting inside the setter that truncates 2.5 to 2.

Model identity vs. stale instances. If the method mutates and returns a fresh model, your original $product variable may be stale. Either use the return value or call $product->refresh(). Forgetting this leads to confusing bugs where $product->quantity shows the old value immediately after a successful update.

Mass-assignment and $fillable. If the implementation calls $product->update(['quantity' => $q]), your Product model's $fillable must permit quantity. A Guarded model will silently no-op — a classic half-hour debugging session.

Cache invalidation is on you unless documented. Don't assume the package clears your application-level caches. If you cache product pages or inventory counts, invalidate them in an event listener or after the call.

Extension points worth checking:

Is the service bound via an interface in the service provider? If so, you can decorate it to add logging or authorisation without forking.
Are there config keys controlling behaviour (e.g. allow_negative, dispatch_events)? Re-publish the config and diff it against yours after upgrading.
Does the package ship a model trait or HasQuantity concern? Using it keeps your model aligned with future package updates.

Log the before/after. Quantity changes are audit-sensitive. Even if the package doesn't log, add a lightweight listener recording old, new, user_id, and source. Cheap now, invaluable during a stock discrepancy investigation.

Pin the version and read the changelog on upgrade. A single-line release note is not a guarantee of a non-breaking change. Run your quantity-related tests against the new tag in CI before merging the bump.

Bizzcloud Laravel Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips