- What Laravel versions does eloquent-ifrs support, and will it work with Laravel 10?
- eloquent-ifrs officially drops Laravel 10 support, requiring PHP 8.2+ and Laravel 11+. If you’re on Laravel 10, you’ll need to upgrade or evaluate alternatives like custom-built double-entry systems or older package versions. Always check the [changelog](https://github.com/ekmungai/eloquent-ifrs/blob/master/CHANGELOG.md) for breaking changes.
- How do I handle existing financial data when migrating to eloquent-ifrs?
- Migrating existing financial data requires backfilling into eloquent-ifrs’ schema (e.g., accounts, journal entries). The package provides migrations, but you’ll need to manually map legacy transactions to the new structure. Test thoroughly—data inconsistencies can arise if opening balances or VAT entries aren’t aligned. Consider a phased rollout for critical systems.
- Can eloquent-ifrs work with multi-tenancy (e.g., Laravel’s globalScope or Stancl/Avenger) for SaaS accounting?
- Yes, eloquent-ifrs supports multi-entity accounting via `entity_id`, but you must design tenant isolation carefully. If using Laravel’s globalScope or Stancl/Avenger, ensure `entity_id` aligns with your tenant strategy. Conflicts may arise if tenant-specific data isn’t properly scoped in queries or migrations.
- Does eloquent-ifrs support non-EU VAT rules (e.g., GST, sales tax in the US)?
- While eloquent-ifrs includes specialized VAT logic for EU markets (e.g., reverse charges, intra-EU transactions), non-EU tax rules like GST or US sales tax require customization. You’ll need to extend the `TaxRule` model or override VAT-related methods. The package’s modular design allows for this, but test thoroughly for compliance.
- How does eloquent-ifrs handle performance for high-volume transactions (e.g., 10K+ entries/month)?
- Double-entry systems inherently create 2 database rows per transaction, which can bloat storage. Optimize performance by indexing `entity_id`, `date`, and `account_id` fields. Use batch processing for bulk operations (e.g., posting journals) and consider read replicas for reporting. The package’s deterministic tests don’t cover production-scale queries, so benchmark under load.
- What if my app’s existing `transactions` table conflicts with eloquent-ifrs’ schema?
- eloquent-ifrs requires custom tables (e.g., `accounts`, `journal_entries`, `transactions`). If your app already has a `transactions` table, you’ll need to either rename it or merge data. The package includes a `remove_vat_id_column` migration fix for SQLite/Laravel 11+ conflicts, but schema conflicts may still require manual resolution. Plan migrations carefully to avoid data loss.
- How do I test eloquent-ifrs in a Laravel app (e.g., with Pest or PHPUnit)?
- Use `orchestra/testbench` for Laravel-specific testing, as eloquent-ifrs relies on Eloquent. The package’s test suite uses PHPUnit 10+ with deterministic PRNG to avoid flaky tests. Focus on validating core workflows: journal posting, trial balance reconciliation, and VAT calculations. Mock external services (e.g., payment gateways) to isolate accounting logic.
- Are there alternatives to eloquent-ifrs for IFRS compliance in Laravel?
- For lighter needs, consider custom double-entry implementations (e.g., using Laravel’s Eloquent events) or packages like `spatie/ledger`. For full IFRS compliance, alternatives are limited—most alternatives lack VAT handling or multi-entity support. If Laravel 10 is a hard requirement, you may need to fork an older version or build a tailored solution.
- How do I customize eloquent-ifrs for non-IFRS accounting standards (e.g., GAAP, local regulations)?
- eloquent-ifrs is IFRS-centric but extensible via hooks like `AccountObserver`. Override methods in `AccountType`, `TaxRule`, or `JournalEntry` to adapt to GAAP or local rules. Document changes thoroughly, as hardcoded IFRS assumptions (e.g., depreciation rules) may need replacement. Test customizations against real-world scenarios.
- What’s the best way to audit or debug journal entries in eloquent-ifrs?
- Use the built-in audit trails: check `journal_entries` for posted transactions and their `lines` (debit/credit pairs). For debugging, enable Laravel’s query logging (`DB::enableQueryLog()`) and inspect the `post()` method’s validation logic. The package’s immutable ledgers prevent direct DB edits, so all changes must go through Eloquent methods.