Queue and cron operations

Choose one processing mode per document flow and monitor the worker that owns it. A pending row is a work item, not a successful document.

Queue mode

Invoice and credit memo messages use separate DB-backed topics and consumers:

php bin/magento queue:consumers:start mageb2b.einvoice.generate
php bin/magento queue:consumers:start mageb2b.einvoice.generate.creditmemo

Run both under the same process supervision used for other Magento consumers. The invoice consumer does not process credit memos. A successful consumer changes pending to generated, meaning that local document generation completed; it does not prove delivery. An exception stores error and the message can enter the queue backend's failure path.

Queue verification workflow

  1. Configure Message Queue for only the document flow under test.
  2. Start the matching supervised consumer and confirm Magento lists it.
  3. Generate a new invoice or credit memo and note its numeric entity ID.
  4. Confirm that the document first enters pending and that the matching topic receives work.
  5. Wait for the consumer, then reopen the detail page. Expect generated with local file metadata or error with a stored message.
  6. Download and validate the result. Verify delivery separately through the intended downstream system.

Do not infer credit-memo queue health from the invoice grid: the credit-memo grid has no E-Invoice status column. Inspect the credit-memo detail page or operational data for that entity.

Cron mode and schedule

All jobs run in Magento's default group:

Job Schedule
einvoice_generate_hourly minute 00 every hour
einvoice_creditmemo_generate_hourly minute 15 every hour
einvoice_generate_daily 02:00 daily
einvoice_creditmemo_generate_daily 03:00 daily
einvoice_retry_failed 04:30 daily

Daily jobs use the respective daily batch size. Hourly jobs process matching pending documents without that daily limit.

Diagnosis sequence

  1. Confirm the document's store view and exact generation mode.
  2. For queue mode, list consumers and inspect the queue backlog.
  3. For cron mode, inspect cron_schedule for the matching job and its latest status.
  4. Run php bin/magento cron:run --group=default once as a diagnostic, not as the production scheduler.
  5. Read the stored error before changing source data or retrying.
  6. Fix deterministic data or configuration errors, then retry once.

Capture queue evidence from the consumer/process view, the affected document detail page and the queue backend or cron_schedule. A screenshot of generated proves local completion only; retain downstream acknowledgement separately when delivery is in scope.

The shared retry job respects Retry Failed Generations and Max Retry Attempts. It can help with transient infrastructure failures, but it cannot correct missing VAT IDs, wrong endpoints or invalid references.