Implementing Contract Pricing in SAP Agricultural Contract Management

Pricing in commodities contracts can be quite complex. We will cover the topic at a high level. The SAP Agricultural Contract Management pricing procedures are provided through the business configuration sets. They are utilized in conjunction with condition types. Generally we deliver one futures condition type, one primary basis condition type, and one secondary basis condition type. However, if a company requires additional condition types, they can configure those on their own.

The pricing procedures play a crucial role in determining the pricing approach and supporting both provisional and final pricing for contract line items. The process of determining price procedures is consistent for both contracts, Materials Management (MM) and Sales and Distribution (SD).

The determination of the pricing approach occurs after entering the valuation point in the contract. In this example, the contract pertains to yellow corn purchased from a third party. The valuation point, which is set up internally in SAP Agricultural Contract Management, helps define the logic for entering prices based on factors such as destination, plant location, and commodity type (in this case, yellow corn).

When the valuation point is entered, the system searches for the relevant condition records in the pricing procedure. Based on the condition types found, the system determines that the pricing approach for this contract is Componentized Futures plus Basis.

Although standard Materials Management (MM) and Sales and Distribution (SD) condition records are used for input, it is important to note that actual pricing information is not pulled from them because the condition types are configured as CPE conditions. They go through a process of formula assembly using BRF+, and then the results of formula assembly go through formula evaluation to arrive at a market price for each condition.

For instance, in this example, the system identified the following condition records at the material level:

• An entry for the provisional futures price
• An entry for the primary basis for provisional pricing
• An entry for the market futures price
• An entry for the market primary basis

Based on these findings, the pricing approach was determined to be Componentized (Futures plus Basis).

Let's examine another example to illustrate the pricing approach for yellow corn. Typically, the widely used approach for yellow corn is Componentized, encompassing futures and basis components. However, there are instances where traders prefer a different pricing approach called Componentized Flat.

To accommodate this, we create a new valuation point in our system specifically for the Componentized Flat pricing approach. To distinguish it, we append the identifier CF to the valuation point name. Additionally, we establish a corresponding basis ID following the same naming convention.

Next, we incorporate a pricing condition that aligns with the Componentized Flat approach. Rather than adding the condition record at the material level, we place it at the material valuation point level. This enables the system to associate the condition record with the specific pricing approach related to the valuation point.

By adopting this approach, we have the ability to control the pricing approach for yellow corn while introducing a different option, namely Componentized Flat. This is achieved through the use of a distinct valuation point, basis ID, and the inclusion of the corresponding condition record reflecting the desired pricing approach. This approach can also be applied to secondary pricing components. In case secondary pricing is utilized, a separate valuation point and basis ID can be established, and the relevant condition record can be added accordingly.

In the example shown below, the provisional prices for soybeans was determined based on the pricing approach determined, the CPE formula assembly, and basis ID determined and the prices entered (or through a curve) for soybean CBOT futures and for basis ID.

Provisional and final pricing play a significant role in agribusiness processes. Provisional pricing serves several purposes. Firstly, it's necessary from a system perspective as our SAP Agricultural Contract Management software requires a price to perform certain functions. Additionally, from a business perspective, provisional pricing is crucial due to the time gap between shipment and receipt of goods, and the payment process, especially in different countries/regions around the world.

For instance, when dealing with farmers, provisional pricing allows us to make payments based while waiting for all the necessary information, such as analysis data, to be finalized. Agricultural companies often set a threshold, typically around 80% of the provisional price, for making interim payments and settlements. This practice extends beyond farmers to other contractual relationships with counterparties, particularly during long voyages.

However, it's important to note that provisional settlement doesn’t involve a final price. Certain criteria and elements, including pricing, must be resolved before a final settlement can take place. Pricing serves as a key factor in determining the final settlement and ensuring accurate and appropriate payments.

Provisional pricing is necessary for both system requirements and business considerations. Usually, we have a provisional condition record for futures, as it's a mandatory requirement. However, the market condition types may vary depending on industry and customer preferences. While many companies utilize market condition types for risk reporting purposes, some consumer product companies may not use them.

Provisional pricing represents a temporary price until all pricing components are finalized. It’s a condition type used to calculate provisional settlements or interim payments. These settlements are based on agreements reached with the counterparty, which may involve fixing the basis price while the futures price remains provisional, or the opposite. The system checks the contract for any fixed pricing components and incorporates them into the calculation. If no fixed components are found, the system pulls the provisional price.

