Skip to main content

menzzo:v2:sales:update

Overview​

Reconciles local Menzzo sales with Magento 2 status changes and applies important downstream side effects.

This command is the status synchronization half of the Sales Import Workflow and is executed by 2 different cron entries.

Schedules​

  1. 00 01 * * * - Line 6 in system-crontab.md
  2. */30 * * * * - Line 7 in system-crontab.md

Command Details​

  1. menzzo:v2:sales:update
  2. menzzo:v2:sales:update --workOn=currentDay

Intent & Purpose​

The command scans local Menzzo sales by date range and status bucket, fetches matching Magento orders in chunks, and updates local sales when Magento status has changed.

It also performs a delta fetch for Magento orders updated in the last 48 hours to catch late upstream changes.

Why Two Schedules Exist​

  • 00 01 * * *: broad daily reconciliation
  • */30 * * * * --workOn=currentDay: more frequent reconciliation for recent activity

The currentDay option narrows the search window to recent sales and helps catch active-day status changes faster.

Workflow​

Side Effects​

  • updates local sale status when Magento has changed
  • writes SaleLog entries for status synchronization
  • runs handleRdv() for sales already in processing
  • when a sale moves to processing, applies product quantity logging through productChangeLog(..., 'sale')
  • attempts RETRAIT email behavior when the shipping method is RETRAIT
  • reuses SaleService::addOrder() to persist the latest Magento payload after reconciliation

Important Behavioral Notes​

Status Buckets​

The command works in two passes:

  • one focused on processing
  • one focused on non-final statuses such as canceled, pending, pending_payment, holded, and payment-related statuses

This structure reflects the fact that processing has special operational side effects.

Delta Fetch​

The final delta fetch searches Magento orders updated in the last 48 hours. This is an important safety net for status changes that may arrive outside the main polling windows.

RETRAIT Email Caveat​

The code calls SaleService::sendRetraitEmail($sale) when a sale becomes processing and uses the RETRAIT shipping method. However, the current implementation of sendRetraitEmail() immediately returns, so the intent exists even though the email logic is effectively disabled in the current codebase.

Error Handling and Recovery​

  • uses LockableTrait to prevent overlapping runs
  • skips Magento orders with refund-related Hipay statuses listed in the command
  • processes sales in chunks of 100 IDs to avoid request-size issues
  • refreshes the Magento API token between requests
  • logs synchronization changes to SaleLog

Operational Risk​

This command is critical because it is where status changes become side effects:

  • stock can be decremented
  • RDV handling can run
  • customer-facing shipping behavior can diverge if reconciliation is late or broken

If this command silently fails, LogiDAV can hold stale order status even while Magento has already moved forward.

Risk Assessment​

Risk Level: critical

This command is part reconciliation job and part operational trigger. It is one of the main sources of stock and workflow consistency between Magento and LogiDAV.

Documentation Status​

  • Command class located
  • Business purpose documented
  • Side effects identified
  • Risk level confirmed
  • @doc.* annotations added to code