Functional Overview

Process Overview

Important: Supplier Portal assumes that supplier data is imported into PIM Server supplier catalogs, then merged and after that is enriched. The process where the data is enriched in the staging area before the merge is not the standard process for Supplier Portal!

There are two major steps in the Supplier Portal process:

  • Supplier invitation

  • Data upload

Supplier Invitation

The invitation of suppliers can be triggered by the portal administrator or by the suppliers themselves. In the latter case, the registration has to be approved by the portal administrator before the supplier can actually use the portal.

The standard process is that the suppliers are actively invited by the portal administrator. The process steps are the following:

First, the supplier organization has to be created in PIM Server (Suppliers perspective).

Optionally, a catalog can be created (Supplier Catalogs perspective) and assigned to this supplier. This action could also be done in the Supplier Portal user interface during the invitation process (Supplier Portal will then create and assign a supplier catalog in PIM Server).

For the import of data into the Supplier Catalog a mapping has to be assigned to the supplier. The mappings can be created using the standard PIM Server import mapping functionality and need to be marked for Supplier Portal in its purpose field:

Normally, a retailer creates one standard mapping for all suppliers to let them upload the data in the same format. However, some suppliers are not able to deliver the data in the defined format which is why it’s possible to define multiple mappings and assign each of them to one or multiple or to all suppliers. This assignment is done in the Supplier Portal administrative user interface ("View mappings" menu).

