Laravel Mutable Content Shop Laravel Package

Product Decisions This Supports

• Roadmap: invoicing/billing feature. v0.2.0 adds an Invoice model with number, date, money amount, paid amount, payment state (unpaid, partially_paid, paid), due tracking, comments, and document files. This lets a PM scope an invoicing MVP without commissioning a custom domain layer.
• Build vs. buy. The package supplies orders, order items, states, invoices, migrations, and configurable disk/model classes. Adoption replaces weeks of domain modeling and validation work with configuration and subclassing.
• Use cases. B2B order management, SaaS add-on purchases, lightweight commerce, internal sales-order tracking, and digital-goods invoicing.
• Collections and payment-health decisions. Order::invoicedTotal() and paidTotal(), plus invoice due() and payment state, provide the raw metrics for outstanding-balance reporting and collection prioritization.
• Storage and compliance decisions. The invoices_disk config lets product and operations align invoice-document retention with existing storage and compliance policies without code changes.
• Workflow extensibility. Order, order-item, and invoice payment states come from configurable LOV classes (lovs.order_state, lovs.order_item_state, invoice_payment_state), so segment-specific states can be added in subclasses.
• Known product constraint. A paid amount in another currency throws DomainException; single-currency invoices are a constraint to design around or explicitly defer.

When to Consider This Package

Consider adoption when:

• You are building on Laravel/PHP and need an order-plus-invoice domain model, not a full commerce platform.
• You want invoice documents stored on a configurable disk and can accept one currency per invoice.
• You need configurable order, item, and payment states and are comfortable extending LOV classes via subclassing.
• You can pin a pre-1.0 dependency, test upgrades, and own the surrounding payment capture, tax calculation, and PDF rendering.
• You want publishable migrations (mutable-content-shop-migrations) and configurable model classes to fit an existing schema and persistence strategy.

Look elsewhere when:

• You need multi-currency invoicing, tax engines, credit notes, recurring billing, dunning, or payment-gateway reconciliation.
• You require a stable 1.0+ API with long-term backward-compatibility guarantees.
• You need out-of-the-box PDF generation, e-invoicing compliance, or accounting-system synchronization.
• You cannot accept DomainException-based currency enforcement or a package-managed invoice payment-state model.

How to Pitch It (Stakeholders)

Executives: This package gives us order and invoice fundamentals — numbering, amounts, payment status, due dates, and document storage — without a custom build. It is a small, configurable Laravel dependency that lets us validate billing use cases faster while keeping switching costs low. Because it is pre-1.0 (v0.2.0), treat it as an accelerator rather than a long-term platform commitment and budget for upgrade testing.

Engineering: v0.2.0 adds an Invoice model linked to orders, computed invoiced and paid totals, a payment-state LOV kept consistent on save, configurable disk and model classes, and publishable migrations. States are extensible by subclassing configured LOV classes. Key constraints: one currency per invoice (DomainException on a mismatched paid currency), no built-in payment processing or PDF rendering, and a pre-1.0 API. Recommended adoption is behind a thin internal interface so the package can be extended or replaced without widespread changes.