Contracts

The Contracts module is used to calculate the payment and revenue relating to an order for a cost centre and a counter party. A counter party could be any entity who has a financial relationship with a cost centre. However, for the purpose of this document we will consider carriers and customers to be relevant counter parties. If a contract is set up between a cost centre and a customer then the contract will be used to calculate the revenue that the cost centre can expect to receive from the customer in respect of orders placed by that customer. If a contract is set up between a cost centre and a carrier then the contract will be used to calculate the payments that the cost centre must make to the carrier in respect of trips that the carrier has undertaken for that cost centre (in order to deliver the orders placed by a customer).

Each contract is defined in a particular currency (MTS will allow a user to configure which currencies are in use for a particular database), all payments relating to that contract will then be created in that currency. The currency will also be allocated to Invoices, Trips and Orders. MTS will not allow payments in different currencies to be applied to the same Invoice.

Therefore, cost centres receive monies from customers for the orders that they place within the MTS system and carriers receive monies from cost centres in respect of trips they have undertaken to deliver the orders that customers have placed.

Given that contracts involve several parties i.e. cost centres, customers and carriers it is worth noting that data maintenance forms are available within MTS that allow an operation to define the parties that it will use within a contract and elsewhere in the system too.

The contracts module uses a number of different items to find out how much the payment or revenue should be for a particular order. The mechanism it uses for identifying this value is described below.

• Identify the contract being used based on the cost centre and the counter party.
• Identify the journey that is taking place for the order (can be identified as being the location id, town, postal region or country)
• Identify the tariff that exists for that journey OR identify the tariff using a lane_ID (if lanes being used)
• Identify which tariff tier should be used based on either the weight of the order, the number of RPEs associated with the order or the number of pallets associated with the order.
• Identity which charge conditions and therefore, charges should be used. Add up all of the charges that relate to this contract, journey, tariff and tier and charge condition.
• Identify the minimum and maximum charge for the tariff if the total of all the charges fall between this value then charge the derived value, if it falls below the minimum then charge the minimum if it falls above the maximum then charge the maximum.

The basis by which payments and revenue are calculated by MTS are defined as charges. A tariff is given a name, ideally, the name of the name of a lane and or a to and from location can be assigned to the tariff. Within the tariff, a number of tiers can be set up, and within each tier a number of charges can be assigned. Charges are dependant upon the payment types that are in the system. For each charge set up, a unit type and a Charge type MUST be assigned. There are a number of units, which are currently available. These are:

• Fixed
• Pallet
• RPE
• Weight
The diagram below illustrates a contract between the cost centre EXEL_EMT and the customer JOULIE_F and is effective from 3rd August 2003. The tariff L-KF034-F represents a suite of charges for any Trips going to and from location KF134-F and UB187-F (These locations are found on the Standard Journey tab).