Often it is necessary to convert the so called foreign key into own key values during transformation. This is usually done in eBiss via Value Tables. It is a matter of converting a foreign key ¹⁾ into a known 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.

Note: For a small number of keys, the alternative Translate() function exists.

Translations can be consumed and established into the existing tables³⁾ via Copy & Paste in eBiss in the following form:

1. The Value-Provider table has two columns:
   1. ID of the host system key
   2. Description(designation in the host system, optional)
2. The actual Value Tables⁴⁾ has four columns:
   1. ID of the foreign key
   2. Description(name of the foreign key, optional)
   3. ID of the host system key
   4. Description(name in host system, optional)

Note: In eBiss we distinguish between global and partner-specific recoding. Partner-specific conversion tables are created automatically when the function LookUpTP is used.

Some examples of common remappings are discussed below:

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.

1. Gender determination alternatives:
   1. GENDER(FK)⁵⁾ → GENDER(IK)⁶⁾
   2. if necessary to be derived from the product group of the supplier
   3. from another characteristic, e.g. buyer controls via the business unit
   4. derived from article EAN
2. Product group(FK possibly linked with gender)⁷⁾ → Product group(IK)⁸⁾

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)⁹⁾ → article category(IK)¹⁰⁾

Color code(supplier) and color name(supplier) → Color code(consumer) and color name(consumer) Multiple colors can be mapped into the “StandardColorContainer¹¹⁾” 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.

(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).

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

The decision whether a partner-specific or global recoding should be made is made by clever use of 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.

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.