Order to Delivery

Business outcome

Logidav imports Magento orders into its operational sales data. A separate carrier-file path can create a Magento shipment and mark matching Logidav sale lines shipped. Those steps do not prove that a carrier physically delivered the parcel: tracking-status synchronization is a separate path. For the upstream purchase boundary, see Checkout and payment; for a product restock-interest request that does not allocate inventory, see Product reservations and restock interest.

Source-backed sequence

View diagram source

sequenceDiagram
  participant M as Magento
  participant C as Logidav SaleCommand
  participant S as Logidav SaleService
  participant DB as Logidav sales and cursor
  participant F as Shipment import record and CSV
  participant E as Logidav expedition importer
  participant X as Magento shipment API
  participant T as Tracking status path

  C->>M: GET rest/V1/orders: entity_id greater than LAST_MAGENTO_ID
  M-->>C: matching order payloads
  loop each returned order
    C->>S: addOrder(sale, true)
    alt addOrder succeeds
      S->>DB: upsert order and applicable new-line stock mutation
      C->>DB: store the successful order cursor
    else exception
      C->>C: log/alert and continue to next order
      Note over C,DB: A later higher ID can advance past this failed ID
    end
  end
  F->>E: pending/processing record with zero errors
  E->>E: dispatch by filename to supported CSV importer
  E->>X: createOrderShipment with order-item quantities and tracking data
  X-->>E: shipment API result
  E->>DB: mark matched local lines shipped and dispatch event
  E->>DB: set order complete only when every line is shipped or canceled
  Note over E,T: Tracking status synchronization is a separate record path

Diagram

The diagram shows reviewed code paths, not an installed schedule or a universal carrier integration. The order importer is the menzzo:v2:sales command. Its SaleApi::getByCriteria() sends GET rest/V1/orders with search criteria; the command reads the last Magento entity ID and requests the next 300 records. Legacy Logidav crontab notes show historical schedule examples for sales import and order updates; they do not prove the current installed cadence.

Chronopost has a separate shipment path from the generic CSV importer:

View diagram source

sequenceDiagram
  participant O as Logidav SaleService
  participant M as Magento Sale API
  participant T as Magento shipment-track rows
  participant L as Logidav SaleProduct

  O->>M: createOrderShipment(order item ID + quantity, carrier + track number)
  M-->>O: shipment ID
  loop each Chronopost track
    O->>M: POST /V1/logidav-api/set-chronopost-reservation-number-for-shipment/{shipmentId}
    M->>T: set reservation number by parent_id + track_number
    T-->>M: affected row count
    M-->>O: 1 if matched, otherwise 0
  end
  O->>L: save shipped / pre-shipped state after shipment response
  Note over O,M: Logidav does not branch on the writeback response

Diagram

This writeback stores Chronopost's reservation number on the Magento tracking row identified by Magento shipment ID and tracking number. A zero-row result or a false API result is not checked by this caller before it marks the Logidav line shipped.

Numbered handoffs

1. Order selection. menzzo:v2:sales (SaleCommand::execute) takes a command lock, reads LAST_MAGENTO_ID, and calls SaleApi::getByCriteria() for orders whose entity_id is greater than that cursor. The client sends GET rest/V1/orders with pageSize=300, currentPage=1, and an entity_id gt filter. The configured host/base URL and installed schedule are not established by these source files.
2. Order persistence. The command calls SaleService::addOrder($sale, true). The service upserts by Magento order ID/source, updates an existing order, and dispatches create/update events. New lines on existing orders run the sale stock mutation only for processing or complete; a new active order applies it to all lines.
3. Cursor and status recovery. The cursor is stored after addOrder succeeds. UpdateSaleCommand separately fetches state for local orders, applies status changes, and calls the sale stock path on a transition to processing. Its delta path looks back two days for processing orders. The source comment describes a late-webhook recovery intent; it does not establish a general webhook or replay guarantee.
4. Shipment file selection. ExpeditionImportCommand::runExpedition() selects import rows marked pending or processing with zero errors, marks a selected row processing, and dispatches by filename to Chronopost, GLS, or the generic CSV command. The inspected method does not establish every carrier's path.
5. Magento shipment. The generic CSV command matches SKU/quantity rows against unshipped local sale lines and calls SaleService::createShipmentCsv(). That method sends order-item quantities and carrier/tracking data through the Magento sale API's createOrderShipment() call.
6. Local shipment state. After that call, the CSV command marks matching local lines shipped, records carrier/import-file/shipped-at values, regenerates track links, dispatches SaleProductsShippedEvent, and checks for completion. Menzzo orders are switched to Magento complete only when every line is shipped or canceled.
7. Tracking status. ShipmentTrackingSynchronizer::sync() stores shipment/tracking information and adds status history when normalized status changes. It is a separate path; the shipment-import sequence does not prove physical delivery.

Operator SKU and quantity edits

The sale controller prefix combines with its method routes to expose two POST handlers on the Logidav sale screen: /sale/{id}/update-sale-skus (SaleController::updateSaleSkusAction) and /sale/{id}/update-sale-skus-qty (updateSaleSkusQtyAction). A SKU switch updates the Logidav sale-product record and dispatches SaleProductChangedEvent; a quantity edit saves the new local quantity and dispatches SaleProductQtyChangedEvent. For Menzzo sales, SaleProductService handles those events by posting attribute=product or attribute=qty to Magento's /V1/logidav-api/update-sale-product route, keyed by Magento item_id. Magento updates the order item's product fields or qty_ordered respectively.

