Price Catalogue: exchanging dynamic information of articles

Price Catalogue message

The Price Catalogue message is used to exchange trade information about articles from a supplier's catalogue to ensure that the customer's ERP system contains the latest information on an article. The up-to-date exchange of a catalogue prevents calculations based on incorrect or outdated information stored locally in ERP systems. Within the Price Catalogue message an article is a product that is offered for sale where dynamic trade information, such as price and lead times, have been added. For example, a box of screws is offered in a catalogue. In this case, the box of screws is the sold article and a loose screw is the product.

The scope of the Price Catalogue message is limited to exchanging dynamic information of articles. The message does not facilitate the exchange of product properties or other product-specific information resulting from the production process. Only information identifying the product is included to enable the linkage between an article and a product. The main reason for limiting the scope is that the exchange of product specifications in a standardized fashion can be highly complex, and there are already solutions for this, such as the European Technical Information Model (ETIM) by ETIM International and Ketenstandaard. ETIM has significant adoption in the construction and installation sector and already started their expansion in steel industry. Therefore, SCSN aims to collaborate with ETIM by using this standard for standardized product specification exchange, and therefore limiting the scope of this message to only the dynamic data of articles.

Roles

Two different roles are identified in this use case:

• Seller: the party owning a catalogue and updating the trade and pricing information, e.g. a wholesaler.

• Buyer: the party receiving the catalogue, e.g. a manufacturing company.

It should be noted that the roles do not exclude each other. A party might buy raw materials from a Seller-party and thus is the Buyer, but simultaneously the party can be the Seller when selling its produced items to other parties. Therefore, the roles are specified for each dynamic customer-relation.

Process

The workflows supported by the Price Catalogue message are limited and are summarized below:

• A Seller pushes a catalogue to a Buyer using the Price Catalogue message.

• A Buyer requests a (part of the) catalogue from a Seller using the Price Catalogue Request message.

The workflows operate under a fire-and-forget principle. In other words: the Seller does not monitor whether the Price Catalogue message is processed in the Buyer's ERP system. Consequently, this means that each time a catalogue is sent, the entire catalogue is sent as contractually agreed between the Seller and Buyer, not only the updated lines.

Specifying articles

In order to exchange dynamic price information, the 'static' article information must be specified and present in the ERP system. Below an example is shown of three different articles containing the same product.

The first catalogue line contains one bottle (EA = each) of shampoo of 250 ml with Seller's identifier '123'. The second line with Seller's identifier '456' is a case (CS) of 6 bottles. The third article is a pallet of 18 cases of shampoo.

Example 1: box of 200 screws

The example below shows how a box of 200 screws is specified using a Catalogue line.

<cac:CatalogueLine>
	<cbc:ID>1</cbc:ID>
	<cbc:OrderableUnit>CS</cbc:OrderableUnit>
	<cbc:MinimumOrderQuantity unitCode="CS">2.0</cbc:MinimumOrderQuantity>
	<cac:RequiredItemLocationQuantity>
		<cac:Price>
			<cbc:PriceAmount currencyID="EUR">3.00</cbc:PriceAmount>
			<cbc:BaseQuantity unitCode="EA">100</cbc:BaseQuantity>
		</cac:Price>
	</cac:RequiredItemLocationQuantity>
	<cac:Item>
		<cbc:PackSizeNumeric>200</cbc:PackSizeNumeric>
		<cbc:Name>Screws black 200 pieces</cbc:Name>
		<cac:SellersItemIdentification>
			<cbc:ID>77490124</cbc:ID>
		</cac:SellersItemIdentification>
	</cac:Item>
</cac:CatalogueLine>

Based on this information, calculations can be made, e.g. to calculate the price of the minimum order quantity. The minimum order quantity is two cases of 200 screws and the price per 100 screws is €3. Therefore, the price of the minimum order quantity is €12.

Example 2: pack of six insulation boards

The second example shows how a pack of six insulation boards is specified using a Catalogue line.

