Increasing volatility in commodity prices leads to a variable cost base for any manufacturing industry. The forecasting model for projecting input cost has varying degrees of success because it must factor in complexities arising from emerging market demand, geopolitical uncertainty, and market speculation. In most cases commodity price volatility has an impact on profit margins, as the manufacturers are not able to pass the price increase in the final product.
Also Read: What is SAP HANAIMP 16 Certification?
Business managers do not like to deal with unpredictable operating margins. Fortunately for major commodities, financial derivative markets exist and allow for a balance in market risks. The derivative contracts executed in the opposite direction provide a hedge by fixing the cost base from day to day market movement. Let us try to understand this principle with examples from the industrial metals, agriculture, food processing, and energy industries.
Copper Price Subject to Change During Gap Between Sale and Delivery
Copper smelters purchase copper concentrate to produce industrial grade copper plates (cathodes). The price of copper concentrate is decided based on the percentage of copper and trace quantities of other precious metals. Copper concentrate is physically procured first let’s say from a mine in Australia to a smelter in China. Price is fixed based on the delivery date of the concentrate at prevailing copper market price. The transportation takes about a month and the processing and final sale of the processed copper cathode takes place after another month. The sale obviously is at the current copper market price. In this example, there is a two-month lag between the date the copper concentrate was purchased from the mine and the point of sale to other manufacturing operations. An increase in copper price during this period leads to a favorable sale price, sometimes even windfall gains. On the other hand, a drop can wipe out the margin or even take the company out of business. Ideally the processing unit would want the copper price to stay the same so that the margin is truly based on its operational efficiency. To achieve this, it places a hedge in London Metal Exchange (LME) by buying or selling Grade A copper futures at the same time when the physical transaction is executed to offset the price risk.
Grain Exposed to Market Risk During Distribution
A trading and grain distribution company decides to purchase corn from St. Louis grain elevator on a Mississippi river barge to be shipped to its export elevator at New Orleans, Louisiana. When the barge is loaded, draft lines on barge is used to estimate weight before it starts sailing. Typically, the market price on the load date along with basis differential is used to price the shipment. After a two-week journey, the barge reaches its destination. At this time the stock is unloaded and weighed on a scale. A sample is also taken to determine moisture, foreign material, and quality of the corn stock. It is then decided to store this corn along with a similar quality corn on an elevator. After a few days, the corn in the elevator is used to fulfill an export obligation by loading a Panamax vessel. On the load date vessel inspection reports are drawn to determine quality and weight, along with other vessel costs, which are then used to finalize the grain payment. Again, here there is a spread between the buy from St Louis grain elevator and sell date of Panamax vessel, which exposes the grain distribution operation to market risk. To mitigate Yellow Corn number 2 future is traded by the grain company on Chicago Mercantile Exchange.
Quality and Price Uncertain for Wheat Flour Shipment
A flour milling company needs hard red winter wheat to fulfill its sale obligation of a certain specification of wheat flour. It decides to buy it from Crookston, Minnesota via rail cars to deliver to it’s processing plant in Albany, New York. The sales contract is created well in advance of the harvest season. The exact quality of the grain that will be received is not known at the time, nor is the projected price of the grain. Similar challenges are faced by other food processing companies that deal with raw commodities, e.g. cereals, processed meals, snacks, and baking products.
Price of Oil Varies Due to Market Conditions
In the energy industry, refining margins are driven by crack spread. Crude oil is used by refinery to produce gasoline, diesel, and jet fuel. The difference between the price of each individual product and crude oil defines crack spread. Crude oil can have long procurement cycles particularly for waterborne crude. The price of each of the finished product varies daily based on market conditions which are complex to forecast.
Understand Risk Management Strategies
As can be seen from the various examples, understanding the commodity price exposure and being able to hedge this risk with appropriate financial instruments is of significant value. However as is also evident from the various examples, at every step there is ambiguity in terms of quantity, quality, and price. Even though a big portion of the risk can be mitigated by hedging, it is not a straight-forward task. The accuracy of hedging depends on robust ERP framework which can provide timely input on the status of individual transactions as more information becomes available on the transaction lifecycle. The results feed into a daily review of hedge positions and adjustments that need to be made to keep up with the underlying exposure from physical transactions.
Risk management program requires a holistic assessment of commodity risk profile using analytics, diagnostics, and modelling tools. For a big trading house, the software ask translates into a portfolio of reports that need to run near real time, churn a very high data volume to the tune of hundreds of millions of rows, and result computation based on complex calculation logic.
Figure 1 illustrates the daily risk management process in a traditional setup. The process is dependent on a series of intermediate tables, several batch jobs with high processing time to build the intermediate aggregation tables, and ultimately joining the aggregation results and presenting to users via risk reports. The starting point—transactional exposure recognition—can have further complexity depending on the interface design that keeps your accounting / ERP solution and risk management solution in sync. The biggest drawback in this process is hedge execution is on yesterday’s data. The process of exposure aggregation and building risk reports precludes any possibility of near real-time risk reporting. Not to mention, the aggregation of data may also limit the possibility of full drill down to lowest granularity and diagnostics.
Figure 1 – Daily risk management process in a traditional setup
Figure 2 represents the daily process with risk reporting on SAP HANA. The in-memory database eliminates the need of aggregate tables and allows parallel processing of several threads for quick computation. Since the data is available in-memory, the data access is immediate, which allows for mass data processing. As a result, with SAP HANA architecture, intermediate aggregation tables are no longer needed and risk reports can be built with real-time data and support full drill down to lowest granularity.
Figure 2 – daily risk management process on SAP HANA
SAP Commodity Management
SAP Commodity Management software provides the business capability required in buying and selling commodities. It allows for procurement and sales contracts to be priced based on market quotes and complex formulas and has the capability to settle with counterparty based on provisional prices and then a true-up based on final prices. Most importantly, it can identify and recognize exposures from underlying transactions to allow for combined risk assessment of physical and financial transactions.
Data Modelling with Core Data Services
Data modeling is key for risk analytics. After the evolution of SAP HANA there was a fundamental shift in the way data models can be built. HANA database allows pushing down calculation logic to the database layer. In a classic approach, data is retrieved in the application layer and then intensive computations are carried out. With a data-centric approach, the use of application layer is minimized. Most of the computation is carried out in the database layer. Moreover, row and column-based data store and ability for massive parallelization leads to fast data aggregation without the need for intermediate aggregation tables and less indices, thereby promoting mass data analysis.
Core Data Services (CDS) views is an SAP modelling infrastructure to harvest the capabilities of SAP HANA database. The programming model executes the logic at the database layer by keeping the data definitions and consumption on the database server. CDS views are also integrated with ABAP to allow developers to find the best balance between application programming models and database level programming. In the optimized approach, it is found that a large part of the ABAP application can be migrated to CDS views, which brings the advantage of the HANA database.
Architecture Consideration – Risk Reporting in SAP S/4 HANA Database
Figure 3 represents the recommended architecture. SAP S/4HANA allows online transaction processing (OLTP) and online analytics processing (OLAP) into a single in-memory database. The transactional system has the data reliably available all the time. It offers great convenience to build analytical data models in the same system without the constraint or dependency of data replication.
This architecture is a great improvement from the past and works most of the time unless there is a concern that a lot of free form modelling and what-if analysis needs to be carried out by the end users. The architecture risk in this approach is that unconstrained simulations and concurrency can bring a lot of strain on the CPU, thereby impacting the online transaction processing.
Figure 3 – Risk Reporting in SAP S/4HANA Database
Architecture Consideration – Risk Reporting in a Sidecar HANA Database
In the approach shown in Figure 4, SAP HANA sidecar is used as a secondary database which stores replicated data from the main transactional system. SAP Landscape Transformation is used to replicate the table entries in real time. It follows a trigger-based replication approach for migrating data between the two systems.
Figure 4 – Risk Reporting in a Sidecar HANA Database
The sidecar database provides full SAP HANA computation capability. SAP HANA CDS views are used in this landscape, as there is no ABAP application layer. SAP HANA CDS views reside in HANA extended application services and do not require ABAP layer. The views use native SQL to allow table access directly without any ABAP dictionary declaration. The front-end controls typically run through a Fiori screen and ABAP based user interface is not a possibility.
Such an architecture is normally needed when there is a need for free form simulations by users and a lot of what-if analysis, which can potentially bring strain on the CPU. A side car architecture is also required when the access privileges for data modelling conflict with audit requirements. The analysts may need to modify table entries to realign data in some situations. And this is not allowed in a main transactional system. The stringent regulatory controls that govern the transactional system may not necessarily apply to the sidecar database.
The primary drawback in this approach is that the modelling is limited to replicated tables only. Any additional information cannot be accessed immediately and requires an SLT setup. The other challenge is monitoring of SLT failures. SLT normally works reliably but changes in source system, e.g. modification in table structure can lead to SLT failures.
