Implementation Guide

Changes often happen overnight!

For approximately 14 years now, ECLASS has been the established international standard for the industry, trade, craft, food industry, services many other sectors. To many people, use of this 4-tier class structure to describe and exchange products between business partners has meanwhile become a daily process.

The new ECLASS 7.0 Release now offers even more users the opportunity to optimise their processes. Not only does it provide new contents but compared to previous releases, also introduces a genuine paradigm shift.

ECLASS radically changed the ways in which people communicate. ECLASS 7.0 meets future data exchange requirements between business partners.

By integrating the most important trade standards such as PROLIST, ETIM, proficl@ss, bau:Cl@ss, IMPT, EDMA, eCALS, and CECED, ECLASS 7.0 is basically suitable to meet any inter-agency requirements with regard to complex data exchanges.

The BME (Federal German Association for Materials Science, Procurement, and Logistics) developed its BMEcat standard for catalog data exchange together with ECLASS e.V. ensuring optimal support of ECLASS 7.0.

Another important step towards worldwide acceptance is the continuous support of multilingual structures. ECLASS, with its trade specific linguistic terminology variations will significantly improve flexibility on the one hand and professional accuracy on the other. The result is that all users will virtually be able to implement an unobstructed data exchange.

Our Implementation Guide intends offering you an initial impression of the new features available when using ECLASS 7.0

ECLASS 7.0 Basic Representation presents a version variant with all essential new contents in the usual format. Consequently, no users are restricted in any way when processing the advanced contents in a CSV format. In addition, the basic version is downloadable as an XML variant.

The new structural elements described under "New structural elements of Advanced Representation" are not part of the basic version. A reference list with the structural elements of the Advanced Representation, maps the attributes contained in the basic version.

The 4-tier class structure is associated with the new application class (AC). This, in turn, contains all relevant structural elements such as blocks and aspects.

Integration of both the PROLIST standard and CAx elements results in additional important data model extensions. Using “Cardinality" multiplication elements as well as variant access of special blocks by means of “Polymorphism” results in significant simplification.

Implementation of additional data type extensions (Level type and Axis type) results in further simplifications. Consequently, a single data type combines physical-technical links originating from various attributes.

It should therefore be possible to transfer the complex data model in a data structure configured for that purpose. That is why eClass 7.0 uses ontoML rules defined in ISO 13584 – part 32.

These rules describe the form and arrangement of the structural elements and predefine how to interpret the ontoML in order to be able to process ECLASS 7.0 Advanced Representation from a data-technical point of view.

Following the release of ECLASS 7.0, the ECLASS standard is available in two different export formats. Internationalisation required amendments of ISO standards. Significant amendments involved both a distinction between ISO-standard conformant “closed” value lists and “open” proposal lists and the introduction of standard compliant measurement units.

The usual CSV export format of the ECLASS-standard includes eight CSV files, which Office programs such as MS-Excel and MS-Access can process and implement. The attached ReadMe file describes the amendments, structure, contents, and associations of the CSV files.

With effect from ECLASS 7.0, it will also be available as an additional export format in ECLASSXML format for automatic ECLASS-standard processing. This export format bases on an ISO-standardised XML format for product data exchange. Related specifications are published in ISO 13584-32:2010 (ontoML) . These specifications offer a uniform and comparable data structure for communications between machines. Consequently, two export formats are available for processing and implementing Basic Representation. Export of Advanced Representation is only available in ECLASSXML-format.

The following matrix provides a functionality overview of both the basic and Advanced Representations.

A block is defined as the total of various attributes under a single name.

For detailed descriptions of devices with classes, a structure like this is extremely helpful.

Using a car as an example, the block “wheel” would contain all attributes to describe the wheel: Rim diameter, tyre size etc. Another block would then describe the “axle” properties. In addition, apart from attributes, a block can also contain additional sub-blocks with attributes and more blocks: In this example the “wheel“ block is subdivided into “rim” and “tyre”.

In order to create a block, a so-called reference property has to be created in the Advanced Representation.

see more under Block

Within the contents of data description, cardinality is therefore a means to determine the number of identical blocks.

In the “wheel” example of the “car” class, you will find that the attributes for a wheel with double tyres will be quite different from a wheel with single tyres. Therefore, if values are to be allocated to a “wheel” block one will first have to decide which type of wheel is to be described: Single tyre or double tyre. Following the decision for “double tyres”, the block “wheel with double tyres” is accessed and related attributes made available (Data-technically, the block “wheel” is replaced by a specialisation “wheel with double tyres”).

