Client X invoice their services to customers via one of two different billing mechanisms, based on the contract between them.
Firstly through a Resource Related Billing process, where again this splits into two processes. Internally delivered work is where costs are posted to a works order via confirmed time. The second is when the work is sub-contracted to an external vendor, and costs are again posted to the works order but via service entry sheets.
The costs from both scenarios are copied through to the subsequent Debit Memo Request (DMR) and populated on condition type EK01. However, EK01 is not the reference condition for populating the sales price (ZPR2), but a “fixed rate” sales price for the material determined (via the DIP Profile’s material determination) based on a quantity of time (measured in EA). Note that due to the requirement to use serial number profiles (in order to activate technical objects for using Functional Locations) on the DMR, the minute unit of measure could not be adopted – you cannot assign a serial number to a measurement of time.
The second method was a bespoke DP90 transaction (ZPD90) that was created to “copy” activity numbers / service masters from the confirmation and add to the DMR, when a different Billing form was maintained on the works order. The requirement being that dependent on the customer, and whether the work was performed internally or externally, then the billing form and DIP profile in the works order should be auto populated and thus, providing the correct billing mechanism – I.e. fixed price materials (copied from services) or use standard DP90 with Resource Related Billing.
Each of the two billing methods both had separate rules as to how “minimum cost to the customer” should be calculated. These were as follows:
Fixed price Services (i.e. actual materials) – “Minimum order” value
RRB with fixed price per quantity transferred (I.e. the labour) – “Minimum item” value
Finally, during the second scenario, there was a requirement to “round up” the price of the Labour into 15 minute intervals, and this should only be effective after the first full hour had been invoiced.
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”
- 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.
The lesson I learnt from this was to “play back” the solution as early as possible, perhaps in a simulated environment or pilot the solution with the client before any development and configuration is carried out. What may seem obvious to the Functional Consultant may mean something completely different to a client – if they are not familiar with SAP terminology and the strict guidelines that it it follows.