Introduction

The Supplier Portal allows suppliers of products to edit data for their own products and send them to the Perfion owner for use in Perfion, just as if the Perfion user entered or imported the data manually.

The Supplier Portal introduces a number of commands available to both the supplier organization user (referred to throughout this document as a Supplier User) and the Perfion Owner.

Whenever a supplier invokes a SubmitItem command, or a Perfion Owner accepts an item through the Supplier Portal, a Supplier Item Command is executed behind the scenes.

Starting from 2026-R1 SR1, the Perfion API has been extended to support execution of Supplier Item Commands directly through the API. This also means that Supplier Item Commands can be executed inside Actions by constructing the appropriate XML payload.

A Sample Command

Below is an example of a SubmitItem command. This command performs exactly the same operation as when a supplier user submits an item through the Supplier Portal.

<SupplierItemCommand command="SubmitItem">
  <Items>
    <Item>
      <Id>711104</Id>
    </Item>
  </Items>
</SupplierItemCommand>

The above command submits the supplier item with ID 711104.

The Commands at a Glance

There are currently nine available Supplier Item Commands. These commands are divided into two categories:

• Item Commands operate on an item as a whole and move it between item statuses.
• Value Commands operate on individual feature values belonging to an accepted supplier item.

The table below lists all currently available commands.

Who Can Issue What

Commands are partitioned by issuer.

Normally the back-end refuses commands issued by the wrong principal.

When Supplier Item Commands are executed through the Perfion API, the same restrictions apply, except that all commands are allowed when executed by a Perfion Administrator or through an Action.

Item Statuses

Every supplier item has an item status. Commands have preconditions based on these statuses and may change them.

• Draft – The supplier is currently editing the item.
• Submitted – The supplier has submitted the item and it awaits review.
• Accepted – The owner has accepted the item and linked it to a standard item.
• Rejected – The owner declined the item and returned it to the supplier.
• Locked – The owner has frozen the item to prevent further supplier changes.

Value Statuses

Individual values on supplier items also carry statuses. These statuses are manipulated by the Values Commands.

• NoAction – No action required.
• AwaitsOwner – Waiting for owner review.
• Accepted – Value accepted by owner.
• Rejected – Value rejected by owner.
• Ignored – Value reviewed but ignored.

The Commands at a glance

There are 9 commands in total, grouped into two categories:

• Item commands operate on an item as a whole. These commands move the item between the statuses Draft, Submitted, Accepted, Rejected, and Locked.
• Values commands operate on individual feature values on an already accepted item. They are used to Accept, Reject, Ignore, or Reopen specific feature values that the Supplier has changed.

The table below lists all currently available commands:

Who Can Issue What

In the interface, commands are partitioned by issuer.

Normally the back-end refuses commands issued by the wrong principal. When issuing Supplier Item Commands through the Perfion API the same restriction applies, except that all commands are allowed when either issued by a Perfion Administrator or when issued through an Action.

If it was not for this exception, a SubmitItem command executed from the API Tool Window would always fail, since only a Perfion User can access that window and a Perfion User may not issue a SubmitItem command.

Item Statuses

Every supplier item carries an item status. Commands have preconditions that determine which statuses they can operate on and may change the status during execution.

• Draft – The supplier is currently editing the item. Only Draft items can be submitted, and only Draft or Rejected items can be deleted by the supplier.
• Submitted – The supplier has handed the item over to the owner. It awaits either an AcceptItem or RejectItem command.
• Accepted – The owner has accepted the item and a link to a standard item now exists.
• Rejected – The owner declined the item. The supplier may edit and re-submit it.
• Locked – The owner has frozen the item to prevent further changes by the supplier.

Value Statuses

Each value on a supplier item also holds a status. The Values commands change these statuses.

The possible Value Statuses are:

• NoAction – No further action expected on this value.
• AwaitsOwner – The value differs from the linked standard item and is waiting for the owner to either Accept or Reject.
• Accepted – The owner has acted on the value and accepted it.
• Rejected – The owner has acted on the value and rejected it.
• Ignored – The owner chose to ignore the value.

Common Command Structure

All nine commands share the same XML envelope. Only the command name, the contents of the <Item> element, and a few attributes vary between commands.

