Partners and Lengow Product Feeds

This page explains why the Menzzo Partners exports and Magento Lengow files can contain different products and values. They read related catalog data, but they are separate generators with different selection contracts, storage, schedules and field sources. Equal product counts are therefore not guaranteed by the current code.

The technical behavior below was checked against the pinned source revisions. Whether every difference is an intended business rule still requires confirmation from the catalog owners. The English feed is excluded from the operational comparison because the team does not use it; Magento still includes store ID 13 in the generator's configured store loop.

Data flow and ownership

View diagram source

flowchart LR
  L[(Logidav mirror tables)] --> PG[menzzo-partners General generators]
  PG --> PC[general*.cache]
  PC --> PE[partners.menzzo.fr endpoints]

  M[(Magento catalog and stock)] --> LG[Axelites Lengow LaunchExport]
  LT[(lengow_flux_export_products)] --> LG
  LG --> LF[pub/media/lengow/store-code/lengow_feed.csv]

  PE --> C[Diagnostic comparison by product ID]
  LF --> C

Diagram

The Partners side reads mz_product and mz_product_info from its configured Logidav database and serves cached files. The Lengow side selects products directly from Magento for each store, reads Magento stock and scoped attributes, and writes the public files below pub/media/lengow/.

Endpoints in the active comparison

Market	Partners source	Localized row used by Partners	Lengow file
FR	https://partners.menzzo.fr/?feed=general	mz_product_info.store_id = 3	https://www.menzzo.fr/media/lengow/french/lengow_feed.csv
DE	https://partners.menzzo.fr/?feed=general_de	mz_product_info.store_id = 2	https://www.menzzo.fr/media/lengow/de/lengow_feed.csv
IT	https://partners.menzzo.fr/?feed=general_it	mz_product_info.store_id = 14	https://www.menzzo.fr/media/lengow/it/lengow_feed.csv

Always compare each Lengow market with its corresponding Partners endpoint. Comparing DE or IT with feed=general uses the French Partners selection and produces a misleading result.

The URLs above are production outputs, not health-check commands. Inspecting them requires the normal production-access approval for the exact request and target.

Generation lifecycle

Partners

index.php routes feed=general, feed=general_de and feed=general_it to the matching cache-delivery scripts. The General, GeneralDe and GeneralIt classes create a temporary semicolon-separated file and replace the corresponding cache only when the temporary file is larger than 44,945 bytes. The HTTP layer reads that cache, emits pipe-separated rows and converts the response to ISO-8859-1.

The reviewed repository establishes the cache builders and delivery path. It does not establish the deployed scheduler or the age of the cache currently served. A fresh HTTP response can therefore still contain data from an earlier cache generation.

Magento Lengow

The Magento cron job axelites_launch_lengow_export runs at 0 */4 * * * in the declared configuration. LaunchExport processes store IDs 3, 14, 2 and 13, builds a temporary UTF-8 file with pipe-separated quoted fields, then renames it to:

pub/media/lengow/<store-code>/lengow_feed.csv

The French store code is rewritten from fr to french. The rename prevents readers from seeing a partially written normal file. A per-product Throwable is printed and the loop continues, so one bad product can be omitted without failing the complete export. Runtime logs are required to prove that no row-level exception occurred.

The four-hour declaration proves the source schedule only. It does not prove that the deployed cron is enabled, that the job completed, or when the public file was last replaced.

Product eligibility rules

Partners selection

All three Partners generators require:

• mz_product.is_active = 1;
• visibility in 2, 4, 5 or 6;
• a non-null source_id;
• a non-empty product EAN;
• is_new = 0;
• the market-specific mz_product_info row shown in the endpoint table;
• a strictly positive localized price before the row is written.

Additional market differences are part of the current implementation:

