Skip to content

Changing an order line's delivery mode ​

DeliveryChangeService handles changes between classic, etage, etage_with_assembly and retrait. Its source distinguishes eligibility, available prices, payment and applying the change; a requested change is not necessarily an applied change. The related carrier assignment recalculates the line's real shipping method after a change.

Evidence boundary

This page describes the cited code revision, not the active production configuration, payment outcome or every caller and webhook. Trace the actual request and verify persisted state before taking operational action.

Eligibility ​

The base check rejects a line when there is no sale, the order is not processing, the line is shipped, canceled, printed or Chronopost-printed, the sale's real method is TRUSK and the line has a tracking ID, or the line has a scan that is not deleted. It returns a specific reason for each rejection. See eligibility.

Options and supplement ​

The current mode must be recognized and the store must have at least two enabled delivery modes. The service calls pickup-to-delivery pricing for the line; it rejects missing pricing data, excludes the current mode and excludes non-pickup alternatives priced at zero or less. Pickup is priced at zero; floor delivery with assembly uses the floor-delivery price. For each offered mode, the supplement is the greater of zero and new price minus current price, rounded to two decimals. This method does not itself prove the underlying price calculation is correct for every product or store. Source.

Request and application ​

  1. requestChange() rechecks options, rejects a mode not offered for the store and records a pending history entry.
  2. If the supplement is positive, it creates a Stripe payment link and leaves the history pending. Creating a link does not prove payment or application.
  3. If the supplement is zero, it applies immediately. If the new price is lower than the current price, the method also creates an SAV request; that request alone is not proof of a refund.
  4. applyChange() reloads the line, rechecks eligibility when the history is not already applied, synchronizes operational state, sets the new mode, recalculates the carrier, records the new real shipping method and marks the history applied. See request and apply.

Pickup and delivery operational state ​

DeliveryModeOperationalStateSynchronizer acts on transitions between pickup and the three delivery modes. It prevalidates appointment and request assignments, then moves a line from a delivery request to a pickup appointment or from pickup appointments to a compatible delivery request. Transitions wholly within the delivery modes do not enter this cross-category synchronization branch. See synchronizer and transition filter.

Payment reconciliation ​

The chatbot-facing change endpoint validates the request, locates the sale and its line and calls requestChange(). A separate menzzo:delivery-change:sync-payments command takes a lock and reads pending changes. For each payment-link ID, it queries up to five Stripe Checkout sessions and selects the first whose payment_status is paid; then it marks the history paid and applies the change inside a database transaction. Missing link IDs, Stripe errors and exceptions are counted; unpaid changes remain pending. The command returns zero even when its error counter is nonzero, so an exit code alone is not evidence that every change succeeded. The installed schedule, complete duplicate-payment behavior and Stripe state remain unverified. Source.

After applyChange() flushes, it attempts a confirmation email unless the history tag is TEST; email exceptions are logged. That attempt does not establish delivery of the email. Source.

Still to trace ​

Additional callers, Stripe webhook and duplicate-event handling, pricing formulas, email/SAV outcomes and cross-system transaction boundaries require their own end-to-end review. Use the custom business-rule inventory to track those gaps; do not infer an actual payment, refund, carrier acceptance or delivery from a history status alone.

Internal developer documentation for Menzzo systems.