Order import and line-item business rules

This page makes the rules around SaleService::addOrder() and addOrderItem() discoverable. It complements Sales Import, which covers the Magento cursor and status paths, and Order-line carrier assignment, which explains carrier decisions in detail.

Evidence boundary

These are code paths at the cited Logidav revision. Connector-specific mapping, runtime configuration, current production behavior and all possible event listeners require separate verification.

New and existing sales

addOrder() identifies an existing sale by source and source order ID. For an existing sale it updates status, billing email, order information and contact details; it adds missing line items, while updateOrderItem() in this base service updates only the two Alfy fields on an existing line. A new sale goes through createNewSale(), creates each line, calculates the sale-level shipping method and dispatches creation events. Existing sales dispatch update events instead.

For processing or complete, the new-sale branch applies a quantity log to each line unless FROM_SAV is defined; the existing-sale branch applies it only to newly created lines. These branch conditions do not prove that every connector override, replay or event listener is idempotent. See addOrder and updateOrderItem.

What a new line records

addOrderItem() requires a local product; a missing product throws an exception. It copies order-item quantities and financial values, source item IDs, options and selected delivery/Alfy/pickup fields. The line reference is the local sale ID, one-based item position and total item count, separated by /.

It initializes availability from the product, sets normal lines unprinted and unshipped, and sets common sent/canceled/viewed/IDF flags. When FROM_SAV is defined, it marks the line printed and shipped; product ID 8360 is also marked shipped. The code itself does not explain the business identity or purpose of that product ID.

If the requested delivery mode is etage with a truthy assembly flag, the stored line mode becomes etage_with_assembly. A nonempty pickup appointment date is parsed as d/m/Y and stored at 08:00 when parsing succeeds; the time field is separately copied from the input. The line also copies its input shipping_amount. Finally, the service calculates the line carrier and saves the line. Source.

Customer availability and consolidated stock

• The base availability label starts with the product's available value. An item option with value En stock or containing semaine replaces it; underscores are converted to spaces.
• For Menzzo, the availability date starts at the order creation date. A dispo option containing semaine adds seven days for Une semaine, or seven times the parsed number of weeks. For other sources, Fin de produit, empty or invalid availability falls back to the sale creation date; a numeric value is parsed as Ymd when possible.
• If the original product is not in stock but has consolidated quantity, the code looks up the same-SKU product list. If any related product is in stock, the new line is marked sent in stock and consolidated stock. The source shown does not establish that an external stock transfer occurred.

See line creation and consolidated-stock check, availability label and availability date. Some marketplace services override the label method; verify the actual service for the source before generalizing these rules.

Sale-level shipping and related side effects

The new-sale path separately calls setRealShippingMethod(). For the legacy ECO methods it chooses ECO_TDL for a specific department list, ECO_IDF for departments 75, 92, 93, 94 unless the Lengow marketplace is Cdiscount, otherwise ECO_PREVOTE. Express methods map to EXPRESS_CALBERSON; the remaining floor, pickup, Cdiscount and Lengow branches follow the ordered sale-level mapping. A line may subsequently have a different method.

The service also creates a SalePresto record when the payment method is PaylineCPT, card type is PRESTO MENZZO, and status is pending_payment; the reviewed method does not by itself establish a successful external payment. Source.

The new-sale path dispatches a shipping-amount event for non-Menzzo sources, while the shown base listener's condition requires source Menzzo, status complete or processing, and a nonzero sale shipping amount. Do not infer that this dispatch reaches the shown listener's calculation branch without tracing other event producers and listeners. Source · listener.

Further work

Trace marketplace-specific overrides, all event listeners and operational triggers separately. The custom rule inventory keeps those gaps visible rather than treating a broad menu or controller map as proof that all business rules are documented.