<cac:CatalogueLine>
	<cbc:ID>2</cbc:ID>
	<cbc:OrderableUnit>PA</cbc:OrderableUnit>
	<cbc:MinimumOrderQuantity unitCode="PA">1.0</cbc:MinimumOrderQuantity>
	<cac:RequiredItemLocationQuantity>
		<cac:Price>
			<cbc:PriceAmount currencyID="EUR">20.00</cbc:PriceAmount>
			<cbc:BaseQuantity unitCode="MTK">1</cbc:BaseQuantity>
			<cbc:OrderableUnitFactorRate>3.6</cbc:OrderableUnitFactorRate>
		</cac:Price>
	</cac:RequiredItemLocationQuantity>
	<cac:Item>
		<cbc:PackSizeNumeric>6</cbc:PackSizeNumeric>
		<cbc:Name>Pack, 6x insulation boards</cbc:Name>
		<cac:SellersItemIdentification>
			<cbc:ID>890223</cbc:ID>
		</cac:SellersItemIdentification>
	</cac:Item>
</cac:CatalogueLine>

The calculation of the price of the mimimum order quantity is more complicated here as it is calculated with different units. Therefore, the element OrderableUnitFactorRate is used as ratio between the price unit and orderable unit.

The minimal order quantity is one pack of six insulation boards and the price per one square metre (MTK) is €20. The OrderableUnitFactorRate is 3.6, meaning that the square metres within one pack of insulation boards is 3.6 m2. The OrderableUnitFactorRate is used to convert the base price unit to the orderable unit. Therefore, the price of one pack of six insulation boards is €20 x 3.6 = €72.

Dynamic information

As stated earlier, the core of the Price Catalogue message is to exchange dynamic trade information that changes from time to time, such as price and lead times. The RequiredItemLocationQuantity element contains the conditional price related to a specific location, validity period and ordered quantity. The example below shows the usage of RequiredItemLocationQuantity.

<cac:CatalogueLine>
  <cbc:ID>1</cbc:ID>
  <cac:LineValidityPeriod>
    <cbc:StartDate>2019-01-01</cbc:StartDate>
  </cac:LineValidityPeriod>
	<cac:RequiredItemLocationQuantity>
		<cbc:LeadTimeMeasure unitCode="DAY">2</cbc:LeadTimeMeasure>
		<cbc:MinimumQuantity unitCode="EA">1</cbc:MinimumQuantity>
		<cbc:MaximumQuantity unitCode="EA">10</cbc:MaximumQuantity>
		<cac:Price>
			<cbc:PriceAmount currencyID="EUR">9.00</cbc:PriceAmount>
			<cbc:BaseQuantity unitCode="EA">1</cbc:BaseQuantity>
			<cbc:PriceTypeCode>net</cbc:PriceTypeCode>
		</cac:Price>
	</cac:RequiredItemLocationQuantity>
	<cac:RequiredItemLocationQuantity>
		<cbc:LeadTimeMeasure unitCode="DAY">2</cbc:LeadTimeMeasure>
		<cbc:MinimumQuantity unitCode="EA">11</cbc:MinimumQuantity>
		<cac:Price>
			<cbc:PriceAmount currencyID="EUR">7.50</cbc:PriceAmount>
			<cbc:BaseQuantity unitCode="EA">1</cbc:BaseQuantity>
			<cbc:PriceTypeCode>net</cbc:PriceTypeCode>
		</cac:Price>
	</cac:RequiredItemLocationQuantity>
</cac:CatalogueLine>

In the above example the article net price is provided since the start of 2019. The lead time for the article is 2 days. There are two different prices. For purchases of 10 or fewer articles, the price is €9. The price for a purchase of 11 or more articles is €7.50. These price ranges are called ' staffels' or 'staffelkorting' in Dutch, meaning that a discount occurs when the number of ordered articles increases.

Orderable units and price units

As shown in the second example above, different price and orderable units can be used and can lead to complex calculations. This picture shows two types of units that are possible in the Price Catalogue message and how to calculate with them.