The properties of this multiple (“poly”) substitutability (“morphism”) resulting from this special variant are therefore used to describe various details of a product structure keeping the number of total attributes manageable and free of redundancies.

Each unit-associated property may express values (numbers) with regard to its basic unit and dosage unit.

Consequently, attributes are used quite universally and do not require multiple definitions should the scale of data volumes differ considerably. In addition, common usage units can be used.

One example is the pressure range, varying from Pa (overpressure in compartments) to mbar or hPa (air pressure) to bar (Pressure in tyres and technical installations) involving six different scales. Moreover, Anglo-American regions still use the psi unit.

Convertibility of figures to various units is a prerequisite for using different units for an attribute. An attribute cannot have the unit kg/m³ (density) and kg/m² (surface density).

New data types such as Time, Date, Timestamp, and URL were introduced ensuring a high quality data exchange.

Level-Type, specifies common technological values such as minimal, maximal, nominal and typical. The Axis-Type specifies location references within a system of coordinates.

By means of ECLASS 7.0, ECLASS e.V. supports standard users with additional information making it possible to update from ECLASS Release to Release more or less automatically. The result, a significant saving in data processing costs. Updating from 6.2 to 7.0 will make this possible for the first time.

Below please find a description of the Release-Update-Files and Transaction-Update-Files made available by ECLASS:

The Release Update Files (RUF) contain the information on what has changed in one major release compared to the one before. It is a “human readable” collection of CSV files and is only relevant for the basic release. RUF differs between classification and transaction updates. Changes are documented for classes, properties, and all other ECLASS elements regarding modifications, additions and deletions (MOVE, SPLIT, JOIN). RUF only contains modified elements.

The Transaction Update File (TUF) contains all information that is needed for a semi-automatically upgrade of valuated productive data. This can be transactional data or a catalogue file (e.g. a BMEcat file) with ECLASS data (class/property/value/unit) that must be transferred from a previous ECLASS major release to a later ECLASS major release. TUF is available for ECLASS Basic and Advanced in two different XML files. It includes only information that cannot be obtained by the direct comparison of subsequent structure data releases.

A global indication of the time and effort involved in implementing ECLASS cannot be given. It is dependent on many factors that can be different for each user. These include, for instance, the available master data quality, the product volume (for catalogs, procurement, or sales), product complexity, number of language versions etc. In addition, the possibilities of the ERP-system used are as important as the basic goal of ECLASS implementation. The deeper ECLASS’ integration into internal or cross-company processes, the bigger the required effort, but also the expected Return on Investment (ROI). If required, you can use ECLASS-experienced IT service providers, whose addresses are available through info@eclass.eu.

Implementation of the ECLASS – export format CSV (Basic) is easy and requires relatively little effort. Office programs can open, filter, copy relevant content of the CSV files, and convert them to formats best suitable for processing by following IT-systems. The attached ReadMe file describes the contents and relations.

Implementation of ECLASS – export format ECLASSXML Basic is likely to require more time and effort. On the other hand, investment security and having chosen and realised an implementation route that is internationally conformant and allowing a later change-over to the Advanced Representation, makes life easier.

ECLASS will provide a free viewer to display and control data in ECLASSXML format.

The increased implementation efforts of the Advanced Representation are, depending on corresponding application scenarios, offset by an expected higher Return on Investment (ROI).

ECLASS will provide a free viewer to display and control data in ECLASSXML format.

See Frequently Asked Questions (FAQ)

Regular online meetings and webinars

• Exchange of user experiences
• Professional knowledge provided by consultant to user

Ask us when you have any questions

Apart from classic E-Procedure processes, ECLASS 7.0 is becoming more and more important for process integration into electronic planning processes because it also allows transfer of E-CAD planning data from the manufacturer to the customer.

Nowadays, companies wishing to make planning data available for ECAD systems have to use numerous target formats. Something, which is costing companies a considerable investment in resources. ECLASS 7.0 provides a data model that simplifies transfer of planning data and subsequently accelerates planning processes.

Example: The industrial enterprise “ABC LTD” provides its customers with product information and planning data. At ABC LTD, two people are working on preparing data for E-CAD system 1, E-CAD system 2, E-CAD system 3, and E-CAD system 4 because each planning system has quite different requirements. By introducing ECLASS 7.0, ABC LTD provides its software partners with only a single electronic catalog in BMEcat format, which contains both product information and planning information for the E-CAD-systems. A single person can now create this catalog at ABC LTD.

