We have been having some pricing/billing errors lately that I think I have traced to a data entry error which is being allowed by DBA.
 
When entering an item number in DBA, once the line is complete and the user advances to the next line item, DBA will not allow the user to go back and change the item number of that line.  The user must delete the line and re-enter it in order to change the item number.
 
However, DBA will allow the user to change the item number while still editing it during the initial entry.  When trying to research the cause of the error, I can reconstruct a scenario as follows:
 
When a user keys an item number and presses Enter,  DBA populates the rest of the line with the item description and appropriate pricing.  However, occasionally our customer will order something unusual.  My data entry clerk has on occasion keyed the usual item number, pressed enter, discovered the mistake, and arrowed back to the item number and changed it.  DBA, in this case, will not automatically change/update the item description and the price.  The item description can be forced to update by deleting the contents of the cell and entering back through the field which is what I think my clerk has been doing.  However, as we have since discovered, DBA will still not update the price.  Unfortunately, the unusual item sells at a higher price, but we have been mistakenly billing at a lower price due to this glitch in DBA.  If I do not watch the daily order booking report and review the margins, I will not catch it either as my customer's PO does not show the price for my data entry clerk to compare.
 
So, would it be possible to create some logic which will A) get DBA to update the *entire* line if the item number is changed at initial entry time (item description and price), or B) get DBA to not allow the user to change the item number once the item number field has had a valid item number entered into it and then focus has advanced to the next field (sort of like it does now when you try to edit an exisiting SO line)?
 
Thanks!
Chris

David, what dates are your files? I'm running the 6/20 update and mine behaves as Chris describes.
 
I've got a BKSOA.RUN and BKSOA2.RUN both dated 7/1/05.
 
Banner dates are 6/10/0 (not a typo, it says 6/10/0) on the header screen and 5/9/05 on the line item screen.

OK, we got part of it fixed for this update and will take care of the other part for the next one.  If you up arrow and change the part number, the price now pulls in for the new part number.  Description, unfortunately, does not; that will be fixed for the next update.

9/25 update now available does fix the Convert to CAPS problem.  
 
David - please refresh my memory on the Kit Quantity issue.

Quote from Lynn Pantic   on 09/27/05 at 07:02:22:

Type K Items do not get an Original Quantity amount put in.
 
Interestingly enough, the new SO-A no longer displays the Original Qty in the box for it above the line item detail even on non-Kit items, but apparently it does track it, as on non-Kit items it does ask you if you want to change the Original Quantity when changing.