Unit Management
With version 10.1 a major refactoring of the Unit Management has been implemented which provides several advantages.
Note that in order to realize this feature the release comes with integrated update scripts that will adjust your existing units in the system.
It is strongly recommended to perform a data backup before and revise all units maintained in the system after the upgrade for consistency.
Overview
The data model entity of type unit has been refactored to allow for export, import and API based access from now on.
The following list describes the main enhancements in more detail:
A mandatory, globally unique code has been introduced which also acts as the external identifier of a unit.
Migration scripts will use the so-called "System Units" unit system's codes for this. In case duplicates are recognized during migration, they are named accordingly.
All unit system-specific fields are renamed to "Alternative ..." (e.g. "Alternative Code", "Alternative Symbol", etc.)
Unit fields have been adjusted and correct categories are assigned to the fields
The generic import has been activated for the unit entity
The generic List API has been activated, hence units can now also be created and adjusted via the Service API
Export data providers have been adjusted to support the unit root entity and all its child entities
Repository
|
|
New Fields
New LabelsAll fields within the UnitSystemSpecific sub-entity are now treated as "alternative". Alternative Code, Alternative Categories etc. Those fields need to be qualified by a unit system, no change here except the label of the fields. New CategoriesAll fields have been assigned meaningful categories |
Data Migration
Multiple update scripts will migrate the existing units and create the new fields.
The new Unit.Code field is initialized with the Code of the unit from the "System Units" unit system
In case a Unit had no mapping to the "System Units" unit system (which is actually an invalid state to some sort, see Enum Provider),
the code of the Unit System with the smallest Unit System ID is used. A prefix "mig" and a suffix with the Unit System's identifier is added to the code.In case there were duplicate codes within a unit system (probably due to custom scripts or other situations), the code is prefixed with "mig_dup", followed by the code and the database id of the duplicate unit.
The "System Units" unit system which existed in previous versions is removed
As the new Unit.Code field is also the unique external identifier, there is no way for the system to know which of the duplicates should be active and kept, the customer and project need to manually open the Unit Maintenance and adjust the code of those units.
Enum Provider
The Unit Enum Provider can be used with a unit system context, or without. The default is without. Such as for fields like Order Unit or others.
Within the GDSN area it is used with the GDSN unit system context. The unit system to use can be provided in the repository as enum parameter.
So the "System Units" have been in the past, is now just "all units", by omitting the UnitSystem parameter.
Here an example, no unit system context, but a filter for only the order units:
Example of a GDSN specific enum provider configuration. Context set to GDSN (ID = 70), only Units of the Category "Area":
Desktop UI
The basic maintenance perspective has not changed much, except that the "System Units" unit system is gone now.
Import
Units can now be imported just like every other entity. The Unit.Code needs to be provided as external identifier.
Export
Most export templates using units will be automatically migrated, however, some special cases apply.
Please see the Export Compatibility documentation of the Knowledge Base for this.
Service API
The generic ListAPI functionality works now also for units. This includes read and write calls.