One of the things that true project accounting professionals love about Dynamics SL is that the software has not one by many project accounting modules.
There is a module for time and expense as expected, there is a module for creating customized billings by project, there is a module to track goals against utilization goals, and there is a module to track multiple iterations of project budgets rather than simply the original project budget and current budget.
These modules set Dynamics SL apart as a superior project accounting solution as does the software’s design of project-related prompts through financial and distribution modules as well.
One of the truly unique modules within the Dynamics SL project series is the Project Allocator module. Jon Augdahl, our Dynamics SL Practice Manager, described the module best when he said “it’s really more of a project transaction creator than a project transaction allocator”.
For example, the Project Allocator module can create markups on inventory used on a project to cover some of the overhead required for buying and effectively getting the inventory onto the project. Profit can be built into, not only inventory, but other expenses on an agreed upon basis with the client so that transactions are created based on labor, transaction volume, inventory issues to a project, or even statistical items such as head count on a project.
Transaction units, flat rates, and dollar amounts can all be the basis for transactions being created. Start dates and end dates can be put into consideration so that markups to clients can only exist during the planned calendar date of the project-meaning that if the project takes longer, markups are removed. This can be a selling feature for a client who values very much on-time projects.
Project Allocator also pays attention to a “Bill to Maximum” configuration setting in project accounting. This means that allocator will not continue to create billing transactions once the contract value or billing maximum has already been reached.
Need your transactions to be created across companies? No problem-that too can be configured here.
Many of the fields from the source transaction are written to the allocated transaction. The following is a list of these fields:
• Source Account Category-stored in PJTRAN.data1 (an account category in Dynamics SL is a chart of accounts for operations people that are not used to dealing with gl account numbers.)
• Comment
• Vendor
• Transaction IDs
• Labor Class Code [stored in tr_id05]
• Employee
• Subaccount
• User Fields [stored in the corresponding user field]
• Transaction Date
In addition, the fiscal period number, system code, batch ID, and system-generated detail number of the source transaction are concatenated and stored in the field of the allocated transaction.
Here is what the screen looks like. As you can see the transactions can be created in a preliminary mode-which helps greatly in ensuring the transactions created are the transactions you intended to create.
So if you are evaluating project accounting options, please consider Dynamics SL for truly robust project accounting functionality and integration with financial and distribution modules. Having a module to create the transactions that you would normally have to compute in a spreadsheet and key in as either a journal entry or a project transaction is an added plus and a big convenience too.
