(Further on Microsoft Dynamics NAV:here.)

The process

The two main processes for Microsoft Dynamics NAV partners are implementing new projects and providing services such as support and upgrades to existing customers. A third process is selling infrastructure and assembling computer systems but this is an extra service, not the core business.

To support the projects (jobs) the company needs people, software licenses and hardware. The people (resources) need to be carefully planned on the projects as they are the least flexible part of the company. Hardware (items) and software licenses (G/L accounts) will be purchased from vendors such as Microsoft.

The projects can be divided into large and small projects. The larger projects are new implementations and upgrades. Smaller projects include implementing small features and helping users with regular support issues.

Invoicing can be done in various ways. New implementations and small projects can be invoiced per billable hour while upgrades are sold fixed price. For hardware we will use items. Licenses are invoiced directly to the General Ledger.

Large projects also have budgets and a plan that need to be maintained. If the budget is fully used and the planning milestones have not been reached there should be a new budget created in order to complete the project.

To support this process we will use the Jobs functionality with some customizations. Projects are called Jobs in Microsoft Dynamics NAV so we will use that term from now on.

The Jobs module has been completely redesigned by Microsoft for version 5. In this article we will use a lot of the new functionality where we would have done customizations in the older versions of Microsoft Dynamics NAV.

Fits

The registration of the Jobs can be done using the standard functionality of Microsoft Dynamics NAV as well as the budgeting and planning.

The standard software also allows us to invoice Jobs both fixed price and on time and materials. We can also purchase items for our Jobs.

Gaps

The Jobs module in Microsoft Dynamics NAV is often referenced as a framework that almost always needs some changes. Fortunately, it is designed to be easily changed and we will do so to support our processes.

Resource groups

Although many companies work this way; budgeting on Resource Groups is not possible. We will create a solution for that. We will also make it possible to see the total number of planned, used and invoiced hours.

Time registration

The standard software allows us to register hours but it does not have a real-time sheet application. We will create one.

Item calculation

We will create a solution calculating the system assembling. As hardware specifications are changing rapidly we do not want to create a new item for each system when we may only sell that particular configuration once or twice.

Issue registration

Our support team needs a single point for registration of all support issues for all customers and follow up their workflow. For this we will also create the functionality to register and follow up issues.

Getting started

Before we start creating any new jobs, we should have a look at the data and posting model of the Microsoft Dynamics NAV Jobs module.

The starting point is the Job table, which has Job Tasks and Job Planning Lines we can use for budgeting and planning. Each job can have its own prices.

The Job Planning Lines get invoiced through the standard Microsoft Dynamics NAV Sales functionality which then creates Job Ledger Entries.

How many jobs

The first step is setting up a new job. There can be different angles on setting up jobs.This depends on how we want to work with the system. The minimum requirement is to have at least one job per Bill-to Customer. This enables us to do the invoicing.Some companies use jobs this way to use it as a pre-invoice engine.

Another angle can be to set up new jobs nicely for each project we do for the customer. In our case this starts with the basic Dynamics NAV implementation.When this is finished we close the job. If the customer has any new requirements we will need to start a new job. This way we can keep better track of what issues we have outstanding with each customer. The downside of this methodology is that it requires some work to set up a new job every time.

Most companies end up with a solution in the middle. It is common to set up a new job for larger jobs and to have a job for support issues. This also allows us to set up different invoicing strategies for each job. We will use this strategy.

Job card

Let’s have a look at the Job Card and the important fields there.

Let’s see these fields in more detail:

• No.: This is the unique number of a job. We can use different number series strategies for this, from simple sequential numbering to linked number series for different job types or manual numbering.
• Description: This should be a logical description of the job for internal use. Most people will search on this field so make sure to have certain rules for naming. This will make searching for old jobs easier in the future.
• Bill-to Customer No.: Each job has one Bill-to Customer. If we want to invoice multiple customers for one job we will need to customize the application.
• Search Description: By default this will be populated with the value of the description field but can be changed to another value if required.
• Person Responsible: This is an informative field indicating who is responsible for this job.
• Blocked: If this field is checked, it is not possible to make new entries for this job. Use this for closed jobs.
• Job Posting Group: This refers to the G/L Accounts that are used for the Work In Progress postings (WIP). There can be different G/L Accounts for different types of jobs or WIP methods.
• WIP Method: Each job can have one Work in Progress method. We wild discuss this briefly later in this article.
• Status: The jobs have a limited set of status fields. The only available status values are Planning, Quote, Order, and Completed.