The SKU handler refuses non-admin changes after a line has been exported to CSV or shipped. Both event listeners throw when Magento returns an unsuccessful API status. Because Logidav saves its edit before the listener's remote call, an unsuccessful response can leave the local and Magento item records out of step; compare both records before retrying.

Data ownership and transport

Segment	Owner and transport	What the source establishes
Order selection	menzzo:v2:sales → SaleApi::getByCriteria() → Magento order API.	GET rest/V1/orders with entity_id > LAST_MAGENTO_ID; configured host/base URL and current schedule are unknown here.
Operational sale	Logidav SaleService and local sale/line records.	Upsert by Magento order ID/source and status-dependent line behavior.
Shipment handoff	Carrier shipment CSV → Logidav importer → Magento shipment API.	CSV SKU/quantity matching and a createOrderShipment() call with tracking data. This is shipment creation, not carrier-label generation.
Operator item edit	Logidav sale screen → SaleProductService event listener → Magento update-sale-product.	SKU and quantity edits use Magento order-item ID; Magento updates product fields or ordered quantity.
Local completion	Logidav shipment-line state, then Magento order status for Menzzo.	Local complete condition: every line shipped or canceled. This is not proof of customer receipt.
Chronopost reservation ID	Logidav setSaleProductAsShippedChronopost() → Magento shipment-track API.	Shipment ID plus tracking number identifies the Magento track row to update; caller does not inspect the API result.
Delivery tracking	Separate tracking synchronizer.	Normalized tracking status and changed-status history are recorded; the upstream tracking provider/schedule is not established here.

Failures, retries, and duplicates

• Order cursor gap: a failure during addOrder is logged/alerted and the loop continues. If a later higher-ID order succeeds, the cursor can advance past the failed order. The command's inspected source does not show an automatic backfill for that skipped ID.
• Status update: the two-day delta path is limited to matching processing orders. It is not a general recovery guarantee for every missing event or status.
• Shipment import error: a thrown importer error sets the row to error. The selector reviewed here accepts pending/processing rows with zero errors, so this command does not establish automatic retry of an error row.
• Remote/local split: Magento shipment creation precedes the local shipped-line updates. The reviewed code does not establish a cross-system transaction or a duplicate-submission guard. Verify state at both owners before any replay.
• Delivery: shipped line/order completion must not be interpreted as carrier delivery. Consult the tracking record path and project-owned tracking evidence separately.
• Item edit remote failure: operator changes are saved in Logidav before the Menzzo event listener updates Magento. A thrown or unsuccessful response can leave different values across the two systems.
• Chronopost writeback: Magento returns 0 if no shipment-track row matches both shipment ID and track number. The Logidav caller does not branch on that result before saving the line's shipped flags, so verify the Magento tracking row separately when the reservation ID is absent.

Diagnosis

1. Identify the order ID and the last state known at each boundary: Magento order, Logidav sale, shipment import record, Magento shipment, local shipped lines, and tracking record.
2. For an order absent from Logidav, check the cursor/import path and preserve the failed ID and the next successful ID; the cursor gap above makes that pair important.
3. For an order with no shipment, confirm whether a shipment CSV import record was selected and which filename-specific importer ran. Do not assume a label was generated by this path.
4. If Magento has a shipment but Logidav line state differs, stop before replaying the file and ask the owning operator to reconcile both states.
5. For “delivered” questions, start from the separate tracking-status evidence. Do not use shipped_at or Magento order complete as proof of physical delivery.

The existing Logidav sales-import workflow, shipment-generation workflow, and shipment runbooks provide the project context. Read their evidence notes alongside these source refs; installed schedules and production outcomes are not checked here.

Evidence and open questions

Source-verified at axelites/logidav@e0b7a25c1912039c1520eb04c1b4c242d74b6d1e: addOrder persistence; UpdateSaleCommand status/delta code; shipment CSV record selection and dispatch; CSV-to-Magento shipment creation; subsequent local line updates and completion; separate normalized tracking synchronization. At axelites/logidav@88d9180215a5d489407498fe4905fdd38efd756d, the menzzo:v2:sales command and GET rest/V1/orders selection, operator SKU/quantity edit handoffs, Chronopost reservation-number writeback, and Logidav shipment-report request builder were reviewed. The corresponding Menzzo API route declarations and implementations were reviewed at axelites/menzzo@6bf5acf477d65bcfd54182549fc9487e110da007.

Still unknown or out of scope: the configured cadence and deployment; the configured Magento API host/base URL; all carrier-specific producer formats; automatic recovery for skipped cursor IDs and error import rows; duplicate protection and retry safety around shipment creation; tracking provider ingestion; customer-visible tracking behavior; and actual delivery/owner acceptance. Magento's webapi.xml declares GET /V1/logidav-api/get-shipment-reports/:from/:to mapped to ApiManagementInterface::getShipmentReports, but no matching interface declaration or ApiManagement implementation exists at the audited Menzzo pin. Logidav's SaleApi::getShipmentReports() constructs a request to that path, but no caller was found in the inspected Logidav source. Treat this report route as an unresolved contract, not an available workflow.

Source references: SaleCommand, SaleService::addOrder, UpdateSaleCommand, ExpeditionImportCommand, SaleExpeditionCsvCommand, shipment creation, completion check, and tracking synchronizer.

Additional source references reviewed at axelites/logidav@88d9180215a5d489407498fe4905fdd38efd756d: menzzo:v2:sales command and Magento order query and SaleApi; operator edit handlers and event listeners; Chronopost shipment creation/writeback; and report-request client. At axelites/menzzo@6bf5acf477d65bcfd54182549fc9487e110da007, see Magento Logidav web API declarations, API interface, and API implementation.