Rule	FR General	DE GeneralDe	IT GeneralIt
Extra localized joins	Requires store 9 and store 8 rows	None	Requires store 9 and store 8 rows
Dropship	Empty or AsirGroup	Empty or AsirGroup	Empty only
Hard-coded SKU/EAN exclusions	Yes	Yes	No equivalent lists in the reviewed query
Positive shipping rate required	No	Yes	Yes
STOCK_DESCRIP	Raw mz_product.qty	Empty	Empty
Derived qty_stock column	Present	Absent	Present

A localized mz_product_info row does not prove that Magento assigned the product to the matching website/store. This is the largest structural difference from the Lengow selection.

Magento Lengow selection

For each configured store, LaunchExport::getProducts():

• sets the current Magento store and calls addStoreFilter();
• accepts only simple, configurable and bundle products;
• requires a non-empty EAN;
• requires visibility in 2, 4, 5 or 6;
• excludes label = bipolart;
• requires store-scoped status = 1 for the normal export;
• applies the hard-coded EAN exclusion list and a hard-coded SKU exclusion list in the row loop.

The dropship rule then rejects any non-empty drop_ship value, with two exact exceptions on the French store only:

• asr893ran5409
• asr893ran5415

For DE and IT, every product with a non-empty drop_ship value is skipped. For DE, the completed row is also rejected when configured customer-facing fields contain a known French residue pattern.

The normal Magento collection does not apply the Partners source_id or is_new = 0 requirements. It also does not remove a selected row merely because getProductPrice() returns an empty value for a nonpositive price. These reverse differences can produce a small number of products found only in Lengow.

Why product counts differ

Use set differences, not the net count, when diagnosing a market:

partners_only = Partners IDs - Lengow IDs
lengow_only   = Lengow IDs - Partners IDs
common        = Partners IDs intersect Lengow IDs

The durable causes are:

Direction	Code-level causes to check first
Partners only	Missing Magento website/store assignment; disabled store-scoped Magento status; unsupported Magento product type; label = bipolart; dropship rejection; German row validation; row-level exception during export.
Lengow only	Partners source_id missing; is_new != 0; missing required Partners localized joins; nonpositive Partners price or shipping rate; Magento removal row retained temporarily.

For DE and IT, a large Partners-only set is expected when localized Logidav rows exist for products that are not assigned to the corresponding Magento store. For FR, the broader Partners AsirGroup allowance is an additional recurring cause.

The hard-coded lists are not identical across all markets: FR and DE Partners apply SKU/EAN lists comparable to Magento's lists, while the reviewed IT Partners query does not. Inspect the pinned source before treating those lists as a shared contract.

Field semantics

Rows with the same product ID can still have different values because the generators read different stores and persistence layers.

Field	Partners source and rule	Magento Lengow source and rule	Diagnostic consequence
ID	mz_product_info.feed_id	ancien_id when present, otherwise Magento entity ID	A comparison must record which identifier contract is being used.
SKU	mz_product.sku	ancien_sku when present, otherwise current Magento SKU	The same ID can legitimately expose different SKU strings under current code. Business intent remains to be confirmed.
PRICE	Localized mz_product_info.price	Store-scoped Magento product price	Differences can reflect store scope or synchronization lag between Magento and the Logidav mirror.
PRICE_PROMO	Localized special_price when price, start and end are non-empty and the end date is not before today	Magento special price when price is positive, both dates parse, start is not after end, and today is inside the inclusive range	Partners can expose a future promotion before its start date; Lengow does not.
PROMO_FROM, PROMO_TO	Raw localized values when the Partners promotion check passes	Raw Magento scoped dates when the stricter Lengow check passes	The generator does not itself prove timezone or upstream synchronization equivalence. Compare full timestamps and source scopes.
AVAILABILITY	Computed from mz_product.availability	Computed from Magento disponibilite, unless a removal row forces -1	Both normal paths convert a future YYYYMMDD date to day difference minus one, return 0 for today/past, and default to 60 for other values. Different source values can still yield different results.
STOCK_DESCRIP	FR uses raw mz_product.qty; DE/IT leave it empty	Magento stock registry quantity for the product and current store, formatted to four decimals	This field is not sourced from the same stock read. A zero in Lengow and a positive Partners value requires stock-scope and synchronization diagnosis.
qty_stock	FR/IT cap stock at 15 and force zero unless available = En_Stock	No equivalent documented output rule	Do not compare qty_stock with Lengow STOCK_DESCRIP as if they were the same contract.
shipping_rate	Localized shipping_amount, with coefficient fallback; DE/IT skip nonpositive results	Store data shipping_amount, with coefficient fallback	Store data and fallback inputs must be compared separately.