Most companies want to have more sub statuses for the order phase.The best approach for this is to add a new status field that maps with the standard status field. This requires minimum changes to the application while creating new workflow possibilities.

• Allow Schedule/Contract Lines: If this field is not checked it is not possible to create planning lines, which have both schedule and contract options. When planning lines are created they will be split into a schedule and a contract line.
• Starting and Ending Date: These are informative fields that are only used to calculate the currency exchange rates for the job.
• Foreign Trade: In the jobs module it is possible to send calculate and create invoices in a currency other than the local currency. This will increase the complexity of the implementation and should be used carefully.

Job task and planning lines

When the Job is created, the next step is to create Job Tasks and Planning Lines.These can be used in different ways.

Using job task lines we can cut the job into smaller pieces, which we can then schedule and invoice. The more detailed the job tasks are, the better we can measure the progress of the job, but the more work they require to maintain. Balance is the key to success here.

The Job Tasks can be created with the same structure as the Chart of Accounts, meaning the actual Task Lines can be grouped using Begin and End Total lines. Each level can be indented for better readability.

The Job Planning Lines are the detail lines of each job task. This defines what we will do and how this will be invoiced. A job planning line can be linked to the master data types Resource, Item, G/L Account, or Text.

Job Tasks and Job Planning Lines can be copied very easily from other jobs. This allows us to reuse them and even create template jobs for frequently used combinations.

The line type in the job planning line defines how it will be invoiced. There are three types:

• Schedule: The amounts on this line will only be used in for budgeting purposes. When invoicing we need to post one or more job journal lines that will be invoiced or we can create another job planning line with the invoice amount. Schedule lines should be used when billing on time and materials.
• Contract: This line will be invoiced with the exact amounts. However the amounts do not show up in the budget. This can be used when invoicing fixed price jobs in a schedule, for example: 50% when signing the contract and 50% on job completion.
• Both Schedule and Contract: This line will be invoiced exactly the same way as the contract lines but the amount will also show up in the budget.

Job journal

When the job tasks and job planning lines are set up we can start the job. During the job we will consume resources and items from our company. This should be registered using the Job Journal.

When creating a job journal line a few fields are particularly important for the process:

• Line Type: This has the same options as the job planning line, Schedule,Contract, and Both Schedule and Contract. When the job journal line should be invoiced, the type should be Contract. When the job journal line is part of a fixed price the line type should be left blank. When the line type is Schedule, the system will create additional Job Planning Lines of this type which may corrupt our budget for the customer asthey are already created.
• Unit Cost and Unit Price: These fields will determine the cost of the job and the price that will be invoiced to the customer if the line type is Contract.This information is also used in the calculation of the Work in Progress.

 

Job examples

Let’s go through some different job scenarios to see how we can use this functionality.

Chapter objects

The chapter objects contain both the changes we discuss in this article and as the example jobs we will use. After importing chapter 8.job, run page 123.456.700 Jobs Add-on Setup and then run Initialise Application.

When this completes, restart the Role Tailored Client. You should now see the Project Manager Role Center.

1 | The new implementation

Implementing Microsoft Dynamics NAV 2009 is not an easy task and many things need to be taken care of before we can use the product. We will implement Microsoft Dynamics NAV for Packt Publishing. The job for this example is EXAMPLE1.

For the implementation we will create various job task groups. Each part of the implementation gets a code. Because the sorting is done on this field we will create codes using numbers and a logical name. For example, 0200. SETUP and 0210. FIN.

Leave enough space in the numbers to add additional lines if required. This will avoid renaming which is an expensive task for the database engine and users will have to wait until it is completed..

