Most users are associated with a standard billing rate. However, the billing rate may vary depending upon the client, project or task for which the work is being done. Rate precedence permits you to define default rates for users, clients, projects, tasks and work types; these can then be overridden on a case-by-case basis.
To provide a visual explanation, please refer to the chart below, wherein the flow of precedence is from top to bottom, as well as some example that can further illustrate the logic behind the Rate Rule Precedence concept.
Rate Rule Precedence Chart
Precedence goes from top to bottom with side “sub-routine” for dependent fixed rates.
|
Project Rate Card: A standard Billing rate based on Roles assigned to a Project. Rate Cards take precedence over all other Rate Rules and apply only for Billing. | ||
|
Project Fixed Rate: A fixed dollar amount for a specific date span, set at Project level. | ||
|
Task Fixed Rate: A fixed dollar amount for a specific date span, set at Task level. | ||
|
Resource Daily Rate: A fixed dollar amount for each work day, set for one or more resources. May depend on particular Task, Project, Client or Work Type. |
 |
- Depends on Task - Depends on Project - Depends on Client - Depends on Work Type - Fixed, rate, no dependency |
|
Resource Recurring Rate: A fixed dollar amount for a specific date span, set for one or more resources. May be flat charge or pro-rated. May depend on particular Task, Project, Client or Work Type. | ||
|
Resource Hourly Rate with Dependency (task): A rate per hour for work done on a particular Task, and set at Resource level. | ||
|
Resource Hourly Rate with Dependency (Project): A rate per hour for work done on a particular Project, and set at Resource level. | ||
|
Resource Hourly Rate with Dependency (Client): A rate per hour for work done on a particular Client, and set at Resource level. | ||
|
Resource Hourly Rate with Dependency (Work Type): A rate per hour for work done on a particular Work Type, and set at Resource level. | ||
|
Task WBS Rate: A rate per hour for work done on a particular Task, and set at Task level. | ||
|
Project WBS Rate: A rate per hour for work done on a particular Project, and set at Project level. | ||
|
Client WBS Rate: A rate per hour for work done on a particular Client, and set at Client level. | ||
|
Work Type WBS Rate: A rate per hour for work done on a particular Task, and set at Task level. | ||
|
Resource Hourly Rate with no Dependency: A rate per hour for work done on a particular Task, and set at Resource level. | ||
The billing rate that is dependent upon the specific project takes precedence over the billing rate associated with the client. The Rate Rule Precedence Chart demonstrates the hierarchy of rate precedence.
The rate rule with the highest precedence is applied. Rules of lower affect rate precedence.
Example
For example, a user may charge Client ABC Inc. $75.00/hour for all consulting purposes. Yet, if this user works on project Implementation for ABC Inc., then the client is charged $100.00/hour.
Business Scenario Example 1
- Project fixed billing rate overrides user's daily billing rate.
- Company X has defined for all of its consultants a fixed daily rate. This means that no matter how many hours worked in a day of consulting, consultants always bill the client the same rate for a day. This is the overall policy for the company for its consulting services.
- At some point, the company receives a new consulting contract in which the client requires that the project be split into different phase dates, each involving a deliverable. In this case the client agrees to a fixed billing rate per phase. The client is not concerned about the number of consulting days required to complete the specified deliverables; instead the client requires that the required work be completed for those dates.
- In this case, the system would override the consultant's fixed daily rate with the project's flat fee in those given date intervals.
Business Scenario Example 2
- User costing hourly rate with task dependency overrides user's hourly costing rate.
- User X has a standard hourly costing rate of a 100$/hour, except that managers want to make an exception for a specific type of work which requires more skills and effort from the given user. They would then create a rate with a task dependency, which then overrides the standard hourly rate of that user.
Business Scenario Example 3
- An organization has structured its departments according to services rendered. Each of the departments has billing rules defined by client for all of its members and their tasks. Since the department as a whole provides the same type of services internally, the organization defines its billing rates for charge back/invoice purposes.
- A scenario occurs where a member of a group does not inherit this billing rate for a specific type of work performed. An exception would then have to be created for that user, for that task which would then override the group/billing rate previously defined for that user.
Business Scenario Example 4
- Assume that organization A has a different billing rate for each client A, B and C. The only exception is that senior consultants are billed at cost plus 25% for any customer. Therefore the following rules would be created in PSA software:
- Client A: Billing rule of $100 per hour assigned to Client A; no need to create any user specific billing rules
- Client B: Billing rule of $10,000 fixed billing assigned to Client B; no need to create any user specific billing rules
- Client C: Billing rule of $1000 per day per assigned to Client C; no need to create any user specific billing rules
- Senior Consulting billing rule created as a Cost Plus (+25%) rule assigned to all senior consultants
- As the above example shows, by using the precedence chart, a complex scenario can be implemented using very few rules. The PSA rate engine is very flexible yet straightforward, and addresses simple to elaborate billing rule needs.
- Rules defined through the Financial Setup may be thought of as a library of cost and billing rules that may be used by the organization. These rules are not put into effect, however, until they are associated with a particular user or group. Therefore, the next step after rule definition is the association of rules.