Weave Code
Myinvois Laravel Package
jiannius/myinvois
A Laravel package for integrating with Malaysia's MyInvois e-Invoicing platform, offering helpers to submit, validate, and manage electronic invoices through the LHDN MyInvois API from PHP applications.
Jiannius Myinvois SDK
Frequently asked questions about Myinvois
- How do I install and configure jiannius/myinvois in a Laravel application?
- Install it with Composer using the jiannius/myinvois package name, then publish or add the services.myinvois configuration block. The package registers a Laravel service provider and a Myinvois facade, so you can resolve the client from the container or use the facade. Configure credentials and environment settings before calling submission helpers, and keep APP_KEY stable if you enable queued jobs.
- What can I use the jiannius/myinvois package for?
- It wraps LHDN's MyInvois API for electronic invoice workflows: submitting documents, validating their status, checking submissions, and managing invoice lifecycle operations. In v1.5.0, production use should go through queueSubmission() so high-latency submit-and-poll work runs on a worker instead of a web request. Existing submitDocuments() calls remain available for synchronous use.
- Which Laravel and PHP versions does this MyInvois package support?
- The package is built as a normal Laravel package with a service provider, facade, config, artisan command, and domain events. Exact Laravel and PHP version constraints are defined in its composer.json, so check those constraints before adding it to an older application. v1.5.0 is intended as a patch-level upgrade for existing installs, with new queue behaviour opt-in.
- Does jiannius/myinvois support queued MyInvois invoice submission?
- Use queueSubmission() with the SubmitDocuments and PollSubmission jobs to move LHDN submission and status polling out of the request cycle. This requires a real queue connection, worker capacity, a scheduler entrypoint, and a shared lock store such as Redis, database, or memcached. Do not rely on array or file lock stores on multi-host deployments because the in-flight lock becomes ineffective.
- How does Myinvois::clientFor() handle multi-tenant LHDN credentials?
- Contracts\ResolvesMyinvoisClient and Myinvois::clientFor() let you resolve per-organisation credentials and enforce one client per submission, which is the key capability for SaaS and agency deployments. The resolver must work in the worker context, not only during an HTTP request. If per-org credentials depend on session or request context, clientFor() can fail on the queue worker.
- How does this package prevent duplicate MyInvois submissions?
- The package uses an in-flight lock and throws MyInvoisInFlightException when the latest submission is still SUBMITTED or VALID, and it can refuse a new parent submission in that state. This puts idempotency in the package and reduces duplicate submissions from application code. The lock still depends on a shared lock store and a lock duration longer than worst-case job runtime.
- What are the retry_after and lock_seconds requirements for queued MyInvois submissions?
- Set retry_after above 120 seconds, and set lock_seconds longer than the worst-case job runtime including poll backoff. These are hard configuration invariants because getting them wrong can cause duplicate job execution or an expired lock during a live submission. Document and enforce them in every environment, especially production workers.
- Why do I need sync_schedule when using queueSubmission()?
- queueSubmission() only registers a schedule when sync_schedule is configured, so queueing and sweeping should be deployed together. If you enable queued submission but never set sync_schedule, documents can remain in SUBMITTED with no reconciliation. Configure the schedule entrypoint and verify it runs under schedule:run or schedule:work.
- What MyInvois paths are not covered by the preprod sandbox testing?
- The preprod run did not cover INVALID reasons live, rejectDocument(), or payable_rounding, so treat rejection and rounding paths as unverified against the sandbox. Exercise them with a pilot cohort of real invoices before relying on them in production. The INVALID reasons currently have unit-test coverage only.
- How should I monitor failed MyInvois jobs and maintain this package in production?
- Decide who owns dead-letter handling for jobs that exhaust retries and what SLA applies when a submission never reaches LHDN. Monitor queued jobs, failed jobs, and submission status, and keep APP_KEY stable because job payloads are encrypted. For upgrades, v1.5.0 is opt-in for queueing and leaves submitDocuments() unchanged, but the queue workstream still needs infrastructure and observability.
Weaver
How can I help you explore Laravel packages today?