Our consultants will help the customer to install the system, help with the setup and convert the data from the old system. When this is done we will help them with testing and train them for using Microsoft Dynamics NAV. The consultants will be set up in the system as Resources, which are in turn entered into the job planning lines.

When everything is working as expected we can schedule a go-live weekend and help them in the first period using the system.

Invoicing a job like this is done using a budget. We will make a pre calculation of the number of hours we think are necessary and start with that. During the job we need to measure the used budget and compare it with the progress.

Budgeting

The budget is created using the Job Planning Lines. During this phase of the job we do not yet know which resource will be used for the job tasks and it might even be done by more than one resource. This is why we want to use Resource Groups in our budget.

This is not possible in the standard application so we have created a modification which we will discuss at the end of this article.

The Line Type of these job planning lines is Schedule. This means that these lines are just for budgeting and schedule purposes. The system will invoice the actual consumption posted in the Job Journal.

2 | The infrastructure

To use Microsoft Dynamics NAV 2009 Packt Publishing needs new infrastructure.Their current systems do not meet the requirements for Microsoft Dynamics NAV 2009.

For this job we could create new Job Task Lines in the implementation job, but for a clearer overview we will create a new job, EXAMPLE2.

Our company builds and sells its own computer systems. We can build both servers and desktop systems. Because none of the systems are exactly the same and available components switch regularly we do not want to create an item and a bill of materials for each system. Instead we use a Calculation system that allows us to determine a price for a system. For other products like switches, routers, printers, and laptops we use items which we purchase from vendors.

The Job Tasks and Job Planning Lines for this job look like this:

The installation costs in this job are Resource Groups with line type Schedule,just as in the previous job, so we invoice actual hours spent on the job.

The other lines are of type Both Schedule and Contract. This means we will invoice exactly what is in the budget. The job journal lines for these tasks should be posted with a blank line type.

3 | The upgrade

Our customer requests an upgrade from Navision version 3.70 to Microsoft Dynamics NAV 2009. We can do this for a fixed price but we require a fee for analyzing the system.

For this job, EXAMPLE3, we can start with a limited number of Job Task Lines, just for the quote. When the customer agrees to do the upgrade we can add new job task lines.

Both the Quote and the Upgrade are fixed price and posted directly to the general ledger. This does not mean we cannot have our resources to register the actual hours using the job journal but the line type should be blank.

Another part of the upgrade is not done fixed price. The systems needs some redesign, a conversion to SQL Server 2008, and the customer wants additional training and support.

The fixed price part of the upgrade is invoiced in three phases. When the job starts we invoice 50%, when we deliver the test system we invoice 40% and 10% is invoiced three months after go-live.

This is done using lines of Both Schedule and Contract line type.

4 | The support team

For the support team, our policy is to create one job per fiscal year per Customer.We will use this job, EXAMPLE4, for invoicing the maintenance of the license and all support issues.

The support issues can be both little questions customers call us for, such as changing a report or a page, or implementing new features that requires only a few days work.

Each issue and new feature will be created as a job task line. The new features will be created by the account manager who sells the feature. We can then decide if the invoicing is done fixed price, using contract lines, or on time and materials using schedule lines.

Our support team also needs to use the job system, but we do not want them to manually create a new job task line for each support call, and we also want them to view all outstanding issues for all customers easily. For this we have created a new issue registration system which we discuss at the end of this article.

Each issue in the system is linked to a job task. When Support Engineers create a new issue, the job task line is automatically generated for them and they can use it in our time and billing system.

 

Time sheets

For all the jobs in our examples it is critical to have a solid registration of resource hours. In the standard Microsoft Dynamics NAV job application resources need to post a job journal for each combination of Job, Job Task, and Posting Date. This is not the way most people want to register their hours; therefore we have created a Time Sheet application.

Data and transaction model

The Time Sheet application is layered above the job journal line and is created using resources and job tasks.

There is an approval process for the person responsible for the job allowing them to make corrections.

The time sheet is designed to be created for each week. The system automatically generates the week starting date and creates the description. After that the resource can create time sheet lines for each job task line, and populate the number of hours each day of the week.

If we look at this time sheet we can see, after it is updated, that Wednesday is missing two hours.