The Requirement
Our customer is a staffing company. Staff can either be paid as a vendor or as an employee. We designed solutions for both. The vendor solution is described here.
NB decided that Resource Related Billing would not work as it is not user friendly. We wanted a solution that both satisfied the requirement and was both easy to use and maintain. (We all want this in all software designs, right?!)
The price of staffing is variant. A shift worker can have Shift 1, 2 or 3 at regular time, over time or double time as combinations.
SAP Variant Configuration (VC) can easily handle this plus all the other types of staffing billing like (sick, vacation, jury duty, health and welfare, per diems etc.,)
We wanted to be able to invoice a customer for one week of staffing and pay a vendor for their portion of that week, including an admin fee or profit for each week of billing (difference between customer price and vendor price).
Easy to use. Easy to maintain.
NB’s Design
One sales order and one purchase order are linked to each other, and a corresponding line item on each represents one week of staffing.
We built one line of a sales order to represent one week of a staffing role’s billing. Based on manual input or an interface we build from the client’s time keeping system, VC calculated every day with a date like this:
- Day 1 Shift 1 RG
- Day 1 Shift 1 Overtime
- Day 1 Shift 1 Overtime
- Day 1 Shift 2 RG
- Day 1 Shift 2 Overtime
- Day 1 Shift 2 DoubleTime etc. to Day 8 (yes there are 8 days a week not just in the song)
We calculate total hours for each shift.
We enter customer total price for each shift combination:
Shift 1 Price RG, Shift 1 Price OT, Shift 1 Price DB etc. for all 3 shifts.
VC multiplies the total hours by the prices to get the totals for each shift:
Shift 1 Total Price RG, Shift 1 Total Price OT, Shift 1 Total Price DB
If this was a distribution channel for managed services (VC reads the DC), then we enter the price we were pay the vendor:
Shift 1 Pay Rate RG, Shift 1 Pay Rate OT, Shift 1 Pay Rate DB etc. for all 3 shifts.
We calculate the total vendor price:
Shift 1 Total Pay RG, Shift 1 Total Pay OT, Shift 1 Total Pay DB
And VC would then calculate an admin fee; the calculation of customer total price minus vendor total price (as a total not for each shift). We pass the amount we are paying the vendor and the admin fee to SD pricing. If it was not managed services, we would pass the full customer price to SD pricing. (business segments: using employees or 1099 vendors)
A Note on Rounding
Because SAP rounds (correctly in my opinion) in the last step of the calculation and our client’s customers round at every calculation we had to use a Variant Function which allows the calculations done in VC to passed through a custom ABAP function module to perform the rounding. This personally hurt my ego because I love the challenge an all standard SAP solution (a few years later I was vindicated when a major new customer of theirs wanted the rounding the way standard SAP calculates it)
Week Ending Date
Week ending date is critical in the staffing business.
We pass the end of the week date we maintain in VC to the first date field on the sales order line item. This then gets picked for billing calendars. If the order is managed services where we need to pay the vendor, rather than re-interface all this VC to the SAP PO, SAP fortunately stores the VC for sales order (or a PO) in database tables. (We actually start this process from the PO first, but it is easier to explain from sales). We could not use the SD 3rd party order process because we wanted the design to be easy for users.
Ease of Use
Each resource is paid and billed for through one purchase order and one sales order for entire lifetime that resource is at that customer. Each line item on a sales order has a corresponding line number on a purchase order. We added to the sales order line item in Additional Data B the purchase order and week ending. Each line also has references to the time keeping system both at a work order level and at a week ending level. Therefore if customer service ever needs to see in one glance the billing for a particular resource they can find the sales order (we use the time keeping system’s order number as our sales order number).
Here we can open up the PO and see the exact same VC screens as the order because it is the same VC. This is key. There is no need to dual maintain the sale order and the purchase order VC. Even if one is changed manually then the other is kept in sync, because it is the same VC object shared by the PO and the SO.
Pricing
Here is where VC really shines. Because unlike standard SAP pricing conditions that can exist only once on a line item; VC conditions can repeat.
We maintain all condition records at $1. And use VC to multiply it by the results of our calculations.
Pricing example: (10 hours in all shifts)
Pricing example: (10 hours in all shifts)
$10 per hour.
Rate X hours
Vendor pay rate $8 per hour
Vendor total price
Item pricing screen sales order:
The corresponding PO line item for this order would pay the vendor $720 using the same VC we used on the order.
There is also an MBE/WBE solution we accomplished keeping this design intact, but that is another article.
Easy to Use
Keeping the sales order and purchase order live and in sync on a line item was challenging from a design perspective, it makes it easy for users to find a week’s worth of billing over months and years. Yes, there is an AP and AR invoice for every week of billing, but there is only ever one synced sales order and purchase order. Easy.
Easy to Maintain
SAP Variant Configuration has a bad reputation of being difficult to maintain. Although staffing naturally does not have as many design changes as a physical product changes have been made quite easily to the design over the years. The challenging piece is that any design changes had to succeed in new orders (easy) and existing orders (challenging as SAP does not like to change the past. We have implemented pricing and VC changes for the Affordable Care Act. We also eliminated the need for a sales tax software and returning the customer to using standard SAP for US sales and use taxes. (It can be done! That might be in another article…)