Root Element

Every Supplier Item Command starts with a root <SupplierItemCommand> element.

<SupplierItemCommand command="..." supplierId="..." lockedItemHandling="...">
  <Items>
    <Item> ... </Item>
    ...
  </Items>
</SupplierItemCommand>

Item Element

Each <Item> element identifies a Supplier Item that the command should operate on.

For Item commands, the <Features> element is ignored. For Values commands, it is required and specifies which feature values should be affected.

<Item>
  <Id>123</Id>
  <Features>
    <Feature> ... </Feature>
    ...
  </Features>
</Item>

Feature Element

Used by the Values-commands to identify the specific feature values to act on.

<Features>
  <Feature>
    <Id>104</Id> <!-- Feature id (integer) or feature name -->
    <Languages>
      <Language>DAN</Language>
      <Language>EN</Language>
    </Languages>
  </Feature>
</Features>

Command Result

On success, the back end returns a result containing one or more IdPair entries describing what happened for each item.

<Response>
  <Result>
    <IdPairs>
      <IdPair kind="StatusChange">
        <SupplierItemId>711104</SupplierItemId>
        <StandardItemId />
      </IdPair>
    </IdPairs>
  </Result>
</Response>

Every returned IdPair contains a SupplierItemId, identifying the Supplier Item involved in the operation. When a Standard Item is involved, the corresponding item id is returned in StandardItemId.

For example, SubmitItem only changes the status of a Supplier Item and therefore does not return a Standard Item id.

The kind attribute describes what occurred during processing.

The Items-Commands

The Items-commands move a supplier item between statuses. They are in this Section listed in the order an item travels through its lifecycle.

SubmitItem

Submit-Item is how a Supplier hands a Draft item over to the PIM Owner for review. It is the only command the Supplier can issue. The portal validates that all features marked Mandatory in the supplier’s configuration have values in every language the supplier operates in. If validation passes, the item moves to Submitted and waits for the owner.

Example

<SupplierItemCommand command="SubmitItem" supplierId="1" lockedItemHandling="Fail">
  <Items>
    <Item>
      <Id>710969</Id>
    </Item>
  </Items>
</SupplierItemCommand>

Accept-Item

Accept-Item is how the PIM Owner takes a Submitted item into his own “Product Catalog” by creating or linking an Item (product) in his repository. The back end first looks for an existing standard item that matches the supplier item by the configured supplier key (e.g. ItemNumber). If a match is found, the supplier item is linked to that standard item (KeyMatch). If no match is found, a new standard item is inserted (StandardItemInserted) and linked.

Once linked, all features configured as “Auto Accept” have their values copied automatically from the supplier item to the standard item. Features whose values differ between the supplier item and the standard item are marked AwaitsOwner so the owner can decide them later with a Values command.

Features whose values match are marked NoAction, since no further action here is expected.

Example

<SupplierItemCommand command="AcceptItem" supplierId="1">
  <Items>
    <Item>
      <Id>710969</Id>
    </Item>
  </Items>
</SupplierItemCommand>

Reject-Item

Reject-Item is how the PIM Owner declines a Submitted item or revokes a previously Accepted item. Rejection is a status change only: the item’s data is preserved so the supplier can correct it and resubmit. Any existing link to a standard item is preserved, but all spec statuses are reset to NoAction so the supplier can rework the item in the portal.

Example

<SupplierItemCommand command="RejectItem" supplierId="1">
  <Items>
    <Item>
      <Id>710969</Id>
    </Item>
  </Items>
</SupplierItemCommand>

Lock-Item

Lock-Item is how the PIM Owner freezes an Accepted item against further updates from the supplier or further Values commands. A Locked item keeps its link to the standard item. While locked, Values commands will only affect the item if lockedItemHandling permits it (see section 'The Values-Commands').

Example

<SupplierItemCommand command="LockItem" supplierId="1">
  <Items>
    <Item>
      <Id>710969</Id>
    </Item>
  </Items>
</SupplierItemCommand>

Unlock-Item

UnlockItem reverses a previous LockItem and returns the item to Accepted status. The link to the standard item is preserved, so further Values commands may resume normally.

