How Odoo products become known to the 3PL, the four ways to get them there, what a push actually sends, and how automatic matching links an existing 3PL catalogue without ever creating products behind your back.
Product push and enrichment are part of LataSys 3PL Connector: Products, a companion app installed alongside the core connector. Installing it reveals the features described here; without it the product push flows stay off. Existing installations upgrading from an earlier version get the app installed automatically, so nothing they were using changes.
Operations > Products lists one line per (product, instance) pair - the product binding. It records the state of that product at that 3PL:
The same product can be bound to several instances independently - synced at the 3PL, still to-push at your 3PL.
SKU rule. The 3PL identifies products by SKU. A binding uses the product's Internal Reference by default; the Remote SKU field covers the case where the 3PL knows the product under a slightly different code (for example a legacy code with a trailing space - it happens). Products without an Internal Reference cannot be pushed and are rejected with a clear message naming them.
Two businesses rarely keep product data in the same place. One puts the warehouse name in the product name, another in a Studio field, a third wants the variant attributes spelled out so a picker can tell a red medium from a blue large. The Product Fields tab (inside Synchronisation on the instance) is where you say which Odoo field feeds which 3PL field.
The table is the full set, not your provider's set. Every instance carries the same catalogue of product fields the connector knows about - SKU, name, description, barcode, weight, dimensions, HS code, country of origin, price, cost, category, unit of measure, variant attributes, lot and expiry flags, supplier and supplier code, and free warehouse notes. Rows your provider cannot accept are shown greyed and are never sent, so the table doubles as an honest answer to "what can this 3PL actually hold?".
Everything is auto-mapped on day one. Each row starts on the Odoo field the connector would have used anyway, so a new instance behaves exactly as before without you touching the tab. Name is worth knowing about: it defaults to the product name plus its variant attributes - "T-Shirt (Red, L)" - because a warehouse operator picking from a shelf needs to tell variants apart. Odoo's own display name is deliberately not used, since it prefixes the internal reference and the SKU is already travelling in its own field.
Overrides are obvious and reversible. Change the Odoo
Field on a row and the row is flagged Overridden, in bold amber,
with the default it replaced shown alongside ("was
l3pl_warehouse_name"). The arrow button on the row puts that
one back; Reset All to Defaults on the tab header clears every
override on the instance.
Odoo Field is a path, so any product shape works.
Type a field name (default_code), or follow relations with
dots (categ_id.name,
seller_ids.partner_id.name,
product_tmpl_id.x_studio_warehouse_note). A path asked of a
variant falls back to its template automatically, so it does not matter
whether your business keeps the data on the template or the variant. A
path that does not resolve is simply not sent - it never fails the
push.
Transforms handle unit disagreements. Odoo stores weight in kilograms; your 3PL may want grams, pounds or ounces. Each instance starts on its own provider's unit, and the Transform column lets you change it - along with metres to centimetres, centimetres to inches, rounding, whole numbers, upper and lower case, and a yes/no conversion for tracking flags. Switching an instance to a different provider moves the default unit with it and leaves your overrides alone.
Untick Send to hold a field back even though the provider would accept it. Required rows (SKU and name) are the exception: a product missing one is refused before the request is sent, with a message naming the field rather than the 3PL's error code.
A push tells you what you sent. It does not tell you what is there now: warehouse staff edit descriptions, a SKU never arrives, items appear at the 3PL that Odoo has never heard of. Compare Products, on the Product Fields tab of the instance, answers the real question - are the two catalogues the same, and where exactly do they differ?
The comparison fetches the 3PL's catalogue and lines it up with Odoo's through that instance's own field mapping, so it compares the fields that instance actually exchanges, in the units it exchanges them: 1 kg here and 2.205 lb at a pounds provider is one weight, not a difference. Every SKU gets one of four verdicts:
Everything the 3PL holds is kept, including fields the connector does not map: the provider's own record for each SKU is shown exactly as it came back, and the unmapped field names are collected on the report with a count of the products carrying them. The reverse gap is flagged too - fields your 3PL would accept where your mapping table has no Odoo field.
Which products are compared is set by Compare Which Products. By default it is the products linked to this 3PL, because a business with two 3PLs sends different products to each and the other one's catalogue is not "missing". Switch to every product with an internal reference when this 3PL is meant to hold the lot.
Product Master, on the same tab, settles the argument before it starts. With Odoo as master (the default) the connector pushes Odoo's data as usual and Apply pushes the outstanding products out. With the 3PL as master, product pushes from Odoo are held back - scheduled, bulk and queued alike - and Apply writes the 3PL's values onto the Odoo products instead, undoing any unit conversion on the way in. Either way nothing is written without a person pressing a button, and a scheduled comparison only ever reports.
Applying to Odoo touches only fields the mapping covers, and only where the mapped Odoo field can be written directly. A field fed by a path into related data, or by a computed value, is reported back as "not applied" rather than guessed at, and every applied change is logged in the product's chatter.