Carrier shipment operations

This page starts after Logidav has assigned a line-level realShippingMethod. It explains the operator action that creates a label or shipment and the local state that is written afterward. The assignment rules themselves are in Order-line carrier assignment.

The source snapshot is axelites/logidav@42116ebc0ba509bce9cc6651a55ecefd9a5fdb38. It is a code reference, not proof of the deployed revision, active credentials, a configured schedule, carrier acceptance or physical delivery.

The states to keep separate

View diagram source

flowchart LR
    A[Line created] --> B[realShippingMethod assigned]
    B --> C[Operator selects line]
    C --> D[Carrier command or manual flow]
    D --> E[Label and tracking stored locally]
    E --> F[Pre-shipped, where the carrier path uses it]
    E --> G[Magento or manual shipment]
    G --> H[Line shipped]
    H --> I[Order completion check]
    E -. separate status sync .-> J[ShipmentTracking status/history]

Diagram

These fields do not mean the same thing:

Field or record	Meaning established by the source
SaleProduct.realShippingMethod	The result of the assignment rules. It is a routing value, not a provider response.
SaleProduct.carrier	The carrier written by a label or shipment operation (GLS, BRT, RETRAIT, IDF, and similar values).
is_ticket_printed / ticket_printed_at	A local ticket/label operation reached its local success path.
expedition_ticket_files and track_links	Local PDF paths and tracking URLs saved for the line.
tracking_id / shipment_infos	Provider or internal tracking identifiers and the response data retained by the operation.
is_pre_shipped / is_pre_shipped_at	A pre-shipment state used by some carrier flows; it is not the same as is_shipped.
is_shipped / shipped_at	The line was marked shipped by a shipment path or manual validation.
SaleProductShipment and SaleProductShipmentTracking	Normalized per-line shipment and tracking records. The synchronizer stores one SHP tracking record per line and removes redundant older tracking rows for that shipment type.
shipment_status and status history	A normalized status is recorded only when it changes. A local status value does not prove delivery.
Sale is_sent_expedition, tracking and completion	Order-level state updated by some shipment paths. Completion is checked after the operation; it is not carrier proof-of-delivery.

ShipmentTrackingSynchronizer::sync() normalizes a non-empty status to uppercase, stores carrier, quantity, tracking IDs, links and files, and records status history only when the normalized value differs from the previous value. See the synchronizer.

Which operation handles each route

Assigned value or workflow	Entry point in this snapshot	What the source does	Local success boundary
CHRONOPOST	menzzo:chronopost:print-tickets	Calls sendToChronopost() for selected lines that are not already marked is_printed_chronopost; reads each returned chrono_reservation_number; downloads the Skybill PDF; saves it under web/pdf_chronopost/.	Sets is_printed_chronopost, chronopost_files, tracking links and a shipment-tracking row. A failed PDF or send records the Chronopost print error.
GLS	menzzo:gls:print-tickets	Reuses an existing local ticket when ticket files and tracking links are already present; otherwise builds the GLS request, calls sendExpeditionToGls(), saves the returned label and extracts each TrackID.	Sets carrier GLS, tracking IDs/links, shipment_infos, expedition_ticket_files, is_ticket_printed and ticket_printed_at; errors set ticket_print_error and sync an error tracking row.
BRT	menzzo:brt:print-tickets → BrtService::createSaleProductShipment()	Groups selected lines by one sale, rejects a mixed-sale selection, sends either pallet or parcel data to the BRT API and builds the returned labels plus companion PDFs.	Sets carrier BRT, internal sender reference, tracking links, files, is_ticket_printed and is_pre_shipped; then sets sale is_sent_expedition and checks completion. Exceptions are written to ticket_print_error.
RETRAIT	menzzo:sale:expedition	Requires a processing sale. It selects requested lines (or shippable RDV lines), calls createOrderShipmentMagento(), then updates selected lines.	On a successful Magento shipment, sets order is_sent_expedition, line is_shipped and carrier RETRAIT, stores order tracking and checks completion. An invoice attempt is made after shipment.
Floor validation (etage)	menzzo:sale:expedition:validate-and-ship-upstairs-sales	For selected unshipped lines, records a manual validation and calls setSaleProductsAsShipped(..., 'IDF', false).	The line is marked shipped with carrier IDF; sale tracking links and completion are recalculated. This command does not show a carrier-label API call.
Geodis/SDEN export path	menzzo:asir-group:sale:expedition:generate-geodis-for-sale-product-txt-and-send	Reads selected ticket-printed lines, builds a SDB_*_GEODIS_*.txt file from stored tracking and parcel information, and marks is_gls_text_file_generated.	File generation is visible in source. Remote pickup/acceptance is not established by this command and must be verified separately.
VIR, TRUSK, Tamdis, IDF and other specialist screens	Carrier-specific controllers/commands listed in Orders and Fulfilment	These paths have their own selection, label, validation or shipment operations. Assignment to a value alone does not prove that the operation ran.	Confirm the carrier-specific command response, local ticket/tracking fields and any downstream shipment record before calling the line shipped.

Chronopost

The command accepts comma-separated order IDs, sale-product IDs, a user ID and a progress token. It skips a selected line already marked is_printed_chronopost, calls the sale service, then uses the returned reservation numbers to request the configured Skybill URL. Successful PDFs are saved below web/pdf_chronopost/ and recorded on the line. The command then calls ShipmentTrackingSynchronizer with carrier CHRONOPOST, the reservation/tracking IDs, links and files. A download containing Shipping service was failed, a download exception or a failed send is recorded as a print error.