A prerequisite for making product information available for the various business processes is implementation of the ECLASS data model in the user's management system for product information.

Depicting internal processes in manufacturing companies showing competency allocation and related reporting, requires a classification of one’s own product spectrum. Depicting distribution processes of these companies also requires portfolio structuring towards the customer. Procurement, production, and distribution processes are becoming increasingly intertwined, viewed from a SCM (Supply Chain Management) perspective. Therefore, use of a cross-industry standard offers a basis for data exchange between the areas involved.

ECLASS product classification allows companies to include their products and services in a standardised category structure, easily and efficiently. It can be used for the organisation of procurement processes as well as in-house reporting.

The advantages:

• ECLASS covers a broad range of procurement subjects for both manufacturing and trade.
• Nowadays, many suppliers can already make ECLASS-classified product data available – additional in-house classification is no longer required reducing processes and increasing procurement efficiency at the same time.
• On top of that, ECLASS is available in several languages and can therefore be used internationally.

ECLASS 7.0, being the descriptive standard, allows efficient linking of e-Procurement processes beyond the boundaries of individual companies: under ideal circumstances the manufacturer, to be precise, classifies each product or service only once. Any other participant in the process then uses the classified data. Procurement as well as master and product data management benefit in particular because investment in classification and data maintenance can be minimised.

Marketplaces offer the user an advantage because it allows them to compare many suppliers and their respective product portfolios. If a proper overview of manufacturers and their own product structures is insufficient, then an overall structure is required whereby manufacturers have to categorise their products in order to be of any service to the user.

For such purposes, ECLASS and its version 7.0 in particular, provide an excellent basis because it not only allows a hierarchic product search but also product selection using the attributes. Use of ECLASS 7.0 Advanced Representation also gives users the opportunity to make relevant engineering data immediately available.

Using ECLASS 7.0, procurement organisations can easily conclude tender-based framework contracts with their suppliers. Procurement operators draw up specifications based on ECLASS 7.0 in respect of products to be purchased and submit these to their suppliers so they can put in a bid.

Requirements

• regarding products are taken from (reference) details based on attributes laid down in ECLASS 7.0,
• regarding description details of catalog products and services are laid down in “templates”.

In turn, suppliers manage their product information based on industrial standards regardless of the applying procurement organisation and integrate the product information of their sub-suppliers. Avoiding different product description standards increases data quality and data security.
 

Example:

Procurement operator ABC defines a partial ECLASS segment relevant to the actual procurement e.g. laptops.

The procurement operator, using segment details, defines the “laptop” requirements, for example hard disk capacity > 500 GB.

Procurement organisation ABC defines the descriptive details required from the expected catalogs i.e. the attributes (and proposal values) which the supplier is obliged to provide, for instance manufacturer, manufacturer's article number, CPU-type, guarantee period.

Procurement organisation ABC distributes its segment details, covering the requirements and requested descriptive details expected from the catalogs, to its suppliers.

Supplier XYZ creates a BMEcat for his products together with the required descriptive details and enters his product data in the catalog. To make sure everything is correct, the supplier checks the BMEcat to see whether:

• the data are correctly coded in accordance with ECLASS,
• the data requirements of the corresponding catalog included in the templates and
• the article requirements are met.

Using this catalog, the supplier offers his products to procurement organisation ABC enclosing the catalog at the same time.

Procurement organisation ABC carries out its commercial selection and downloads the catalog on its IT-system to ensure product access under the agreed conditions.

ECLASS 7.0 can assist in optimising in-house data management. Many companies find that providing product information is becoming more and more complex. Apart from the ever-increasing complexity of data processing, demands placed on master data management are growing continuously. Systems have to be able to save master and product data in such a way that they can serve virtually any publication channel. Company officials responsible for the products are often not aware of which product properties to describe in order to cover any business event. In such cases, ECLASS 7.0 would also be an obvious choice when looking for an in-house data model to describe products.

A uniform catalog data exchange format is a prerequisite for standardised master and product data exchanges. This is where the BMEcat-format comes into it. BMEcat is able to display ECLASS 7.0 in full; it allows description of classified products, which can then be transferred to a business partner in the form of a complete catalog.