Restructure Rental Package Pricing

Background

From a pricing perspective the rental application has two main processes, sales of consumables and renting of rental items and packages. The requirement is to separate the pricing of these processes, including ensuring a single setup of prices for sales items (consumable products) regardless if it's sold via sales order or rental agreement.

For rental items and packages the pricing set up will be consolidated to enable this from a single start point.

In addition rental package prices will now be defined in a matrix and be added to a price list.

For rental items and rental packages the requirement is to find the correct price list and price for the right customer and rental agreement, and not simply retrieve the actual rental price. Based on the control objects for rentals, for example country, state, customer group, customer site, or reason, M3 must be able to select the correct price list. The main goal is to enable users to define a set of rules that will allow M3 to find the correct price list.

Solution

In the following figure, the yellow boxes illustrate the retrieval of the rental item pricing.

Currently, rental packages are priced using the same programs as used for defining the packages. With the new solution, the package definition will be separate from its pricing. Instead, the pricing will become part of the price list setup.

STS125 is a new program created for this purpose. It is accessed from program STS017 by using option 12='Rental Package Rates'.

The current programs 'Rental Package. Open Header' (STS450) and 'Rental Package. Open Line' (STS451) remain unchanged, using tables STPSHE and STPSLI, so that the old rental flow 'Rental Agreement. Open' (STS100)'Rental Agreement. Open Lines' (STS101) continues to work. In order to manage this rental package pricing using tables STPSDH and STPSDL, we have created the following programs:

A new table STPSPR (Rental Package Prices) will contain the prices for the rental package based on a price list.

The package prices are stored as a matrix of prices in the same way as for rental item prices. The package price is retrieved based on the price list in the same way as normal rental item prices are retrieved to the agreement line.

Limitations

The Restructure Rental Package Pricing is done for Equipment using 'Rental Agreement. Open Lines' (STS201) through STS100. Therefore, programs STS450 and STS451, which use tables STPSHE and STPSLI, remain unchanged, so that rental customers using STS100 – STS101 can use the old package handling, while Equipment customers can use STS455, STS456 and STS457 with tables STPSDH and STPSDL.

Workflow

  1. A package is created in STS455 – Rental Package Header

  2. In STS455, you select option 11 = 'Lines' to access STS456

  3. From STS017, you select option 12 = 'Rental Package Rates' to access STS125

  4. On STS125/E you set up the rates

STS120 will automatically calculate other field values when a specific field value is entered. For example, when you enter a value in one of the four fields in column 1 (Rate/day), the other fields against that line are calculated. When you press Enter, the calculation is made. The Standard cost %, Delivery charge and Delivery cost fields are optional. If values for them are entered, then they will be distributed down to the package lines in the same way that the retrieved price will be distributed down using the price factors.

Migration Program

Since key fields are removed for this solution no all-encompassing migration programs can be written.

The restructure of the packaging functionality, from STPSHE – Package Header and STPSLI – Package Lines to STPSDH – Package Definition Header and STPSDL – Package Definition Lines, has included the removal of 4 key fields that do not exist in the new solution. These are Division, Warehouse, Currency Code and Customer.

It is possible that packages therefore are set up with any permutation of these fields and Division and Currency were mandatory fields. To do a migration of all the data successfully then would entail a unique package ID being assigned to each and every record that currently appear in the table STPSDH. This is not really practical or possible as an automated process.

Related topics