Possibly the orderable and price unit are the same which makes it relatively easy to make calculations. But for many articles the unit of measures are different and therefore the units have to be converted. As shown in the picture, for example, the article can be ordered in cases and the price is based on bottles. The element OrderableUnitFactorRate can be used for the conversion between both. OrderableUnitFactorRate is the factor by which the base price unit can be converted to the orderable unit (pay attention: so not the other way around!). For example, if we know that the price is €10 per 1 BO (bottle) and the OrderableUnitFactorRate is 12, then the calculation shows that the price per orderable unit results in €120 per CS (case).

When working with price ranges, in Dutch 'staffels', it is possible that a third unit is introduced. Elaborating on the example, besides the cases and bottles the unit liter is also used. The element ContentUnitQuantity can be used to express this extra unit of measure, e.g. in this example the ContentUnitQuantity is 15 LTR (liters), which equals the orderable unit of 1 CS.

Each price range (staffel) is specified using a RequiredItemLocationQuantity element with a MinimumQuantity and a MaximumQuantity. For the example. the following price ranges with their corresponding price units are available:

Price range (staffel)	Price unit
1-25 LTR (liter)	€60,- per 1 BO (bottle)
25-50 LTR (liter)	€55,- per 1 BO (bottle)
50-100 LTR (liter)	€50,- per 1 BO (bottle)

If one CS is ordered and known is that each CS equals 15 LTR, then we know that it fits within the first price range and each bottle costs €60. When three cases are ordered, this is 3*15=45 LTR and fits within the second price range. Each bottle now costs €55. Now the price per bottle is known, also the price for the ordered cases can be calculated using the OrderableUnitFactorRate.

Price Catalogue Request message

Besides the Price Catalogue message being used to send a price catalogue from a seller to a buyer, it is also possible to request a catalogue. By sending the Price Catalogue Request message, the buyer requests the seller to send an update of the entire catalogue or part of the catalogue as agreed on in the contract. The Price Catalogue Request is a compact message and shows some overlap with the Price Catalogue message.

Product Specification message

As already mentioned in the first section, the Price Catalogue message limits the scope to only the exchange of dynamic data of articles and does not specify the products itself. The main reason for limiting the scope is that the exchange of product specifications in a standardized fashion can be highly complex, and there are already solutions for this, such as the European Technical Information Model (ETIM) by ETIM International and Ketenstandaard. ETIM has significant adoption in the construction and installation sector and already started their expansion in steel industry. Therefore, SCSN aims to collaborate with ETIM by using this standard for standardized product specification exchange rather than introducing an own SCSN product classification standard.

The Product Specification message is created by SCSN to enable the seller to send product information such product characteristics according to an existing product classification standard, such as ETIM or eCl@ss. The connection between the Price Catalogue messages and the Product Specification message is made through the item identifiers, for example by specifying a GTIN code in StandardItemIdentification.

The content and structure of the Product Specification message is created by SCSN. Although there does not exist a UBL message for this specific purpose, many UBL components and structures were being reused to make the recognizability as big as possible.

Price Catalogue example

The following example shows the syntax of the Price Catalogue message. It should be noted that most fields are filled with the default type. A full example is being developed.

Example XML Price Catalogue

