Currently, xTuple's Project subsystem provides a useful tool for grouping orders, and doing some very rudimentary tracking of tasks and labor - but not much more.  The goal of this effort is to add time and expense accounting to Projects, and improve the overall integration of Projects into the rest of the application.

 

Functional Requirements

The enhancements to Projects will do the following:

1. Create linkage between Projects and CRM Accounts
2. Allow users to enter actual time on a particular Project/Task
3. Allow users to enter actual expenses on a particular Project/Task, tied to Expense Categories and other A/P and Purchasing functionality.
4. Maintain billing rates for resources, markup for expenses per Project/Task
5. Allow users to create an invoice from time and expenses logged against a Project

 

New Terms and Definitions

None

 

Related Existing Functionality

Currently, there are simple numeric fields in Project / Task / Status for Hours and Expenses, Budgeted and Actual, with a calculation under each for Balance remaining:

 

That's about it, I think.

 

Similar and Related Requests

FR #7247 (Add support for Project Cost Accounting):

  - Add ability to create Job work orders for Projects
  - WIP to COGS accounting is manually controlled
  - Support for backdated Labor Posting
  - Add "Project Workbench" for "One stop shopping" to handle Billing and Cost recognition
  - Include Cost+ revenue recognition business rules

FR# 6884 (Add progress billing capability):
Add progress billing capability to xTuple ERP Standard. Billing would be driven by new attributes to Project Tasks and would be released to A/R using the Select for Billing interface.

FR# 5469 (Milestone and recurring invoice schedules)

FR# 6888 (Add project linkage to Misc. Voucher)

FR# 7128 (Ability to Link Journal Entry to Project)

FR# 6889 (Add ability to show/hide closed projects on project search)

 

 

Conflicting Features

None that I've seen.

 

User-Level Functionality

First:  Project will likely be moved out of CRM, and into its own top-level menu item (although this will soon be configurable!)

 

 

 

Window Changes

 

Project main window

• Add CRM Account link under Description on Project header
• Should Billing tab be at Project or Task level?
• Status, Tasks, and Comments tabs largely unchanged

Task main window

• Status tab updated as below:

• Change "Hours" to "Time" and add UOM cluster
• Actual Time and Expenses is now a calculation rathern than an entry field
• If a Budget field is updated, it should write a Comment to the Project "Budget updated from X to Y" and prompt to Save the Task before closing
• The "Add New" buttons should really be "Add/Maintain Time" and "Add/Maintain Expenses"
• Expenses needs currency cluster
• Again, should Billing tab be at Task or Project level?

New time and expense entry screens (rough mockup):

 

• Note:  Should there be a configuration setting for Time entry to choose either Start/Finish time, or just enter Total Time directly?  (Total Time will need UOM cluster)
• Should Expense Categories cover whether or not the expense entered is reimbursable?

Here are two screen shots from Quickbooks time entry.  A weekly entry form (substitute Project for Customer:Job in our parlance):

 

And this other, one-at-a-time entry form, which is more analagous to our shopfloor workbench:

 

 

 

Billing tab (wherever it is) should include:

 

Report Changes

TBA

 

Batch Manager Changes

None at this time.

 

Usability Considerations

TBA

 

Problems and Alternatives

What might go wrong with the solution described in this document?

Why might this not be the best solution?

What are the limitations of this approach? What's missing that might be desirable?

Describe briefly other ways to solve the basic problem and the advantages and disadvantages of each alternative.

Justify the chosen solution or argue why one of the alternatives would be better. Be as broad as possible here, since an important purpose of this section is to provide alternatives in case the initial attempt at implementation encounters a significant implementation block.

 

Internal Design

Now that we have defined what we have to do and how we think it should look to the user, we can describe the internal structure of the application. If possible, outline the architecture of the feature implementation here. Then in the sections below describe the changes and additions to the application to create this architecture.

 

Basic Algorithms

Are there particular algorithms required to implement this feature? If so, describe them here.

If you are going to outline a particular algorithm in pseudo-code
    put it in a programlisting
    try to limit lines to approximately 80 characters
    try to limit programming constructs while still being clear about intent
end if // a programming construct that may be unavoidable to maintain clarity

 

Custom Widget Changes

Do we expect to modify existing custom widgets to support the windows described above?

What new custom widgets will we need? Will they be derived from existing widgets? What behavior do we expect from them?

 

Schema Changes

What changes do we anticipate making to the database schema? New tables? Views? Indexes?

 

The new whatever-you-call-it table

 

What privileges do we need?

 

Stored Procedure Changes

What stored procedures do we expect to create, eliminate, or change?

 

Performance Considerations

How will this feature impact the performance of the application overall?

 

Error Handling

What internal errors do we anticipate might occur?

How can we best hide them from the user, prevent them, or fix them automatically?

 

QA Considerations

Does this feature require any special tools or data to test? Is it testable (some features may be hard to reach from the user level)?

What are some anticipated areas of concern that require special attention?

 

Documentation Considerations

Is there a significant documentation impact?

Does the feature require a standalone essay or only field-level descriptions?

 

Release Considerations

We should build this as a scripted solution first, with the goal of offering it as an xTension Package, and/or in the commercial Editions.  There will likely be some plumbing that needs to go into the core product, but this will likely be after the 3.3 release.  The solution should be fully-implemented by version 3.4.0.