Providing an Overview of Master Data in SAP Agricultural Contract Management

Understanding SAP Agricultural Contract Management master data is an important topic and this module is crafted to provide a high-level overview of some of the essential configurations needed in SAP Agricultural Contract Management. We will be discussing discount and premium quality schedules, tolerance schedules, optionality, and standard master data, such as materials and business partners. However, there are other master data areas, such as pricing, fee master data, and production services, that we will only cover at a high level in this module and more in depth in later training.

Let's begin by examining the standard master data utilized in SAP Agricultural Contract Management to ensure accurate and efficient operations. The system requires the setup of business partners to facilitate transactions between various entities within the agricultural industry.

The Discounts, Premiums, Quality Schedule (DPQS), an essential component of SAP Agricultural Contract Management, plays a critical role in calculating volume and value adjustments using the captured weight and quality characteristics of each load.

The DPQS consists of two parts: volume and value. The volume schedule, created initially, determines volume adjustments by flagging characteristics in the schedule to calculate adjustments based on gross weight or net weight. For example, moisture content affects quantity adjustments as wet grains require drying, resulting in weight loss before further processing.

The value schedule, the second part, is utilized during settlement to calculate discounts and premiums based on quality. For instance, in the case of wheat, a default protein percentage can be set. If the actual protein content exceeds the default, an additional premium may be applied, while a lower protein content may result in a discount. It's worth noting that the characteristics listed in the volume and value schedules do not have to be identical, as protein content impacts value but not quantity.

The DPQS is applied and used at various stages throughout the agricultural contract management process. During contract capture, it can be assigned specifically to a contract or assigned generically based on plant location. When a load is received, the volume schedule is used to determine quantity adjustments, and the adjusted quantity is then consumed against the contract. The DPQS schedule is also utilized during settlement, where both the volume and value schedules are used. The Logistically Adjusted Quantity (LAQ), which includes the applied quantity from the volume schedule, is carried into the application document and used for settlement. The value schedule handles discounts and premiums to adjust the value accordingly.

The DPQS can accommodate time-dependent changes, such as varying discount percentages or rates based on factors like seasonality. Multiple versions of the schedule with different validity dates can be created to incorporate these changes effectively.

Overall, the DPQS schedule provides a structured framework for managing discounts, premiums, and quality adjustments throughout the agricultural contract management process. It ensures accurate calculations of volume and value, facilitating efficient settlement operations. By leveraging actual weight and quality characteristics, the DPQS enables effective management of diverse agricultural contracts.

In terms of specific usage, the DPQS on the contract is applied during the application and settlement of all loads against the contract. Additionally, the material schedule defined by the DPQS lists all allowable materials that can be applied to the contract. During application, the DPQS is used to adjust the load weight, often referred to as "shrink," as impurities such as moisture are typically removed, reducing the load's weight. Furthermore, the DPQS is checked during application to ensure that the load falls within acceptable characteristic value ranges. During settlement, the DPQS is checked to determine premium or discount information based on the load's characteristic values.

During the setup of the volume schedule, you assign it a name that corresponds to a specific material, company code, and regulator, which represents the regulatory agency involved.

For instance, let's consider an example where we manage moisture content. The volume schedule allows for version management, as described earlier, enabling you to handle changes in rates based on future dates or other factors. By defining date ranges, you can effectively control these adjustments.

To configure the volume schedule, you input the relevant characteristics and specify the calculation method. You can determine whether the adjustment to the volume will increase or decrease, among other options.

Regarding regulatory agencies, such as the USDA, they provide published values that can be utilized. Typically, these values come into play when there are general issues like a particularly wet harvest season, resulting in elevated moisture levels. The regulatory agencies weigh in on such matters.

Therefore, the published values from the regulatory agency can be accessed and incorporated into the system to ensure accurate volume adjustments

Now let's discuss the base net calculation, which is an important concept on the volume side. It involves creating a dependency among multiple characteristics, resulting in a cascading effect that impacts future calculations. For example, let's consider the characteristics of moisture, heat damage, and contrasting classes.

To implement the base net calculation, you need to specify the sequence in which these characteristics should be considered since they have a cascading effect. First, you would calculate the moisture adjustment, using it as the base for subsequent calculations.

Then, you would utilize the moisture adjustment as the foundation for calculating the heat damage kernels.

Finally, when inputting the characteristics for contrasting classes, you would incorporate the cumulative impact of both the moisture adjustment and the heat damage into the calculation. This cumulative effect ensures accurate adjustments.

Moreover, you can indicate which characteristics you want to apply the base net calculation to. In this example, for damaged kernels, the base net is used, meaning it utilizes the cumulative effect of the flagged characteristics.

By utilizing the base net calculation, you can ensure accurate and comprehensive adjustments based on the cascading impact of relevant characteristics for each specific calculation.

Let's have a closer look at the table above:

Arrowed base net quantity will be used for calculation of Next base net.

Normal progressive calculation: Calculation of rate will be changed according to volume calculation rule. Final Adjusted Qty is 931.78 LB.

This characteristic will consume adjusted quantity of final Base net indicator. Here 3rd char.

