Every day, depending on the number of employees, a service company generates hundreds of working time bookings that have to be invoiced to customers at a later date. It must be ensured that the working time bookings can actually be billed and are assigned to the correct customer orders and service types. This sounds like a lot of manual work. But it doesn't have to be. In this article we will show you how you can easily manage this task with foreknown.

One of the core tasks of foreknown is to convert all working time bookings recorded in Jira, Tempo Time Sheets (Jira plugin) or directly in foreknown into billable and non-billable services based on individual rules. But before we get into the details, let's go over a few basics.

Working Hours & Services

In foreknown, a distinction is made between working hours and resulting services. This clear separation has several good reasons:

1. Working time bookings are not only used to generate services, but are also used to record full time and thus to maintain a working time account in order to detect over- or undertime.
2. The duration of the billable services sometimes differs from the duration of the working time bookings,
   1. because some working time bookings may not or only partially be charged to the customer.
   2. because rounding rules are applied when transferring working time bookings (e.g. billing always in full 15 minutes).
   3. since daily rates are used where, for example, 7 hours of booked working time results in a service at a full daily rate.

Thus it makes sense to separate working time bookings from services in order to be able to reconstruct the basis of a service at any time.

Rules - The connecting link

In foreknown, we provide rules that serve as a link between working times and order-related services. They ensure that the working time bookings of all employees from all relevant projects and tasks become service entries, which in turn are assigned to the correct orders, order positions and service types. But how do the rules in foreknown actually work?

In order to understand how it works, we first need to backtrack a bit. The basic task is to identify the necessary criteria via all properties of a working time booking in order to be able to assign it unambiguously to an order, an order position and an service type. In order to have as many properties as possible available, we have attached so-called "labels" to each working time booking, which result from the assigned task.

1. Project: Project abbreviation from Jira or also from projects created in foreknown, e.g. Project:ABC.
2. Task Type: Type of the task e.g. Type:Epic, Type:Task, Type:Story, ...
3. Epic: ID of the parent epic from Jira where the task is assigned (for SCRUM projects) e.g. Epic:ABC123
4. Sprint: Name of the sprint from Jira where the task is assigned (for SCRUM projects) e.g. Sprint:KW23-2022
5. Release: Name of the release from Jira where the task is assigned (for SCRUM projects) e.g. Release:Version-1
6. Priority: Name of the priority from Jira where the task is assigned e.g. Priority:Medium
7. Task: ID of the task that was posted to e.g. Task:ABC002
8. Tempo Account: ID of the tempo account from Jira e.g. Account:XYZ

Furthermore, all labels stored in the Jira task are transferred 1:1. In this way, you can also use your own labels or labels provided by foreknown with special functions. We will come back to this later.

Documentation Note: For more information see chapter "Billing / Rules" in our documentation.

Apply rules

With the help of the labels and the employee of a working time booking, there is now a lot of information available to ensure a clear assignment. Before we show an example of how a detailed rule can be structured, one more important piece of information.

Every project that was created in foreknown or via Jira in foreknown is automatically assigned a so-called basic rule. This basic rule already ensures that all working times of tasks of the project flow into this basic rule via the above mentioned label Project:. Afterwards the necessary "detail rules" have to be defined. The following dialog shows the possible settings of a detail rule.

A detail rule uses the labels that are stored at a working time booking and can check defined labels for existence with an OR or AND link. The detail rule takes effect if one or all of the selected labels are present in a working time entry. In addition, restrictions can be made on the employee or permission group level. Then the desired order position and service type are selected and the detail rule is ready.

Example

All working hours, which flow on the Epic "ABC123" and their subtasks, are to run on the order position "Shop development". Employees Max and Marina should be booked as junior developers and Moritz as senior developer.

Rules must be defined for this, as follows:

1. Activate option "This rule takes effect if at least one of the following labels is present".
2. Select labels: Task:ABC123, Epic:ABC123
3. Select desired order, order position
4. Select desired service type: Junior Developer
5. Select employees: Max, Marina

The second rule differs from the first rule only by the service type (Senior Developer) and the employees (Moritz)

All detail rules are sortable in order and are also applied in that defined order.

Special features

There are a few special use cases for the rules, which we would like to point out here.

The fallback option

The option "This rule takes effect if none of the preceding detail rules could be applied" is used to create a fallback for all working time bookings that failed through all previous detail rules. It goes without saying that these detail rules must always be at the end of the list. There can also be several detail rules of this type, for example if you define one fallback per employee or permission group.

In this way, you can ensure that all working time bookings can always be assigned. It should be noted, however, that the preceding detail rules also always cover all desired cases.

Use standard rules

For a basic rule, it can be specified that so-called standard labels are evaluated and applied for the assignment of working times to order positions and service types.

1. Order: -.
2. Service: .

For example, if you already assign the above two standard labels to each task, all working time bookings of this task can be automatically assigned to an order position and service type.

However, this only makes sense if each individual task is cut in such a way that activities at this task refer to an order position and service type. As soon as several service types, e.g. junior and senior developer, book working times on one task, a clear assignment would no longer be guaranteed.

Documentation Note: For more information see chapter "Billing / Rules / Standard Labels" in our documentation.

Identify service type from activity description

For your detail rule, you can also check another checkbox "Identify service type from the work log description". Activate this checkbox to search for an service type in the work log description using a prefix :... or postfix (). An service type identified in this way overwrites the previously selected service type.

So, for example, if a junior developer is working on a task, that developer would set a postfix "Dialog implemented (J-ENT)" in the work log description, and a senior developer would set "...(S-ENT)". These abbreviations result from the abbreviations stored at the service types in foreknown and thus ensure the correct assignment of an service type.

This option thus requires that each employee always thinks of the prefix or postfix when booking his working time and enters it correctly.

Permission Groups

A detail rule can also be restricted to specific employees. For example, a rule could ensure that all junior developers are booked to the corresponding service type "Junior developer". For this purpose, all affected employees can be assigned to the rule individually. If, however, you want to ensure that the right employees are always included in all affected detail rules, you can also assign one or more permission groups.

If, for example, each employee in the company can be uniquely assigned to an service type, you could create an permission group for each service type (possible via System Administration) and assign the relevant employees to this permission group. In the next step, the permission group can then be assigned to a detail rule and all relevant employees for this detail rule would already be taken into account.

This also has the great advantage that you can add or remove employees centrally in one place and it would automatically update all detail rules that use this permission group.

Documentation Note: For more information see chapter "System Administration / Permission Groups" in our documentation.

Conclusion

The rules in foreknown represent a powerful tool to be able to correctly assign many working time bookings to orders, order positions and service types with little effort. But before you create your invidiual rules, you should think about how your projects and tasks are structured e.g. in Jira and which information can already be provided for foreknown when creating tasks. Because this information has a significant influence on the design of the detailed rules.

Once the set of rules has been defined, however, it no longer matters how many work time bookings have to be managed, since assignment to tasks can be automated to the greatest possible extent. This not only simplifies the activities of the project manager, but also leads to current key figures on the project, order, team and company, whereby positive and negative developments can be identified at an early stage.