Understanding the Basics of Contract Types in SAP Agricultural Contract Management

Objective

After completing this lesson, you will be able to understand the basics of contract types in SAP Agricultural Contract Management

Types of Contracts

SAP Agricultural Contract Management supports the following contract types:

  • Third-Party Purchase: An agreement between a grain buyer and a seller, not of the same purchasing entity. In this context, the third party typically refers to an independent farmer or producer who is selling their grain to a grain buyer or an intermediary entity.
  • Third-Party Sales: An agreement between a grain seller and a buyer, not of the same selling entity. In this context, the third party typically refers to an independent buyer or an entity that is purchasing grain from the grain seller.
  • Intra-company: Contracts created between two plants or locations of the same company.
  • Inter-company: Contracts created between two different organizational units with different company codes.

    There is no third-party vendor or supplier involvement in inter-company or intra-company scenarios. In a single transaction, contracts are created for both the purchasing side and the sales side.

    The "Lead Contract" is the side for which the contract is created. The contract for the other side is called a "Mirror Contract". It is created in the background by copying all the data from the lead contract through standard output processing.

  • Vehicle: The number of vehicles per contract item, with planned quantity per vehicle being captured. Only entire vehicles can be priced instead of just quantity (including CDOTE supported pricing).
  • Spot Purchase: Refers to an agreement made for the immediate purchase and sale of a specific quantity of grain at the prevailing market rate on the day of the transaction. In this scenario, the contract is initiated without any pre-existing contractual arrangement between the parties involved.

    SAP Agricultural Contract Management supports three types of Spot Purchase contract:

    • Spot Immediate: Allows for the creation of immediate spot contracts for incoming loads in case the vendor does not have open contractual agreements. The price can either be fetched or manually entered.
    • Spot End of Day: Allows for spot requests to be marked for end-of-day processing. The spot monitor will create contract(s) for those spot requests and price them automatically with the defined end-of-day price.
    • Spot Accumulate to Own: Allows for the accumulation of loads into a single contract for pricing when all loads have been received.
  • Storage Agreement: An agreement for a buyer purchasing grain from a storage facility or elevator where multiple sources of grain are mixed or stored together. In this type of contract, the grain being purchased is not individually segregated but is part of a larger pool of grain from various suppliers or sources.
  • Firm Bid Offers: A dedicated non-position or mark-to-market relevant contract type that allows for target prices and pricing instructions to be specified in the document and tools to send them to external monitoring systems. Conversion from offers into contracts is supported from the worklist or via provided APIs.
  • Quotes: Allows for a flat price to be specified for a commodity. They are valid from their creation until the expiration date, which is entered in the quote header. The quotes are associated with a specific delivery period and, when converted, the contract's delivery period must fall within the quote's delivery period.
  • Templates: Pre-built templates with copy-with-reference functionality to support fast and easy contract entry.

Contract Details

A commodity contract is a document that represents an agreement between a buyer and a seller of a commodity. It contains all of the terms and conditions that have been agreed between the two parties.

Contract capture is the first step in the agricultural commodity contract process. The terms and conditions that govern the execution of the remaining downstream processes are defined during contract capture, such as the following:

  • call-off
  • load data capture
  • contract application
  • contract settlement
  • contract closure

The contract details captured include the following:

  • counterparty
  • contract period
  • commodity
  • quality terms
  • tolerance terms

Structure

A commodity contract is structured as follows:

  • Contract Header: The contract header contains details that are relevant to the entire contract, including the trade counterparty, the external number, and the payment terms.
  • Line Item: A contract line item contains information about the commodity, such as the plant, quantity, and order unit.

    The following details are also stored at line-item level:

    • Acceptable quality terms and associated pricing adjustments
    • Tolerances for overfills and underfills
    • Additional logistics options
    • Associated related trades and so on

Contract Header

This header marks the beginning of the contract capture process, where crucial details are established to initiate a contract.

These details include the following:

  1. Counterparty: The involved party with whom the contract will be entered into, whether it is a supplier, customer, or any other relevant entity.
  2. Payment Terms: The agreed-upon terms and conditions regarding payment, such as payment due date, payment method, and currency.
  3. Incoterm and Incoterm Location: The specific international trade terms that define the responsibilities and costs between the buyer and seller, along with the location where the goods will be delivered.
  4. Document Currency: The currency in which the contract will be conducted and recorded, ensuring clarity in financial transactions.

Document Status

In SAP Agricultural Contract Management, the contract status is now aligned with the standard Global Trade Management (GTM) contract statuses, which determine specific contract actions:

  1. Allowed to be Planned: This status indicates that the contract is eligible for planning activities.
  2. Included in Position: Contracts in this status can be included in position reporting.
  3. Completed: Contracts in this status are finalized and completed.

