Struct ResponsibleOperator 

pub struct ResponsibleOperator {
    pub did: String,
    pub name: String,
    pub role: OperatorRole,
    pub eu_operator_id: Option<String>,
    pub eu_operator_id_scheme: Option<String>,
    pub country: String,
    pub registered_trade_name: Option<String>,
    pub postal_address: Option<String>,
    pub electronic_address: Option<String>,
}

Identifies an economic operator responsible for a DPP.

Under ESPR, the “responsible economic operator” is whoever places or makes the product available on the EU market. This can be the original manufacturer, an importer, a distributor, or a remanufacturer.

Contact details

postal_address, electronic_address and registered_trade_name exist because four separate provisions require the same four-part shape of whoever is answerable for a product, and confirmed against the verbatim OJ text they are: ESPR Art. 27(6) (manufacturer) and Art. 29(3) (importer) — “name, registered trade name or registered trade mark, postal address at which, and electronic means of communication through which, they can be contacted”; Art. 4(4) of Regulation (EU) 2019/1020 — “the name, registered trade name or registered trade mark, and contact details, including the postal address”; and Art. 16(3) of Regulation (EU) 2023/988 — the same, “including the postal and electronic address”.

ESPR Annex III, point (k) is what puts them in the passport: “the name, contact details and unique operator identifier of the economic operator established in the Union responsible for carrying out the tasks set out in Article 4 of Regulation (EU) 2019/1020 or Article 15 of Regulation (EU) 2023/988, or similar tasks pursuant to other Union law applicable to the product”. Contact details are never a free string in any of the four.

⚠️ That quote’s “Article 15” is the Regulation’s own cross-reference, and it points at the wrong article — Art. 15 of 2023/988 is Cooperation of economic operators with market surveillance authorities; the responsible-person provision is Art. 16. The quote is left exactly as enacted, and ResponsibilityBasis::GeneralProductSafety carries the explanation, including why it changes nothing in substance.

All three are Option because this type is a persisted shape — it is stored inside the transfer chain — and the envelope rule is additive-only. None means not stated, never “has none”.

Fields

did: String

The operator’s DID (e.g. did:web:acme.example.com).

name: String

Human-readable name of the economic operator.

role: OperatorRole

The operator’s role in the supply chain.

eu_operator_id: Option<String>

EU-assigned economic operator identifier, if available.

eu_operator_id_scheme: Option<String>

The scheme Self::eu_operator_id is expressed in — "vat", "lei", "eori", "duns". None when no EU identifier is held.

Paired with the value because an identifier without its scheme cannot be stated truthfully to a registry: the value alone does not say what it is, and guessing produces a false claim rather than a missing one.

country: String

ISO 3166-1 alpha-2 country code of the operator’s establishment.

registered_trade_name: Option<String>

Registered trade name or registered trade mark, where it differs from name.

All four provisions name it as an alternative to the legal name — “name, registered trade name or registered trade mark” — because the two are frequently different and a reader holding the product sees the trading one. Kept as a separate field rather than overloading name, which is the legal name.

postal_address: Option<String>

Postal address at which the operator can be contacted.

ESPR Art. 27(6) adds a constraint the other three do not: “The address shall indicate a single point where the manufacturer can be contacted.” That is a property of the content, not of the shape, so nothing here enforces it — a free string cannot express “single point”, and a structured address still could not say whether it is the only one.

electronic_address: Option<String>

Electronic means of communication through which the operator can be contacted — an email address, or a contact URL.

Distinct from did, and deliberately: a DID document resolves keys. Nothing in it is required to be a mailbox or a form, so it is not a channel through which a person can be contacted, and reading it as one would satisfy the obligation on paper and not in fact.

Trait Implementations

impl Clone for ResponsibleOperator

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ResponsibleOperator

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for ResponsibleOperator

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for ResponsibleOperator

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl Serialize for ResponsibleOperator

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl StructuralPartialEq for ResponsibleOperator