I discovered that for an entry that is less than a dollar that one has to enter it as such: 0.63
The leading zero must be entered before the decimal or QMEM assumes that the entry means that you entered $63.00. QMEM will not accept a decimal as the first character of an entry in the register. I would suggest that you allow a decimal entry without having to enter a leading zero.
Yes, I have entries that are less than a dollar for a category called "Tax: OTC".
Re: Less than a dollar entries Feb 06, 2006 06:04 am
I would
suggest that you allow a decimal entry without having
to enter a leading zero.
I would go so far as to suggest that the current mode of "format enforcement while typing" be abandon for the more traditional "format on field exit" for both value and date fields.
First, it solves the above issue.
Second, it allows a user preference to be added at some point to assume two decimal points for value fields. As a Quickbooks user who has long ago gotten out of the habit of using the decimal point, I almost invariably enter my co-pay value as $1000. <The default should still require use of the decimal point, I'd just like to be able to enter one-zero-zero-zero, and have it interpreted as $10.>
Third, it would standardize the entry of dates. <Anyone else notice that the Insurance Payments:Paid On field is treated differently from the rest of the dates? This is how I would like to see ALL dates behave.>
Re: Less than a dollar entries Feb 15, 2006 11:31 pm
The new QMEM update to v2.1.1.2 didn't address this issue. Please don't forget about it. It should be a very minor fix, but it is an irritation when entering things such as Tax on OTC items.
Re: Less than a dollar entries Feb 16, 2006 01:56 am
The new QMEM update to v2.1.1.2 didn't address this
issue. Please don't forget about it. It should be a
very minor fix, but it is an irritation when entering
things such as Tax on OTC items.
Thanks
Just to warn you, it may not be a minor fix. If they are using a "formatted text box" control <possibly provided by the .Net Framework>, the behavior may be inherent in the control they are using. In which case, they would have to replace the control with a "dumb" text box and do all of the format validation by hand.
On the other hand, I also want to make sure that its known that you are not the only one that is bothered by this. Of course, I'm also bothered by the <not so> "smart" formatting that the date fields try to do.