It's important to note that the volume schedule needs to be completed, released, and ready for use as a prerequisite before creating the value schedule. The volume schedule name should be attached here as a required assignment. Similar to the volume schedule, we also have areas to specify the material, company code, and regulatory agency. The value schedule also utilizes versioning to further differentiate the data.

In the value schedule, you can indicate the currency being used, such as U.S. dollars or EUR. Multiple calculation methods are available. Typically, ranges are inputted, often in percentage form. Additionally, characteristics can be set as yes or no.

Actions during the application process, such as load acceptance, rejection, or negotiation, can be specified. If negotiation is chosen, settlement will require reaching an agreement with the counterparty on the applicable rate when it meets a specific level.

To capture these characteristics, we leverage SAP's functionality for characteristics and classes. Characteristics are set up for various attributes like moisture for different materials. They are then grouped into classes based on commodity type, such as soybeans, and attached to the material master.

Regarding currency, the settlement currency is defined based on the currency assigned to the contract. If the contract specifies U.S. dollars, settlement and invoices will be in U.S. dollars. It's possible to have contracts in different currencies, allowing for flexibility in unsettled contracts.

We can be very specific when we are assigning the DPQS. If there is a schedule that is specific to a particular business partner, we can assign it directly to the contract. However, if the schedule is generic and applies to all business partners, we can assign it to a location.

In this context, a location refers to a master data object, typically a plant or elevator.

Now, when it comes to commingled stock, we have additional business rules in place. These rules allow us to assign a volume schedule that reflects the quality of the load in elevator A, resulting in additional shrink for the commingled stock. This specific functionality is applicable only to commingled stock.

The tolerance schedule on a Global Trade Management (GTM) contract should not be confused with the delivery tolerances on a purchase or sales order.

The tolerance schedule on a GTM contract governs the allowable quantity that can be applied to a contract through one or more application documents. The type of tolerance schedule (contract, delivery period, per delivery) determines how the allowable overfill or underfill quantity is calculated.

On the other hand, the delivery tolerance on a purchase or sales order is a standard practice in logistics execution. When creating a delivery for a purchase or sales order using Load Data Capture (LDC), it's important to consider that commodity quantities are rarely exact and may deviate from the planned quantity. Hence, a delivery tolerance must be taken into account.

The specific tolerances (over/under delivery) on purchase or sales orders are usually determined based on business requirements.

Now, let's delve into the topic of tolerances within the GTM contract context. The current schedule assigned to a contract is a mandatory requirement, and failure to assign it will result in a validation error.

Given that we deal with weight-based products, tolerances are necessary due to the inherent variability in quantities during procurement or sales. It's crucial to understand that the tolerance schedule is distinct from the delivery tolerances specified in purchase orders and sales orders. The tolerance schedule specifically focuses on how the application of products aligns with the contract and how any deviations from the expected quantity should be handled. It does not pertain to logistics, but instead concentrates on the application of the contract.

When assigning the tolerance schedule, it is essential to create it as master data and then assign it to the contract. The GUI tip transaction provides a dedicated tab for managing the tolerance schedule, and for users of the app, there is a specific section for this purpose.

During the assignment of the schedule, you must specify when the tolerance evaluation should occur. There are three options available:

• Evaluating based on the last load, which applies to all line items of the contract and accumulates the effect.
• Evaluating based on the delivery period, considering each line item individually and performing the evaluation when the last load is received for that specific line item.
• Evaluating on a per-delivery basis, where you define the allowable tolerance for each load. If the delivery method is utilized, it is necessary to provide the mean value per delivery to determine the tolerances for quantities exceeding or falling below this mean.

The tolerance schedule allows you to indicate how overfills and underfills should be handled. You can assign a percentage range, such as zero to % for overfills and zero to % for underfills. Alternatively, you can assign a specific quantity, allowing, for example, up to bushels for overfills and up to bushels for underfills. It is also possible to use a combination of both approaches.

Considering the timing of the evaluation is important. While overfills are automatically managed by the system, underfills require explicit instruction. In the manual application work center, you can set the underfill indicator to trigger the evaluation for underfills. However, if the evaluation is performed on a per-delivery basis, both overfills and underfills are automatically handled by the system.

These are the key aspects to understand regarding tolerances within the GTM contract framework.

Optionalities are a way to extend specific contract terms and allow for more possible values. They can be used to apply additional premiums or discounts based on certain contract terms. For example, let's consider a contract to buy corn from farmer Jim. The contract specifies that the commodity must be delivered to plant A. However, an optionality is established to allow delivery to plant B if requested by the company or farmer Jim. If farmer Jim delivers to plant B, he will receive an additional payment to cover his transportation costs.

During the application process, loads can be applied to a contract if all the contract terms match exactly. Optionality can be used to extend specific contract terms and allow for more than one possible value. The decision to apply premiums or discounts is optional and not required.

In Brazil, for instance, there may be cases where a grower can deliver to two different plants, but the trading company does not pay a fee for the second plant. This shows that applying premiums or discounts based on the discharge location is not mandatory.

