Projecteurs d'usine (modules de projecteurs) : Programme universel de modules pour les marchés nécessitant un décodeur - frontière d'approvisionnement, étiquetage, contrôle des révisions et flux de travail des réclamations

Factory projector headlights (projector modules) make sense for B2B programs because they reduce mechanical variants: one module platform can support multiple housings and multiple vehicle applications.

Qu'est-ce que pas universal is the vehicle’s electrical behavior. Many platforms use bulb monitoring, PWM dimming in DRL/low modes, and CAN-controlled lighting logic. In those markets, a decoder (CANBUS / anti‑flicker / load module) is often required to avoid flicker or dashboard warnings.

We manufacture the projector modules. We do not manufacture or supply decoders.
This note is written in “factory program” language so your team can copy terms into PO/PI and keep reorders consistent.

1) Supply scope (what we ship, what we don’t)

We ship:

• Projector module set (as per confirmed model + revision)
• Mounting parts (only if listed on the packing list)
• Product label + carton label with Model / LHD-RHD / Rev / Batch
• Revision-linked Spec Confirmation Sheet

We do pas ship:

• Decoder (CANBUS / load resistor / anti‑flicker module)
• Vehicle-side harness solution
• A guarantee of “no warning / no flicker on all vehicles” without platform validation

Plain-language rule for your sales team:
Mechanical coverage can be universal. “No flicker / no warning” is a system result (vehicle + decoder + install).

2) PO / PI clauses (copy-paste)

Use this wording to keep responsibility clear and prevent “assumed inclusion” disputes.

Decoder boundary (recommended)

• Decoder is not included in our supply. Buyer arranges decoder and harness.
• Buyer is responsible for vehicle platform validation and decoder selection.

Sample-to-mass consistency (recommended)

• Mass production must match the approved sample revision. Revision code must be stated on PO.
• No unapproved substitutions are allowed for parts affecting interface/fit/beam. Any change requires Rev update and buyer written approval.

Packaging / labeling (recommended)

• Carton label must include Model / LHD-RHD / Rev / Qty / Batch No. / Date.
• Batch/Rev traceability is required for aftersales claims.

If you want it even more “PI-ready,” put it as line items:

• “Projector module: Model ___ / LHD / Rev ___ / Qty ___”
• “Decoder: excluded (buyer supply)”

3) Revision naming (example format you can standardize)

To avoid “same name, different behavior,” the Rev must be visible and consistent. Here is a simple naming approach that works in warehouses and claim handling:

• Module code: UPJ-30
• Function: LO (low-only) or BIF (bi-function)
• Side: LHD / RHD
• Revision: RevA, RevB, …

Example SKU line on PO:
UPJ-30-BIF-LHD-RevA

If the connector or harness exit changes, do pas keep the old Rev. Create a new revision (or a new SKU if your ERP prefers).

4) Label content (real examples, warehouse-readable)

Labels should let a warehouse separate inventory without opening cartons.

Product label (minimum)

• Model: UPJ-30
• Side: LHD
• Rev: RevA

Carton label (minimum) — example line

MODEL: UPJ-30-BIF | SIDE: LHD | REV: RevA | QTY: 10 | BATCH: 26A15 | DATE: 2026-01-27

If your market runs mixed inventory, add:

• Customer code / PO No. (optional)
• Inner box quantity (optional)

Important: If your carton label does not show Rev + Batch, you will eventually mix stock and lose the ability to troubleshoot objectively.

5) Packing list language (no guessing)

Use short, non-interpretive packing lists.

Example packing list (module-only program):

• Projector module ×1 set
• Mounting parts ×1 set
• Decoder: excluded

If your downstream channel sells a “complete kit,” keep that as a separate SKU on your side (buyer-managed), not as an inconsistent factory pack-out under the same carton label.

6) Why decoders are commonly required (what triggers support tickets)

In decoder-heavy markets, these are the repeat offenders:

• Flicker in DRL mode (PWM dimming and low duty cycles)
• Dashboard bulb-out warnings (load monitoring / current signature mismatch)
• Random shutoff (ECU protection logic)
• High/low trigger mismatch (different switching logic across platforms)

A projector module can pass outgoing inspection and still create these issues on certain platforms. That is why decoder strategy must be treated as part of the system design.

What we will not write on a datasheet without validation:
“Error-free on all cars” / “No flicker on all vehicles” / “100% plug-and-play.”

What we can support reliably:
A stable, traceable module revision that your decoder pairing can be built around.

7) Change control (what counts as a “new Rev”)

To keep reorders stable, the following changes require a new revision and written notice:

Interface / installation changes (always new Rev)

• Connector type change
• Pinout / polarity marking rule change
• Harness exit orientation change
• Mounting points or mechanical envelope change

Behavior changes (new Rev if installers can feel it)

• Startup behavior / trigger behavior
• Thermal protection behavior that changes user-visible output
• Any electrical behavior change that affects decoder pairing

Optical changes (new Rev)

• Parts or assembly changes that affect beam pattern or cutoff behavior
• LHD/RHD optics change (never “mixed” under one Rev)

We do not do silent swaps on these items. If a material/sub-supplier change is unavoidable, it is either:

• documented as a new Rev, or
• held until buyer approval is received (depending on impact)

8) Aftersales claim workflow (simple, fast, traceable)

This section is intentionally operational. It reduces “endless guessing” and speeds up resolution.

Evidence required (minimum)

1. Carton label photo showing Model / Side / Rev / Batch / Date
2. Short video or photos showing the issue (flicker/warning/shutoff)
3. Vehicle info: make/model/year + mode where issue occurs (DRL/low/high)

Factory response timeline (typical)

• Within 24–48 hours: verify Rev + Batch in production records and confirm module configuration
• If needed: request one additional check (connector seating / polarity / ground quality) — only when evidence is unclear

Resolution path

• If issue is batch-specific: isolate the batch, stop-ship if required, and provide replacement/credit per agreed terms
• If issue is platform/decoder-related: confirm module Rev is correct, then support your decoder pairing by ensuring the module side has not drifted (Rev consistency).
• If a change is required: issue a new Rev and mark it clearly on labels and PO language

This workflow protects both sides: you avoid random replacements, and we avoid treating system-level behavior as “mystery defects.”

9) What to send in your RFQ (so the quote matches the program)

To quote and freeze the correct revision, send:

1. Target market(s) and driving side: LHD or RHD
2. Function: low-only or bi-function
3. Mechanical limits: depth, mounting preference, housing constraints
4. Connector preference (if fixed) + harness exit direction requirement (if any)
5. Decoder reality in your market: “commonly required” (yes/no) + your sourcing plan
6. Label language + barcode requirements
7. Sample qty, first order qty, and reorder rhythm

We reply with:

• module recommendation + Rev
• Spec Confirmation Sheet for approval
• label field confirmation (product + carton)
• lead time for sample and mass production tied to that revision

Takeaway (the “one sentence” you can align on internally)

In many markets, universal mechanical fit does not equal universal electrical behavior. We supply the projector module only (decoder excluded), and we keep your program stable through visible revision codes, batch traceability, warehouse-readable labels, and controlled changes—so your decoder pairing does not drift across reorders.