By default, a contract is initially saved in Draft status, allowing for further modifications and adjustments. However, once a contract is set to the Call-Off relevant status, it becomes a finalized contract, and it cannot be changed back to Draft status. This ensures that completed contracts remain consistent and maintain their final state throughout the contract management process.

Contract Snapshots

Contract snapshots are specific data collected when saving an SAP Agricultural Contract Management contract. The contract must be in the appropriate status to support output. This data is timestamped to allow for easy identification of changes over time and allows for the identification of changes that require a signature.

Contract snapshots allow for the following:

  • Manage and assign contract attributes, which will govern the creation of a new contract snapshot.
  • Monitor different snapshot versions directly in contract maintenance transactions.
  • Manage contract attributes that will identify the counterparty signature relevancy and signature status, such as Signature sent to counterparty or Signature received.
  • Leverage functionality that can facilitate custom form creations, such as contract amendments.

    An amendment occurs when a change is made to at least one amendment-relevant field. When amendments are made, the contract status goes to awaiting amendment approval and blocks call-off, application, and settlement until the amendment is approved.

Fees

There is a provision to include fees at the contract header level, which are subsequently considered during the settlement process. These fees are incorporated into the overall Settlement Amount.

Fees can be added in two ways, depending on the configuration:

  • Manual Entry
  • Automatic Defaulting from BRF+ Rules

When entering a contract, users have the option to manually include the fee amount at the contract header level. Alternatively, if the BRF+ rules are configured to do so, the fee can be automatically populated based on predefined criteria.

Trade Office

There is an option to define a trade office at the contract header level. This feature is particularly beneficial as not all grain elevators or plants may have an individual office, and sometimes multiple elevators or plants are licensed together. Regulatory authorities review credit sale sequences based on trading offices, which are physical locations with specific attributes, including addresses, phone numbers, fax numbers, and more.

Each trading office is associated with one and only one legal entity, ensuring clarity in organizational structure. When generating confirmation documents, the address of the trading office is printed, providing a clear reference for all parties involved in the contract.

Trader

Trader

Original Responsible TraderResponsible/Amending Trader
This field is used to capture the Trader ID of the person who first creates the contract. When it is entered, the Original Trader ID remains unchanged and cannot be edited throughout the contract's entire lifespan.This field is meant to record the Trader ID of the user responsible for making any modifications to the contract. Initially, it will be the same as the Original Trader ID. However, as the contract evolves, different traders may be involved in making subsequent changes, and each amendment must be documented to ensure a complete and accurate record for tracking and auditing purposes.

Contract Line

Essential information about each contract line item is recorded in the item overview. A contract can consist of multiple line items, each having distinct materials, plants, or quantities. The following details are established and captured for each line item:

  • Material
  • Plant
  • Quantity
  • Unit of Measurement

Commodity Items

A commodity item is an extension of the contract line item, and it contains additional information that is specifically required for the management of an agricultural commodity contract. This information includes the delivery period of the contract.

  • In SAP Agricultural Contract Management, there is only one commodity line item for each line item.
  • The commodity line item quantity is always same as line item quantity.

In the Commodity Items tab of a commodity contract, you can display the following information:

  • Quantities: You can display a breakdown of the quantity for each quantity type (for example, Consumed Quantity, Available to Call-off Quantity, Underfill Quantity, and so on).
  • Pricing Aspects: You can display the futures and basis condition amounts and values.
  • Assignments: You can display assignment partners, such as an order or application document, along with the assigned quantities.
  • Document Flow: You can display a detailed trading solution document flow, which lists all of the documents for the contract in a hierarchy. The information displayed includes the document type and number, the ID of the user who created the document, the creation date, and the document status.

Tolerances

In the Tolerances tab of a commodity item, you can assign a tolerance schedule in the commodity contract. The details of the tolerance schedule are automatically copied from the master data into the contract. If needed, you have the flexibility to modify these details.

Additionally, you must specify the tolerance type, which plays a crucial role in determining how and when the tolerance schedule rules are applied to the contract. You have three options from which to choose:

  1. Per Delivery: This option means that the tolerance schedule rules are applicable to the quantity delivered in each load. If you select this tolerance type, you will need to enter the expected quantity for each load, enabling the system to evaluate the actual load quantity against the expected load quantity.
  2. Per Delivery Period: With this option, the tolerance schedule rules apply to the total quantity delivered within a specific delivery period.
  3. Per Contract: Here, the tolerance schedule rules apply to all the contract line items associated with a particular commodity, taking into account the entire contract.

Contract DPQS

