Re: [Gnumed-bugs] Sufferable bug, billing

[Busser, Jim]

On 2013-10-01, at 1:10 PM, Karsten Hilbert <address@hidden> wrote:

> On Tue, Oct 01, 2013 at 06:53:20PM +0200, Karsten Hilbert wrote:
> 
>>> When billing using the Add button, and after
>>> having inputted an "item" (fee code), the corresponding "Value"
>>> is correctly looked-up however if the user alters 
>>> what was entered in the "Item" field and even despite that
>>> they hit "return" or "enter" there is a failure to refresh.
>> 
>> I have looked at the edit area and it seems to behave
>> quite like any other.
>> 
>> What is your expection of what should happen upon hitting
>> return/enter ?
>> 
>> This is not a search field. It is a suggest field. It
>> auto-searches. If it doesn't show matches it did not find
>> any (or is broken). There's no place for return/enter in
>> that scenario. There never has been with any of the
>> phrasewheels.
> 
> Ne'ertheless I have now made the phrasewheel empty out the
> amount field should the bill item field be modified.

Thanks, but maybe it is I who is unclear. Where (above) you explain "This" is 
not a search field, are you referring to the "item" field or the "amount" field?

What I was observing was the case where

- I have inputted a value into (let's call it "item 1") into "item"

- an auto-search occurs … here I am not sure whether you are referring to 
auto-searching for a match on "item 1" or a corresponding (related) financial 
amount but in any event, provided that what I entered into "item 1" is an 
existing item with a corresponding, related financial amount, that amount 
displays automatically. Maybe you are referring to this as the "suggested 
amount"?

- at this point, without my either committing or cancelling the transaction, I 
recognize that I had inputted the wrong item code, and I alter the value of 
"item 1" to be "item 2" and I then I then hit return, and observe no change in 
the "suggested" amount despite that "item 2" is likewise an existing value with 
a related "suggested" amount already defined in the database.

Thus I was imagining this a sign of a problem, because there *does* exist, in 
my database for item 2, a reference amount, and I could not understand why the 
same procedure as caused "item 1" to cause the "reference amount 1" to be 
displayed would not, upon the user altering the value of "item 1" into "item 
2", cause a new lookup.

-- Jim

signature.asc
Description: Message signed with OpenPGP using GPGMail