In terms of differentiation between viewing provisional and fixed prices, the contract includes pricing lots where fixed prices and components are specified. These pricing lots can be viewed in an SAP Agricultural Contract Management view, which provides a clear indication of whether a price is fixed or provisional.

Regarding the example displayed in the figure, the futures price and provisional price are the same. This is due to the configuration and setup of our system, which pulls daily market prices from the Derivative Contract Specification (DCS).

For our soybean purchase contract example, the futures price is determined by first determining the CPE formula key from the BRF+ decision table assigned to the highlighted table.

For our soybean purchase contract example, the decision table looked at the valuation point (D_0001_SB) on the contract and the condition record determined for futures (ACFT for provisional futures price and AMFT for market price) and found the CPE formula key, which is a CPE configuration object. This configuration object is linked to a series of configuration tables that will ultimately link to a DCS and Market Identifier Code (MIC) from which the futures price is determined.

For our soybean purchase contract example, futures were configured to DCS for CBOT soybeans futures and, based on the delivery dates entered (3/1/2020 to 4/30/2020), it fell within the May futures, as determined by the orthodoxy table. Based on the determined maturity key date, futures price was derived based on the commodity curve.

The system was able to determine the futures price by following the assembly formula, which ultimately led to identifying the appropriate DCS and MIC assigned to the DCS table. Through configuration logic, the system determined that soybeans on the Chicago Board of Trade should be used.

Furthermore, the system determined the price type, specifically the closing type price, and the maturity key date and the associated maturity code by referring to the futures in the orthodoxy table. In this example, the key maturity date found in the orthodoxy table was May 14, and it corresponded to a specific contract maturity code.

The configuration setup, particularly the information obtained from the assembly formula, guided the system to utilize the orthodoxy table for this specific determination process.

After retrieving the necessary details from the orthodoxy table, the system returned to the DCS to search for the most current price entered that matched the given maturity code and maturity key date. In this case, it found a price of $10.10 within the DCS, which was then pulled into the contract as the provisional price.

Note

When daily prices aren’t available or not entered, the system employs a commodity curve to determine the price. This ensures that a price is still provided, even in cases where it can’t be directly sourced from the DCS table.

Let's explore the process of determining provisional pricing for the basis in our soybean purchase contract example. To begin, the basis price is determined by identifying the CPE formula key from the BRF+ decision table assigned to the highlighted table.

In essence, the basis for provisional price calculation refers back to the BRF+ system, specifically the table responsible for determining the formula assembly. This step ensures accurate and consistent determination of the basis price for the contract.

For our soybean purchase contract example, the decision table looked at the valuation point (D_0001_SB) on the contract and the condition record determined for basis (ACBS for provisional primary basis price and AMBS for market price) and found the CPE formula key, which is a CPE configuration object. As this is a primary basis component, it is then linked to a DCS and MIC.

For our soybean purchase contract example, after determining the valuation point, the basis ID must be determined.

The following highlighted BRF+ function is used:

In the context of our soybean purchase contract example, the decision table found the valuation point (D_0001_SB) specified in the contract. It determined the associated condition records for the primary basis, namely ACBS for the provisional primary basis price and AMBS for the market price. Through this evaluation, the system identified the corresponding basis ID, which is then incorporated into the contract. It's worth noting that our system maintains a one-to-one relationship between the valuation point and the basis ID.

In this case, the orthodoxy table is utilized to gather information such as the DCS and the key maturity date. The CPE configuration is responsible for deriving the price type, which, in this scenario, is a purchase bid (through configuration settings). Furthermore, the basis type is determined as 10A, representing the provisional price.

The basis ID is determined through the BRF+ table and, from there, the primary basis price is found in the basis price table (FDCS17B).

For our soybean purchase contract example, the primary basis market price is the same determination logic, with the exception that price type is 05 closing and basis type is 10B.

When the parties involved agree on the price and any relevant foreign exchange rates, if applicable, for each component (for example, futures, primary basis, secondary basis), a price fixation is performed in the contract. It is important to note that price fixations can occur at different points in time and do not necessarily require pricing all components simultaneously. The timing for price fixations is flexible, allowing for adjustments to be made at any stage.

To support this staggered approach to price fixations, as well as to support the requirements for risk reporting to reflect this staggered approach, SAP Agricultural Contract Management uses pricing status to reflect the status for each fixed pricing lot for a contract line item. The pricing status is going to be automatically determined in the contract when you're performing the price fixations. In addition, the ability to create multiple pricing lots per contract line item is supported and quite common in the industry.