In summary, optionalities provide flexibility in contract terms and can be used to incentivize desired behaviors or control what is allowed in a contract. The evaluation of optionality occurs during the call-off and settlement processes. There are three types of optionality: explicit, implicit, and any, each with different requirements and rules for application.

Explicit optionality requires a quantity declaration before application, while Implicit optionality does not require a call-off but requires matching the defined optionality values for the load. Any optionality allows the contract to be applied to any load, regardless of the defined values. Settlement calculations may consider optionality values for applying premiums or discounts.

Pricing in SAP Agricultural Contract Management is a highly complex process and will require a special deep dive for training. The purpose of this module is to provide a high-level understanding to provide context for understanding the subsequent training modules.

The pricing requirements for Agricultural Companies is driven based on whether or not the commodity is priced based on a futures market or not. Commodities that are futures driven are called "hedgeable", such as corn, wheat, soybeans, and so on. Commodities that are not futures driven are called "non-hedgeable", such as feed wheat, soybean hull, potatoes, amber durum, and so on.

Pricing needs to be flexible to allow the breakdown of the price into multiple components, particularly for "hedgeable" commodities. For "hedgeable", Agricultural companies breakdown the price into a "Futures" component and at least one or more "Basis" component(s). "Non-hedgeable" typically only needs one price component, one "Basis" component.

Regardless of which type, the pricing needs to be flexible in terms of when and how the commodity is priced in the contract. It is not unusual in this industry to perform logistics prior to pricing all price components as well as invoicing based on provisional or partial pricing. In addition to this, there is a need to be able to price multiple times against the same contract line item, hence there is a requirement to support multiple pricing lots per contract line item.

The FX (Foreign Exchange) requirement also adds another layer of complexity in that if the contract currency is different from the futures market currency, then there is a need to capture provisional exchange rates as well as have the ability to "fix" the exchange rate on the pricing lot based on the agreement with the counterparty at any point in time. Furthermore, there needs to be an ability to provisionally invoice based on provisional exchange rate as well as final invoice based on "fixed" exchange rate.

To support these requirements, SAP Agricultural Contract Management uses the Commodity Pricing Engine (CPE) to price both types of commodities. The futures price is defined through CPE configuration, BRF+ rules and Pricing Tables.

• Material Master: Stores the materials used in SAP Agricultural Contract Management contracts.
• Physical Commodity: Details for the commodity that is specified in the contract.
• Valuation Point: A Valuation Point is a unique market location for which a unique market norm can be defined in market curve for a set of products and/or physical locations.
• DCS: Derivative Contract Specification (DCS) is defined from the Futures market contract specifications.

  For a good example of the types of data that go into a DCS table. you can visit: KC HRW Wheat Futures Contract Specs - CME Group

• Basis ID: For Basis valuations / differences occurring frequently, Agricultural companies define 'BasisIds' and capture typical/normal values in tables (like by commodity, location, delivery period) and subsequently use these for Mark-to-Market and PnL analyses on the Basis specifically.
• MIC: Market Indicator Code maintained for pricing procedures.
• Orthodoxy: A hard wired "custom defined" table can be used to define market norms (maturity key dates of a certain index) per country/profit center combination and delivery period (typically a calendar month).

Agricultural companies provide a wide variety of services rendered throughout the commodity contracting, logistics execution, inventory management, and financial settlement supply chain lifecycle. They charge and collect fees for these services.

Integrating services and associated fees within supply chain processes enables reliable, efficient, and effective collection of service revenue, and allows for the following:

• To maintain six different fee types
• To utilize both manual addition and auto determination of fees in various logistic documents
• To collect fees in the commodity settlement process
• To generate separate invoices
• To generate accrual

Fees can be attached to every logistical document during the lifecycle of a deal, but before final settlement.

Attaching fees can happen in two ways:

• Manual: entered by user during a transaction
• Derived Automatically: through flexible BRF rules

Production services are necessary to reflect physical and book inventory impacting events. They occur within soft commodity storage facilities due to operations performed for conditioning the grain to maintain or improve quality.

They also facilitate the adjustment of the inventory based on physical measurements in the bins.

The production services framework must include the following:

• Master data setup
• A processing work center for executing operations
• Integration into inventory position and mark-to-market reporting

Production service master data defines which service is being executed (that is, drying, blending, and so on) and which goods movement types are being leveraged to execute the appropriate postings:

• Condition and Transfer: Transferring a material to another storage location and then performing operations on it, such as reducing moisture content by drying, cleaning, and so on.
• Condition in Place: Performing operations on a material in the existing storage location to improve the characteristics. For example, aeration in place, fumigation in place, and so on.
• Condition and Transfer with Byproduct: Transferring a material to another storage location and then producing a single by-product during the operation.
• Quantity Adjust - Measure Up: Measuring stock at bin level and then adjusting the physical inventory.
• Quantity Adjust - Weigh Up: Measuring the actual stock at bin level and then adjusting the physical inventory and the book inventory
• Material to Material Transfer: Determining a target material based on the input material and input characteristics.
• Material to Material - Multiple Materials: Material-to-material transfer with multiple inputs and one output to support services like blending operations.
• Process and Convert: Material-to-material transfer with one input and multiple outputs to support services like crush operations.