Example

<SupplierItemCommand command="UnlockItem" supplierId="1">
  <Items>
    <Item>
      <Id>710969</Id>
    </Item>
  </Items>
</SupplierItemCommand>

The Values-Commands

Values-commands operate on individual feature values rather than on the item as a whole. They are issued by the PIM Owner against items that have been Accepted (and may be Locked). Each <Item> in the command must list the specific <Feature> entries to act on, optionally narrowed by <Languages> for localizable features.

All Values commands share a single behaviour pattern: they change the spec status of the listed values. AcceptValues additionally copies the value from the supplier item to the linked standard item.

Accept-Values

Accept-Values copies one or more feature values from the supplier item into the linked standard item and sets their spec status to Accepted. For localizable features the languages listed in <Languages> are accepted; values representing languages omitted from the list are left untouched. For non-localizable features the <Languages> element is ignored.

If the supplier item is currently Locked, the lockedItemHandling attribute decides what happens. The default is Fail.

Example

Accept feature value for feature 104 in both Danish and English, and the feature called ItemNumber on item 1230. The supplier is locked-handling=Update so the values are written even if item 1230 is currently locked:

<SupplierItemCommand command="AcceptValues" supplierId="1" lockedItemHandling="Update">
  <Items>
    <Item>
      <Id>1230</Id>
      <Features>
        <Feature>
          <Id>104</Id>
          <Languages>
            <Language>DAN</Language>
            <Language>EN</Language>
          </Languages>
        </Feature>
        <Feature>
          <Id>ItemNumber</Id>
        </Feature>
      </Features>
    </Item>
  </Items>
</SupplierItemCommand>

Reject-Values

Reject-Values marks the listed feature values as Rejected. It is a status change only — no data is written to the standard item, and the supplier may then choose to change the value and have it reviewed again. Localizable features are rejected at the language granularity given in <Languages>.

Example

<SupplierItemCommand command="RejectValues" supplierId="1">
  <Items>
    <Item>
      <Id>1230</Id>
      <Features>
        <Feature>
          <Id>104</Id>
          <Languages>
            <Language>DAN</Language>
          </Languages>
        </Feature>
      </Features>
    </Item>
  </Items>
</SupplierItemCommand>

Ignore-Values

Ignore-Values marks the listed feature values as Ignored. Use it to signal that the owner has seen the value and chosen not to act on it — the value is neither accepted nor formally rejected. Like RejectValues, this is a pure status change.

Example

<SupplierItemCommand command="IgnoreValues" supplierId="1">
  <Items>
    <Item>
      <Id>1230</Id>
      <Features>
        <Feature>
          <Id>EanCode</Id>
        </Feature>
      </Features>
    </Item>
  </Items>
</SupplierItemCommand>

Reopen-Values

Reopen-Values moves the listed feature values back to AwaitsOwner so they can be decided again. This is the inverse of an earlier Accept/Reject/Ignore decision and is useful when the supplier has supplied new data for a previously closed feature, or when the owner wants to revisit a decision.

Example

<SupplierItemCommand command="ReopenValues" supplierId="1">
  <Items>
    <Item>
      <Id>1230</Id>
      <Features>
        <Feature>
          <Id>104</Id>
          <Languages>
            <Language>DAN</Language>
          </Languages>
        </Feature>
      </Features>
    </Item>
  </Items>
</SupplierItemCommand>

The lockedItemHandling Attribute

Values commands can target items that are currently Locked. The optional lockedItemHandling attribute on the root element decides what the back end does in that situation. It has three possible values:

As noted above, if the lockedItemHandling-attribute is omitted, the back end uses Fail as the default. The attribute is only meaningful for the Values commands; Items commands are not affected by lock status in the same way (LockItem requires the item to be Accepted, and UnlockItem requires it to be Locked).

Validation and Errors

Every command is validated before any effects occur. Validation covers: existence of every referenced item; that the supplier issuing the command matches the items id; that the item is in a status compatible with the command; that mandatory features (for Submit-Item) are filled out; and that the configured supplier key is present (for Accept-Item).

If validation fails, an error message is returned and the Command does nothing, i.e. nothing is written to the database.