[TechnicalData]: Adding commercial properties

[mrentsch65]

To better support Logistics/Trade, I propose to add an optional SMC CommercialData to the SMT TechnicalData with content particularly relevant for commerce, border crossing and customs — such as tariff code, packaging information, dimensions, weight, volume, material etc.. I believe such content belongs rather to the product specification SM (TechnicalData) than the transaction SM (PurchaseOrder), which currently does not provide it either.

ECLASS has in many product classifications definitions like the following, which should also be provided in the SMT TechnicalData:

"Manufacturer product description" (0173-1#02-AAU734#003),
"GLN of manufacturer" (0173-1#02-AAY812#003),
"Customs tariff number" (173-1#02-AAZ800#003),
"HS-Code of the WCO" ( 0173-1#02-AAZ851#003),
"GTIN (EAN) code" (0173-1#02-AAO663#005),
"Net weight"(0173-1#02-BAD875#010),
"gross weight" (0173-1#02-BAF368#007)
...

It is also worthwile to look at the definitions of https://schema.org/Product and ensure compatibility to them.

[BirgitBoss]

Some of these properties are also part of Digital Nameplate

[mrentsch65]

Some of these properties are also part of Digital Nameplate

Hi @BirgitBoss, can you please point to these commercial properties in DigitalNameplate? The only one that I can recognize besides the "OrderCodeofManufacurer", is"CountryOf Origin":

And I believe, the missing property "Manufacturer product description" was a mistake from the beginning of this SMT, especially since it is carried in SMT SoftwareNameplate (see #181).

@mv-sickde

[tfunken]

We also have the need to put "commerical data" somewhere, specifically:
unit of content - 0173-1#02-AAO250#004
order unit - 0173-1#02-AAO249#004

So just to add some throughts: When discussing this with some component manufacturers, we decided that it would not be a good idea to simply include them in the technical data because we felt that they are not 'technical', so it would be semantically inaccurate, even though the general structure would allow it.

We are currently considering whether it would make sense to include them into a nameplate of a type AAS (as some kind of type nameplate), or or if there will be so many properties that we need a new submodel with a structure similar to technical data. Thus, the options would be:

• SMC Commercial Data in Technical Data
• New Submodel Commercial Data similar to Technical Data structure
• Namplate (only feasible of few properties, which is not the case I think)

I would currently lean towards introducing a new submodel. Technical data can grow quite large in productive use cases (>50 MB), even with a single classification system. Otherwise, it would feel as though we are introducing submodels within submodels.