Unhandled exception has occurred when recalling recurring transactions using Sage 50 CA 2017.2

It has come to our attention that after customers install the latest update, Sage 50 CA 2017.2, they may receive an unhandled exception error when they recall a recurring transaction and use their keyboard to get to the record they are looking for. We are working on a fix for this error, but have created knowledgebase article ID 84693 that has workarounds for this error message.

Parents
  • Well they fixed it.   Somewhat with release 2018. You can at least hit a letter and it will take you to the first entry, however, when you have multiple recurring entries that start with the same letter, you will have to arrow or use your mouse to get to the next one.   You can not continue to hit the letter to move to the next entry.

    Sage, If you are going to fix it,  Fix it right the first time.

  • in reply to LAP

    The type-to-find has actually been fixed to work like a normal type-to-find field everywhere else.  Instead of hitting SSSSSSSSSSSSSSSSSSSS I will be able to type 'Sage S' to put in the renewal fee for Sage Software.

  • in reply to RandyW

    Okay,  How about 4  different variations of one vendor/customer.   HLS - ?  I think typing H in that case would be much easier then HLS as they are not all together... 

    You are not going to please everyone so let the masses decide how they want it to work, or even better give us the option in settings?

    So I vote for the way you have had it setup for the last 20 years!

  • in reply to LAP

    As Randy noted, when fixing the function the decision was made to make the search function more consistent with other areas of Sage 50 with multi-key searching. 