The Partners promotion check does not verify that the start date has arrived or that the start date precedes the end date. Lengow performs both checks. This is a direct code reason for a populated Partners promotion becoming blank in Lengow.

Removal lifecycle in Lengow

lengow_flux_export_products tracks products written during the normal Magento export. Each successful normal row refreshes its updated_at value. After the normal selection:

1. tracking records older than three days are deleted;
2. remaining records not refreshed today are selected;
3. those products are appended through the disabled-status path with AVAILABILITY = -1;
4. after the three-day retention window, the tracking record and removal row disappear.

Consequently, a product can be present only in Lengow even though it no longer passes the normal selection. Treat AVAILABILITY = -1 as a removal notification, not as an active publication row.

Reconciliation procedure

1. Record the retrieval time, response status, content length and any cache/file timestamp available for both sources.
2. Use the market-specific Partners endpoint. Do not use FR general as the baseline for DE or IT.
3. Parse rows by ID; also retain SKU because Magento can emit ancien_sku.
4. Remove the header, then report total IDs, duplicate IDs, common IDs, Partners-only IDs and Lengow-only IDs.
5. For each Partners-only product, check Magento store assignment first, followed by scoped status, type, label, dropship, blocklists and DE validation.
6. For each Lengow-only product, check AVAILABILITY = -1, then Partners source_id, is_new, required localized joins, price and shipping rate.
7. For value differences, compare the exact source fields in the field-semantics table. Do not infer a bug from CSV values without checking store scope and generation time.
8. Review the Magento export output for per-product exceptions before declaring the exported set complete.
9. Re-run the comparison only after both files have been regenerated from the intended source state. A successful HTTP download alone does not prove freshness.

Business rules awaiting confirmation

The source proves what the applications currently do. Seif and Marouen still need to confirm whether the following behavior is the intended contract:

• Magento website/store assignment is mandatory for channel publication.
• All dropship products are excluded outside FR, with only the two named FR exceptions.
• bipolart and non-simple/configurable/bundle products must remain excluded.
• Partners should exclude is_new != 0 while Lengow does not.
• FR and IT should require the additional store 8 and 9 Logidav rows.
• IT intentionally omits the hard-coded SKU/EAN exclusion lists used by FR, DE and Magento.
• Removed products should remain for up to three days with AVAILABILITY = -1.
• The Partners promotion rule may expose a promotion before its start date.
• ancien_id and ancien_sku are the intended identifiers in Lengow.

Until the owners confirm these points, change requests should distinguish a code discrepancy from an intentional publication policy.

Source locations

Component	Repository path
Partners HTTP routing	menzzo-partners/index.php
Partners FR generator	menzzo-partners/src/Cron/General.php
Partners DE generator	menzzo-partners/src/Cron/GeneralDe.php
Partners IT generator	menzzo-partners/src/Cron/GeneralIt.php
Magento selection and row generation	menzzo/app/code/Axelites/Lengow/Cron/LaunchExport.php
Magento export tracking and retention	menzzo/app/code/Axelites/Lengow/Helper/Lengow.php
Magento declared schedule	menzzo/app/code/Axelites/Lengow/etc/crontab.xml

The existing Lengow integration page covers order import and shipment/status feedback. Those inbound order flows are separate from the product-file generation described here.