Hi Lubos,
Billable time entered 2 hours and 50 minutes at a rate of € 60,-
To be invoiced shows an amount of € 170,- which is correct.
On the invoice appears the following:
which is not correct. Can you please fix this bug
Hi Lubos,
Billable time entered 2 hours and 50 minutes at a rate of € 60,-
To be invoiced shows an amount of € 170,- which is correct.
On the invoice appears the following:
Sorry but this is not a bug. You should use as suggested by @Mark for Qty 170/60 which will give a long string of 2.8333333333. If you multiply that with 60 you will get 169.99999999
The problem with both @Mark’s and @eko’s suggestions is that they require you to know in advance what the extended value of the billable time will be. The problem itself originates with the fact that Manager calculates (and displays) a decimal equivalent (in hours) of the HH-MM time input, but rounds that to two decimal places.
I also do not think this is a bug, however, because the software performs as designed.
Think about whether this is really an issue, though. The customer sees an invoice billing for 2.83 hours with correct arithmetic. Only on the Billable Time entry screen does 2 hours 50 minutes show. And would this even have been noticed if the rate was, for example, 37.50? It became noticeable only because the rate was an even multiple of 1/60 of an hour—or €1 per minute.
How many organizations actually record and bill time to the minute? Not many. Those that do (or their accounting programs) almost invariably convert to decimal hours for billing calculations.
A solution is to round decimal hours with higher precision. But you would have to display the higher precision or customers would not be able to reproduce the math. Four decimal places would be enough for two-decimal currencies. But is that overkill?
You would be surprised, Many consultants from law firms, public relations agencies, etc actually bill by the minute. This is favoured by the clients as in essence it is perceived to reduce costs and thus enhance efficiencies.
I also wonder if 2.83 hour is easier to understand than 170 minutes or 2 hours and 50 minutes. I would break my brains to figure out how many minutes that 0.83 really is, a quick calculation 0.83*60=49.8 and not fifty, so rounding is the culprit.
Having said all that, there is obviously an issue, but I do not think this is a bug nor do I think there is an easy fix.
Usually, however, in minimum “blocks” of minutes, such as 6 (0.1 hour) or 15 (0.25 hour).
Sorry, I diasagree with @Mark and @Eko. You probably don’t use the tab Billable Time.
Hours and minutes and rate is what you need to enter in the module Billable Time. Not Quantities. When you click create new sales-invoice you expect the program to create an invoice with the data you entered. You don’t expect that it converts time to decimals. You also don’t expect the program to “change” the billable amount of € 170.00 to € 169.80 because of the conversion
I also disagree with @Tut.
The software doesn’t perform as expected. I expect the Sales-invoice to be € 170.00- and not € 169.80.
And I expect it shows 2 hours and 50 minutes. So in my opinion it is a bug.
The question how many organizations actually record and bill to the minute is irrelevant.
As @ Eko writes many consultants from law firms, public relations agencies etc. bill by the minute. I’ve seen hundreds of those invoices in my career.
This is a mismatch between sales invoices having quantity as single decimal number and billable time being hours/minutes.
There are two solutions:
Qty
field on sales invoice at all. We simply state time spent on invoice line description.I’m not sure which one is more desirable.
A user setting to specify billable time is converted in invoices into units of either
I would recommend @lubos’ first option, stating hours and minutes in the description.
People do not customarily make conversions of hours and minutes to decimal hours. Unless their practice is to record time in conveniently sized “blocks” of minutes as I mentioned previously, how will they know what to enter?
For even a simple case of 20 minutes of work, 0.33 hr is not precise enough. For example if a lawyer bills $300/hr, the client will expect to pay $100. But the calculation would produce $99. You would need 5 decimal places in the time entry to produce a rounded billable amount of $100.00.
Granted, many users could remember 0.33333. But now suppose the billable time moves to 23 minutes. Who can remember 0.38333?
The program, on the other hand, can easily convert 20 or 23 minutes to a fractional hour with much greater precision than necessary, even for 4-decimal currencies. Let the description be what people understand—hours and minutes—and the internal calculations be accurate, but invisible. A customer checking the math will confirm the same amount as displayed.
A human brain calculates in hours and minutes, not decimals. Therefor I suggest that we record hours and minutes in billable time and that the program converts it to decimals, as long as the result on the invoice is exactly the same as displayed at billable time. I think option 1 is more desirable.
My personal “hack” on this is to just set the “hourly rate” box to my “per minute” rate, and then only use the hours. If the math is too hard that day, I’ll type in (3*60)+22 and make manager do it for me.
Mainly because the rounding error is customer facing, I do agree that it should be resolved, but this works for me until it is. It has been brought up pretty regularly since 2015, and even if you can convince the manager user to accept it, they then have to convince all their customers to do so as well.
Attorneys typically bill by the 1/10 hour. What I’d like to see in the Billing module accept ether whole hours and minutes, or fractions of an hour. This seems like it would satisfy everyone and be easy to code. For example billing at $350/hour the same time could be entered:
Hours Minutes
1 12
= $420
or
Hours Minutes
1.2 0
=$420
However, currently if I enter 1.2 hours into the hours field, the resulting calculation is $350 as if I had only entered 1 hour into the hours field.
This is the least desired behavior because it doesn’t even catch an illegal entry, it just silently calculates the wrong number.
@Mark It’s about the edit screen of billable time:
So why not enter minutes as the lowest unit of measure and bill 170 minutes @ $1 per minute = $170
I’m in the Billable Time module, Desktop version 24.4.12.1431. I’ll reiterate that it is very undesirable behavior to accept a decimal hour entry into the hours field, give no error message, and silently round down to the hour. It is very instinctual to attorneys to think in decimal hours, and quite natural to enter “1.2” into an hours field.
My preferred solution solution is that the software accept either hours and minutes, or decimal hours. However, it is critical that it warn of illegal entries which silently round down, losing the business money in the process!
The lowest denominator is minutes, Why not use it as such everyone know 60 minutes is an hour. So if someone used 6 hours we all know it is 360 minutes.
That is a kind of workaround. But as lawyers typically use tenths of hours, 5.2 hours is natural way of thinking of it, and is easier than doing the mental math 5*60 + 12 = 312 minutes.
In PR consultancy they charge by the minute. I am not against any system but when things become pretty variable the default should be the lowest denominator and I believe that minutes are that. Although in Formula 1 it seems hundreds if not thousands of seconds
Which is not to say that it is a correct method.
In my opinion, the legal profession makes their extra money very easily that way.
Of course, they can very easily enter minutes instead of tenths of an hour, as apparently in PR consultancy.
But yes, with 13 minutes of work, that does mean they can “only” bill 13 minutes instead of 3 /10 of an hour (18 minutes).
While there’s absolutely nothing wrong with that approach, the problem is it’s not the only way of charging. Any improvement to Manager need to focus on solutions which work for most people.
Having said that, I’m not sure why hours with a decimal point is truncated rather than converted into minutes