The source also calls getChronoPdf() recursively when the downloaded content is empty. That is an implementation detail to consider when diagnosing a stuck print; it is not an approval to replay a live request.

Sources: command setup and selection, PDF and error handling, and local tracking state.

GLS

The GLS command first checks whether a selected line already has ticket files and tracking links. If so, it determines the status from the existing tracking IDs and synchronizes the existing local data instead of creating another label. Otherwise it generates a bare internal code, calls GlsService::sendExpeditionToGls(), saves the returned PDF below web/pdf_gls/, extracts TrackID values and writes the line-level tracking and ticket fields. The generated PDFs are merged into one local file for the operator.

The command records provider response data after removing PrintData, sets the carrier to GLS, and writes a sale log. A missing saved file, a provider response with ok=false or an exception stores an error code/message and synchronizes an error tracking record. The command's final !END! block indicates its local process output; it does not establish provider delivery.

Sources: existing-ticket branch, API response and local writes, and error/merge output.

BRT parcel versus pallet

The back-office command parses per-sale values in the form saleId#number for palettes and parcels. It groups selected sale-product IDs by sale and passes those values to BrtService.

BrtService refuses a selection containing lines from more than one sale. It stores the entered palette/parcel counts on each selected line before calling the API. The request then uses this precedence:

Input	Request sent to BRT
paletteNumber > 0	numberOfParcels = max(paletteNumber, 1), plus palletType1 (default EPAL) and palletType1Number.
paletteNumber = 0 and colisNumber > 0	numberOfParcels = colisNumber.
Both are zero	numberOfParcels = max(computed product package count, 1).

The request also derives weight, volume, consignee data and a unique internal sender reference. Missing name, address, postcode, city or telephone aborts the request before the API call. A successful response must contain labels; otherwise the operation records an error. Each returned label contributes a tracking ID and URL, and the same local shipment/tracking data is applied to every selected line. See BRT request construction and parcel/pallet mapping.

Floor delivery and pickup

The assignment page explains why etage may route to TRUSK for an eligible IDF address or to VIR otherwise, and why a pickup line becomes RETRAIT. The shipment operation is separate:

• menzzo:sale:expedition:validate-and-ship-upstairs-sales is a manual floor-validation path. It skips already shipped lines, marks selected lines shipped with carrier IDF, regenerates sale tracking links and checks completion. The source does not show a carrier label request in this command.
• menzzo:sale:expedition is the pickup (RETRAIT) path. It requires a processing sale, creates a Magento shipment for selected lines, then marks those lines shipped with carrier RETRAIT. If no selected line is eligible, it writes an error and does not claim a shipment.

Do not use realShippingMethod=TRUSK, VIR or IDF as proof that a label exists. Check the corresponding operator action and line-level ticket/tracking fields.

Sources: floor validation and pickup shipment.

Configuration shape

The source configuration defines parameter shapes, while the active values live outside the repository. Keep credentials and active endpoints out of documentation.

Integration	Source configuration shape
Chronopost	menzzo_chronopost_skybill_url, account number and account password.
GLS	gls.user, password, urlShipment, contact IDs, parcel-details URL and label dimensions.
Geodis	Separate geodis.Send and geodis.Receive URL/login/API-key groups.
BRT	brt.api_url, user ID, password, customer code, departure depot and operating mode.
VIR	vir_config host/FTP/SFTP and agency/shipping-type fields.
Trusk	trusk_config and trusk_coeff values.

The BRT API receives the %brt% parameter array through mz.brt.api; the Chronopost and shipment services are registered as container services. This proves dependency wiring, not that credentials are present or that a provider endpoint is reachable. See parameter shapes, carrier blocks and Geodis/GLS/BRT blocks.

Diagnosis path

When an operator reports a missing label or an order that appears shipped too early, inspect the states in this order:

1. Confirm the line's realShippingMethod, requested delivery mode, supplier/store and the assignment revision. This identifies the intended path only.
2. Confirm the selected operator command or screen actually ran for the line. The commands accept selected IDs; an assignment alone does not enqueue a label.
3. Check ticket_print_error, ticket_print_error_message, is_ticket_printed, carrier, tracking IDs, links and ticket files together. A file path without a tracking ID is incomplete local evidence.
4. Check SaleProductShipment and its tracking row, including shipment_status and status history. The synchronizer records normalized status changes; it does not make a provider response successful.
5. For RETRAIT, IDF manual validation or other shipment paths, check is_shipped, shipped time, sale is_sent_expedition and the Magento/local shipment response separately.
6. Treat complete, is_pre_shipped, a local PDF or a tracking URL as an application checkpoint. Confirm carrier acceptance or delivery only through the owning provider/runtime evidence.

Production boundary

This page does not authorize replaying a carrier command, changing a ticket flag, or querying production data. Any recovery must use the owning operational runbook and an approved, read-only checkpoint before a separately authorized mutation.

Open evidence

• The source snapshot does not establish the deployed revision, active parameter values, installed cron schedule or provider acceptance.
• The Geodis/SDEN text-file command proves local file generation and a local generated flag; its external handoff and acknowledgement need a separate source/runtime packet.
• The matrix names the specialist routes documented by the current interface page, but each specialist carrier still needs its own end-to-end provider/readback evidence before the workflow is marked complete.
• A local shipment or tracking status is not physical delivery. The delivery boundary remains a separate tracking/provider question.