Skip to Content

Must read before this blog Commodity Pricing Engine (CPE) – Introduction

This blog will discuss some important keywords that are relevant for a better understanding of CPE. Moreover, these terms will be used frequently and hence having a firsthand understanding of them would be beneficial.

Derivative Contract Specification (DCS)

As the name suggests, it is a contract specification in a way trading is done at exchanges. Every exchange provides a specification for a commodity to be traded at that exchange.

Consider an example of soybean to be traded at an exchange.

The above image shows that if a Soybean Futures Contract has to be created when the following specification have to be met.

Contract Unit signifies that the quantity should be in multiples of 5000 bushels. Price quotations for soybean to be traded at this exchange would be in cents per bushel. The specification even provides the minimum price fluctuation(tick size)  that is possible for the quotations of soybean being traded at this exchange.

SAP provides DCS similar to this.

As seen in the image above, the first tab ‘Basic Data’ shows the Physical Commodity i.e. Soybean. It also shows the unit of measure to be used for that commodity while trading i.e. BU. Product Symbol here is DCS is same as Product code in the contract specification.

Maturity Code Determination is the way to identify futures for a contract. But what are futures?

Well, whenever a commodity is being traded then the buyer and seller decide upon a specified future date as a reference and agrees to buy or sell that commodity at that date in future at a future price. These futures can be specific months, weeks or even days depending upon the commodity being traded. Each maturity code has a specific code and maturity code determination is used for the same.

Example: SMYY (as seen in the image)

  • S – Product Code
  • M – Month Code
  • YY – Year

So if the product code is for CME Globex and the mont is January 2018 then the Maturity code would be ZSF18. ‘Determination Methods’ is a way to determine the Maturity. It can be Manual or something like SMYY as shown in the image.

The second tab ‘Derivative Details’ gives some more information about the market.

Quantity/UoM refers to the lot size whereas the tick size is same as seen in the contract specification.
NOTE: Tick size can be different for a different MIC.

Other fields refer to the quotation that will be used for this contract specification. It is sometimes possible that CPE Unit of Measure can be different that Quotation UoM. This is typically in case of metals where individual components have different UoM.

The third tab ‘Periods’ gives details of all maturity periods possible for a commodity.

As seen in the image, the maturity here is for the month of July with a Contract Maturity Code ZSN16. There are different types of periods that can be defined and each refers to a specific activity. So in the image above trading can be done from 15.03.2014 to 15.07.2016 and quotations would also be for the same period. Whereas the final contract can be made in the period 01.07.2016 to 15.07.2016 and its settlement can be done only on 15.07.2016

These period are generally resemblance of how business is done for a specific commodity.

A DCS can be created/viewed using the transaction FDCS01 or from SPRO -> Materials Management -> Purchasing -> Commodity Pricing -> Commodity Pricing Engine -> Definition of CPE Quotations -> Market Data Based on Derivative Contract Specification -> Derivative Contract Specifications -> Specify Derivative Contract Specifications

A similar path can be identified for Sales and Distribution side.

Market Identifier Code (MIC)

MIC is a four character key that identifies a stock exchange or a trading platform. It is assigned to a DCS and each DCS needs to have at least one MIC assigned to it. An operational MIC always starts with ‘X’ followed by 3 more characters. The MIC seen in the DCS above is not the operational MIC but rather a MIC of the operational MIC.

XCBT is the operational MIC for Chicago Board of Trade but it has a market in different cities so if the trading is done in Chicago then the MIC used is CBOT whereas if the trading is done in Kansas City then the MIC used is KCBT.

There can be a case when more than one MIC is assigned to a DCS. This happens if the contract specification is similar for both the exchange or trading platforms. For example: If soybean is traded at both FCBT and KCBT and the contract specification is same, then both MIC can be added to a single DCS.

Moreover, a MIC can be assigned to multiple DCS as a MIC only identifies the market but not the commodity being traded

MIC can be created/displayed/changed via SPRO -> Materials Management -> Purchasing -> Commodity Pricing -> Commodity Pricing Engine -> Definition of CPE Quotations -> Market Data Based on Derivative Contract Specification -> Specify Market Identifier Codes

A similar path can be identified for Sales and Distribution side.

 

 

Both DCS and MIC together form a market reference that is frequently used in CPE.

More in the upcoming blogs.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Alejandro Jacard Plubins

    Have you been able to implement the mass loading of prices for a DCS using transaction TBD4?  We wish to automate pulling data from a Reuters data feed for several DCS on a specific MIC, but there is little documentation to enable it.

    Thomson-Reuters have not provided any tips either, so it’s unclear how to proceed. There is plenty of info regarding exchange rates or other financial-related  information, but nothing for commodity prices.

    (0) 

Leave a Reply