During contractual negotiations, an agricultural company must reach an agreement with their counterparty regarding transportation responsibilities. Additionally, there needs to be a clear understanding of when the transfer of ownership will occur. These decisions will have implications for downstream document generation and goods movements.
SAP Agricultural Contract Management supports three possible methods of title transfer:
- Title Transfer at Origin (TTO): This refers to the transfer of ownership at the point of origin.
- Title Transfer in Transit (TTI): This is only applicable for plant-to-plant stock transfers for Intra/Inter - company scenarios. It is not applicable for third party contracts.
- Title Transfer at Destination (TTD): Ownership is transferred upon reaching the designated destination.
Origin
Stock ownership is transferred at Origin. As a result, the stock becomes responsibility of the receiving party from origin itself. Title transfer will occur at the Load event.
Destination
Stock ownership is transferred at Destination. So stock is the obligation of the supplying party until it arrives at destination. Title transfer will occur at the Unload event.
There is a process in inventory management called Valuated Stock in Transit, which was added during the early stages of SAP Agricultural Contract Management. This functionality was developed to address the needs of SAP Agricultural Contract Management and other industries that required expanded capabilities for managing in-transit inventory stock.
Valuated Stock in Transit is utilized for purchase scenarios where title transfer occurs at origin, and for sales scenarios where title transfer occurs at destination. It plays a role in the sales process and involves managing stock in transit.
The incoterm parity, which determines the title transfer, is valid against the call-off order process. Validations have been implemented to ensure that the title transfer in the order matches the incoterm specified in the contract, or that the appropriate optionality is used.
During the load and unload events within the load data capture business process, the actual transfer of ownership takes place. In the case of title transfer at origin, stock ownership is transferred at the origin, making the receiving party responsible. The title transfer occurs during the load event. Conversely, for title transfer at destination, stock ownership is transferred to the destination, and the supplying party remains responsible until the stock arrives at the destination. The title transfer occurs during the unload event.
Note
The incoterm/parity, which determines the title transfer, is validated against the call-off order (purchase/sale).The transfer itself occurs within the Load Data Capture business process during Load and Unload events.
Incoterms
- The title transfer terms define the event types to be used within the business scenario. The previous examples illustrate the event types used for third party purchase and sales, and inter/intra company.
- Title transfer may occur at origin, at destination, or at some point in transit. If the transfer occurs in transit, additional steps are required to record the specific time at which title transfer occurs.
- For example, TTO (FOB incoterms) require the load event type for the load data capture process and the unload event type when receiving into unrestricted stock.
- Current functionality for title transfer in SAP Agricultural Contract Management uses the combination of parity/incoterm and title transfer type: Incoterm is defined in the contract.
The incoterms used to determine title transfer are contained in a configuration table in SAP Agricultural Contract Management. For example, if the contract specifies TTO, it indicates that a load event is required for capturing load data and an unload event is needed when receiving the stock into unrestricted stock.
Similarly, for a sales scenario with TTD, both load and unload events are necessary.
The incoterm, which is defined in the contract, determines the title transfer. It defaults from the counterparty's information in the business partner, but it can be overridden if necessary. These title transfer details are crucial not only for load and unload events but also for automated document generation.
It's important to consider the impact of title transfer and incoterms downstream, as it influences document generation and the specific events required. Paying attention to these details ensures accurate processing and documentation.
Procurement - Title Transfer Destination
Let's consider some examples related to procurement. If the title transfer occurs at the destination, it means that the contract specifies an incoterm linked to the destination. In this case, for procurement, only an unload event is needed. The contract may specify a quantity, such as 1,000 bushels, but the actual unload event quantity may not match exactly. It can be entered as an approximate value, such as "about 1,000 bushels."
Unplanned
If you're not using a purchase order with a call-off or a nomination, the process is treated as unplanned. This means that the purchase order will be created automatically at the time of load data capture. The contract will be for the actual weight, in this case, 1,000 bushels, and an application will be created based on the DPQS schedule or volume schedule attached to the contract or specified as a default based on the plant location. The purchase order is generated automatically through the load data capture process, not manually created by the user.
If there is no nomination in place, the quantity from the load data capture is used to create the documents downstream, such as the purchase order, delivery application, and goods movements. The information from the contract is copied to the purchase order. In this example, the purchase order is based on the actual quantity. It will also consume the contract based on the defined volume schedule. If a Logistically Adjusted Quantity (LAQ) is specified, it will be used for consumption against the contract. Further details on this will be discussed later.
Regarding governing weight in contract creation, it relates to settlement and the update status of the application document. If you choose to settle or finalize based on origin weights and analysis, it can be done that way. In such cases, the picture will be different, and both the load event and unload event will be required to capture the origin weights and analysis. The unload event is still needed to complete the title transfer.
In the scenario where you settle based on origin weights, the load event creates the order and inbound delivery, but no goods receipt is posted since settlement needs to be done before the stock arrives. When the second load event occurs, the goods movement can be posted, as it is a destination-based title transfer or TTD.
There are various possible variations and complexities involved, but the configuration tables and solution logic handle different scenarios.
Planned
In a planned scenario where the title transfer occurs at the destination, you create a purchase order with a call-off. Let's assume the quantity specified in the purchase order matches the contract quantity exactly. However, when the delivery arrives, you will need to have an unload event. The actual quantity may not be exactly the same, so you will enter an approximate value. The application document will be created accordingly, and adjustments may be made based on volume and analysis characteristics.
In this example, there is a remaining quantity of bushels on the purchase order that needs to be handled. To address this, there is a process called Snip, which can be executed as a transaction or set up as a batch job. It will close out the purchase order for the leftover quantity and potentially free up quantities for future call-offs or deliveries. For instance, if the contract quantity was bushels, it would free up the remaining five bushels for a future transaction.
If the title transfer occurs at the origin in a procurement scenario, you will have both a load event and an unload event. Let's say the load event is for bushels, then the purchase order will be automatically created for the actual quantity of bushels. The application document will also be generated, and the stock will visible as inbound stock in transit.
When the stock is received, say for bushels (as weights may vary), the purchase order will be updated to reflect the receipt of bushels. The application document will also be adjusted accordingly, potentially considering analysis characteristics. The stock will be moved from inbound stock in transit to on hand.
In the planned scenario, where the purchase order is created in advance with a call-off, you will still have both a load and unload event. The timing of the purchase order creation is the only difference. The subsequent processes and adjustments remain the same as described above.
Spot and Commingled
Spot contracts, where the title transfer is at the destination, a destination contract will be created in the background. The purchase order will be generated when running the spot monitor or creating the spot contract, and it will be for the actual quantity. The trading contract will also reflect the actual quantity.
For commingled scenarios, there will be an unload event, indicating the transfer of stock. Depending on the setup, you may already have an existing storage agreement, and business rules can automatically apply or default the storage agreement to the load during the unload event. The application document created as a result will have a storage status. Alternatively, if there is no existing storage agreement or it is unknown, the storage treatment can be assigned at a later point.
Governing Weights and Analysis
Governing weights and analysis are defined with your counterparty during contract negotiations. This includes specifying the type of certification, such as official, certified, inhouse and so on, based on your customer's requirements. This information impacts the downstream document generation and behavior of contract application status.
The concept of timing in this context refers to the order in which certain events occur, such as whether the settlement is based on destination or origin, and whether it depends on the timing or certification type for testing. It affects the contractual arrangements and helps determine the appropriate actions and sequencing.
The weights and analysis can be taken at the following times:
- At Origin
- At Destination
- By Certification Type for Testing
- By Timing
Timing
The governing terms for a contract are defined in the DPQS tab of the contract. The DPQS schedule can be assigned to the contract or scheduled at the unload or load location. The timing and version of the validity period for the DPQS schedule can also be specified.
The timing is assigned in the contract and the following are supported:
- At Contract Creation: The DPQS version and validity version assigned at contract creation will be used.
- At Discharge: The latest DPQS version and validity version is used at time of LDC unload event.
- At Load: The latest DPQS version and validity version is used at time of LDC load event.
- At Contract: The system considers the relevant version of value schedule from which the contract was saved.
The different versions of DPQS schedules configured in our solution include destination certified, destination official, and destination house. These versions have a hierarchy, which impacts the application status. For example, if the contract requires a certified analysis for final settlement, but the load event input includes a house analysis, the application status will be provisionally applied. When the certified analysis is input, the status will change to finally applied.
Governing Terms are Defined in the Contract (DPQS tab)
The governing weights and analysis must be defined in the contract. Included in this definition is timing (destination, origin or first), as well as what certification type (certified, official, house, nota fiscal). These are configurable. SAP Agricultural Contract Management delivers the necessary business configuration sets to accomplish this task.
Governing Terms Impact Application Status
Let's consider an example where the contract's governing terms are destination official weights and analysis. A barge is loaded with estimated weights and analysis and shipped down the Mississippi river to the customer. When the load event is entered, an application document is created with the status of provisionally applied because the estimated weights and analysis do not meet the governing terms. The application document's incoterms indicate destination and the status is provisionally applied.
When the barge arrives at the customer location and the unload event is entered with the actual weights and analysis, the application status will change to finally applied as the governing terms are now met. Assuming the price is already fixed in the contract, final settlement can be run (assuming the pricing is fixed on the contract).
