Product Reservations and Restock Interest

This page documents Menzzo's precommand form and the Logidav import of confirmed product reservations. In these handlers, “reservation” means a customer's request tied to a product and contact details. The reviewed journey does not create an order or invoke an inventory-reservation/stock-allocation API, so it is not evidence that a unit is held for the customer.

For the downstream order and shipment path, see Order to Delivery. For the checkout/payment state of a purchase, see Checkout and payment.

Source-backed journey

View diagram source

sequenceDiagram
  participant U as Customer
  participant V as Product page form
  participant R as Magento Request handler
  participant DB as Magento mz_pre_command
  participant SMS as OTP SMS provider
  participant C as Magento Verify handler
  participant J as Logidav import command
  participant A as Magento Logidav API
  participant L as Logidav ProductReservation

  U->>V: Submit product, email, phone, consent
  V->>R: POST /axprecommand/ajax/request
  R->>R: Validate contact, consent scope, product eligibility and arrival data
  R->>DB: Save pending_otp record and OTP metadata
  R->>SMS: Send OTP
  R-->>U: Return public token and SMS result
  U->>V: Enter OTP
  V->>C: POST /axprecommand/ajax/verify (token, otp)
  C->>DB: Verify token/code and set status=confirmed
  J->>A: GET rest/V1/logidav-api/precommand-reservations?status=confirmed&sent=0
  A-->>J: Paginated reservation rows
  J->>L: Upsert by Magento reservation_id

Diagram

The product page's Reservation view model supplies the request and verify URLs. A normal request stores a pending_otp row in Magento's mz_pre_command table. Successful OTP verification changes that row to confirmed; an already-confirmed token returns success. Test-mode handling can set a request to confirmed directly, so that branch is not evidence of the customer OTP journey.

The Logidav command is named menzzo:product-reservation:import. Its defaults are status=confirmed, sent=0, and page-size=500. It calls ProductApi::getProductReservations(), which requests rest/V1/logidav-api/precommand-reservations against the configured Magento API base URL, pages through the result, and upserts ProductReservation records by the Magento reservation_id. This command is the source-backed cross-system handoff; its installed schedule is not established here.

State and identifier boundaries

Boundary	Identifier and state	What the source establishes
Product-page request	Magento product_id, normalized email/phone, generated public_uid; status pending_otp.	Stores request price, availability estimate/date, store, consent, and OTP metadata after eligibility and arrival checks.
OTP verification	public_uid token plus submitted OTP.	Valid code sets confirmed and otp_verified_at; expired code sets expired; invalid code increments attempts.
Magento API export	Magento reservation entity_id returned as reservation_id, with product SKU and request fields.	Default Logidav filters request status=confirmed and is_sent_to_logidav=0; the API also supports pagination and date/status/sent filters.
Logidav import	ProductReservation.reservationId mapped from Magento reservation_id.	Existing record is updated; otherwise a new Logidav reservation record is inserted. The command wraps a non-dry-run import in a transaction.

The Magento API payload includes consent and sent-to-Logidav fields, but the inspected Logidav hydrator does not map either field into ProductReservation. The import command also does not write an acknowledgement back to Magento. The lifecycle of is_sent_to_logidav, any separate acknowledgement, and the command schedule remain unresolved in this source review.

Validation and failure boundaries

• The request handler requires a POST with Magento form-key validation, product ID, email, and phone. It rejects invalid email/phone, ineligible products, missing arrival data, and an already-active reservation for that product/contact.
• In the French consent scope, the request path requires the consent flag. Reusing an exact pending request may return its existing public token instead of creating a second request.
• The request record is saved before the handler attempts the SMS send. If the SMS provider throws, the response can still have success=true with sms_sent=false; that response alone does not prove OTP delivery.
• Verification rejects missing token/code and expired codes. Invalid codes increment the attempt count and return a cooldown value. An already-confirmed token is idempotently reported as confirmed.
• The import command rejects an invalid sent filter or a page size outside 1–500. It fails on an unsuccessful/malformed Magento response or missing required reservation fields; on a non-dry-run failure it rolls back the transaction and returns a failed command result.
• No reviewed handler in this journey turns the request into a Magento order item or adjusts salable stock. Customer interest, OTP confirmation, Logidav import, and inventory allocation are distinct states.

Evidence and open questions

Source-verified at axelites/menzzo@6bf5acf477d65bcfd54182549fc9487e110da007: product-page endpoint configuration, request validation and persistence, OTP verification state transitions, and the paginated Magento API response. Source-verified at axelites/logidav@88d9180215a5d489407498fe4905fdd38efd756d: menzzo:product-reservation:import filters, API call, required-field validation, transaction, and upsert identity.

Still unknown: whether and how a scheduled job invokes the importer; whether another Logidav path acknowledges imported rows back to Magento; how request state is exposed to operators/customers; and whether a separate inventory workflow ever allocates stock. This page does not infer those behaviors from the word “reservation.”

Source references: Menzzo product-page view model, request handler, OTP verification handler, reservation states, and Logidav API declaration and implementation; Logidav reservation import command and Magento API client.