Content
So I’ve been playing around with cost and budget planning. When I entered some unit costs, and subsequently some labor costs, I noticed that after saving/updating the budget, the Planned Costs column is still at zero. The cost types and/or users all have rates applied to them. For example, Labor: Home Rate is set at $75 (unit Hour) and Mileage: Travel is set at $0.56 (unit Mile).
Is this the intended behavior, is it a bug, or is it a feature that has not yet been completely implemented?
I know that when I am entering this information, there is an edit icon on the Planned Cost field for me to directly enter the planned cost for that line item, but it would seem to me that if I know the number of units (let’s say 966 miles of travel) and the Cost type rate (0.56 per mile) this should be an auto calculation resulting in a planned cost of $540.96 without requiring me to enter that in manually.
Additionally, I would expect that anytime I enter estimated hours in a work package that this could be added automatically as a planned labor cost.
The end result would be the ability to quickly set up a complete project with a good guess at a budget (or a few budgets) without having to do all the math by hand.
Replies (4)
Hello Mike,
thanks for your question.
May I ask which version of OpenProject you are using?
I followed the steps you describe (creating two cost types, setting rates for each of those and assigning them to a budget) using OpenProject 3.0.14 and the sums were displayed automatically:
Could you verify that the rates are displayed properly for the defined cost types (in “Modules” > “Cost Types”)?
Using OpenProject 3.0.14 (mysql2), Costs plugin 3.0.14. Testing in “production” environment. Running on Ruby v2.1.0.
I tried this again with a brand new budget, and it now appears to work starting from scratch. (The sums are automatically updated when the unit values and type fields are changed/updated.) I did not notice this happening before, so I am going to investigate further and see if I can now reproduce the behavior I described earlier and post an update.
Thanks, Robin.
(Incidentally, attached is my list of my definitions as listed in Modules > Cost Types.)
I think I found the problem… Or at least part of it. In my initial setup of the Costs plugin (Modules → Administration → Plugins → OpenProject Cost → Configure), I had altered the way the costs were displayed. I set the Currency field to a dollar sign ($) and then changed the Format of Currency field to
%u%nor%u %nwhich would result in something like “$125.00” or “$ 125.00”— which is a more typical format for domestic use in the US.I dug into the Javascript code for the Edit-In-Place editor. The problem with my setup is that it appears the Javascript search expression assumes that the currency symbol will always be to the right of the numeric value (such as “125.00 USD”, “750.00 EUR”, and “910.50 CHF”.) When I click the “edit” button and manually edit the number, the currency unit becomes part of the field value which upon submission, results in no conversion from a string (“$125.00”) to a float. (i.e. 0.00)
It appears that the system is smart to remember that if the Planned Costs field was in edit mode on submission, then it will be in edit mode when you go back to update the budget, and once the form loads it will have the bad value in the field. If you never change it (e.g. you are updating some other line item), as long as bad characters (currency symbols) are in the field, you won’t get a proper number conversion and end up with a 0.00 after submission.
I wondered if this had also broken the auto-calculate feature too, but it appears that as long as the Planned Costs field is in non-edit mode, the auto-calculate still works fine and will submit the values properly. I was fairly certain that in my previous example this was not the case, but I have not been able to reproduce that behavior, so I could have been mistaken.
So for now, I will keep my Cost Format in the form of
%n %u, although this may not be the desired case for everyone, and certainly the ISO 4217 standard allows for currency codes to be placed as either prefix or suffix.I have the same issue. I prefer to have %u%n, but am forced to have it the opposite way. Please allow either order. It would also be nice to not display any the cents (decimal point & 00).