Appearance
Stock and Catalog
Business outcome
For a new product, read Product creation to storefront. It follows the Logidav Publish action through Meduse, Magento's FTP importer and the return acknowledgement. This page covers the separate operational stock and price path.
Logidav imports product data from Magento and processes selected availability and price updates back through a Magento API path. Logidav also records stock mutations from operational events. The reviewed code does not establish a single end-to-end catalog feed to every storefront, partner, or marketplace.
Arrival-reservation quantities and restock notifications are separate product workflows. Follow Arrival reservations and restock notifications for their filters, fallback quantity, reservation import and customer-channel rules.
For the separate Meduse catalog path, start at Meduse interfaces and connector workflows. The Logidav Meduse contract maps the other side of those file handoffs. Its FTP readers/writers and Laravel jobs are different from the Logidav-to-Magento queue below.
Source-backed sequence
View diagram source
sequenceDiagram
participant M as Magento
participant P as Logidav ProductCommand
participant D as Logidav product data
participant Q as Logidav update queue
participant A as Availability/price processor
participant API as Magento Logidav import API
participant L as Product quantity log
P->>M: Product API import query
M-->>P: Product data
P->>D: Persist imported product data and progress marker
Note over D,L: Operational stock changes use a separate ProductQtyLogService path
D->>L: Apply supported stock mutation and write quantity log
D->>Q: ProductService queues availability / PriceService queues price
A->>Q: Select queue rows in batches of 500
A->>API: POST rest/V1/logidav-api/import-logidav-queue
API-->>A: Batch result, with partial or failed status possible
Note over API: Marketplace/storefront propagation beyond this Magento API is not established
The stock side also has two explicit reconciliation commands: menzzo:product:inventory:sync-stock sums unsynchronised inventory rows into product quantity, while menzzo:products:sync-store-visibility derives non-France EU visibility from availability. Both queue or persist local state before any downstream readback.
Numbered handoffs
- Magento product import.
ProductCommanddefinesmenzzo:v2:products, separates fast and full modes, uses a lock, and has a persisted progress marker for a Magento API import. The default page size is 300; the fast path can filter in-stock rows and skips rows without a Logidav ID or French store data. The page does not assert the command's installed frequency. - Operational quantity changes.
ProductQtyLogService::productChangeLog()skips canceled sale products. Itssalebranch decrements product and inventory quantities and writes quantity logs. The method's supported action branches areupdate,cancel/cancelProduct,qty, andsale/uncancel. - Availability and price producers.
ProductServicequeues availability updates;PriceService::updatePriceProductInfo()queues price changes. - Queue consumers. The reviewed availability and price processors select the API path (
useApiInsteadOfRabbitMq = true), process batches of 500 rows, and callProductApi::importLogidavQueueBatch(). - Magento import endpoint. That API method posts to Magento
rest/V1/logidav-api/import-logidav-queue. Its result can report a partial or failed batch status. - External channels. The reviewed producer/consumer files do not prove that this generic queue then updates Amazon, Cdiscount, ManoMano, or other marketplaces. Those paths need their own source evidence.
- Arrival reservations. The reservation command targets Menzzo, non-dropship products with availability from five weeks onward, computes a supplier-remainder or fallback quantity, and queues the French store attribute
qty_arrival_reservation. See the linked detail page for the exclusion and composed-product rules. - Inventory and visibility reconciliation. Inventory rows are grouped and marked synchronised after
updateProductQty(). Store visibility queuesvisibility=4for allowed availability buckets andvisibility=1otherwise, with Austria using a narrower allowance. Missing product-store assignments are reported instead of queued.
Data ownership and contracts
| Data | Documented owner/path | Evidence limit |
|---|---|---|
| Product catalog import | Magento API → Logidav menzzo:v2:products command → Logidav product data. | Command help and implementation establish an API import and progress marker; field ownership and deployed schedule need further evidence. |
| Logidav stock quantities | ProductQtyLogService applies selected action branches and writes quantity-log entries. | The inspected log() creates an entry on each invocation; no existing-entry lookup/deduplication guard is present in these methods. |
| Availability updates | ProductService producer → Logidav queue → batch processor → Magento import API. | Current processor selects API transport and uses 500-row batches. API results can be partial/failed. |
| Price updates | PriceService producer → Logidav queue → batch processor → Magento import API. | Same API endpoint path is source-backed; external marketplace propagation is not. |
| Marketplace and storefront feeds | Independent partner/marketplace integrations. | The generic queue path does not prove downstream destinations, their schedules, or their acceptance rules. |
Failures, retries, and duplicates
- Quantity-log duplicates: the reviewed quantity-log
log()method creates a row each time it is invoked; these methods do not guard against an existing matching entry. Do not document a duplicate-entry guard or assume repeated invocation is safe. - Physical returns: the reviewed action branches and callers do not establish a
returnaction or a physical-return stock increment. A return flow needs a separate source-backed producer/path before it can be documented as behavior. - Queue batches: the Magento API result may be partial or failed. The reviewed paths identify the batch size and response categories but do not establish a complete retry, dead-letter, or deduplication policy.
- Scheduler: command definitions and help text do not prove the live cron frequency or that a command is enabled in a particular environment.
- Marketplace propagation: no guarantee is made that Magento acceptance means an external channel has accepted or published the data.
Diagnosis
- Identify the exact product/SKU, the data field in question, and which system's value is believed to be authoritative.
- Separate the inbound product-import marker from a stock mutation and from an outbound availability/price queue row; they are different paths.
- For stock quantities, inspect the action and matching quantity-log history in the documented owner environment. Repeated calls may write repeated log entries.
- For an outbound update, record the queue item/batch result and the Magento API response category. Do not infer that a batch row reached a marketplace.
- If the issue is a physical return or an external marketplace, stop at the missing path and ask the owning project for its source and operations guide.
Existing Logidav stock updates, queue debugging, marketplace sync troubleshooting, and product reference add project context; use their source boundaries and schedules cautiously.
Evidence and open questions
Source-verified at axelites/logidav@42116ebc0ba509bce9cc6651a55ecefd9a5fdb38: the product import command's API/progress-marker path; stock mutation branches and log creation behavior; availability/price queue producers; current API-based batch processor selection; 500-row batching; Magento import API route; partial/failed batch result handling.
Still unknown or out of scope: actual scheduler configuration; all catalog fields' system of record; physical-return producer; external marketplace/storefront fanout; marketplace-specific payloads and schedules; queue retry/deduplication behavior; deployed configuration and acceptance.
Source references: ProductCommand, ProductQtyLogService mutation, sale action, quantity-log creation, availability producer, price producer, availability processor, price processor, and Magento batch API.