Managing Catalog Versions

The plug-in is used to manage catalog versions. The default behavior of Fulfillment Provisioning changes based on the number of catalog versions. The following table lists the various possibilities:

Number of Versions Default
Catalog starts with one version The version is treated as default.
Catalog starts with multiple versions, and none are configured as default The first activated configuration will be treated as default.
Only one versions is set as default The default configuration cannot be deactivated, but it can be replaced with a new one.
Except the locked versions, loaded and activated versions can be edited using the Catalog UI. The Service Order Processing will be able to select and use only the activated and default catalog versions. To select the right domain version, the Service Order Processing looks for the #KOPVERSION in the SOD dataset. The course of action will change based on the availability of #KOPVERSION in the dataset. The following table lists the possibilities:
Availability of #KOPVERSION in The Dataset Default
#KOPVERSION not found in the dataset The Service Order Processing selects the default version of the domain.
#KOPVERSION found in the dataset and it contains the name of the used version. For example, 1.3.6::GSM If the service order comes back to Service Order Processing, it will use the used version.

Default Catalog Versions

The default catalog version depends on #KOPVERSION. For example, a Fulfillment Provisioning node can have two versions: 1.3.5, which is the default, or 1.3.6, which is an active version.
Version of the Incoming Order Version on the Fulfillment Provisioning Node
1.3.5 Either ther is no #KOPVERSION or #KOPVERSION =1.3.5
1.3.6 #KOPVERSION =1.3.6

If you switch the default from 1.3.5 to 1.3.6, all incoming orders that are without #KOPVERSION will start using 1.3.6.