====== Conversion of properties ======

Often it is necessary to convert the so called foreign key into own key values during transformation. This is usually done in eBiss via [[en:transformation:lookuptables:start|]].
It is a matter of converting a foreign key ((FK= foreign key)) into a known internal key ((IK = internal key)). It is self-evident that the internal key is one-to-one and the cardinality foreign key to internal key can be equal **n:1**. 

{{:images:sign_warning.png?nolink|}}**Note:** For a small number of keys, the alternative [[en:transformation:mappings:funktionen:allgemein:translate|Translate()]] function exists.

===== Preparation =====

Translations can be consumed and established into the existing tables((These must necessarily be defined in advance.)) via **[[en:howtos:copy_paste|]]** in eBiss in the following form:
  - The **[[en:transformation:werteprovider:start|]]** table has two columns:
    - ID of the host system key
    - Description(designation in the host system, optional)
  -The actual **[[en:transformation:lookuptables:start|]]**((Depending on your needs, this recoding table can be global or partner specific.)) has four columns:
    - ID of the foreign key
    - Description(name of the foreign key, optional)
    - ID of the host system key
    - Description(name in host system, optional)

{{:images:sign_warning.png?nolink|}}**Note:** In eBiss we distinguish between **[[en:transformation:lookuptables:start#global|global]]** and **[[en:transformation:lookuptables:start#partner-specific|partner-specific]]** recoding. Partner-specific conversion tables are created automatically when the function **[[en:transformation:mappings:funktionen:abfragefunktionen:lookup:lookuptpvalue|LookUpTP]]** is used.

Some examples of common remappings are discussed below:

===== product-group-remapping =====

Product group recodes are usually required in a retail eBiss system because vendor PRICATs are usually only provided with vendors or, ideally, standard product groups.
If standard product group codes are used, it makes the customer's work easier, because he then does not have to make the specific recoding for each supplier but only makes a recoding from the standard product group to his product group codes.


If the product group code is gender dependent, then the gender must be determined first.
  - Gender determination alternatives:
    - GENDER(FK)((FK= foreign key)) -> GENDER(IK)((IK = internal key)) 
    - if necessary to be derived from the product group of the supplier
    - from another characteristic, e.g. buyer controls via the business unit
    - derived from article EAN
  - Product group(FK possibly linked with gender)((FK= foreign key)) -> Product group(IK)((IK = internal key)) 

===== Article category =====
Article categories are usually classes of product groups. If these are to be transmitted within an interface, then it needs an appropriate global conversion from the own product group key to the own article category key.

If needed the derivation of the article category can be made from the product group most likely n:1.
product group(IK)((IK = internal key)) -> article category(IK)((IK = internal key))                                           

===== Color conversion =====

Color code(supplier) and color name(supplier) -> Color code(consumer) and color name(consumer)
Multiple colors can be mapped into the "**StandardColorContainer**((This is a complex data type in the eBiss Middleware TradeItemDocument.))" as a list.

Also with the color codes the use of standards offers itself around as many as possible partners with global Umschlüsselung to convert.

===== Size conversion =====

(if necessary depending on article category and supplier):
Article category(IK) is already known and can be used with the manufacturer size information as a lookup foreign key.
I.e. it needs the following conversion table:
Item categoryID((consumer)-size(supplier) -> size(consumer).

===== Seasonal key =====

This is done analogous to the previously described conversions, usually partner specific.

===== global or partner specific recoding =====

The decision whether a partner-specific or global recoding should be made is made by clever use of **[[en:transformation:mappings:funktionen:abfragefunktionen:lookup:start|LookUp functions]]**. This is done by first using a non-mandatory mapping rule to determine if a global remapping value exists, if yes it is used, if no a partner specific remapping entry is required. If this is not available, the foreign key is entered into the mapping table and the mapping to the own key must be done manually. If all the required conversions are present, the messages can be processed successfully.

{{:images:sign_warning.png?nolink|}}**Note:** Sometimes it is necessary to concatenate the foreign key or lookup value with different keys to look up a unique host system key.\\ **Example:** Supplier product group & gender are needed as lookup values for own product group identification.