In the DPQS tab of a commodity item, you can assign a DPQS to a commodity contract. The system also provides the following options:

  • Timing: DPQS timing defines how the system selects the version of the DPQS. For example, you might write a purchase contract in April 2022 for October 2023. You may not know the details of the standard schedule for the 2023 crop year yet, so you would pick the schedule name but set timing to At Discharge. By doing so, when the producer starts delivering against the contract, the version of the contract that is valid will be used.
  • Schedule at Unload Location: If you select the Schdl at Unload Loc (Schedule at Unload Location) checkbox, the system uses the default DPQS for the discharge location, and you do not need to enter a schedule name. For example, this option may be used in cases where the contract has more than one discharge location. The system determines the relevant schedule for the discharge location by using the TSW location assigned to the value schedule. Schedule at unload location is not valid for third-party sales scenarios.
  • Override Base Schedule: The details of the selected value schedule are displayed on the DPQS tab. By default, this information is display only. However, if you select the Override checkbox, you can choose to omit characteristics or change the value ranges for characteristics. However, you cannot add new characteristics.

Contract Optionalities

In addition to defining discounts or premiums, you have the option to include additional logistics choices known as optionalities. These optionalities allow you to specify premiums or discounts for various logistics scenarios. For instance, you can set a premium for a particular discharge location or a specific mode of transport.

To facilitate this, you have the flexibility to set default values for attributes like Mode of Transport, Means of Transport, Crop Season ID, and Source Location. When the default values are established, you can then further customize the optionalities by entering the desired details in the Additional Optionality Values screen area.

Each optionality is defined by providing the following information:

  1. Optionality Category
  2. Value Type
  3. Option Value
  4. Premium or Discount Details

This setup allows you to tailor the contract's pricing and logistics based on specific attributes, offering a versatile contract management approach.

Contract Cancellation

During the duration of a contract, it is possible to initiate a cancellation process to close all or a portion of the remaining open quantity on the contract. Commodity contracts often involve large quantities that are not entirely filled, making cancellations necessary for various reasons, such as underfills, washouts, or mutually agreed reductions in the contract quantity.

When you are entering a cancellation, the system conducts validation checks to ensure accuracy before saving the cancellation. These validations include verifying the availability of the open quantity and checking the contract's current call-offs and prepayments to ensure the specified cancellation quantity is viable.

In the case of intercompany or intracompany contracts, if a quantity is canceled, the system automatically generates the corresponding cancellation in the mirrored contract.

Although there is no related goods movement for the canceled quantity, it must still be settled. Canceled quantities may be settled at a different price than the established contract price, and a cancellation fee may also apply.

Valuation Point

Valuation points play a crucial role in automatically determining the pricing approach for each line item in a commodity contract. To achieve this, you can define a valuation point on the Valuation Data tab within the commodity contract. However, before utilizing them, you need to set up these valuation points in the master data. It's worth noting that the valuation point field is optional.

Whenever there is a change in the valuation point, the system will automatically reevaluate the pricing formula accordingly. Therefore, it allows for flexibility and adaptability based on the specific valuation points chosen.

When a fixation has been established in the contract, it is essential to bear in mind that the valuation point cannot be modified anymore. Therefore, it is crucial to carefully consider and finalize the valuation point before creating the fixation in the contract.

Pricing Tab

The Pricing tab offers an SAP Agricultural Contract Management-specific view in addition to the standard Commodity Pricing Engine (CPE) views, enabling you to set and visualize price fixations on one screen, and manage pricing operations efficiently.

Related Trades

A commodity contract often has connections with other contracts, serving various purposes, such as pricing (for example futures contracts), intercompany or intracompany trades, or washouts. This functionality empowers users to access and manage these related trades associated with a particular contract, allowing for easy viewing, addition, or removal of such connections.

When you initiate an intercompany or intracompany contract, the system automatically generates a corresponding mirror contract to maintain the symmetry of the transaction. For instance, when a purchase contract is created, the system simultaneously generates the corresponding sales contract, and vice versa. These interconnected contracts are displayed on the Related Trades tab, providing users with comprehensive insights into the entire network of connected contracts for better coordination and tracking.

Credit Sales/Audit Sequence Information

Audit Sequence

Licensed companies must provide external auditors and regulators with proof of contracts being created in a sequential order, chronologically and without gaps. The proof of contracts being created in a sequential, chronological and complete inclusive order is by an audit number (sequence) assignment. Regulators may require different groupings of contracts or audit numbers which will require multiple pools and sequences. Due to the dynamic nature of contracts, and the need to reallocate responsibility, change terms, or change pricing statuses, the number sequence assignments must accommodate these contracts moving between number sequences over their life span.

Companies maintain audit number sequence pools using a pre-defined set of attributes and the system must determine automatically which audit number pool will be used.

Log in to track your progress & complete quizzes