The October ’18 release of Project Service focuses on customer-driven enhancements, with practical and tactical functional and usability improvements. Among the enhancements:

• Adjustments to approved time, expense, and journal lines.
• Support for time unit on role price line.
• Ability to make copies of price lists by adding a markup percentage.
• Configurable unit of time for project work estimation to match org unit settings.

Adjustments to approved time, expense, and journal lines

This feature will give the much-needed ability for project administrators to make changes to approved time and expense entries. Most project-based companies set up temporary codes for projects, tasks, and other attributes like work categories and have consultants log time against these interim references until the permanent codes are set up in the system.

It’s also common to reclassify time on a task to another task on the same project or on a different project for the same customer. In a majority of such cases, changing of this reference data will also impact financial postings in the ERP or accounting system. This feature will allow these updates to approved actuals and handle the updates with a historical trail.

Unit-aware expense category pricing for setup, estimation, and actuals

With this feature, Project Service will support a unit–based pricing method for expense categories. This will enable scenarios such as the following:

1. Mileage reporting on projects by traveling consultants.
2. Pricing by project deliverables based on units of work. A number of industry verticals like accounting firms (where tax returns are priced by unit) and BPO firms (where support calls are priced by units of calls processed) will be able to leverage this capability to estimate and track projects costs and revenue closer to their business model.
3. Providing a way to price and cost for subcontracted deliverables as delivery units. When subcontracted work doesn’t need to be tracked at the granularity of time or expenses incurred by the vendor but rather in terms of units of output completed and delivered by the vendor, the ability to model the vendor’s delivery units as a category of expense that can be priced by unit will be a key capability.

Use transaction filters to review invoicing backlog when creating invoices

Project Service creates invoices from all unbilled sales actuals that were recorded on a project. This feature will introduce a view where you can filter actuals using the native XRM filter capabilities and mark the transactions that are ready for invoicing. This will provide better control for the project managers on what gets invoiced to the customer for each period.

Date effectivity validation on price lists

This feature ensures that Project Service users avoid errors in price defaulting arising from having more than one price list effective for a certain date. As Project Service customers are aware, the product allows for multiple project price lists to be associated to quotes, project contracts, and organizational units. This is to allow for inflationary pricing changes represented by price lists with different date effectivities.

With this feature, the system will validate the price list setup to ensure no overlapping date effectivities given a single context such as a project or a contract. Also, the system will ensure that when an estimate on a quote or contract spans multiple price periods, the system is able to correctly price the work.

Resourcing unit currency on role price lines for cost

Project Service allows only one currency per price list, which is specified on the price list header. The price list line for resource pricing has the same currency specified on the price list header. However, for globally operating project service companies that have centralized pricing across all of their divisions across countries, this can necessitate a data-intensive setup where they’ll need to set up a price list for each distinct currency that they sell or incur costs in.

With this feature, Project Service will allow for a line-level currency for resource prices that differs from the price list header currency. Currency on the price list header will be used as a default on the resource price lines. This way, large global firms that would like more centralized pricing setup may work with one global price list that specifies resource prices in many currencies. This could also enable scenarios where prices managed by each resourcing unit come together as one master price list.

Using a single currency per price list will still function, which benefits companies that allow for more decentralized pricing and that track exchange prices for resources. This can be customized so that the resource prices on a price list follow the currency of the price list header.