Batch Determination Within Trading Contract

Both automatic and manual batch determination is possible for sales-side as well as two-sided trading contracts. When you enter a characteristic of a batch, the system offers you a list of matching batches you can choose from. The batch number is assigned to the item and will be transferred to the follow-on sales order and to the outbound delivery.

When traders want to sell batch-managed material from their inventory, they are able to use variant configuration in the trading contract to specify material requirements. These are stored in a batch. A trader is thus able to determine and secure sales of the required batch and orders can be completed in a timely manner.

This allows reuse of the batch determination process from the standard ERP sales process. You only need to set up the minimal configuration at the trading contract level and item level. Any other configuration required for batch determination is reused from ERP sales processing.

Trading Contract Consolidation

Many trading contracts with the same business partner with equal or similar items are present in the system. If these items have an open quantity, a trader previously could not combine and collect the correct items and close individual trading contracts. The new trading contract consolidation function now enables you to reduce the number of open trading contracts and to consolidate open items.

A flexible framework to close, to copy, and to create new contracts or items is provided. The Trading Execution Workbench (TEW) enables you to carry out these activities in an efficient way. An algorithm is introduced to consolidate and determine the price conditions effectively. You can also define your own algorithms.

Trading contract consolidation enables trading companies to eliminate costly double maintenance of multiple trading contracts with the same business partner and hence cut administration time, cut inventory, and free up time for front-office users for more productive selling time.

The trading contract consolidation framework is flexible and configurable and can easily be extended.

Shadow Trading Contracts

This function allows you to create shadow trading contracts based on an ERP Sales Orders or ERP Purchase Orders.

The creation of a sales order or purchase order automatically triggers the creation of a trading contract.

The generated trading contract behaves like a native trading contract and raises, for example, events, and as such can be used to create end-to-end trading scenarios involving a third-party front-office application.

The trading contract function allows for the transmission of the commodity price risk to a commodity risk management system and the appropriate hedging of the commodity price risk.

The existing SOA interface can be reused to connect purchase orders and sales orders to the trading contract as well as to an external application for risk management processing.

Collective Accrual Processing

It is now posssible to select multiple target documents as a basis for creating an expense document. New fields are added to the existing user interface in expense workbench, enabling flexibility of selection criteria. New execution buttons are added for enhanced collective processing.

You can post an expense document with reference to multiple underlying documents, such as trading contracts or logistics documents. A new criterion has been added for selecting target documents with different status: either documents with not-accrued planned expenses or documents with unsettled expense invoices. In addition to existing single document processing, the collective process can be done online or in the background for batch processing.

With this new function you can benefit from the following advantages:

Expenses are broken down into individual trading contract items to enable accurate contract based P/L for better business decision making. Furthermore, with SOA technology, expense management can be integrated with 3rd party solutions such as Commodity SL by Triple Point Technology, which enables traders to manage their risk position for expenses and secondary costs.

The existing user interface in the Expense Workbench and configuration via existing expense management can be reused. A standard interface is also provided to receive expense data from external systems (such as Commodity SL).

Service Operations for Commodity Management

New and enhanced A2X Services help you process trading contracts and their analysis-relevant data.

The business function Trade, Commodity Management 4 offers CRUD-like (create, read, update, delete) services that enable you to:

The above-mentioned A2X services support standard SOA architecture and enable the development of enterprise services.

Empties Bill of Material

The empties bill of material function enables you to include items from the empties BOM in the follow-on documents of trading contracts.

Item lines of the BOM are added in the overview screen. If you enter a unit of measure of a full product in a trading contract and an empties BOM exists for the unit of measure, the system automatically adds items for the empties components. You can have the system add empties items to the trading contract as well as to the business benefit document. Separate empties BOMs are maintained and these BOMs are used to add the item lines to the trading contract.

Stock Transport Order in the Trading Contract

This function enables you to enter stock transport orders in addition to standard purchase orders within the framework of trading contract processing. The system supports intra-company-codes as well as cross-company-code stock transport orders.

You may need to process goods movements in other ways than the standard goods issue/goods receipt process. It may be necessary to use internal stock transfers between your plants.

One-sided Organizational Data in the Trading Contract

With this function you can specify whether organizational data is entered for both purchasing-side and sales-side, or whether the system should take account of the relevant organizational data only, that is, either sales-side or purchasing-side. This means that for sales-side trading contracts, the system takes account of organizational data from Sales and Distribution (SD) only. Purchasing-side trading contracts are entered with organizational data from Purchasing (MM) only.

You can thus only maintain organizational data of the sales-side for creation of a sales-side trading contract and organizational data of the purchase-side for creation of purchase side trading contract.