Quantities of minutes could not be adjusted, else the business would lose sight of the actual number of minutes that were confirmed, (initial sales price) which would then lead to losing visibility of the any revenue made from “rolling up” their number of minutes, (I.e. final ZPR2 minus initial ZPR2).

The second challenge was to ensure that the billing methods never overlapped, I.e. do not charge a minimum order value of the item(s) have a minimum amount themselves. Also, there were the following scenarios to consider:

• Recalled works (Free of charge) where KBM1 was utilised
• Out of hours (Fixed price with and without a profit surcharge dependent on customer)

In summary, the billing requirements were quite complex and needed to be fully automated based on one key factor… who the customer was and when the work took place. Apart from these facts, it was expected that the system would fully automate the remainder of the pricing calculations.

Minimum order value:

To achieve this, the standard minimum order condition types (AMIZ and AMIW) were copied and assigned to the pricing procedure – ZMIW and ZMIZ. The tables as standard included the “Pricing group” and a record was created against the Sales Organisation, Distribution Channel, Division and Price Group (Z1) – with a value of £50.00.

By maintaining only certain customers with a Z1 on their master data record, it guaranteed that if the vendor invoiced this customer, then a minimum order value of £50.00 would be applied regardless of the items being invoiced. We now needed to prevent the minimum order from being triggered if the scenario dictated minimum item value. The one control that would not change would be the billing method for the customer, so by NOT maintaining a Z1 on specific customers meant that they would never be invoiced a minimum order value – I.e. those customers that preferred to be invoiced based on a time calculated rate (and chose to pay a minimum item amount for Labour).

Minimum item value:

This condition type was a little more difficult, as standard SAP does not provide a condition type to support this process. I investigated several options, including the use of minimum order quantity on the material master, (not appropriate as this is “Order quantity” based, not “Target quantity” as in a DMR). Also, material determination – even Sales BoM’s etc. None of these were a suitable solution. I finally created a copy of the minimum order value, but requested a calculation (913) to be created that checked the previous condition type (the reference) and applied an uplift to the item, as in the header. Naturally, there would only be condition records created for the material “Labour”.

As a precaution, I also created some condition exclusions that deactivated the minimum order value if minimum item was active, and vice versa. The rules would be as follows:

• Minimum order is initially active (as it is document type specific only)
• Minimum order will be set to inactive if minimum item is active – Controlled via condition exclusions
• Minimum item will only be active if there is a valid condition record – Controlled via condition records created for material “Labour”

Therefore…

• Minimum order will be included when invoicing option 1
• Minimum order will be excluded when NOT invoicing option 1
• Minimum item will be included when NOT invoicing option 1
• Minimum item will be excluded (not determined) when invoicing option 1

The first thing to do was to create a material called “Labour”. This would be the material used during option two when RRB was the billing method. Once this had been created and configured in ODP1, I then created a typical sales condition record (ZPR2) that was maintained with 15 minutes at £12.50.

Finally, add the formula to the conditon type on the pricing procedure.

Finally, the requirement to start “rounding” the minutes that were transferred from the DIP profile was achieved by creating a custom table (ZROUND_2544) and would be handled through pricing (and not quantities). Firstly, the requirement should not be fulfilled if the minimum order condition type was active (as this was a separate billing method and only Labour should be rounded). If the minimum order was not active, the next check would be to make sure that the material existed on table ZROUND and was flagged as active (so it could be controlled via a maintenace based master data table). This would store all the service materials that (when determined through RRB) would then round up to a value based on a piece of master data.

The calculation (formula) would then as follows:

Check the item being invoiced on the DMR exists on the custom table ZROUND_2544 (and is flagged as active)

Read Pricing Communications-Condition Record for condition type ZMIV

If condition record is found

And condition record is active on the DMR (I.e. minimum item value has been activated)

And has a positive rate (so it avoids “divide by zero” in any calculations)

Read Pricing Communications-Condition Record for condition type ZPR2

Only continue if record found

Condition pricing unit must have a value  (so it avoids “divide by zero” in calculations)

Divide Item quantity(I.e. minutes confirmed) by the pricing unit and round up to one decimal.

63 minutes divided by £12.50 = 5.04,  therefore becomes 6

Multiply the resultant value (6) by the Pricing Communications-Condition Record rate (6 x £12.50)

Round resultant calculation to 2 decimal places to determine condition value

Pass condition value back into standard SAP and populate ZPR2.

Finally, add the formula to the conditon type on the pricing procedure.

During the initial pricing workshops, there was a clear misunderstanding as to what “Actual costs” referred to. Whether correctly or not, I interpreted this phrase to mean the actual costs posted against the works order, whereas the client mean that it was “Actual time”, and time had a fixed sales price – not related to the costs whatsoever. It was quite far in the project when this was realised, and after some development had already been done to check activity rates, cost centres etc. to determine a “cost per minute” that should be added to the DMR.