Now, the actual invitation process starts. The portal administrator can select a supplier to invite, enter additional information (first and last name, e-mail address of the supplier's administrator) and acknowledge the invitation. Supplier Portal will send out an invitation e-mail with a link which can be used by the supplier to go to the portal and complete the registration (set the password).

An alternative supplier registration process is supported, where the supplier can register in Supplier Portal without being invited. The portal administrator gets notified per e-mail and has to approve the registration.

User Roles

Supplier Portal supports 3 roles:

  • Portal administrators / managers (usually a “heavy” PIM Server user)

  • Supplier administrators (“main user” of a supplier)

    • Upload data / review the validation results

    • Communicate through the timeline

    • Create further supplier users for their organization

  • Supplier users

    • Same as supplier administrators but without the possibility to create new supplier users for their organization

Data Upload

The standard data upload process looks as follows:

  1. Supplier uploads data through Supplier Portal

    1. Delta uploads are supported, that is the supplier can upload items that need to be updated only

  2. Validations (defined in the import mapping) are executed

  3. If the data is valid, it is imported directly into the respective supplier catalog of PIM Server

    1. Previous content of the supplier catalog is overwritten if the uploaded item was already stored in the catalog and now contains updated values.

  4. The retailer is notified (through the Supplier Portal timeline and via e-mail)

  5. The retailer merges a subset from the supplier catalog into the master (PIM Server)

  6. Data is enriched (normal PIM Server process)

  7. Data is exported

As stated above, Supplier Portal assumes that supplier data is imported into PIM Server supplier catalogs, then merged and after that is enriched.

The process where the data is enriched in the staging area before the merge is not supported by Supplier Portal and should not be deployed. The reason for that is that there’s no mechanism to prevent an update of the PIM Server supplier catalog by the supplier. That is, the upload process overwrites the data in the PIM Server supplier catalog and would also overwrite the changes the retailer made.

After the data has been uploaded, the retailer can use standard PIM Server functionality to compare the supplier catalog data with the Master (show items that are in the master catalog, show items that are not in the master).

It might be beneficial, to set a certain item status in the import mapping (e.g. “02 Modified by Supplier”). Filter/grouping options can then be used to identify the items that were uploaded. Please note, that all items uploaded by the supplier will then receive this status in the PIM Server supplier catalog and not only the ones that have actually been changed.

Management of Import Mappings

Supplier Portal uses PIM Server mappings for imports. This means, every format that can be mapped to the repository in PIM Server can also be made available for supplier uploads through Supplier Portal (CSV, XML, Excel, text, BMEcat, etc.) This is an important USP for the supplier portal because we really have maximum flexibility at this point.

When creating a mapping, make sure you fill out the data sources for the files (right click on the file names in the mapping source view) and the mapping description (in the save mapping dialog). These texts will be displayed to the suppliers in Supplier Portal.

The PIM Server mapping has to be saved with purpose “Supplier Portal” in PIM Server. This setting makes the mapping available in Supplier Portal. By default, such a mapping is not visible to any suppliers yet. To change its visibility, go to the Supplier Portal administrative UI (that is, log in as an portal administrator) and click “View mappings” in the navigation area.

Every mapping can be assigned to either all suppliers or individual suppliers. The same is true for the “Media Assets” mapping, which is a “proxy” for media asset uploads (it’s not a real mapping because the uploaded images are sent to Media Manager). If you hide it from some or all suppliers, they will not be able to upload images.

Also, in the Supplier Portal administrative UI a portal administrator can upload 3 files for every mapping:

  • Documentation (e.g. a PDF describing the data format and validation rules)

  • Template (e.g. a CSV with just one line (header) a supplier can use to fill out)

  • Example data (e.g. a CSV with some sample items)

If uploaded, these 3 files are available for suppliers in the upload wizard.

Validation Rules

As described earlier, a test run is performed up first every time a supplier uploads data. The PIM Server test run is used, that is Supplier Portal sends the data to PIM Server via a REST API, the PIM Server test run is executed and the results are sent back to the portal. If errors occur, the workflow stops and the data won’t be released for import. If the test run was successful, the supplier can trigger the import (release the data for import).

During the test run, standard PIM Server repository validations are executed. Additionally, the user can define further validation rules in the mapping. This is done through scripting in the “Function” view of the PIM Server import perspective.

In PIM Server 6.0, several new import functions were added. For the validation functionality, the following functions are critical:

  • logError(string)

  • logWarning(string)

  • logInfo(string)

These functions do not have a return type but generate a message in the import log (with a severity corresponding to each function’s name). The problem log is displayed to the supplier in the portal after the test run. Thus, it is possible to stop the import on certain conditions, but also generate infos and warnings for the supplier (e.g. telling them that the data is not completely correct, but will still be accepted).

Examples for validation on test run / import

A required field check (price in this case) looks like this:

if ( [Price] = “” , logError( “The price is required!” ), [Price] )

This statement compares the price with an empty string. If it’s empty, logError is executed (which stops the test run). Otherwise, the price is returned as result of the “if” statement.

If the user wants to generate warnings or informational messages if the price is empty, this can be realized like this:

if ([Price] = “” , logWarning( “Warning, price is missing!” ),[Price])

The following example shows a lookup check for the color value. In this example, the retailer only accepts the color values of red, black and white:

if( isInList( [Color], “Red, Black, White” ), [Color], logError( “The value of attribute Color is not valid!” ) )

Other examples:

  • Field lengths: 2 fields together may not exceed a length of 64 characters

    if (length([Short description]) + length([Keywords]) > 64, logError( "E1234" ), Short description (English)])

  • Warning if short description contains certain strings (e.g. „New in assortment“)

  • Look up checks (e.g. for units)

  • Date format checks (e.g. YYYY-MM-DD hh:mm:ss)

  • Number format checks (comma separator)

  • Default value (e.g. unit „piece“ if unit is empty)

Since the import functions are contributive, more sophisticated checks can be implemented. For example, consultants can implement a function in Java checking if the value is a valid GTIN code (isGtin(string)) and then use it in the mapping to validate the data.

Based on the input from the projects, we will add new validation functions into the standard in future releases.

Communication

The home page of both suppliers and portal administrators has a timeline in the middle of the screen. The timeline is a message stream, showing system messages and user generated messages sorted chronologically.

Every supplier organization sees only their messages in the timeline, that is

  • System messages (test run and import results) for uploads started by the supplier

  • Broadcast messages (messages written by the portal administrator directed to all suppliers)

  • Personal message feeds between the supplier's users and the portal administrator

It’s possible to respond to messages.

Text messages can include links (which are opened in new browser tabs) and attachments. Attachments can be used e.g. to send unstructured data through the portal.

Portal administrators see all messages of all suppliers per default. However, there’s a supplier filter and message type filter (suppliers have message type filters only). The filter setting is persisted, that is if it’s set once, it will be available automatically in the next session.

The test run and import result messages are sent asynchronously. This means, a supplier is able to start a test run and to close the browser right after. When the test run is completed, the supplier will be notified through the timeline (and by e-mail).

E-mail notifications can be set up. Suppliers and portal administrators can choose on event type basis when they want to get notified by Supplier Portal.