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%n or %u %n which 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).