<Catalogue>
  <cbc:ID>normalizedString</cbc:ID>
  <cbc:Name>string</cbc:Name>
  <cbc:IssueDate>2000-01-01</cbc:IssueDate>
  <cac:ProviderParty>
    <cac:PartyIdentification>
      <cbc:ID>normalizedString</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>string</cbc:Name>
    </cac:PartyName>
  </cac:ProviderParty>
  <cac:ReceiverParty>
    <cac:PartyIdentification>
      <cbc:ID>normalizedString</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>string</cbc:Name>
    </cac:PartyName>
  </cac:ReceiverParty>
  <cac:CatalogueLine>
    <cbc:ID>normalizedString</cbc:ID>
    <cbc:OrderableUnit>string</cbc:OrderableUnit>
    <cbc:ContentUnitQuantity unitCode="normalizedString">1.0</cbc:ContentUnitQuantity>
    <cbc:OrderQuantityIncrementNumeric>1.0</cbc:OrderQuantityIncrementNumeric>
    <cbc:MinimumOrderQuantity unitCode="normalizedString">1.0</cbc:MinimumOrderQuantity>
    <cbc:MaximumOrderQuantity unitCode="normalizedString">1.0</cbc:MaximumOrderQuantity>
    <cac:LineValidityPeriod>
      <cbc:StartDate>2000-01-01</cbc:StartDate>
      <cbc:EndDate>2000-01-01</cbc:EndDate>
    </cac:LineValidityPeriod>
    <cac:RequiredItemLocationQuantity>
      <cbc:LeadTimeMeasure unitCode="normalizedString">1.0</cbc:LeadTimeMeasure>
      <cbc:MinimumQuantity unitCode="normalizedString">1.0</cbc:MinimumQuantity>
      <cbc:MaximumQuantity unitCode="normalizedString">1.0</cbc:MaximumQuantity>
      <cac:Price>
        <cbc:PriceAmount currencyID="normalizedString">1.0</cbc:PriceAmount>
        <cbc:BaseQuantity unitCode="normalizedString">1.0</cbc:BaseQuantity>
        <cbc:PriceTypeCode>normalizedString</cbc:PriceTypeCode>
        <cbc:OrderableUnitFactorRate>1.0</cbc:OrderableUnitFactorRate>
        <cac:AllowanceCharge>
				 	<cbc:ChargeIndicator>boolean</cbc:ChargeIndicator>
				 	<cbc:AllowanceChargeReasonCode>normalizedString</cbc:AllowanceChargeReasonCode>
				 	<cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>
					<cbc:Amount currencyID="normalizedString">1.0</cbc:Amount>
		 		</cac:AllowanceCharge>
      </cac:Price>
    </cac:RequiredItemLocationQuantity>
    <cac:Item>
      <cbc:Description>string</cbc:Description>
      <cbc:PackSizeNumeric>1.0</cbc:PackSizeNumeric>
      <cbc:Name>string</cbc:Name>
      <cac:BuyersItemIdentification>
		    <cbc:ID>normalizedString</cbc:ID>
				<cbc:ExtendedID>normalizedString</cbc:ExtendedID>
      </cac:BuyersItemIdentification>
      <cac:SellersItemIdentification>
			  <cbc:ID>normalizedString</cbc:ID>
				<cbc:ExtendedID>normalizedString</cbc:ExtendedID>
      </cac:SellersItemIdentification>
      <cac:StandardItemIdentification>
			  <cbc:ID schemeID="normalizedString">normalizedString</cbc:ID>
				<cbc:ExtendedID>normalizedString</cbc:ExtendedID>
      </cac:StandardItemIdentification>
      <cac:ItemSpecificationDocumentReference>
			  <cbc:ID>normalizedString</cbc:ID>
				<cbc:IssueDate>2000-01-01</cbc:IssueDate>
				<cbc:DocumentTypeCode>normalizedString</cbc:DocumentTypeCode>
				<cbc:VersionID>normalizedString</cbc:VersionID>
				<cac:Attachment>
					<cbc:EmbeddedDocumentBinaryObject mimeCode="normalizedString" filename="string"></cbc:EmbeddedDocumentBinaryObject>
					<cac:ExternalReference>
						<cbc:URI>normalizedString</cbc:URI>
						<cbc:FileName>string</cbc:FileName>
					</cac:ExternalReference>
				</cac:Attachment>
      </cac:ItemSpecificationDocumentReference>
			<cac:AdditionalItemProperty>
			  <cbc:Name>string</cbc:Name>
				<cbc:Value>string</cbc:Value>
			</cac:AdditionalItemProperty>
			<cac:ManufacturerParty>
			  <cac:PartyIdentification>
			    <cbc:ID>normalizedString</cbc:ID>
			  </cac:PartyIdentification>
		  	<cac:PartyName>
					<cbc:Name>string</cbc:Name>
				</cac:PartyName>
			</cac:ManufacturerParty>
      <cac:Dimension>
			  <cbc:AttributeID>normalizedString</cbc:AttributeID>
				<cbc:Measure unitCode="normalizedString">1.0</cbc:Measure>
      </cac:Dimension>
    </cac:Item>
  </cac:CatalogueLine>
</Catalogue>