When it comes to price fixation, you can find this process in the Conditions tab of the contract, specifically under the SAP Agricultural Contract Management pricing view in SAP GUI. Alternatively, you have the option to use the maintain pricing SAP Fiori app for performing price fixations.

To determine whether any pricing has been done, you can check for price fixations or pricing lots within the view. This section provides clear visibility into whether any pricing activities have been conducted or not. In the current view, it is evident that no pricing has been carried out thus far.

A popup screen is presented. The fields available for input will vary based on which pricing approach was determined. In this example, the pricing approach determined was FB (componentized) and therefore both futures and basis are presented for entry. The pricing quantity also must be indicated regardless of which pricing approach is determined.

There are three options available for entering a price component:

1. Manual entry
2. Fetch price (basis requires REIF services)
3. Price with CDOTE - ability to price futures by raising a fill request on the treasury side to purchase or sell futures

When the price is entered, the pricing status will be determined automatically based on the components entered. In the provided example, multiple pricing lots were fixed with different pricing statuses. For instance:

• In one case, a futures and basis component were entered for a certain number of bushels, resulting in a status of "flat" being determined.
• In another case, only the futures price was entered for a certain number of bushels, indicating that no basis was established.
• Similarly, for a different quantity of bushels, only the basis price was entered, resulting in no futures being established.
• Lastly, a certain quantity of bushels was left reserved with no price established. It's important to note that leaving a quantity without pricing is optional.

These pricing statuses are utilized in reports, such as position reports by type, as well as in mark-to-market and P&L reports. It's common in the agricultural industry for companies to price only a portion of the line item, gradually pricing as they go. This leads to different pricing statuses for different amounts within the contract. Unlike other industries where the entire contract line item is typically priced at once, in agriculture, having partial pricing statuses is common.

Managing these pricing statuses is crucial for subsequent application and settlement processes, which will be discussed later. It's important to understand that this practice is prevalent and considered the norm in the agricultural industry.

It is common for traders to mark the intended price type during the creation of a contract. This is used for reporting purposes for comparing intended price type against the pricing statuses of the price fixations for the contract. There is no SAP Agricultural Contract Management functionality behind this field. There is a configuration table associated with this field.

As each pricing lot is fixed behind the scenes, a pricing aspect is created. Pricing aspects can have up to five conditions configured for them. They can function as a summary of the CPE conditions. The pricing aspect is critical for the use of the GTM assignment framework. There are two primary condition records configured for the pricing aspect:

• One is for futures (FP01)
• One is for basis (BP01)

The prices are automatically copied into these condition records as pricing fixations are saved. If there is more than one basis component, they are added together. When loads are applied to contracts, the pricing lots are consumed by default logic (FLAT, NBE, NFE, NPE). BRF+ tables can be used to change the consumption method. Pricing lot consumption is triggered again during the settlement process, which means that the pricing lot consumed could be different than was consumed during application. Pricing aspects can be seen in the Commodity Items tab of the contract.

Although we have various pricing lots based on the settlement process, it's important to understand the underlying purpose of using these condition types. They serve as additional pricing aspects to support the settlement process.

Now, when it comes to consumption during settlement, determining which pricing lot to use becomes crucial. To address this, we provide a default logic for consumption. The default logic prioritizes consuming the flat pricing lot first, followed by NBE, NFE, and NPE. The goal is to finalize pricing as much as possible. However, it's important to note that if a contract is partially priced, it cannot be completely finalized until the necessary amount is priced for settlement.

After contract creation, instead of referring to the condition records, we rely on the pricing fixations during the application phase. These pricing lots are consumed accordingly. The ultimate expectation is to have everything become flat, enabling correct settlement as per the agreed contract quantity. Provisional invoicing may occur until that point, and it's possible to have multiple layers of provisional invoicing.

Additionally, pricing lots can have quantities above or below the contract quantity due to overfills or underfills. In such cases, we may need to create additional pricing lots or cancel existing ones to accommodate the changes. The complexity arises from the unique requirements of the agricultural industry, which we need to cater to for accurate settlement.

Furthermore, it's worth noting that there's a scenario where the Load Data Capture (LDC) is searching for a contract. In this case, if the contract is unknown, application instructions can be provided to instruct the system to search for the relevant contract. To determine how to consume the pricing lots in this scenario, an additional BRF+ table or logic is used, which may differ from the default consumption logic explained earlier.