Reply Children
  • in reply to KathleenF

    Kathleen: 

    That upsets me.   Your reply tells me Sage does not want feed back from the end user.....   

    Have a good day!

  • in reply to LAP

    We absolutely do value feedback from the end user. I reached out to the development team with your question in order to get the answer from them. I would recommend submitting your suggestion to our Ideas page which allows other users to vote on it.

  • in reply to KathleenF

    And did your development team talk to the end user's before proceeding, or did they just make the "decision" to change it?    The census that was on this page was everyone wanted it to work the old way.   So before you make changes to the way we use the program with its little quarks.....  ASK!

  • in reply to LAP

    Why bother? For years the Accountants in their "Network" have been asking for changes - none are ever implemented as Sage rides the cash cow that is this program. Fair warning. Don't expect much. Functionality in 2017 is only very little changed from 2008. (But they keep collecting "development" fees.)

  • in reply to LAP

    LAP said:
    we use the program with its little quarks.....

    I think you meant 'quirks', unless you're playing on the word 'Quantum'.  

    And KathleenF probably meant 'Function' unless she's playing on another word we use a lot here in the oilpatch. 

    All software should be consistent with the functionality of its underlying platform or computers in general, with shortcuts like control-c and control-v working the same in every software package using the interface.  Where there is no convention, software developers should be creative.  Here, there is a convention - type-to-find fields have been in software from before the early days of DOS TurboVision.

    Some of those endearing quirks that you are used to may be chafing someone else.  We have 58 recurring sales orders starting with 'P' and 129 starting with 'T'.   And 1,756 item numbers that start with 'F'.   For us, pressing 'T' 100+ times is never going to be better than typing even a dozen characters, or pressing 'T' and using the arrow key, and pressing 'F' a thousand times is obviously hopeless.  

    I'm not interested in writing training materials that explain three ways to find an item in a list, depending on which  screen it's in, even if one of the ways is a little better in some circumstances.  We're going to take the opportunity to improve our recurring transaction naming convention for a little more efficiency. 

    And I'm posting a suggestion that anywhere there is a searchable type-to-find list, the screen should display a search window, as in the order entry's Item Number, Item Description, Account, and Project fields. 

  • in reply to donhobs

    donhobs said:
    none are ever implemented as Sage rides the cash cow that is this program.

    If I thought my clients were going to freak at the tiniest change that's meant as an improvement, I'd stop making changes too.

    And there hasn't been NO change.  There were a flurry of useful improvements in about 2011, and some tweaks and fixes since. 

    But yeah, most everything in the last 5 years looks to have been to disable advanced features and make sure we had to keep paying to keep working.  Squeezing the peasants, in other words.

    donhobs said:
    But they keep collecting "development" fees.)

    I think they need that money to move to an online SAAS model, the perception seems to be that desktop software in general has become obsolete.

  • in reply to RandyW

    I also said this Randy. 

    You are not going to please everyone so let the masses decide how they want it to work, or even better give us the option in settings?

  • in reply to LAP

    According to  https://en.wikipedia.org/wiki/Incremental_search type-to-find was first developed in the 1970's and is widely used.

    I haven't seen Sage's repeat-the-first-letter method used anywhere else, and I've always assumed it worked that way because it was just broken - i.e. the timeout for starting back at the beginning of the string was shorter than a human could manage on a keyboard.  

    If this is not a system object then there should be a setting in the software.  It would probably have to be one setting - I can't think it would be feasible to put a separate setting for each of hundreds of dialog boxes in the software though.

  • in reply to RandyW

    Sir.  

     

    You obvious have a lot of programming experience and what little programming I have goes back to the Vic-20. 

     

    You are doing a wonderful job of supporting this change.  I will give you credit. 

     

    However the error in programming that you call it, has not been a high priority on Sage's nor ACCPAC's fix it list as it has been there a long time.  

     

     I can and have express that I am disappointed with how they decided to fixed it.  It may be more functional for you but this change does not work for me and may not work for others. 

     

    I can and have made suggestions on how to make all parties happy though you think it is not plausible. 

     

    I have also acknowledged that not all parties will be made happy in the end.

     

    I did suggest that the End Users be asked for their input as they are the ones who use it on a daily basis. 

     

    So sir in conclusion,  if you still disagree , then let's agree to disagree.  

     

    AGREED?

     

     

    Regards.

  • in reply to LAP

    LAP said:
    You are doing a wonderful job of supporting this change.  I will give you credit.

    I don't work for Sage, so it's not my job.  Supporting this mishmash for clients and other users is my job.

    LAP said:
    I did suggest that the End Users be asked for their input as they are the ones who use it on a daily basis. 

    I certainly do agree with you that end users be asked more for input. 

    Obviously, none of us were asked if it would be OK to have that dialog box crash at the first keystroke.   Had Sage done a staged rollout of a .0 release as they have done in the past, the problem would likely have been caught before the first wide release, and before a forced update to keep payroll current. 

    Sometimes 'put it back the way it was' is just not possible.  Maybe they used third party vendor software components that are no longer supported, or perhaps the way they programmed that dialog is incompatible with some other parts.  Or it was just one more different way of doing things that took extra time.  I can't know, I only guessed at why.

    I've submitted my input literally hundreds of times.  Some of those bug fixes and improvements have been implemented.

    Some aren't - there's easily a half-dozen bugs in the Inventory Adjustment screen. 

    Entering a purchase return (negative quantity) in a foreign currency often rounds the dollar amounts strangely so it's impossible to enter without allowing negative inventory, so I process a stack of these at day end in Single User Mode. 

    The font choice, and font size for the invoice screens is so bad it's just... unfathomably stupid.   If only we could use the 2007 software with the 2018 data back end and payroll.

    Editing a text descriptions in an invoice screen is just painful.  Trying to get the cursor into the right position while it's redrawing and refreshing failed inventory lookups makes it a bad version of Centipede.  Sage sales people should have to use the Sage 50 invoice screen to send renewals.

    When 'User supplier item numbers...' (Quantum) is checked on a Purchase Invoice screen, the cursor shoots off to another column when inserting a line.  Or gets stuck in a kind of phantom zone between columns.

    The additional payment methods attached to vendors should have been made optional - i.e. 'not selected' should mean 'keeps working like it used to'.

    Inserting and deleting a line should be possible with a hotkey.

    LAP said:
    So sir in conclusion,  if you still disagree , then let's agree to disagree

    We too, are stuck with whatever new challenge Sage serves up each October.  If not for payroll updates we would have stopped updating at late 2012 to keep from losing Crystal Reports forms.    In comparison nothing added since is worth half a pinch of sawdust. 

    I think we agree that Sage should not have uncorrected bugs for most of a year.  In any case I'm not sure that what we think matters as much as it should, to Sage.  We still disagree on whether this one thing should stay the same, and that's OK.